Friday evening I had dinner with Felix. Among other things, we talked about good code. Good code, we both agreed, is simple. It's code boiled down to its essence.
"Perfection is achieved when there's nothing left to take away", Felix half-quoted Antoine de Saint-Exupéry.
Good code, he said, looks as if it had been rewritten five times and the author learned with each iteration what's important and what isn't, what the essence of the code is and removing what isn't.
Not only do I agree, but I also think this is yet another exclamation point after YAGNI ("You aren't gonna need it").
YAGNI, I truly believe, is one of the most important principles required to write good code. YAGNI, to me, means that you don't clutter your code with optionality for a tomorrow that might never come.
Don't add code because "in the future we might …” Even if. Even if the intentions are good, even if the code would be neat, even if, yes, should the day come that we need to solve this problem, this code would solve it well — even then: don't add it.
You can't predict the future, no one can. What looks probable today might look laughable tomorrow and code added based on what's likely today might be dead code in a few months.
Until then it's zombie code: code that isn't strictly dead — it is executed — but it doesn’t affect functionality. It’s there because it might affect functionality some day. And code — dead or alive or something in between — ain't free: it needs to be read, maintained, its tests need run. The less we have, the better off we are.
If we can we remove it, let’s remove it, and if we know we could remove today, let’s not add it.
Joy & Curiosity
Came across Kelly Johnson’s 14 Rules of Management in the Acquired episode on Lockheed Martin. Johnson ran Skunk Works and knew a thing or two about shipping with a small team: “The number of people having any connection with the project must be restricted in an almost vicious manner.”
The same episode contains a mind-blowingly good story about how they got photos from space down to earth, in the 50s. Listen to the 3-5min starting at 1:34 here.
This post on the 3 motivational forces of developers is interesting because I also often think in 3 buckets of motivation, except they don’t match exactly the ones mentioned here. For example, I think the “Technology Motivated” bucket here is too narrowly-scoped and was reminded of what Dave Draper wrote in his foreword to Dan John’s Never Let Go: “Dan craves knowledge and understanding, and is compelled to pass along what he discovers. Knowing is not enough; applying what he knows helps; instructing makes him complete.”
There’s been an update in a 2.5 year old issue on the Tailscale issue tracker that I’ve been watching since 2.5 years. I love issues like these, in which everybody’s helpful, shares tips and custom solutions and scripts, and then everybody’s happy if there’s a big breakthrough in the case.
Came across John Tromp’s personal website and it made me think how much I miss these very personal websites that when you open them make you feel like you entered a person’s universe, with arrows pointing to all their interests and passions.
