Introduction
Every developer knows that deep, sinking feeling of being stuck. Being “blocked” can happen to a programmer at any moment, whether it’s a feature story, an elusive bug, or designing the architecture for an application. Luckily, with experience developers learn how to keep moving forward and may even enjoy the challenge of being stuck on a challenging problem.
Getting unblocked is a skill and requires different techniques depending on the challenge and the developer’s work environment. In a large enterprise, you may choose to do pair programming, or work on a problem with another developer, to get another perspective into a problem. If the problem is especially challenging, you may even need go to a senior developer for help. When working alone, it’s a more intimidating challenge to get unblocked. It can feel like you against a world of possibilities and self-doubt. New developers may not know how to begin to break a larger problem into solvable pieces. Let’s break down solving the different kinds of problems that developers face in their jobs step by step.
Feature Stories
What Are We Doing Here?
A feature story is generally a task or multiple with the goal of adding something of value to a product. A feature story can be as small as adding a button to a website. Or, it can be as large as adding a new API to a web application. Given the range of possibilities that exist in a feature story, the first step to solving one is to make sure you understand the requirements. In a team setting, a product manager might have clearly written down the plan and purpose of a feature story. Even so, think of all the edge cases and side effects of implementing that feature and whether they may change how you approach solving it. You may not be completely sure what to implement and try to assume, which won’t end well. When I first started programming, it happened to me a couple times. I was in the middle or even completed a feature story before a product manager or senior developer asked me why I was doing X when I should be doing Y. A lack of communication causes misunderstandings and wasted time.
Has it Been Done Before?
The next step in solving a feature story is seeing if it’s been done before. In a large enterprise, a developer may have already done exactly what you’re trying to do. For example, it’s very likely another developer has done a database migration like one you’re trying to do. Looking through your organization’s GitHub history will help you learn the steps and standards you need to follow to do the migration.
If another developer within your organization hasn’t already done a story like yours, try just Googling the task. If you need to build a tooltip for your React application, are you really going to spend a month building the most perfect, responsive tooltip in 2022 when you can just spend a couple of hours installing the “react-tooltip” dependency and customizing it to your organization’s standards?
Break it Down
The most important skill I learned when doing feature stories is to break a problem down into manageable parts before attempting to solve it. Even if you have never written code before, you can at least try to create a checklist of steps before starting a story. For example, “create a class that does X” or “hook up a database to Y using Z framework.” I use this technique all the time when working with a new language or framework. After writing down the steps you’ll take, you can quickly start implementing what you learn from the framework or language’s docs.
Research
Have you ever worked on code from the 1970s? Or maybe you’ve worked on code written yesterday, but nothing seems to make sense. Developers like to call this legacy code. The times I’ve struggled the most with stories have been when working with legacy code. If you get into the code and nothing makes sense, you have options. In a large enterprise, there may be internal documentation for the area of code you’re working on. For example, there may be technical documentation explaining how a particular API works and how to interact with it.
You may even still work with the same person who wrote the code you’re trying to understand. If the code was written decades ago, this is much less likely. However, there could be a developer who is a subject matter expert (SME) in that part of the code. If the framework you’re using is unfamiliar or old, it could be helpful to read its documentation to make sense of it.
Bugs
If you’ve ever tried to program before, you’re probably very familiar with the concept of bugs already. When something unexpected or incorrect happens in a program it would be considered a bug. Bugs can be elusive and difficult to solve. This is because bugs can be anything from an internal language flaw to a programmer’s poor implementation of a feature.
Who to Call for Bug Problems
If you’ve already found the bug and can reproduce it consistently, you have an advantage. For error messages, you could try searching the exact error message and you might find out exactly what you’re doing wrong. If you’re using legacy code, you may discover a GitHub Issues page for that problem and see how others worked out around it. Or you may learn that nobody has been able to solve it yet! When I worked with Java 8, I once had a very specific error message caused by a language issue that was almost a decade old, but it was never solved.
Tooling for Pesky Bugs
If you can’t reproduce a bug consistently or it's time to solve one then it’s time to use your developer toolkit. The debugger is the most powerful tool you have. Depending on the language you’re using, you can go line by line and check the values of all the variables you’re using. You may even need to check individual threads for multithreaded applications.
If you can’t seem to reproduce a bug, you’ll have to get creative. You can set up monitoring to try to find patterns of when the bug occurs. For example, you can use a framework like Prometheus to find how often a bug occurs and whether it occurs with specific devices or versions. Some languages may even have useful internal tools that you can use to find bugs. If you’re using Java, you have a great toolkit available as part of the JDK you can use to profile your application.
When You Try Your Best and You Don’t Succeed
In the words of Chris Martin, sometimes you may just feel like you’re “stuck in reverse.” Though Chris suggests that “lights will guide you home,” I would suggest that developers try other techniques for when they can’t find a solution. Though it sounds counterintuitive, sometimes it can be helpful to step away from a problem. I’ve found going for a walk or even leaving the problem for the next morning can give your brain time to refresh itself and see a problem with a new perspective.
Programming is not a linear process. It’s easy (and misguided) to spend hours or days on the same problem without asking for help, taking a step back, or brainstorming other solutions. The number of hours that a developer works is not a good measure of their productivity. So, the next time you watch the hours tick by while sitting in front of your IDE, take a step back, ask for help, read documentation, and come back with a fresh perspective.
Photo Credits xkcd.com/530 xkcd.com/1741 xkcd.com/1172