Hacker News Reader

Comment by troebr | Hacker News Reader

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

Reply on news.ycombinator.com