Solving the 'right' engineering problems
In engineering, it's easy to find problems. The code is never 100% perfect. The product never has all the features. But which problems are worth solving?
“We should refactor this code, it is too complicated and entangled.”
“Since we have sign in with Google, we should build sign in with Facebook as well.”
Sounds familiar? These and other thoughts are always going through my mind when I think about the products I build. But, unlike the past (junior) version of myself, I rarely action them these days.
As I get more experienced, I realize that engineering is not about solving all problems. It’s about solving the right problems. Despite what our brains may tell us, there will never be enough time to complete everything on our todo list. So naturally, some problems will get solved, while others won’t.
How do we decide what is right? I use a few different strategies.
Take a neutral position
As engineers, we see code of our products every day. This gives us insights into what can be improved, but it can also bias us into thinking that problems in the code are more important than they actually are.
For example, I used to work on a project which had a huge, 2000 lines of code file for sending emails. I always saw this file with the corner of my eye in my code editor, frustrated over how entangled and unsophisticated the code was. I also felt slightly embarassed that I was the author of it. What would other think?
Such frustrations and embarassments can lead us to push for changes - proposing that the code should be refactored in a team meeting. But that’s our emotions speaking; our personal relationship with the code.
So, we need to distance ourselves from our emotions and take a neutral position. If we ignore the embarassement and the sense of ‘code imperfection’, is this problem still worht solving?
Ask ‘how does this benefit others’?
I’ve asked this powerful question myself and others many times. Often, we forget that as engineers, we are here to benefit others - our customers, company and the team.
In the example I gave earlier, I wanted to refactor a 2000 lines of code file. So, what real problem does that solve?
In my case, the file was last touched a year ago, and it worked well to send emails to the customers. We never had any complaints about emails not working.
So, as far as our customers are concerned, this isn’t solving any problems. Neither does it solve any problems for the team, as the file was rarely touched. So the only person that benefits from this is myself and my ego. In other words, it doesn’t benefit anyone.
On the other hand, if the file was modified every week, and all team members always lost 1 hour when changing it, then a refactor could benefit the team.
Ask for data
“Let’s refactor this code to make it more performant”. Is this worth it?
This depends on data - how much more performant would it be? Would this make visible impact on company costs, or the customer experience?
For example, if the UI is visibly non-performant on mobile devices, this is a real, customer impacting problem.
On the other hand, if the code is already fast and customers are not noticing slow prformance, then it may not make sense to solve this problem, unless it would save the company money on infrastructure costs, for example.
As engineers we need to understand that our focus and time are limited. By asking ourselves the right questions about our problems, we can separate the right ones from the nice to have ones.
Remember to take a neutral position, understand the benefits, and ask for data.
“We should refactor this code, it is too complicated and entangled”
- Famous last words