The handbook of the selfless programmer
The dependency of civilization on software has increased rapidly over the last 100 years and is definitely near 100% today in 2025. Software is responsible for:
- people's identities
- airplanes, cars
- warehouses, factories, offices
- medical equipment
- videogames, social media
- distribution and archival of knowledge
- distribution of books, series, movies and porn
- et cetera
Similarly, the amount of abstractions1 used by the average programmer is also very rapidly increasing.
understandably so, since abstractions are great. they allow us to be more efficient2 because we can skip learning all the basics
and solving all the difficult technical problems, and instead we can jump right to implementing the business logic for our hot new idea.
There is however a caveat to that: if people are not forced to solve something
difficult, they will generally avoid it. The number of programmers that learn the basics and understand the computer they are
programming for is decreasing proportionally to the increase of abstrations, thus:
we decreasingly understand the thing we increasingly depend on.
Whether you are in the "software is in decline" or "you're just wearing rose-tinted glasses" crowd, some simple logical deduction should at least nudge you towards the former. After all, if we understand it less and less, how can it not be in decline? This should be at least a little bit alarming, because as established earlier, software is pretty important. Software declining so much that it becomes unbearably slow and unreliable as we add more and more abstractions is already something most of us should strive to avoid if possible, but what's worse, we don't currently have any mechanism to prevent our understanding of software from reaching zero. That may take a very long time to happen, or it may not happen at all, but if it happens, the consequences could be anything, including things like, say, total downfall of human society. As unlikely and pessimistic as that sounds, it has happened many times before in human history, and we should not be so arrogant to think that we are now somehow impervious to it.
As a game developer that sometimes makes the deeply regrettable decision of participating in online discourse, I've been called "delusional" and "an idiot" on multiple occassions for insinuating that I don't use a game engine. There's a rotten obsession with utilizing every shortcut necessary to finish a project as fast as possible, minimizing scope and quality, maximizing profit, and worst of all, infecting others with this sickness. Its a deeply self-centered way of working, and directly ties to the fact that the very concept of an abstraction is somewhat selfish:
"I will use this very substantial amount of deep gruesome work someone else did without understanding it, so that I can build my thing quickly and effortlessly"
However, don't misunderstand; by no means do I suggest that "we all program in assembly" as the so-called "software engineers" like to remark amidst dependency injecting their javas, or something. I use some abstractions too. Everyone does, and there's not much we can do about that. What we can change though, is how many we use, and how do we use them. Therefore I propose we meet somewhere in the middle, and with that I bring forth the handbook of the selfless programmer, a set of guidelines for everyone who wants to help us regain our understanding of software by lowering the amount of abstractions we use, and being responsible about those we keep.
- Given your employment opportunities, do your absolute best to employ yourself such that you care a lot about what you are working on, and have enough agency to make a difference. It will make deep work, solving difficult problems and making the right decisions much easier.
- If you can and want to become self-employed, even better.
- When programming, carefully consider your role in society. Ask yourself how many abstractions do you really need.
- Given your current programming ability and financial situation, weigh the time to market of your project against the continued success of humanity and the wellbeing of your grand-grandchildren.
- Every time you do add an abstraction, be grateful for the work of the giants whose shoulders you stand on. Spend time to understand the code you are using so that you may utilize it responsibly and to it's full potential and gain invaluable knowledge.
- You don't have to go all out right away and write an HTTP server from scratch in C or a game from scratch with Vulkan. If the best you can do right now is use vanilla Node.js instead of Express, then do that.
- Focus on improvement line by line, day by day. Given enough perservance, you may soon find yourself at a point where you need less abstractions and the proposition of writing a HTTP server from scratch in C or a game from scratch with Vulkan does not seem all that ridiculous.
- Realize that cutting down on abstractions and spending 4 years of your life on a project instead of 2 is not that big of a difference in a human lifespan, and it's certainly not something to be ashamed of.
Now, if you think this whole ordeal is just doomsaying, or you just couldn't care less, I still have something in it just for you, perhaps more than you think:
- The pursuit of knowledge, meaning and a higher motive is far better for your own mental wellbeing than the pursuit of hedonism such as profit and apparent success.
- Whatever it is you are working on may very well end up much better when you make it from scratch. The human brain works amazingly well under constraints.
- You'd be surprised how easy it is to turn those "Microsoft employee workdays" into fully productive workdays or even overtime when you are working on something much greater than yourself.
- Lastly, remember that knowing a lot about a lot of things is a great way to avoid "impostor syndrome" - a myth perpetuated by people who don't know anything in order to convince others that it's just a syndrome and they actually know something.
Thank you for reading.
1 LLM technology also counts as a software abstraction (when used for writing software).
2 That is very unclear, it seems to me that regarding efficiency we made a wrong step somewhere with abstractions, probably around Smalltalk.