We developers love to solve problems, it is probably the largest source of dopamine we can get at work so we seek it like an addict. These problems we find can be both technical and product related, it doesn’t matter as long as there is something we can throw the energy at, get in the flow and after one too many cups of coffee have the privilege of exclaiming “Eureka” to the team like some modern day Archimedes, hopefully without the running nude around the office part.

Some product managers will read this and think: “Yeah, I know, they always come to me with requests to refactor half the codebase when we only need a quick change to cover an edge case, or change some tooltip text”. Yes, I’m aware, I’ve done the same in the past, and I think it happens because when this change is discussed we spend too much time on the what and the how instead of the why, Simon Sinek has something to say about this, enough that he wrote the whole book titled “Start With Why” and for a good reason, because I also see this happening all the time.

When we describe the how and what we are not setting a problem to solve, we are handing out instructions instead, and following instructions doesn’t scratch that problem solving itch nearly as well. Presenting each issue with a context of why it needs fixing, how many users it affects or how much money it costs us, makes the expected outcome clearer and, more importantly, it clarifies how much effort a solution warrants. Sometimes there are situations when at first a fix seems quick, but it turns out to be a mountain of work when we actually start working on it or we discover skeletons hidden in the closed from before. When a developer understands the why of the issue then they are much more likely to take a step back and quite possible start thinking about if the effort is worth it or if there is an alternative solution that would reach the same goal. This is exactly what we want because the alternative is potentially wasting a lot of time.

This also extends to actual refactoring and optimising efforts, I think these are still important as ever and probably need an even bigger focus on why. Let’s focus our discussions on why we are rewriting something, and it’s not because “the code is ugly” it’s because it gives a meaningful and impactful outcome, the why in these cases is because the user experience is bad due to slowness or the developer experience is bad due to the mangled mess that every codebase tends become given enough time.

I’ve only really seen developers spending huge amounts of time (prematurely) optimising and refactoring when the reason why the changes are needed are not clear and the problem solver’s mind gets urged to find a problem that isn’t important right now. And rest assured, the problems will be found, every codebase is absolutely littered with them, it’s just a matter of understanding which ones are worth the time and energy investment and the best way to ensure everyone understands that is by focusing the discussions on why. So next time you feel like an unreasonable amount of time was spent solving a minor issue, think about how the problem was presented, was it more the what and the how, or the why.