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.)
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."
devnull3|4 months ago
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.
cube00|4 months ago
If they really insist then I encourage them add trace logging instead so at least it's not wasted effort.
miohtama|4 months ago
inglor_cz|4 months ago
kazinator|4 months ago