Skip to content

Instantly share code, notes, and snippets.

@cellularmitosis
Last active September 19, 2022 05:25
Show Gist options
  • Save cellularmitosis/8a83e77b9c20947d769923a02daf9c0e to your computer and use it in GitHub Desktop.
Save cellularmitosis/8a83e77b9c20947d769923a02daf9c0e to your computer and use it in GitHub Desktop.
Notes on Rich Hickey's "Simple Made Easy" talk

Notes on Rich Hickey's "Simple Made Easy" talk

talk: https://www.youtube.com/watch?v=rI8tNMsozo0

slides: https://www.slideshare.net/evandrix/simple-made-easy

"Simplicity is prerequisite for reliability" -- Dijkstra

Simple:

  • vs complex
  • one concern / role / task / concept
    • about interleaving of concerns, not cardinality (e.g. not limiting classes to one function)
  • objective

Easy:

  • vs hard
  • "to lie near"
  • easy to acquire, easy to understand, near our capabilities
    • the limits of our mental capacity are often not talked about
  • subjective / relative

Not the same thing!

Limits

  • 7 +/- 2
  • We can only consider a few things at a time, and intertwined things (complex things) must be considered together.
  • complexity makes understanding more difficult
  • if you can't understand it, you can't change / improve it

The growing elephant: the code we've already written

  • as the elephant grows, it gets harder to push around
  • our whole job is to change software
  • in the long run, complexity will domniate your velocity

Simplicity buys you opportunity

  • architectural agility is a huge win
  • simplicity makes it easy to change things

"Programmers know the benefits of everything and the tradeoffs of nothing"

  • this touches on another key idea: no bad decisions in tech, only tradeoffs!

"Who wants to be in this band?"

  • touches on a related idea: you get better at what you spend your time on, and your time is an investment.
    • should you invest the next six months using an ORM, or just getting better at SQL?

Another way to state some of this:

  • When considering a decision, ask "how easy/difficult will it be to change this decision 6 months from now?"

Don't complect my thing bro!

Often complexity isn't consciously chosen, it is the default result of choosing what is easy. So consider simplicity when making a tech decision.

We can't significantly improve the limits of our mental capabilities, so it is crucial to work within those limits, which means choosing simplicity whereever possible.

Screen Shot 2021-03-01 at 11 00 55 PM

Pure functions are simpler and easier to test than methods on objects.

Syntax: order of arguments (vs a single dictionary arg)

ORM's: consider instead the yesql approach (sql as a first-class part of your codebase)

Examples of complexity which are commonly chosen these days:

  • ORM vs SQL
  • Eventual consistency vs transactions
  • microservices vs monolith

Choosing simplicity often requires upfront cost, but the payoff is better velocity in the long run.

Simple example: order being a source of complexity

  • [depth width height]
  • Using a set clearly communicates that order does not matter
  • Using a dictionary avoids this particular ordering problem
  • Example of changing [name email] to [name phone email]

Queues can be a good way to decouple / decomplect two pieces of software

Choosing maps instead of classes -- Swift's value types can be a middle road (as long as you stick to Codable).

Can you move it?

Subsystems. Let data be the boundary (between services), rather than verbs / funcalls.

TODO:

  • think more about his points about:
  • inheritance / switch statement / pattern matching vs polymorphism
  • conditionals vs rules?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment