3 Debugging tips we learned from you

Rebecca Dodd ·
Mar 31, 2021 · 4 min read · Leave a comment

Infuriating, facepalm-inducing, but with an intensely satisfying payoff when (if!) you figure them out, bugs are an unavoidable part of being a developer.

Programmer debugging meme

When senior developer evangelist Brendan O'Leary shared with us this amusing story about a "bug" he solved in a previous role, we knew we had to ask you about your most elusive bugs. Now we're sharing some of the best bug stories with you, along with some lessons.

Brendan's example was in fact not a bug at all, but actually the result of an employee resting their purse on the keyboard. This is the first lesson: 

Debugging tip 1: It might not be a bug at all

A surprising number of "bugs" actually have nothing to do with code. One of the first principles of debugging is to reproduce the bug to get started. If you can't do that, it could be a sign that, er, human factors are at play. Consider this example from @MrSimonEmms on Twitter:

I once spent an entire day chasing down an error because I put a backtick in – originally, I thought it was a piece of dirt on my screen. (This was 15+ years ago and the stacktrace wasn't even erroring in the correct file)

In fact, when we asked for your stories, user errors came up a lot:

As Brendan noted in his story, "The lesson is that as humans interact with systems – or as systems become complex enough to take actions on their own – they will make mistakes. And while you can't possibly anticipate every one of those mistakes from the onset, when you encounter one, you can work on making sure you have observability at every level so you can see it when it happens."

Debugging tip 2: Get the receipts

This comment perfectly demonstrates why it's critical to require details such as Screen IDs when users or customers submit bug reports.

LinkedIn comment: "a customer sharing over and over again the same old screenshot claiming that the bug still exists ... That's why all screens have now a small screenID and Version number that is required when screen-shotting issues and bugs!"

Debugging tip 3: Computers do what you tell them to

We asked you for examples of your most unexpected culprit when debugging.

We appreciate the above commenter's self awareness, which brings us to our next lesson…

The code always does exactly what you tell it to – you just might be asking it to do something different from what you really meant. To get to the bottom of things, ask yourself what you expected the code to do versus what it actually did, and from there you'll usually find the answer staring you in the face.

Debugging tip 4: When in doubt, investigate the usual suspects

Occam's Razor is your friend. It's often useful to rule out the obvious before you get too deep in debugging. Of course, no post about debugging would be complete without an off-by-one error, so we couldn't resist sneaking it into the title of this post (see what we did there? 😉)

Your own codebase will no doubt have its usual suspects, as the interaction below demonstrates, so those are a good place to start.

Whether bugs drive you to distraction or you enjoy the challenge (probably both?), we want to hear about yours! Share in the comments below or tweet us @GitLab.

Thumbnail photo by Andrew Wulf on Unsplash

Open in Web IDE View source