Mission Statement of Thorstel Ball

Here is a tweet from Thorsten Ball:

Just re-discovered these Programming Principles I wrote down in a note called "Mission Statement" years ago.

I still think I stand by them 100%? pic.twitter.com/uCcaj6KrjG

— Thorsten Ball (@thorstenball) March 25, 2025

Programming Principles

It was amazing to read this, but it was still an image, so I uploaded the image to ChatGPT and asked it to extract the text, which is as follows:

• Before all: write code for others.

• Working code is not enough.

• Write as little code as possible.

• Write code to be changed and deleted.

• Solve the problem behind the feature.

• Nurse your codebase like a garden.

• Beauty has a place in software development.

• Practice over theory. Theory is fantastic, but be mindful of the gap between practice and theory. And if you don’t see the gap, you need more practice.

• Chop up the problem so that each problem is easy to understand and solve.

• Be fearless. Never be scared of looking into or touching code.

• I want to build robust systems that run for years on their own, that are easy to modify, in which bugs are easily spotted and removed.

• I want my systems to do their job and nothing more.

• Always strive towards high quality and know when tradeoffs need to be made.

• I value simplicity higher than easiness.

• “It works” is not good enough.

• I have a bad memory and I build systems with that in mind.

• I work with other people and the artifacts of my work should reflect that.

• Hacking is not programming, nor is professional software development.

• The history of the software is as important as its future.

• Robustness, simplicity, and maintainability are most important.

• The artifacts of my work should do what they promise to do.

• I care about my work and what I build.

• I love building.

• I strive to reduce things to their most simple form.

• Elegance.

• Remove what’s not necessary.

• Carefulness and thoroughness are essential parts of my work, even when going fast.

• I strive for my work to be neat and uncluttered — “Ordentlichkeit”.

• I invest in my tools. Knowing how my tools work is important. Knowledge of my tools will pay off.

• Knowledge further down in the stack gives me more leverage higher up.

• I favor the Unix philosophy.

• Predictability is more important than “magic”.

• I try to work it out on my own, then ask other people.

• Asking for help is good. Helping others is good.

• I never want to hear myself say: “We do it this way, because we’ve always done it this way”.

• I will always write code with debuggability and deletability in mind.

• It depends.

• Good programmers program a lot. “If you want to get better at benching you need to bench more” “Everybody wants to be a body builder, but nobody wants to lift those heavy ass weights”

• If you can do it in a single machine, do it in a single machine.

• If you can get away without state: database, cash, memory — do it.

• You should have a healthy amount of respect and fear of building distributed systems. If you don’t, you’re either missing something or you don’t know the tools. Knowing how things break is important.

• If you think something not only has upsides, but no downsides, you probably haven’t used it enough. Tradeoffs are the name of the game.

• Never fall for dogma. If you lean towards a dogmatic view — try the other side. You’ll see why the dogma doesn’t always apply.

• In the same vein: watch technologies and domains like a dog go faster.

• I always believed that technical debt can be avoided. Now I know:

  (1) taking on technical debt can be a conscious decision to go fast

  (2) not every bit of debt needs to be repaid immediately, some can linger and is not worth being repaid ever.

Full credit is to Thorsten for sharing it with the world. I hope you find these principles as insightful as I did.