Solve the Problem First

In the earlier section about managing risk, we explored the importance of planning ahead when working on large projects. That idea also applies to smaller, individual tasks you work on as well. When you pull a new ticket to work on, what you should not do is start coding right away, even if you think you may know how to solve the problem. It’s a trap a lot of developers fall into, and it’s potentially a risk because you could be wasting your time and effort implementing the wrong solution.

If you don’t have a good understanding of the problem, the requirements, and the acceptance criteria, you run the risk of shipping code that doesn’t actually solve the issue or that may not be the optimal solution.

So, what should you do when you start a new task?

1. Read the task description and take note of any requirements. It’s sometimes helpful to make a checklist of requirements so you can be sure you’ve checked them all off before submitting your code for review.

2. Read the task description again to make sure you fully understand the problem and what needs to be done. Sometimes it takes a few passes to fully understand what is being requested in the ticket.

3. Write down any questions you might have about any of the requirements in the ticket. It helps to get your thoughts out of your head and written down in case you get distracted or need to temporarily shift your focus to another task.

4. Browse through the codebase to get familiar with the code you think you’ll need to change. There may be technical debt you’ll need to work around, or there may be some abstractions that your solution may need to fit into, so it’s a good idea to poke around the codebase to make sure you know what you’re working with.

5. Come up with an implementation plan. By now, you should have a good understanding of the problem and any technical limitations you may need to work around.

6. Start coding.

Once you’ve worked through all the steps above, the actual coding part should hopefully go smoothly. If you’ve done good research and planned out what changes need to happen before writing any code, it should be fairly straightforward to implement your plan. Most of the work was already done ahead of time, so you just need to translate that plan to code a computer can understand.

By doing all the heavy lifting during the planning phase, you’re reducing the probability that you’ll need to change direction and rewrite code. Don’t assume that code is easy to change and that you can just delete it and write it again. Changing direction after you’ve begun implementing a solution costs money, especially when you’re dealing with large codebases with millions of lines of code.

​important​ It is faster and cheaper to refactor an idea than it is to refactor code.

Solving the problem first allows you to move faster because you’ve already identified how your solution will fit into the existing code, and you already have an idea of what code needs to be refactored, improved, or moved around to implement your solution. Plus, you can present your solution to your teammates to gather feedback before writing any code. It’s possible they may come back with questions or concerns, or they may suggest a better approach that is more efficient or simpler than your original idea. (Occasionally, on complex and important problems, an engineer might both design and prototype multiple solutions—for example, to then compare their performance. But this is a rare situation.)

In order to move quickly and deliver results consistently, you need to learn how to think strategically. Spending time upfront planning your implementation before coding it will reduce costs and time later when it comes to coding your solution.