It’s easy to assume the most important part of a software engineer’s job is coding.

But actually, the most important thing engineers do is solve problems — coding is just a skill they use to create the solutions.

Think about it: When a project fails, or even when it just takes way longer than it should, is it because of problems with the code? Usually, no. It’s because the engineer carefully built something that technically worked, but didn’t solve the right problem. In that case, it’s back to the drawing board for the developer, which is a huge—yet common—waste of time and resources.

This is part of what makes the job so challenging. Learning to code is no walk in the park, but learning to be a good problem solver might be even tougher.

Luckily, problem-solving is like any other skill. With practice, you can become a better problem solver, and thus, a better engineer.

Understand, Design, Build: The World’s Simplest Problem Solving Framework

We recommend a three-step approach to problem-solving: Understand, Design, Build. By following those three simple steps, engineers can finish projects in less time, with less backtracking, and with better results that solve big-picture business problems.

Here’s how it works.

Step 1: Understand the Problem

Before you go any further, stop and ask yourself these questions:

• What’s the business outcome you need to achieve?
• What’s standing in the way of achieving that outcome right now?
• Have you solved a similar problem before?
• Is there something in your existing codebase or infrastructure that can be reworked or directly applied to this problem?
• What do you need in order to solve this problem?

If you don’t know the answers to all those questions, you don’t understand the problem. If you move on to designing or building a solution without understanding the problem, you will realize at different points during the process that you’re missing information you need.

That’s why it’s so key to resist the urge to jump right into coding and to use every step of this framework. And once you have a rock-solid understanding of the problem, keep resisting, because there’s still another step to complete before you write anything.

Step 2: Design Your Solution

Before you start coding, you have to have a more fleshed out plan. You have to design your solution—or multiple solutions, because the first one you come up with isn’t likely to be the best one. Sorry, not sorry.

Consider multiple different approaches that will land at the business outcome you identified in Step 1. And as you identify possible approaches, think about the benefits, risks, and mitigations of each one.

Coming up with all these different approaches could look like a few different things in practice. Try these techniques to find some possible solution designs that might be worth pursuing:

• Group of individual brainstorm
• Whiteboarding exercise
• Design doc
• One pager
• Technical design review

The key thing to understand about this part of the process is that, as a company ages, it’s likely to become more complex. The simple problems tend to get solved in a company’s early days, which means problem-solving begins to go beyond pure implementation and become more creative work. There may not be an exact right answer to solving your problem, but by considering as many approaches as possible, you can compare the costs and benefits of each and hopefully land on the best solution.

A solid framework for this is First Round’s Benefits, Costs, and Mitigations strategy. Create a simple table, like this, to compare all the possible solutions you’ve targeted.

This isn’t too different from a simple pros and cons list… until you get to the mitigations section. That’s where you brainstorm ways to adjust your plan to create more benefits and fewer costs.

Step 3: Build the Best Solution

By fully understanding the problem at hand, and then taking time to carefully consider the pros and cons to multiple different approaches to solving it, you should now have a deep and thorough understanding of the solution that will best solve the problem. Now it’s time to build it.

And after step 2, you should also have a good plan for how you’re going to build it. The hard decisions have been made. Now you get to plug in your headphones, put on a great new album and crush it.

When you use this problem-solving framework, the actual building is no longer the hard part. It’s like in English class when you had to outline your paper before you wrote it. All the points for your project are there are planned out. It’s time to connect the dots.

And the best part: With such a solid plan in place, you know that what you code will be a great solution for the problem. No backtracking. No rewriting. Just coding something awesome.

UDB: Why It Works

Every engineer has been in a position where they’ve had to backtrack to rewrite code that isn’t working, or they’ve finished a project just to discover it doesn’t meet the business needs of the project. Can such a simple framework really eliminate those kinds of failures?

That’s why this three-step process works—it addresses those common reasons and ways engineers get their jobs wrong.

Very few people are lucky enough that problem-solving comes naturally to them. But adopting this framework and then practicing it will allow you to develop and hone those skills, making you a better problem solver, and in turn, a better engineer.