Programming aphorisms

Over my 15+ years of programming experience I’ve learned a thing or two, and I find it quite poetic to distill those lessons into small nuggets.

I admit it’s unlikely that junior programmers derive any value from these, as often you have to (should?) see to believe. And senior programmers might very well disagree anyway.

Almost none of these are original.

• Writing simple code is harder than writing complex code.

• Prefer no code over code. Prefer no state over state. Prefer compile-time over run-time.

• A program that can be faster than human perception, should be.

• As programs grow, working with them gets harder, and development slows down. The goal is to keep as much of the initial speed for as long as possible. Simplicity, tests and modularity help keeping the speed.

• First you do 90% percent of the work. Then you do the other 90% percent of the work.

• The most important code is the code you don’t write.

• Architecture is the set of decisions you wish you had gotten right when you started the project.

  • Therefore, good architecture design allows postponing those decisions.

• Every piece of code has 2 users: production code and test code.

• Technical debt is the unnecessary part of maintenance costs.

• TDD is like communism: if it doesn’t work for you, you’re doing it wrong. Sadly, most people do it wrong.

• When I was a novice, I was excited about clever code and tried to avoid messy code. Now I’m excited about simple code and try to avoid overengineering.

• A layer shouldn’t exist unless it provides some extra value that the layer below doesn’t provide.

  • Furthermore, the extra value should be greater than the complexity cost of having the extra layer.

• Long functions are usually less readable than short functions. But short functions can be unreadable too.

• Your code from 3 years ago is probably horrible. This is good. It means you’ve improved. Unless you’re just a fashion victim.

• Temporary solutions tend to live longer than definitive solutions.