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.
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 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!
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
10 comments
[ 2.8 ms ] story [ 35.3 ms ] threadAnd 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!
Okay.
"Bob, do you have cycles to take on this ticket? Customer says that the application is unresponsive."
Testers investigate things, though.