Lost in Stack Traces

Debugging means playing a detective while staying at home.

Debugging is like being a detective without ever leaving home. Borrowing a term from Flutter, you operate inside a kind of SafeArea. All you need is good nutrition, a clear mind, maybe a rubberduck, and some recharged batteries. Well, you might say, an inspector in the real world protects lives. A software tester protects experiences – keeping users safe from frustration, confusion, and bad surprises.

A bug can appear in countless disguises. Sometimes it only shows up on a handful of devices that have missed an update of a third-party service or software package. It can occur only for some specific sequence of steps a user (or you as a curious, sometimes quirky and intuitive, maybe clumsy, but unstoppable tester 😉) performs while using an application.

Sometimes bugs hide inside different points of a stack trace looking like a haystack – perhaps caused by a single reason, or by multiple overlapping ones. Sometimes they vanish, caught in a try-catch trap and restored by previously set default values that happen to be accurate from a user’s point of view as they are okay with it or simply forgot. From most perspectives a bug may remain invisible, until – like a thief briefly uncovering his face – it suddenly reveals itself.

AI-generated image: Female nerd stuffed with chicken nuggets, ruminating …

Some anecdotes along the way

A user who needs high contrast of text and background, or someone likely to get overwhelmed at too much information, just trying to get ready, overlooking something important, may complain about that submit or buy-now button which, why the heck, does not work. I am a bit lazy, too, when it comes to reading the footnotes. They might leave their apps opened while doing something else, or receiving a test alarm message that keeps on piercing their eardrums, wondering what to do as onTap doesn’t do anything, until they finally … manage to swipe it up, which successfully rickrolls them out of … erhm what was I talking about again? Phew. Back on track.

Footnotes… yes. Those footnotes tend to be getting in your way all the time. Recently while I was ordering pizza, I overlooked some little, but important piece of information: the minimum order value was not yet reached, as the special offer was not included. Now I know. Next, I got caught in the act of not selecting the field “sir or madam” which doesn’t get stored in the auto-fill. Oh well, I couldn’t care less as they only say Hi…

A user may make a mistake to then wonder why they don’t receive any text message from a friend they have been chatting with, unaware of that boolean at some “mobile data for this app” which was turned off.

Another creative user trying to get ready fast, making some experiments, such as drag-dropping a whole calendar file with multiple events into an email client that then goes bananas, only leaving that exit of restarting the computer as killing the main process from the shell is not possible because the icon is behind the pile of open widgets and they forgot the shortcut.

Or they accidentally miss a Ctrl-C to then go and paste some previously copied, unwashed nonsense into an input field of a React app or even a PowerShell window. So please double-check before accepting the confirmation window which appears when you paste ChatGPT’s suggestion.

Side note: Please, don’t ever modify your Windows PATH variable from a PowerShell window, just because some AI tells you to. I did, and spent some extra quarter of an hour reconstructing the brilliant mess. The sequence of strings gets cut in the middle of nowhere. That’s what those wizards are made for, what you see there is actually what you get.

Photo by Monika V. on Unsplash

How many obstacles are on this picture? It depends on the path you take. A person riding a bike on the left might just walk, while the bus just passes by. And those e-scooters tend to fall on the sidewalk, hard to detect at low visuals.

Every case or bug is different.

And just as every crime scene requires a unique approach, experienced inspectors adapt their methods. Still, they rely on a common set of tools. Like fingerprints under the magnifying glass, a coder is watching variables at certain breakpoints. But be careful: Concurrent access or race conditions and manual inputs in a debugging session may induce extra time shifts that sometimes lead to a different behaviour.

At times, you need to know where to look.

• Watching the suspicious code in action, observing how it behaves far downlevel behind the scenes where no one is looking, such as a missing user-specific boolean value of turn_off_animations or is_darkmode covered behind some fancy tapestry of default values, only to be digged up if you set the right breakpoints and have the debugger attached to the device in consideration.

• Not afraid of filtering large issue boards for that specific behaviour.

• Writing some extra lines to test the behaviour without a debugger attached.

Code coverage: Anything that can happen…

• Writing a good bunch of ifs to avoid all kinds of null values, halfly done tasks due to a power cut or an empty batteries, making everything else break.

• Not finished purchases due to a bunch of possible third-party issues such as a user dropping a credit card, reaching a timeout on some third-party services you cannot even debug for, must be cleared from the database before any happy-purchase email gets sent.

Debugging is both zooming in and zooming out: sort of examining each piece of the jigsaw puzzle while never losing sight of the bigger picture, the users and their real scenarios.

Sometimes, the users may not notice the gaps, but you – the investigator – have to uncover them. Other times, the happy path guiding around the missing pieces will keep the users happy, too, without them ever noticing where a null value gets caught in a try-catch block. Just like a passenger sleeping in a taxi while the patient driver gently guides them around a jagged pothole.

Sometimes, worse is better.

The messy start that paves the way for a good finish. Fail first, fix before launch. A rescue net of null checks finely woven against a wave of user complaints that dampens the excitement of a successful launch.

A detective in the real world protects lives. A debugger protects experiences – keeping users safe from frustration, confusion, and bad surprises.

And when the culprit is finally unmasked, when the trail of clues snaps into place, there is a quiet satisfaction. Not the thrill of handcuffs clicking shut, but the softer reward of restored order: a program that runs smoothly again, as if nothing suspicious ever happened.

Photo by Nik on Unsplash