Lessons from Rich Hickey

Lessons from Rich Hickey

Rich Hickey created the Clojure programming language and the Datomic database. He is best known for drawing a hard line between objective simplicity and mere familiarity in software design. This collection organizes his talks on state, time, and systems into seventy-five direct observations on how to build reliable programs.

Part 1: Simplicity vs. Complexity

1. On Simplicity: "Simplicity is a prerequisite for reliability." — Source: [InfoQ]
2. On the Roots of the Word: "The roots of this word are sim and plex, and that means one fold or one braid or twist. Simple is an objective notion." — Source: [GitHub Transcript]
3. On Complecting: "Complect: To interweave, entwine, or join together. Simplicity is the opposite: to untangle." — Source: [InfoQ]
4. On Familiarity vs. Simplicity: "Easy is relative. It's about being near to our understanding, or in our current skill set. The word 'easy' is about being familiar." — Source: [GitHub Transcript]
5. On Programmer Convenience: "We are infatuated with programmer convenience, not to our benefit... All we care about is, 'Can I get this instantly and start running it in five seconds?'" — Source: [InfoQ]
6. On Long-term Speed: "If you ignore complexity, you will slow down. You will invariably slow down over the long haul." — Source: [InfoQ]
7. On the Starting Pistol: "Programmers fire the starting pistol every 100 yards and call it a sprint! The complexity will eventually kill you." — Source: [GitHub Transcript]
8. On Abstraction: "Abstraction for simplicity is about being 'drawn away'—taking a problem apart so you can understand its components in isolation." — Source: [InfoQ]
9. On Comprehension: "How can we possibly make things that are reliable that we do not understand? It is very, very difficult." — Source: [GitHub Transcript]
10. On the Payoff: "The person who has a genuinely simpler system—a system made out of genuinely simple parts—is going to be able to affect the greatest change with the least work." — Source: [InfoQ]

Part 2: Time, State, and Identity

1. On the Illusion of Objects: "No man can ever cross the same river twice. Because what's a river? There's no river. There's water there at one point-in-time." — Source: [InfoQ]
2. On Mutability: "The biggest key insight of Whitehead was there's no such thing as a mutable object. We've invented them. We need to uninvent them." — Source: [GitHub Transcript]
3. On Psychological Artifacts: "Identities are mental constructs. We call it a cloud, we call it a river... we have to make sure we understand that objects are not things that change over time." — Source: [InfoQ]
4. On Pure Functions: "Pure functions are and should be the bricks that we use because they are the things we can use without worrying about them most readily." — Source: [GitHub Transcript]
5. On Side Effects: "The pure function takes immutable values. It does something with them. That stuff it does has no effect on the world." — Source: [InfoQ]
6. On OOP Terminology: "One of the problems with object-oriented time is that we talk about behavior and state and things like that really, really loosely. These terms are almost completely meaningless." — Source: [GitHub Transcript]
7. On Identity vs. Value: "Identity is a putative entity we associate with a series of causally related values (states) over time. It's a label." — Source: [InfoQ]
8. On Values as Magnitudes: "Values do not change. They are immutable magnitudes, quantities, or numbers." — Source: [GitHub Transcript]
9. On Updating State: "To change state, you don't mutate the data; you update the identity to point to a new value." — Source: [InfoQ]
10. On Concurrency: "Using immutable values frees the mind from worrying about what somebody else might do to it. And it gives us the chance to get concurrency and time right." — Source: [InfoQ]

Part 3: The Value of Information

1. On Immutability's Worth: "Immutability is better, Immutability is better, Immutability is better." — Source: [InfoQ]
2. On Objects as Places: "Mutable objects are actually abstractions of places. They do not actually have meaning other than that." — Source: [GitHub Transcript]
3. On IT's Real Purpose: "It is information technology. It is not 'technology technology'." — Source: [InfoQ]
4. On Place-Oriented Programming (PLOP): "We continue to use place-oriented programming languages and databases—and make new ones!—long after the rationale is gone." — Source: [GitHub Transcript]
5. On Interoperability: "Values are easy to fabricate. Anything can create a value. Any programming language can make a value." — Source: [InfoQ]
6. On Hardware Rationales: "The original reason for mutable places was limited hardware. In the modern era, we should prioritize facts over the efficiency of updating a memory address." — Source: [GitHub Transcript]
7. On Encapsulation: "Encapsulation is for implementation details, but information doesn't have implementation!" — Source: [YouTube]
8. On Facts: "A fact is a value associated with an identity at a specific point in time. Once a fact is recorded, it should never change." — Source: [InfoQ]
9. On Thinking Mediums: "Values are the things we use to think. We don't think with 'places' that change under our feet. We think with facts that stay true." — Source: [GitHub Transcript]

Part 4: Problem Solving and Deep Thinking

1. On Why We Program: "If we're not solving problems, I have no idea why we're in this room. We absolutely should be working on solving problems." — Source: [YouTube]
2. On Misconceptions: "Most of the big problems we have with software are problems of misconception. We don't have a good idea of what we're doing before we do it." — Source: [Jim Nielsen Notes]
3. On Features vs. Problems: "We should be solving problems, not building features. A feature is just an attribute of something. It's the shiny chrome knob." — Source: [YouTube]
4. On Tradeoffs: "The chances of there being no tradeoffs in your solution are slim. Usually when people talk about tradeoffs in their software, they're talking about the parts of their software that suck." — Source: [Jim Nielsen Notes]
5. On Being Wrong: "The last thing is you are going to be wrong. I'm frequently wrong. That's part of the game... do not be afraid of being wrong." — Source: [YouTube]
6. On Test-Driven Dentistry: "Test-driven dentistry—I don't think I could come up with a better thing." — Source: [Jim Nielsen Notes]
7. On Problem Statements: "State the problem. Say it out loud, write it down, and talk about it. If you can't state the problem clearly, you don't understand it." — Source: [YouTube]
8. On Critique: "Critique your own ideas. If you don't have questions or see tradeoffs, you're missing something." — Source: [Jim Nielsen Notes]
9. On The Hammock: "Step away from the computer. Go for a walk or lie in a hammock. This allows your background mind to process the information." — Source: [YouTube]
10. On Sleep: "Your brain does its best work while you sleep. If you're stuck, sleep on it for at least one night." — Source: [Jim Nielsen Notes]

Part 5: Design and Composition

1. On the Definition of Design: "Design is fundamentally about taking things apart in such a way that they can be put back together." — Source: [InfoQ]
2. On Preparation: "To prepare the plans for a work to be executed, especially to plan the form and structure of that work." — Source: [GitHub Transcript]
3. On Component Focus: "Every component of a design should be about one or very few things." — Source: [InfoQ]
4. On Extensibility: "The easiest way to make something extensible is this breaking it apart thing because, when you've broken it apart, you end up with pieces that are meant to connect." — Source: [GitHub Transcript]
5. On Composition: "Composition is design for performance." — Source: [InfoQ]
6. On Musical Practice: "Coltrane was a genius at this preparing. He practiced more than anyone in order to seem as if he was making it up most fluently." — Source: [GitHub Transcript]
7. On Harmony vs. Melody: "Melody is sequential and harmony is parallel." — Source: [InfoQ]
8. On Constraints: "Constraint is a driver of creativity." — Source: [GitHub Transcript]
9. On Insufficient Deconstruction: "Usually the answer to your problem in the field is: I have just insufficiently broken something down." — Source: [InfoQ]

Part 6: Programming Tools and Languages

1. On the Instrument Metaphor: "Programming languages and tools are like instruments... Instruments are simple." — Source: [GitHub Transcript]
2. On Targeting Beginners: "Programming languages shouldn't target beginners in their designs nor should they try to eliminate all effort. We are only absolute beginners for a very short period of time." — Source: [InfoQ]
3. On Perpetual Beginners: "On the flipside, we are beginners forever." — Source: [GitHub Transcript]
4. On Blisters: "Imagine you downloaded something and it gave you blisters." — Source: [InfoQ]
5. On Human vs. Machine Interfaces: "What's wrong with SQL? There is no machine interface to SQL. They only designed a human interface." — Source: [GitHub Transcript]
6. On Typing: "Programming is not about typing, it's about thinking." — Source: [InfoQ]
7. On the Cost of Things: "LISP programmers know the value of everything and the cost of nothing." — Source: [GitHub Transcript]
8. On Static Types: "The safety of static types is a mirage, the safety of immutable values is solid and evident." — Source: [InfoQ]
9. On Bugs: "What is true of every bug found in the field? It passed the type checker!" — Source: [InfoQ]

Part 7: Software Growth and Accretion

1. On Breaking Changes: "Breaking changes are broken. It’s a terrible idea. Don’t do it. Don’t try to figure out the right way to do it." — Source: [GitHub Transcript]
2. On Semantic Versioning: "Semantic versioning is a lie... It has got too broad a semantic." — Source: [YouTube]
3. On Improving Software: "We want our software to be different and better tomorrow in a way that our consumers can tolerate." — Source: [GitHub Transcript]
4. On Actual Dependencies: "Actual dependencies are not artifacts but the code itself. Names, if you will." — Source: [YouTube]
5. On the Hat Analogy: "If I put on a hat, it does not change what my family is." — Source: [GitHub Transcript]
6. On Accretion: "Software should only grow by adding new things, never by removing or changing existing ones." — Source: [YouTube]
7. On Relaxation: "Making a function require less or provide more is a compatible change; the opposite is a break." — Source: [GitHub Transcript]
8. On Names and Semantics: "Names dominate semantics. a -> a, [a] -> [a], it means nothing. If you take away the word 'reverse', you don't know anything." — Source: [GitHub Transcript]
9. On Testing: "You need extensive testing to do real-world effectiveness checking, far beyond what type systems offer." — Source: [YouTube]

Part 8: The Nature of Real-World Systems

1. On Effective Programs: "Programming is about making computers effective in the world... either the programs themselves are effective, or they are helping people be effective." — Source: [GitHub Transcript]
2. On Situatedness: "Your program is rarely written from scratch. Invariably, you're going to pull in some libraries. And when you do, you've situated yourself in that ecosystem." — Source: [YouTube]
3. On Predictive Power: "Being effective most of the time isn't about calculation, it's about derived predictive power from information you already have." — Source: [GitHub Transcript]
4. On Row Updates: "It doesn't matter if you're using append-only data structures if your view of the world is update-in-place. A row is a place and you are updating it." — Source: [InfoQ]
5. On Accumulating Facts: "Since one can't change the past, this implies that the database accumulates facts, rather than updates places, and that while the past may be forgotten, it is immutable." — Source: [Datomic Documentation]
6. On Combining Machines: "When you combine two pieces of data you get data. When you combine two machines you get trouble." — Source: [InfoQ]
7. On Databases as Values: "In Datomic, even the database itself can be treated as a value. You can write functions that take values as arguments and return a database value." — Source: [Datomic Documentation]
8. On Trapped Power: "Traditional RDBMS provide powerful logical languages... Unfortunately, that power is trapped in servers, and once data reaches the application, it vanishes in a sea of nested for loops." — Source: [InfoQ]
9. On the Final Target: "Clojure's target is information-driven situated programs." — Source: [GitHub Transcript]