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."
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.