In most production cases, there is no luxury of debugger.
In my current $job, all we get is logs from 70+ node cluster and that too in a shared-nothing architecture. You have to stitch together varied datapoints (job logs on multiple nodes, netstat o/p, job logs of other services, http access logs, tcpdump, etc) to even prove that problem is on the customer side and not ours.
The article is a bit of a "dog bites man", but itsobservations are valid. False assumptions are what caused > 50 per cent of my bugs, and for bugs in production, reasonable logging is what you need. The point with going away from the computer and letting your brain process things is good too, and the point about postmortem is spot on. I hate it when my colleagues say "fixed" without explaining how the error emerged in the first place, and they mostly already learnt to supply context to correction of non-trivial bugs. (I try to lead by example and send detailed e-mails after major fixes.)
Sure, nothing in the article is wrong. But if someone has to be told most of these things, and they already are a professional developer? What were they doing when they were supposed to be learning their profession?
I feel they might have replaced an AI-generated em-dash here: "Set up a short chat or team session to share your debugging tricks - what’s working, what’s not, where time gets lost."
It's pretty crazy the number of times I've banged my head against the wall trying to fix something... and then I'll either step away for an hour, or just come back the next day, and I'll have it fixed in minutes. It really does work sometimes.
When I was trying to learn to code as a kid, I struggled for days trying to wrap my head around the concept of a variable.
I the concluded that programming isn't for me and left the bloodshed ide untouched.
Two weeks later, I was watching TV. And out of nowhere it just hit me. I finally understood what variables are! I ran to the computer to test my assumption, and it was spot on.
To this day, 20+ years later, I still remember the feeling of everything suddenly falling into place!
I was lead dev once and the unofficial "rubber duck." I'd always get called over when someone was stuck on a thorny problem, lean over their shoulder and ask them to explain it and it was always instantly "Oh! I see it now, thank you!" and I had done nothing.
I remember playing a logic game which required lots of thinking to solve it. Then at some point I stopped trying to actively solve it, I just simply stared at the game without trying to solve it, and after a while I tried to solve it. Guess what? I solved it at first attempt, without knowing how! This was really curious and it made me excited so I tried to keep doing it this way and turns out it was not a fluke, this method seemed to work consistently.
I did some research on it and this phenomenon is called "incubation" which is a core concept in the psychology of creativity and problem solving. Apparently it's frequently observed in puzzles, mathematical problems, and design tasks that require restructuring rather than mere computation.
In your case, conscious and effortful thinking can lead to functional fixedness or mental set, where you become stuck on an unproductive strategy, so taking a break allows these rigid patterns to weaken, making space for more flexible or creative approaches.
In psychology, incubation refers to the unconscious processing of problems, when they are set aside for a period of time, that may lead to insights. It was originally proposed by Graham Wallas in 1926 as one of his four stages of the creative process: preparation, incubation, illumination, and verification. Incubation is related to intuition and insight in that it is the unconscious part of a process whereby an intuition may become validated as an insight. Incubation substantially increases the odds of solving a problem, and benefits from long incubation periods with low cognitive workloads.
In my day, when you encountered a tough problem, you'd go outside and have a cigarette, and the solution would magically come to you. Thank God I quit that poison, and have since learned that a brisk walk can accomplish the same goal. But back then it was a joke amongst peers - cigarettes will solve your problems!
Generally speaking, I still like the old-school idea of recreating the buggy production environment in dev environment by export/import of production data to dev env and debug from there.
However, is the problem occured in a SaaS web applications, there are modern cloud logging tools that can help. I found and used Posthog lately and it records user activity on the go, and can even record videos of your web application while it runs and is used by customers. This way you can have both text logging and video logging. Maybe it can be useful to somebody. The good thing about posthog is that it's not difficult to stay inside their free tier
These were the techniques taught to me in college in 1989 when I learned how to debug. We didn't have git back then. Sometimes taking a break helps if you get stressed out and stuck. I worked with a Marine in 1996-1997 at the ATCOM Army base who taught me that going to the snack bar and buying a soda and a bag of chips is the best way to refocus your brain on the problem. Take a walk as well.
Maybe the “go buy a bag of chips” is a way to force the walk to happen.
I tend to do the same though, walk away for a bit and then return to the problem. Sometimes longer breaks are needed though so I might pivot to a different problem for a while.
When I started programming debuggers were very good. Windbg for example was incredibly powerful, you could debug the Windows kernel, boot process, run scripts, author plugins, anything.
And yet here decades later this list about debugging doesn't even mention a debugger, and in many environments they are worse and harder to use than what we had before. I'm so disappointed!
None of these debugging tips involve the use of a debugger, arguably one of the most efficient ways to debug.
In most production cases, there is no luxury of debugger.
In my current $job, all we get is logs from 70+ node cluster and that too in a shared-nothing architecture. You have to stitch together varied datapoints (job logs on multiple nodes, netstat o/p, job logs of other services, http access logs, tcpdump, etc) to even prove that problem is on the customer side and not ours.
"But I can just add print statements" is the bane of my existence.
If they really insist then I encourage them add trace logging instead so at least it's not wasted effort.
The article has slop slurping all over from it
The article is a bit of a "dog bites man", but itsobservations are valid. False assumptions are what caused > 50 per cent of my bugs, and for bugs in production, reasonable logging is what you need. The point with going away from the computer and letting your brain process things is good too, and the point about postmortem is spot on. I hate it when my colleagues say "fixed" without explaining how the error emerged in the first place, and they mostly already learnt to supply context to correction of non-trivial bugs. (I try to lead by example and send detailed e-mails after major fixes.)
Sure, nothing in the article is wrong. But if someone has to be told most of these things, and they already are a professional developer? What were they doing when they were supposed to be learning their profession?
I think it could be useful for youngsters fresh off the college, where you learn a lot of theory, but much less practice such as debugging.
I feel they might have replaced an AI-generated em-dash here: "Set up a short chat or team session to share your debugging tricks - what’s working, what’s not, where time gets lost."
It's pretty crazy the number of times I've banged my head against the wall trying to fix something... and then I'll either step away for an hour, or just come back the next day, and I'll have it fixed in minutes. It really does work sometimes.
When I was trying to learn to code as a kid, I struggled for days trying to wrap my head around the concept of a variable.
I the concluded that programming isn't for me and left the bloodshed ide untouched.
Two weeks later, I was watching TV. And out of nowhere it just hit me. I finally understood what variables are! I ran to the computer to test my assumption, and it was spot on.
To this day, 20+ years later, I still remember the feeling of everything suddenly falling into place!
I was lead dev once and the unofficial "rubber duck." I'd always get called over when someone was stuck on a thorny problem, lean over their shoulder and ask them to explain it and it was always instantly "Oh! I see it now, thank you!" and I had done nothing.
https://en.wikipedia.org/wiki/Rubber_duck_debugging
I agree. The brain works in mysterious ways.
I remember playing a logic game which required lots of thinking to solve it. Then at some point I stopped trying to actively solve it, I just simply stared at the game without trying to solve it, and after a while I tried to solve it. Guess what? I solved it at first attempt, without knowing how! This was really curious and it made me excited so I tried to keep doing it this way and turns out it was not a fluke, this method seemed to work consistently.
I did some research on it and this phenomenon is called "incubation" which is a core concept in the psychology of creativity and problem solving. Apparently it's frequently observed in puzzles, mathematical problems, and design tasks that require restructuring rather than mere computation.
In your case, conscious and effortful thinking can lead to functional fixedness or mental set, where you become stuck on an unproductive strategy, so taking a break allows these rigid patterns to weaken, making space for more flexible or creative approaches.
(for those interested in reading more about this...)
https://en.wikipedia.org/wiki/Incubation_(psychology)
In my day, when you encountered a tough problem, you'd go outside and have a cigarette, and the solution would magically come to you. Thank God I quit that poison, and have since learned that a brisk walk can accomplish the same goal. But back then it was a joke amongst peers - cigarettes will solve your problems!
But you can't just step away. A certain amount of headbanging (and desperation or anger) is needed to trigger your brain background processing.
Generally speaking, I still like the old-school idea of recreating the buggy production environment in dev environment by export/import of production data to dev env and debug from there. However, is the problem occured in a SaaS web applications, there are modern cloud logging tools that can help. I found and used Posthog lately and it records user activity on the go, and can even record videos of your web application while it runs and is used by customers. This way you can have both text logging and video logging. Maybe it can be useful to somebody. The good thing about posthog is that it's not difficult to stay inside their free tier
These were the techniques taught to me in college in 1989 when I learned how to debug. We didn't have git back then. Sometimes taking a break helps if you get stressed out and stuck. I worked with a Marine in 1996-1997 at the ATCOM Army base who taught me that going to the snack bar and buying a soda and a bag of chips is the best way to refocus your brain on the problem. Take a walk as well.
Maybe the “go buy a bag of chips” is a way to force the walk to happen.
I tend to do the same though, walk away for a bit and then return to the problem. Sometimes longer breaks are needed though so I might pivot to a different problem for a while.
Testers don’t debug anything. If you are a tester and you debug something, you are a developer and must be judged as a developer.
Testers investigate things, though.
Logging is a hack now ?
> Debug like a boss
Okay.
"Bob, do you have cycles to take on this ticket? Customer says that the application is unresponsive."
When I started programming debuggers were very good. Windbg for example was incredibly powerful, you could debug the Windows kernel, boot process, run scripts, author plugins, anything.
And yet here decades later this list about debugging doesn't even mention a debugger, and in many environments they are worse and harder to use than what we had before. I'm so disappointed!
Is it just me or is this yet more ChatGPT output?
Yeah I thought it was maaaybe human but this line made me think it's AI:
> Short sentence 1. Short sentence 2. That’s debugging like a boss.
No human writes like that. I suppose the average of all humans does, though :-)
Yea, it's full of AI slop like "It's not X, it's Y!":
> Half the bugs you chase aren’t in your code. They’re in your head.
> You’re not asking for their input, necessarily. You’re asking to have someone listen to you so you can think straight.
> The truth is in the path, not the punchline.
> The log is not your diary. It’s your surveillance system.
> Debugging isn’t just thinking. It’s re-thinking
> These 10 tips aren’t a checklist: they are a starter kit.
> Logs are your sidekick, not your saviour.
It's like typical LinkedIn post made by tech evangelist.