How I Answer When Asked How I Deal with Stress When Resolving Bugs

Summary

This article provides a systematic approach to dealing with stress when resolving bugs in programming.

Abstract

The article titled "How I Answer When Asked How I Deal with Stress When Resolving Bugs" shares a methodical approach to handling bugs in programming. The author emphasizes the importance of using version control systems like git to manage system versions. The article suggests reproducing the bug for better understanding and using logging frameworks to increase log detail if necessary. The author recommends reducing the scope of the problem by identifying where in the code the issue occurs, using unit tests to reproduce the problem, and isolating oneself from distractions to focus on the code. The article also highlights the importance of creating hypotheses and testing them based on a mental model of how the code works. The author encourages creating a different unit test for each hypothesis, making the system more robust and debugging easier for the next person.

Bullet points

Use version control systems like git to manage system versions.
Reproduce the bug for better understanding.
Use logging frameworks to increase log detail if necessary.
Reduce the scope of the problem by identifying where in the code the issue occurs.
Use unit tests to reproduce the problem.
Isolate oneself from distractions to focus on the code.
Create hypotheses and test them based on a mental model of how the code works.
Create a different unit test for each hypothesis to make the system more robust and debugging easier.

I’ll share what I know.

If you approach bugs correctly, you will be relaxed when resolving them. To do this, use version control, identify the bug with a logging framework, reproduce the problem with unit testing, improve its quality using refactoring (automated by a good editor), resolve doubts about the code using a debugger, Using the mental model you have of the system, test different hypotheses by creating new unit tests for each of them.

First, make sure which system version the bug appears on. I hope you already use a suitable version control system (e.g., git ). If you still work by manually copying files and directories, renaming files to foo.c.backup or anything else, you behave like an inexperienced amateur. In desperation, at least make a copy of everything (including the database and other resources) before you start messing with anything.

The second thing to do is reproduce the bug whenever you want. If it’s an intermittent bug, at least implement a way to detect when it occurs. You can do this by monitoring the process (if the program aborts), monitoring the system's logs, or using other tools (for example, monitoring network traffic, memory, or disk usage by the system).

Increase the level of detail in the logs if necessary (if you don’t use a decent logging framework that allows multiple levels, consider adopting one). As a last resort, even printf in critical locations helps.

Once you can reproduce or detect the bug, reduce the scope, that is, try to find out where in the code the problem occurs or at what point in time the problem occurs. You need to focus your attention, no one can keep all the mechanisms and exceptional cases of a reasonably complex system in their head all the time.

This is where the unit tests you should have written would help you a lot; It’s possible that one of them simply doesn’t cover the situation causing the problem. In this case, you first improve the unit test, or create a new one, and then you will have a quick and easy way — running a simple unit test — to reproduce the bug without depending on the rest of the system.

This task of writing the unit test is usually enough for you to discover what needs to be fixed in the system. If you don’t have unit tests implemented, this is a good time to start (but don’t stop there).

If, with detailed logs, a well-defined scope, and a unit test that reproduces the problem, you still don’t know why it happens, it’s time for “Focused (Deep) Work”, described in the book of the same name by Carl Newport.

Isolate yourself from any distractions (close social media, put your phone on Do Not Disturb), open your favorite editor and debugger (or IDE) (which I hope you master — these are your work tools; treat them with respect), and analyze everything carefully.

After reading the code a few times, know what the current version does. If it is not well readable, use the autoformatting and refactoring features (renaming variables and methods, transforming spaghetti code snippets into functions, etc.) to improve it.

Sometimes, this alone is enough to indicate where the error is. Still, inexperienced developers are afraid to touch the code (because they don’t use version control to give them security, because they don’t use powerful enough editors, or don’t know the features of IDEs) and get stuck in the quicksand of poorly written code. Add comments to anything unclear.

If you continue to observe the bug, you will need to start creating hypotheses and testing them based on the mental model you built of how the code works or should work, literally doing experiments, that is, applying the scientific method.

If you think a particular input is causing an infinite recursion that overflows the stack, create a unit test that outputs that input. If you think the system is leaking memory or connections, create a test that simultaneously generates multiple allocations or connections.

Create a different unit test for each hypothesis. Each test that passes is not a waste of time: it makes the system more robust and debugging easier for the next person working on it (probably yourself).

Programming

How I Answer When Asked How I Deal with Stress When Resolving Bugs

I’ll share what I know.

Stackademic 🎓