Problems vs. Tasks in Software Engineering
Awhile back, I was part of a group of employees who participated in a week-long data intensive run by our parent company. It was a really worthwhile experience where we all put in time and effort to solve interesting problems we saw at the company. One of the things that has stuck with me throughout the process was something we actually learned on the very first day — there is a difference between problems and tasks.
As a software engineer, this is something I’ve dealt with on a regular basis, but haven’t always thought about in such explicit terms. So what’s the difference between a problem and a task? Problems have many possible solutions and figuring out the right one for a given situation allows for ownership of that solution. Tasks, on the other hand, are a known entity. There’s already a solution, and you only have to physically go through the steps of completing it. There’s not much thought required, and if the task popped up frequently enough, you’d consider automating it.
One of these things sounds much more interesting than the other, and I’m sure software engineers generally prefer problems over tasks, but the truth is that our jobs are a mix of the two. And it’s important to figure out the right balance for ourselves and our companies. Tasks are often things that haven’t been prioritized for code fixes. We see a lot of tasks when business processes and internal tooling bifurcate. This can be frustrating, but sometimes you also just want to go ahead and accomplish something in a straightforward way. It can feel rejuvenating to do something productive that doesn’t require a full cognitive deep dive.
On the other hand, having too many tasks and very few problems often leads to boredom. When I’m in this situation, I feel like I’m bogged down in the day to day and don’t have space for any future planning. When the balance between tasks and problems is particularly task heavy for any project, I take it as a sign that there are gaps in the software that need to be prioritized and programmatically addressed.
Part of the reason this distinction between problems and tasks has stuck with me is because it helps me gauge my daily work a bit differently. Hitting a dead end when researching possible solutions for a problem is never fun. It can be useful to have some more straightforward tasks on hand to help mentally reset and shake off feelings of discouragement. But having problems to solve is a necessity. Without problems, many engineers would likely feel unengaged with their work. Finding the right balance between problems and tasks is a good skill for an engineer to have. It includes discussion and compromise between business stakeholders and engineers. It also requires knowledge about how your company functions. But most importantly I think it requires a deep understanding of how you work and, in turn, of yourself.