"Simple Made Easy" - Rich Hickey (2011)

ClojureTV · 434K views · 2021 · 1:01:39

Open on YouTube

Software architecture & designFunctional programmingtalk

Why Hacker News recommends it

It is one of HN's most frequently recommended programming talks, cited whenever people debate complexity, simplicity and abstraction, and valued well beyond Clojure.

What it is

Rich Hickey's Strange Loop 2011 keynote separates 'simple' (not intertwined) from 'easy' (familiar or near at hand) and argues that software complexity comes from complecting things. It offers a vocabulary for judging designs and abstractions.

Recommended by 9 HN commenters across 8 different months, 2021 to 2026.

What Hacker News said

Strong rec elamje · 2021-10 · on “Ask HN: Programming talks that made something click for you?”

Simple Made Easy ( [this video] ) The Language of the System ( [LINK] ) The Value of Values ( [LINK] ) All by Rich Hickey (Clojure creator) - strongest programming speaker I've found to date.

Strong rec loudmax · 2022-06 · on “The collapse of complex software”

I highly recommend Rich Hickey's "Simple Made Easy" talk as a way to think about software complexity. We all know that complex systems are hard to work with, but I've found his presentation very useful in understanding the nature of complexity. Understanding complexity helps being able to avoid or minimize it. For example, easy is not the same as simple, and simple changes to one part of a system can introduce great complexity at the macro level. [this video]

Strong rec xiphias2 · 2023-02 · on “Do the Simplest Thing That Can Possibly Work (2004)”

Actually Rick Hickey's talk ( [this video] ) is amazing because he talks about your case by going back to the original meaining of words: ,,Complex comes from the Latin complecti, which means “to entwine around, to embrace'' Simplicity requires layering, so in your examples the main requirement for simplicity is about how intertwined your hobby project is with the transciever code or ethernet code. As long as the abstraction layer works well for you without getting too much into the details of the implementation, it's a simple solution. Of course it's not a clear answer whether you should do things yourself or use a third-party, but if the third-party works perfectly for use case without signific

Strong rec funcDropShadow · 2023-11 · on “Push ifs up and fors down”

This doesn't sound like a simple solution from your fellow devs. It appears to have been an easy solution. If the distinction isn't familiar to you, there is a great talk of Rich Hickey [0], that explains that distinction and some more. The talk is definitely not only applicable to Clojure. YAGNI is a great slogan, but must not be a dogma. If you already know, that you are going to need custom rules. Then prepare for it. But, if --- for example --- the current rules are almost trivial, and you don't know yet, which rule engine will be the right fit later on. Then it might be a good idea to postpone the decision about the rule engine, until you know more. In the meantime a hard-coded solution

Strong rec yooogurt · 2025-12 · on “Rich Hickey: Thanks AI”

If you haven't heard of Rich Hickey, then you're fortunate to have the opportunity to watch "Simple Made Easy" for the first time: [this video]

Recommends frogulis · 2022-06 · on “Revisiting the principles of data-oriented programming”

Rich Hickey's talks "Simple Made Easy" [1] and "Effective Programs" [2] provide a better explanation of these ideas IMO. The specific definition of "simple" is pretty crucial. [1] [this video] [2] [LINK]

Recommends liveoneggs · 2023-10 · on “Can't Be Fucked: Underrated Cause of Tech Debt”

take it up with Rich Hickey I suppose :) If you've never watched Simple Made Easy I really recommend it: [this video]

Recommends delaminator · 2026-02 · on “Ask HN: In the Age of AI, How Do I Grow as a Software Engineer?”

> Claude can make decisions about architecture but they are often not very good decisions, and sometimes absolutely terrible I have to kick it back onto the right track, but as you sort of point out, I got that experience from making my own terrible decisions and finding out the hard way the blind alley I was walking up. Second system, inner platform, too general, planning for scenarios that never happen, stuff that doesn't scale - I've made them all. I think I learned as much from reading as doing though, I could later put names on the mistakes I made. So, for what it's worth - study the meta. Read about architectural theory, system design Study the craft and listen to the masters - [this video]