Infuriating, facepalm-inducing, but with an intensely satisfying payoff when (if!) you figure them out, bugs are an unavoidable part of being a developer.
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:
customer reporting that the new software was not printing the letterhead. The letterhead is fed in from a different tray in the printer. The letterhead tray was empty.
— My dad calls me brucellosis. (@brucelowther) March 1, 2021
During internship a long time ago. Everyone got paged, servers down!!! We rush to the office (yea, they hat the servers in the office) and found the cleaning lady needed a power plug while vacuuming the server room 😅 (true story)
— Bart 全部技術 (@ZenbuTech) March 5, 2021
An employee who complained that the web app often wanted a fresh login during work. Searched and debugged nearly everything until we found out that this employee let other people work with their pc and cleaned the browser cache afterwards but wasn't aware that this reset the app.
— Bernhard Rausch (@rauschbit) March 1, 2021
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.
Debugging tip 3: Computers do what you tell them to
We asked you for examples of your most unexpected culprit when debugging.
Me 🤣
— Steven เด็กน้อย (@TweetsByBooth) March 5, 2021
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.
DNS, it's always DNS!
— cronopio (@cronopio2) March 5, 2021
If not, is definitely SELinux
— Łukasz Korbasiewicz (@korbasiewicz) March 5, 2021
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
