Problems vs. Tasks in Software Engineering

What’s the difference and finding the right balance

Crystal Chang
Nov 6, 2019 · 3 min read
Photo by Daniel Cheung on Unsplash

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.

Thanks for reading! To learn more about Flatiron School, visit the website, follow us on Facebook and Twitter, and visit us at upcoming events near you.

Flatiron Labs

We're the technology team at The Flatiron School (a WeWork…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store