In software engineering, we’re often faced with trade-offs that sacrifice what is best for the long term against something that increases velocity in the short term. A commonly used financial analogy is describing this as taking on technical debt. I will not cover accidental and deliberate tech debt, neither will I give a decision making framework in this article. That is its own subject, and context specific. However, there is a mental framework that has worked well for me across different teams, codebases and systems.

In the present world we live in, most products compete on the same market and for the same resource: our attention. The usual suspects are facebook, twitter, reddit on your phone, netflix, hulu & friends on your other devices. In the “more tolerated” category we have personal messaging: imessage, signal, whatsapp & messenger (hey again facebook). The competition has recently extended to “workplace productivity”. This is a sneaky way of saying “social media, but at work”: slack, teams, email.

Programming is amazing: we get to draw up a system on a whiteboard, and then we can implement everything, all the way down (if we chose to). We can build significant systems in a matter of weeks. The unique thing here is the range of the stack that we manipulate, there are a lot of hats to be worn by a single human! What other field allows to go from 0’s and 1’s (assembly) to fear-of-heights-inducing-levels-of-abstraction, like a bunch of boxes on a whiteboard, representing planet-scale designs?

Open layouts are the worst. They make literally no sense at all. Why do our employers feel compelled to make us work in a zoo-like environment? How are we supposed to get any valuable work done? An open space is only as quiet as the least quiet person at any given moment. This essentially means that it’s noisy all the time. In addition to the audio pollution, visual noise is also everywhere.

I have found that software engineers tend to divide themselves into 2 broad categories: Builders (selfish) Maintainers (selfless) This is of course an oversimplification. Most of the time we do a bit of both, but in my experience engineers tend to lean towards one or the other. The beef I have with this is that maintainers rarely do this consciously. They also enjoy building, it’s just that they typically have some trait (perfectionism, humility, shyness, …) that prevents them from pushing to get the opportunity to be a builder.

This website contains theories and thoughts that I have theorized and thought.

Hello everybody 🔗For as long as I can remember, my family and friends have been telling me “Your theories are ridiculous, and wrong”. So I decided to share them more broadly.