Imagine there is a group of programmers that is asked to solve a programming problem in the least amount of time. There are bookmakers accepting bets on which programmer is going to be the fastest. You decide you want to place a bet, but there is a catch: all programmers have equal backgrounds and experience. How do you decide which programmer is going to be the most productive?
Winning by not Losing
Researchers from Carnegie Mellon University conducted a study on programmer productivity. One thing they observed is that programmers are closer in performance to each other than previously thought. But more interestingly, they found that programmer productivity is strongly influenced by extremely negative performances. In their research, programmers tried to solve 10 problems. The participants were able to solve most problems quickly (e.g. in about 1 hour). But for every problem, there was a small group of programmers that took significantly longer (e.g. up to 6 hours). This group was different for every problem, and most programmers underperformed for at least one problem. They concluded that average productivity is heavily influenced by those few moments of being stuck.
The key to being productive is not to excel but to avoid getting stuck. Instead of focussing on improving your best moments, try to reduce the damage of your worst.
A good way to improve one's productivity is thus to limit long problem-solving sessions. In this article, I will share my experiences with these sessions and give tips on how to reduce problem-solving (and specifically debugging) time.
But before I begin I would like to emphasize that often it is even better not to go down the debugging rabbit hole alone. Pair programming and asking questions in time are good ways to reduce debugging time. If you do however find yourself alone with a problem, hopefully, this article will help. Let's dig in!
The Debug Maze
I like to compare debugging with being stuck in a debug maze. This debug maze is like a regular maze, but with a few special properties. The debug maze is like the one in the image above. You can see where you want to go: a working program. To get there, you can take many different routes. The debug maze is more challenging than your typical real-life maze though, because it has almost infinitely many possible routes to the exit (ways of trying to fix the bug).
Luckily, the debug maze has a special property that we can take advantage of when finding the way out.
Think of your last long debugging sessions. How long did they take? And more importantly, how complex did the solution turn out to be? I remember those sessions being hours long and, to be honest, my last such session was not too long ago. The solutions to the problems were often actually very simple! They often involved upgrading one version of a package, changing one line of a configuration, or adding one if-statement. We can take advantage of this: we know the debug maze often has a short route to the exit. We just do not know which one it is yet.
Knowing this, how can you save time when there are infinitely many routes to try? By realizing that when you're on a long route, it's probably the wrong one. Leaving it may be challenging, though, because of what is called the sunk cost fallacy.
The Sunk Cost Fallacy describes our tendency to follow through on an endeavor if we have already invested time, effort, or money into it, whether or not the current costs outweigh the benefits.
If you have been changing multiple pieces of code for hours without much progress, you are probably following a track that will not bring you to the solution. Mentally it can be hard to let go of your conviction because it feels like a waste of time, right? But often that time is already wasted, even if you continue on your path. After most of my long debugging sessions, in hindsight I wished I had abandoned my initial strategy earlier.
按照标志
So taking a step back and trying a new strategy early can help. But, which one? Luckily for us, the debug maze has another special property: it has signs. These signs point toward the exit. If only real mazes had those! These signs are what we observe during debugging, such as the behavior of the system, logs, monitoring, error codes, and stack traces. The problem for us is, of course, we do not always understand the signs. We often comprehend parts of them, but for me long debug sessions arose precisely when I did not fully understand the signs (but thought I did):
I have worked with Maven now and then for years, to manage external dependencies of a project. From the start, I did not like Maven. I always got into problems with dependency conflicts and mismatches of different packages. I of course blamed all of this on Maven...
Years later, I came across an article on dependency management in Maven on their website. I read it thoroughly and really gained a better understanding of how Maven manages the dependencies under the hood. It dawned on me that I had always understood Maven only partially. In other words, I had not been able to fully comprehend the signs of the debug maze. Reading the article greatly reduced the amount of time I needed to debug Maven issues.
So next time when you are stuck debugging and looking for a new strategy, remember: try looking up the basic theory behind your problem. In the past, a flawed understanding of a technology has led me further astray from the solution than not knowing anything at all about it. Not knowing anything about a technology forces you to learn the fundamentals before diving in.
Can't find the Solution? Stop Looking.
Sometimes you just cannot seem to figure out the problem. You tried all the solutions you (or Google) could come up with and you are still stuck. In my experience, the best thing you can do when you can't find the solution is to stop looking.
I think we are all familiar with a downward spiral of negativity. Albeit frustration, anger, indifference, or a feeling of incompetence: it keeps getting worse. This study found that being stuck in problem-solving is one of the top causes of unhappiness among programmers and another brought to light something rather obvious, namely that unhappy programmers become less productive. This is why problem-solving can start a negative spiral, which you want to break out of as it only becomes harder to solve the problem while spiraling down.
So despite how hard it is to let go of a problem, take some distance. Taking distance does not mean giving up, although it does feel like that sometimes. Know that when you come back with a calm mind and a fresh perspective, you might solve the problem in no time.
Conclusion
Long sessions of problem-solving have a big effect on a programmer's average productivity. Such sessions can be like trying to find the exit of a maze: the debug maze. It differs from a normal maze in that it typically has a simple and short route to the exit and provides signs that can guide you to it, but only if you are able to read them.
The next time you are stuck alone with a problem, remember these tips:
- The solution is often simpler than you think
- If your solution takes many steps and hours to complete, it is probably not the right one
- Go over the fundamentals of the technologies at hand for better insight and inspiration
- Do not allow yourself to go down a downward spiral of negative thoughts during problem-solving. Try to recognize this in time and come back later. It is not admitting defeat but rather preparing for victory!
Of course, these tips do not apply to every situation. Some problems do require more complex solutions. In any case, I think the best way to avoid long debugging sessions is to combine forces with colleagues.
Do you have more tips on escaping the debug maze? Leave them in the comments!