Commentary: How to be really bad at fixing problems in software
Stagnation is real people, but hard to see
How to be really bad at fixing problems in software is about solution stagnation, a trap that many engineers can fall into in which they are constantly performing work, but aren’t making anything better.
Engineers are supposed to work like this:
A new Problem arises.
The engineer seeks the Context to understand the Problem.
The engineer designs and builds a Solution based on the problem and context, hopefully fixing the problem for a long time.
If the context changes dramatically, this is seen as a new problem, and we start again at Step 1.
In this way, a software engineer is fixing problems that might look the same to an outside person but are very different:
When I used the terms Problem, Context, and Solution I am grouping many things together:
The Problem
What is happening now and what needs to happen instead. This can be defined in many ways: explicit requirements, a specification, user stories, a voicemail with a lot of background noise, a Viso diagram, etc. It can also be defined in detail or defined broadly: “the system needs to be faster”. The Problem can be explained to people that don’t work at your company pretty easily.
The Context
These are conditions under which the problem must be solved, the implicit requirements, the budget, the timeline, the strength of the team that you are working with, and many other things. The context are all the things that exist when you say that you have to solve the Problem right here, right now. The Context is hard to explain to someone outside the company.
Here are some examples of the types of contextual rules of engagement that can be different per company or project that you might not consder:
Don’t use the existing code as a starting point, it doesn’t work and I’m mad about it
This needs to be done before the demo Wednesday, yes I know that it is Tuesday, yes I mean tomorrow
You need to work on this around the clock, or create the appearance of doing so
Do not talk to Terry about this
We do not pay for development tools or third-party software here, we build everything ourselves or decide we don’t need it
We already tried the obvious solution, so don’t bother presenting that, and I will offer no further explanation
We only trust third-party software from Microsoft and believe that the cloud is a mistake, as was Linux1
Working Problems and Contexts
To a person outside the contexts in each Problem, it might look like we need logging, get me some and the developer is just doing the same thing repeatedly. But they aren’t, they are paid for understanding the context and providing a solution that solves it for real such that if the context doesn’t change dramatically, it still runs with minimal problems.
At a high level, your job over time should look roughly like
Problem A within Context X => Solution 1
Problem B within Context Y => Solution 2
Problem C within Context Z => Solution 3
Stagnation
An engineer is building a knowledge base of what (problems) works (solutions) in distinct situations (contexts). To become more experienced, an engineer seeks out variety to grow their capabilities. They can get tired of the same set of factors, so they change jobs. 2
Stagnation is what they are avoiding, it can happen to all three factors:
Problem stagnation: If the company only works on logging solutions then I hope it’s a logging solutions company, or perhaps the solutions aren’t working well. This can also be intentional: if you are interested in location and navigation problems, work at a mapping company. If you are interested in solving resource constraint problems under pressure and with weak vendor documentation, work on embedded software.
Context stagnation: context stagnation is why startups attract many smart engineers - the context is always changing. An engineer gets the experience of working on a duct-tape-and-glue team-in-a-garage feel, then if the company survives they experience a medium size product with multiple teams, then perhaps grows into problems at scale as the company expands. Context stagnation can also happen when the business stalls and the constraints can’t, i.e. “we don’t have money to work on anything but keeping the system running”.
Solution stagnation: if you always recommend the same solution even as the problem and contexts change, you have either discovered a very important technology, or are an inexperienced engineer.
Improving the Context, Changing the Context
A sad but understandable thing that can happen to a software craftsman is that their solution is not implemented because of the context. For example, there is not enough time, we don’t have the money for that, I don’t agree with your solution and think it is overkill, etc. Part of becoming a more senior engineer is learning how to navigate these issues - if you and your manager disagree on the context then sometimes you can figure it out and work towards a solution. Sometimes you need to come up with a solution that makes more sense for the current context that you know will need to change soon: you can call these band-aids or hacks or sloppy but they are less than ideal solutions given the context. Many times an elegant solution is not possible, but a solution that moves the context in the right direction is. One of the subtle things that highly experienced engineers have is the ability to figure the right solution for right now and somehow also slightly improves the system and the situation.
Famous Problems and False Solutions
If we now return to our original post, in which we gave bad advice saying that you should “solve” the same problems over and over again, so that you are viewed as important and a hero, we now see that what we are saying is that a set of known problems and quick hacks can give you job security. Create a way to mitigate famous problems, and be famous for it.
This is terrible advice because there should never be famous problems, because if you are really offering things that improve the problem and context, then the situation should change. If a Problem + Context stays alive for too long it starts to feel like a factor of reality. Then you start to hear things like “this is the way it has always been” and you stop thinking of it as a problem at all - it just feels like the local geography.
You shouldn’t leave a company because they could never figure out how to do properly separate customer data, or do a deployment, and then return five years later only to find they are still doing multi-hour deployments and losing data. These situations should never linger - you should fix them for real. Part of the job of a senior engineer is pushing through this stagnation and changing the way the Problem or Context is viewed, so that you can provide an actual engineering solution.
If your job looks like:
Monday: Problem A, Context A, Solution A
Tuesday: Problem A, Context A, Solution A
Then you aren’t a growing software engineer, you are an operator of software supporting it, and a bored one. This trap is easy to fall into because this behavior is highly rewarded. They might be fine with you needing to restart the import process everyday for a year, even though it stagnates you and your career.
I wish this were a made-up example
Contrary to popular belief, developers do not just change jobs over money, or to learn a specific “new” technology, or remote work, or “boredom” (boredom is just how they express the desire for new contexts and problems)