How to be really bad at fixing problems in software
Solving the same problem over and over again means you are an expert or incompetent
One definition of what software developers do is to solve problems. If software isn’t working as expected, we must get it back into a working state as fast as possible. And if something doesn’t exist in the world, or is done manually or in an inferior technical product, then we build something new to solve this problem.
So, the work of a software developer is:
Receive the problem.
Understand the problem.
Find a solution.
Implement the solution.
Heroes
Developers that follow this pattern get rewarded, and get more problems to solve. The Business loves software developers that can fix problems quickly and consistently. These people are seen as Heroes, first responders, firefighters. What would we do without them; this behavior gets promotions and avoid layoffs.
Other behavior is not rewarded, however:
Developers that prevent fires (fire safety inspectors)
Developers that tell you about new problems early but don’t offer up solutions (smoke detectors)
For this reason, your career should focus on solving problems and, if possible, dramatic, important, highly visible ones. Fixing the projector in the executive conference room for the CEO right before a board meeting would be a perfect example of something that makes you a Hero. Or making sure that some important software that fails all the time gets fixed quickly when it fails.
Solve Familiar Problems
The fastest way to solve a lot of problems is to solve problems you have seen before.
Then the steps are simpler:
Receive the problem.
Understand the problem.Find a solution.Implement the solution.
Since you have seen the problem before, your job becomes pattern-matching. Ideally, you would have a file listing the top 10 problems your company faces and ways to solve them quickly.
But, wait, is solve the right word if you are doing the same thing repeatedly?
Let’s see:
solve
to find an answer to a problem
to find a solution
solution
A method or process of dealing with a problem
None of these definitions indicate anything about the problem going away, you seem to have misunderstood how business works if you think they should. A business is an efficient machine for extracting money from a process. It only seeks to change the process if the risk/reward clearly shows that more money will come out after the change. Most of the time, it seeks to find an answer or deal with a problem. They might be perfectly happy with you restarting the very important import system everyday, or just coming in to flip the projector to HDMI 2 and teaching anyone else how to do it or making this easier.
A business is not an engineered machine.
engineering
the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.
When you think of the world improving, that is engineering, not normal business. The discovery and eradication1 of problems are different than doing what your company values.
Solutions vs. Engineering
For example, your company could be pleased with the following “solutions”:
The developer (you) gets paged at 3 AM to restart the import service a few times a week.
If the service stops, another watcher process starts it again and clears out the logs to make sure there is disk space, removing evidence of what happened (last time it stopped, it was because it was almost out of disk space).
Because the deployment process isn’t reliable, a developer uses a Word document that outlines how to edit the configuration files every month and runs a manual drag-files deployment process.
Calling these things solutions likely bothers you, because engineered solutions look different:
After getting paged a few times, the developer rebuilds the import service so it runs without error 99% of the time and does not need to ever be restarted.
The service is moved off a limited server and changed so that it doesn’t eat disk space. Logs are always persisted. The watcher process is given a sunsetted2.
The developer makes the deployment process reliable, slowly removing manual steps until it is entirely automated and can be trusted to be reliable.
From the stakeholder’s perspective, the service runs, and you need to get paid every two weeks, and they don’t have to worry about it that much right now. The second set of options may or may not be rewarded like very fast responses are. Improving a system is a lot of work, sometimes keeping it running is good enough.
You might be thinking - wait, my boss is always pushing for really fixing and improving our systems. Your boss must be an engineer and has chosen The Hard Path.
Choose the Easy Path.
If you are reading this and thinking, “well it depends,” or “this is a gross oversimplification,” or “what an idiot,” then you might be interested in Additional Commentary for this post.
eradication: The act of plucking up by the roots; a rooting out; extirpation; utter destruction.
the second greatest euphemism in our business is saying something that is going away forever is being “sunsetted”. The greatest euphemism in our business is saying “in case Terry gets hit by a bus”, instead of saying “in case Terry resigns”