Bad Software Advice is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
system: a set of things working together as parts of a mechanism or an interconnecting network.
Software developers work on systems. For example, if you work for a a loan approval company which determines if a person should be offered a loan, you work on the code that takes in credit history and runs a series of rules to determine if a person should be offered a loan and if so at what rate.
Your job is to make the system work, make it work correctly, and make it work quickly. You spend most days working on one of those things - support, bugs, production incidents are making it work, adding new features is making it work correctly, and any scaling or performance work is making it work quickly. This involves a lot of complexity as each of these three tasks can also break the system or interact with another attribute. For example, adding features can slow down a system, fixing bugs can accidentally make the system no longer work, and of course making a system faster can make it no longer work correctly.
This system lives within a larger system which is how people interact with it. This greater system includes loan officers, the customer, the support team that field questions, etc. The greater system includes your competitors, other tools that your customers use, the market, and many other things that are interconnected with your small technical system.
What system are you really working on?
That’s Not My Job
Traditionally, computer programmers had a clear answer to this question which is, um, I’m working on the system that the computer works on, because I’m a computer programmer and I don’t understand all the nuance of the greater system. That’s not my job, my job is the technical system.
And for the most part you would be correct. But, a misunderstanding of the greater system can make you build the wrong system:
make it work: it can literally be the wrong system - nobody cares about it.
make it work corectly: it can work to spec, but the spec be wrong, not make sense to the user, or behave incorrectly given context.
make it work quickly: you can tune the heck out of a part of the system nobody cares about, while not addressing something that is the real bottleneck.
Traditionally, understanding the greater system was the role of the product manager, or “the business”. It was somebody else’s job to do this, not your problem.
Cost of development
The cost of development is lowering with the AI winter ending. Computer programmer’s jobs are shifting from being the only ones that can understand and code to being managers of tools and agents that can code very quickly. Our jobs are shifting from making something from nothing to be judges of whether or not something has been done correctly by an agent.
And this means that we need to understand the technical system, and the greater system. We are moving “up stack” so to speak, and becoming higher level builders.
It is a wise investment to spend time learning the greater system.
Bad Software Advice is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.