Infinite Shoulders, Infinite Giants
Clicking a random link on YouTube can trigger a cascade of unplanned explorations. Often it’s a frivolous rabbit hole of fleeting pop culture, but there’s a chance it leads you to something much deeper and consequential, something that changes the way you think. A door opens.
OK, probably not random, Google’s algorithm, The Algo picked it for me, but from all the suggestions, I watched a documentary about Clojure the functional programming language and the creator Rich Hickey. I’ve not used Clojure, and only briefly dabbled with functional programming, but what really stood out was Rich Hickey’s clarity of thinking, his approach to problems, and his conviction. It was compelling viewing. I’m not a professional programmer, but I do like thinking tools, models, frameworks and such. My coding is all personal projects, stretching back to early personal computers in the 1980s. The concept from the documentary that really stuck with me is Hickey’s Simple Made Easy talk.
His argument is that when you do the easy thing, it results in unintended consequences which make it harder in the long run. He goes on to explain that Simple is about not being entangled, and Easy is often about convenience, which causes complexity (braided, entangled).
At that time, I was using AI to vibe code an ambitious project for my home server, an integration server called Ductile designed to be operated by AI agents. I was making good progress, but it used queues and messages which I’m new to, and it was particularly difficult to debug or diagnose issues. I remember thinking ‘what would Hickey say about this’.
It’s not Simple, I have made a lot of choices that were Easy (convenient, quick). Specifically, I was passing large JSON objects about, adding whole other objects and passing that on. Everything downstream has to figure out the shape and meaning of its inputs. The penny dropped, I needed make it Simple, and that meant investing time and effort in the design. Name things properly, pass what is needed.
What I actually did was more profound; I crafted a code review prompt based on Rich Hickey’s core idioms, and set it on my entire code base. I didn’t list the ways he suggests doing things, I simply asked for a review ‘based on Rich Hickey thinking’. Let that sit for a moment, because that sentence would not and could not make any meaningful sense prior to 2023 (ChatGPT).
Review this code base using Rich Hickey thinking. Use his philosophies, idioms, principles and axioms, to tease out areas of improvement. Order the results with the most fundamental impacts first.
To focus the thinking of a luminary, a great thinker, on something I’m working on, and ask for their opinion, advice and recommendation. Furthermore, I can ask for their rationale, explanations, teaching, and all provided with infinite patience.
What resulted was a lot of changes, a lot of discussion and a series of 18 sprints, of what I now call The Hickey Refactor. Through the process, I got a lot more familiar with his ideas, I watched his talks and developed a much better understanding why Simple is better than Easy. A strange, new way to learn, and I love it.
I’m so smitten with this approach, I have researched a list of other well regarded thinkers in the field or programming. Next I will be looking into Joe Armstrong, the creator of Erlang, to hopefully learn how to handle errors and concurrency better. I’m looking forward to giving my project Ductile a full Joe Armstrong review, and then digging into the findings.
My advice to others wanting to try this approach is to first know that the expertise is there, ready to tap into. You need to figure out which giant to climb up on, because those giants are there, their shoulders await. I like the idea of summoning wisdom, calling on a great thinker. For me, I will be using this technique on all my future projects, up front in the design phase, not late when all the easy choices have been made.