I’ve read a couple of books by Pema Chödrön this year and it got me thinking that good coding is Buddhist coding. Hear me out.
One of the core practices in Buddhism is staying in the present moment. In software development terms it would mean that the current snapshot of a codebase works how it is implemented, and your goal as a developer is to fulfill the immediate next requirement — and that’s it.
To me this maps to three points:
1. Change is the only constant
The only thing you can expect to happen to software is change — that’s why you’re there in the codebase. Software that isn’t changing is probably unused. Even legacy software needs to be updated for the latest business requirements or changes in the running environment.
Therefore, code should be written in such a way that it can be easily changed. Any piece of software, if you zoom out, is a total sum of small changes, accumulated from zero (see ZeroMQ’s Simplicity Oriented Design).
2. Don’t work for a future that isn’t there
Nobody knows what happens in the future. The project can go one way or another, or scrapped because business priorities changed. Just the other day at work I’ve seen a line with the commit description “this is temporary until X” — authored in 2018.
Do not make any assumptions about the future. Do not prematurely optimize until you know you need to. Don’t build a generic solution because you might need it; you might not.
I’ve seen a great illustration to this point just recently:
The junior dev asked the senior dev “Why are you pushing this code with no abstraction? What if you want to change it in the future?”
The senior dev responded “Then I will change it in the future”.
In that moment the junior dev was enlightened.
3. Implement the simplest solution for the problem at hand
This directly follows from the previous two points: we expect the code to change, so it should be as simple as possible because we cannot predict how it will change when (not if) the requirements change. Making code complicated implies a bet on the future: the complexity is there to make doing something in the future easier. But (see point 2) we cannot know the future, so it is better to introduce complexity when it is actually needed in the future, not now.
As many people will attest, you can get away with a lot of extremely simple solutions for a long time. “Simple” does not mean “slow”: computers are fast, and if being fast is part of the requirements, a simple solution will be fast. “Simple” code that is slow is simply bad code.
Solutions can become naturally simpler when you stop trying to adapt the solution of today to multiple possible requirements of tomorrow. Instead, you can spend the effort refactoring previously written code so that it becomes simpler, while still only fulfilling the requirement of today, and today only.
Unlike in the financial world, writing some code today to use in the future is not investing, it’s tech debt.