Solve the Problem First

5 minutes, 3 links
From

editione1.0.1

Updated August 7, 2023

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.

โ€‹resourcesโ€‹

Take Ownership

If youโ€™re working towards a promotion to a senior role, your manager may tell you that theyโ€™d like you to โ€œtake more ownershipโ€ of certain projects or tasks that your team is responsible for. To many people, โ€œtaking ownershipโ€ sounds vague and ambiguous the first time they hear it. Take ownership of what, exactly?

There are a lot of differing opinions on what taking ownership means, so if your manager encourages you to do so, the best thing to do is to simply ask them what taking ownership means to them. Itโ€™s always good to clarify their expectations to make sure you donโ€™t miss something they are expecting you to do.

A developer taking ownership of something commonly means they are taking on more accountability for the success of a certain project or task. They are not necessarily the only one responsible for the success or failure of a project, but they will have a bigger influence on the outcome.

Youโ€™re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.
If you found this post worthwhile, please share!