Rich Hickey

The skill today is technical depth. Not knowing more tools. Not passing harder interviews. Something quieter — and considerably more expensive to build.

Technical depth is the ability to think clearly about what you are building before you build it. To ask not just how do I implement this, but does this need to exist at all — and if it does, what is the simplest true version of it?

Here is the one idea this entire session is built on. Simple and easy are not the same thing. Most engineers treat them as synonyms. That confusion is one of the most expensive mistakes in software. And it shows up not just in code but in systems, org charts, processes, and the decisions technical leaders make every day.

Simple means few connections. A simple thing does one job. It doesn't reach into other things. You can understand it in isolation. Easy means familiar. Close to hand. Accessible. Easy things feel like simplicity because they require little effort to start. But ease is about you — your background, your comfort zone. Simplicity is about the artifact — its actual moving parts, its surface area, what it touches.

That distinction is what this session is about. We're going to learn it by breaking it into its smallest practicable piece, removing the emotional friction that keeps most people from practicing it, learning the signal that tells you when you've drifted, and spending time with one person who built his professional reputation on doing this right.

Here is the Josh Kaufman framework applied to this specific skill.

The smallest practicable piece of technical depth is this. Once a day, look at something you've built or are about to build and ask two questions. First: what complexity here is forced on me by the problem itself? Second: what complexity did I add? Those two categories have names. Inherent complexity — the kind the domain genuinely demands. Accidental complexity — the kind you accumulated because a library was handy, a deadline was short, or no one stepped back to ask why. Just that. Just the habit of separating the two, consistently, until the separation becomes instinct.

Now here is why most engineers don't actually get better at this — and it is not what you expect. The problem is not intellectual. You don't get stuck on technical depth because you lack the intelligence to see complexity. You get stuck because naming your own accidental complexity feels like naming your own failure.

When you've spent three days building something, it looks like progress. It looks like craft. Calling it complicated feels like calling your own work bad. And in most engineering organizations, complexity is quietly rewarded. More code means more output. More abstraction layers means you're architecting. A sprawling system means you were doing something important. The person who proposes a simpler solution in a design review can look like they're undercutting the team's effort — or suggesting that last week's work was unnecessary.

Here's the thing nobody says plainly: the simpler answer is usually the harder one to reach. And almost always the harder one to defend. The discomfort is not a sign that something is wrong with you or with the approach. It is the gap between what is easy — familiar, comfortable, already in the library — and what is simple — genuinely uncoupled, genuinely small. Naming that discomfort before you sit down to work is most of what it takes to move past it.

Now the signal that tells you you're drifting. Watch for this specific feeling: explaining why something is hard. When you find yourself saying yes, this is complicated, but that's just how distributed systems work — when you're managing the complexity rather than questioning it — that's the signal. Genuine technical depth makes you more allergic to accidental complexity over time, not more comfortable with it. The moment you're defending the tangle rather than trying to dissolve it, you've stopped practicing the skill.

And now the person who built a life out of all of this.

The Story

Rich Hickey is not a household name outside software engineering circles. He has never given a keynote at a CEO summit. He does not have a bestselling book. But in 2011, he stood on a stage at a conference called Strange Loop in St. Louis, Missouri, and gave a one-hour talk called "Simple Made Easy." In the years since, that talk has been watched and rewatched by hundreds of thousands of engineers. Not because it introduced a new tool. Because it named something that had been murky and uncomfortable in the field for a long time — and it named it with the precision of someone who had spent years being specifically bothered by it.

To understand why the talk landed the way it did, you have to start a few years earlier.

Hickey spent most of his career as a consultant. He was experienced and capable, fluent across multiple languages and platforms. Through the nineties and into the two thousands, he worked across industries — financial systems, scheduling software, enterprise tools. He was good at his job. And he had a persistent unease he couldn't quite shake.

The languages he worked in — primarily Java — were easy. Easy in the exact sense of the word: familiar, well-documented, with large communities and libraries for everything you might need. Starting a project in Java in the mid-two thousands was about as frictionless as professional software development got. And yet the systems he built kept accumulating weight in a specific, recognizable way. Threads and shared mutable state — code that was perfectly clear in isolation but required you to hold the entire system in your head to safely change any part of it. The complexity wasn't usually in the problem. It was baked into the approach.

Around 2004 and 2005, Hickey made a decision that most working consultants don't make. He went back to study — not to a university, but in the way that matters. He spent serious time on the history of programming language design. Not the recent history. The deep history. He went back to Lisp, the language originally designed at MIT in the late 1950s, and tried to understand not just what it was, but what its designers had been reaching for. He read papers from decades earlier. He thought slowly. He followed threads for weeks.

He was still working. He still had clients. He still had bills. This was not sabbatical time. This was thinking carved out of evenings and early mornings, sustained alongside a full professional life. And what he was chasing was an answer to a question that sounds almost too simple to matter: why do systems become hard to change?

He came to a conviction. The way most languages handle state — allowing any piece of code to reach in and modify shared data at any time — was not just inconvenient. It was a compounding source of accidental complexity that no amount of developer discipline could permanently tame. You could write careful code. You could do careful code reviews. You could build elaborate testing suites. But the tool itself made the problem invisible until it accumulated to the point of crisis. And then it was structural. Expensive to change. Not because the engineers had been careless. Because the model they were working in made carefulness insufficient.

He built something different. He called it Clojure. He designed it as a dialect of Lisp that ran on the Java Virtual Machine — meaning it could use Java's vast ecosystem and run wherever Java ran. But its core decisions went against the grain of everything easy. Data structures were immutable by default. State changes were explicit and controlled. Functions didn't hide side effects. None of this was familiar. None of it was close to hand for the Java developers who would need to learn it.

He released the first version in 2007. For a couple of years, adoption was slow. He kept refining it, writing, thinking, explaining the underlying reasoning in blog posts and talks. And there were stretches in those years — quiet stretches, where the work was building and the feedback was thin — where the question of whether anyone else actually saw the problem the same way he did was a real question. Not a crisis. But a real question.

Then in 2011 he gave the talk.

"Simple Made Easy" is structured as a philosophical argument, not a tutorial. Hickey starts by separating the two words with the precision of someone who has spent years being bothered by their conflation. Simple is an objective property of an artifact. How many concepts does it involve? How many other things does it reach into? Can you understand it without understanding something else? The fewer the connections, the simpler the thing. Easy is a subjective property about the person encountering it. How familiar is this? How close is it to what I already know?

He introduced a word he had pulled from archaic English: complect. To complect means to braid or interweave. And he argued that most of what makes software hard to change is not the inherent complexity of the domain — it is things that have been complected together that had no reason to be. Business logic braided into framework concerns. Data structure choices baked into application behavior. Test assumptions tangled with deployment details. Every time you add a dependency you haven't thought through, you are complecting. Every time you let two things share state because it was convenient, you are complecting. And complected things are not just hard to change. They make the people maintaining them feel, over time, like the complexity is natural. Like it was always going to be this way.

The audience was experienced engineers. These were people who had been writing production systems for years. And the talk has a particular quality you notice when you watch it — the kind of attention that comes when someone names something you have spent a career feeling without being able to say.

What Hickey was offering was not a tool to fix the problem. It was a way of thinking — a diagnostic lens you could bring to any system, in any language, on any team. Before you reach for the library, ask: does using this braid together things that should stay separate? Before you add the abstraction layer, ask: does this reduce inherent complexity, or does it just hide the accidental complexity I've already built? Before you argue that a system is just naturally complicated, ask: is it complicated because the domain demands it, or because my choices made complexity invisible?

The talk did not age out. Fifteen years later it is still shared in engineering team channels when someone is trying to explain why a codebase has become hard to move. Not because Clojure conquered the world — it didn't, it remains a niche language adopted by a committed minority. But because the underlying thinking applies regardless of your language, your platform, or your era.

What those years of solitary study modeled was something specific. The practice of sitting with a hard question long enough to actually reach its bottom. Not looking up the answer in a library. Not asking the most senior person in the room. Sitting with the question — for weeks, for months — until you understood what was irreducible about it. What was genuinely demanded by the problem, and what was a consequence of previous choices.

Most engineers have a word for what they do instead. They call it being pragmatic. And sometimes pragmatism is exactly right. But often, what engineers call pragmatism is a quiet preference for the easy over the simple. For the familiar over the genuinely clear. And over years, in a codebase, in a team, in an organization, that preference compounds.

The Skill

The principle from this story is stated plainly: technical depth is the practiced habit of separating the complexity a problem demands from the complexity you have accumulated — and finding the will, regularly, to question the latter.

This matters more at the leadership level than at the individual contributor level. Not because clean code matters less when you're senior. But because at the leadership level, complexity is structural. A technical leader who consistently chooses what is easy over what is simple doesn't just write complicated code — they model a way of thinking that propagates outward. They build teams, processes, and architectures that treat accidental complexity as normal. They create systems that only they can navigate, and that fragility looks like expertise until something breaks at the wrong moment.

The leaders who stay genuinely sharp over decades — not just productively busy, but actually sharp — maintain this allergy to accidental complexity. They don't let a fast answer become a permanent decision. They ask, regularly: what is this thing actually doing, and is that what it needs to do?

In an era where AI generates code on demand, this skill becomes more important, not less. AI makes the easy path dramatically easier. In ten minutes, it scaffolds a working system. In thirty, something quite sophisticated. But it cannot tell you whether what it's building is simple in Hickey's sense. It cannot tell you whether you've asked the right question, decomposed the problem correctly, or avoided coupling things that have no business knowing about each other.

The person who asks AI to design the system is building a muscle for prompting. The person who does the hard conceptual work themselves — who deconstructs the problem, identifies what's irreducible, decides what the moving parts actually are — and then uses AI to accelerate the implementation, stays sharp. They're using a faster tool to run a race they trained to run. The distinction sounds small. Over years, it is enormous.

The signal this skill is working: you start having slower, better design conversations. Not because you know more, but because your questions are cleaner. Not how do we implement this, but what does this actually need to do — and what does it definitely not need to do?

Do This Today

Pick one piece of code or one system you're currently working on — something you know well. A service, a module, a workflow, a schema. This afternoon or this evening, before you close your laptop, set a timer for twenty minutes.

Open the thing — in your editor or in your head — and ask one question: what here is complicated because the domain demands it, and what is complicated because of a choice I made? Write down one specific example from each category. You are not trying to fix anything today. The action is specifically about the diagnostic muscle — training yourself to see the two types of complexity separately, as distinct things.

When the twenty minutes end, you are done. If you want to pressure-test your own analysis, ask an AI to list potential sources of accidental complexity in the same piece of code, then compare its list to yours. The places where you disagree are exactly what's worth sitting with next.

The action is complete when you have two written examples — one inherent, one accidental — sitting in a note with the date on it.

Sources

• https://www.infoq.com/presentations/Simple-Made-Easy/ — Rich Hickey, "Simple Made Easy," Strange Loop 2011, recording and transcript via InfoQ
• https://clojure.org/about/rationale — Rich Hickey's own written rationale for Clojure's design decisions, including the role of simplicity
• https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md — Community-maintained full transcript of "Simple Made Easy" with section headers

This is a dramatized editorial narrative created for personal inspiration, drawn from publicly available sources listed above. It is not affiliated with or endorsed by the person, company, or their estate.