Years ago I saw Marcel Molina give a talk at RubyConf that blew my mind. The title of the presentation was “What Makes Code Beautiful?”
Marcel uses a heuristic for beauty borrowed from a Medieval philosopher named Thomas Aquinas. In Summa Theologica Aquinas wrote that a beautiful thing possesses three characteristics:
1. Proportion: its parts are in proportion to each other and the whole
2. Clarity: its purpose is transparent and easy to understand
3. Integrity: nothing is missing; the thing is complete
Students of medieval history know that Aquinas’ formulation of beauty was critical in the design and construction of churches.
Strange indeed that a centuries-old formulation of aesthetics should re-emerge at a 20th century software conference, in a presentation about beautiful code!
A Latticework of Mental Models
Famed investor Charlie Munger would call Marcel’s presentation a latticework of mental models.
You may not have heard of Charlie Munger, but you have surely heard of Berkshire Hathaway, the investment vehicle that has returned around 2,000,000% of its initial value under Munger’s guidance.
Two million percent! How is this possible?
Munger attributes Berkshire Hathaway’s success to his continual thirst for knowledge. An avid learner, Munger has accumulated mental models from numerous problem domains including physics, economics, and philosophy.
Munger isn’t an oddball. Many luminaries including Bill Gates and Barack Obama have attributed their success to the practice of deliberate learning.
Continual learning and success are so tightly linked that the linkage has become codified as the so-called five-hour rule.
The five-hour rule says that the secret to success is to carve out one hour per weekday to read, think, and experiment.
The question is why?
Why does deliberate learning give you an advantage? How precisely, does it contribute to your success?
In practical and tangible terms, why should you invest in a latticework of mental models?
Plod or Leap
Most mornings the only thing that gets me out of bed is that I’m annoyed by the coding problem I couldn’t figure out the day before.
Being a software engineer is hard, and the job keeps getting harder. Tech refreshes every year so whatever you learn today may be completely worthless tomorrow.
If you are early in your career, when you get stuck, (and you will get stuck) you have to solve problems through deduction, which is a long, tedious process of logical analysis based on facts and direct observation.
Deduction is grueling and time-consuming. That’s why it takes weeks for a junior engineer to do the same task that a senior engineer can do in minutes. Everyone I know who quit tech could not evolve past this stage.
The other way to solve engineering problems is inference. You get to the same destination as you would through deduction but you get there faster, because you are reasoning to a conclusion based on things you already know. In other words, inference is a mental leap.
How Inference Works
In my first comp sci class we learned how to write bubble sorts. The bubble sort gets its name from the way items “bubble” to the top of a list. You don’t need to know anything about code to be able to visualize bubbles rising to the surface. If you’ve ever seen a bubble, you get the gist of the bubble sort.
That’s how inference works. It gives you a mental shortcut that you already paid for with prior knowledge. Pretty sweet!
Here’s a more current example. Many tech shops use circuit breakers like Hystrix to protect components that are vulnerable to network timeouts. When a circuit is broken, the component will stop trying to do something that is likely to fail.
The point is, you don’t need to know the details of how Hystrix works. If you know basic electronics, you get the gist of how a software circuit breaker works.
In other words, knowledge from one problem domain allows you to make a mental leap in another problem domain.
You could have gotten there through deduction, but the time and cost involved would be enormous.
Deduction plods. Inference leaps.
You need to leap.
And that brings me full circle to beautiful code.
The most successful and sought-after engineers I know all have one thing in common. Namely, they are incredibly opinionated. The most effective engineers are not just passengers dozing off on the bus to Janky Town. They are minutely engaged in the aesthetics of their code as well as its function.
Code as art requires a mental leap that is impossible if you are intellectually confined to 1’s and 0’s. To get to beautiful code, you need to actively look across problem domains. You need to weave a latticework of mental models that will allow you to form your own opinions about proportion, clarity, and integrity.
Otherwise, everything you do will look and feel like a paint-by-numbers kit.
So step away from the keyboard. Put down your cool side project. Instead, pick up a non-technical book. Enroll in a class. Learn a new sport. Diversify your investment in yourself!
I'm hiring software engineers! Check out the jobs page to see my open positions.