Don’t look down on print debugging

When print debugging shines

• Seen as a universal, low-friction tool that works across languages, stacks, and odd environments (embedded, legacy, weird game consoles, distributed systems).
• Especially useful early in an investigation to “bifurcate” the code: sprinkle prints, run once, see where behavior diverges from expectations.
• Favored when debugger setup is painful, impossible, or slow (complex build scripts, remote targets, interpreted languages with slow debug mode, missing symbols).
• Useful when code must run at full speed to reproduce bugs (optimized builds, real-time streams, UI/web frontends).

Strengths of debuggers

• Many argue that relying only on prints leaves a lot of power unused: call stack inspection, watches, conditional/logging breakpoints, pretty-printers, time-travel, cross-process debugging.
• Debuggers can be dramatically faster than compile–run–inspect print loops once configured.
• Some say heavy print users often don’t know modern debugger capabilities, though others push back on that generalization.

Logging vs ad‑hoc prints

• Distinction made between temporary “printf here” debugging and structured, level-based logging designed from the start.
• Several see ad‑hoc prints as proto-logging; once in production they effectively become logs, for better or worse.
• Linters, pre-commit hooks, and CI rules are recommended to prevent debug prints leaking into main branches or production.

Concurrency, distributed, and timing issues

• Many note debuggers can distort timing or pause only one thread, making race conditions harder to see.
• Prints (or lightweight tracing) can still perturb timing but can reveal interleavings and narratives over time.
• Some prefer specialized tools (race detectors, valgrind-like tools, tracing systems, time-travel debuggers) over either prints or classic debuggers for concurrency.

Tooling quality and ergonomics

• A recurring theme: debugger UIs are often clunky, language- or IDE-specific, or brittle in modern web/toolchain stacks.
• Poor debugger UX is cited as a main reason print debugging persists; where debuggers are smooth and integrated, usage rises.
• Some note that “printf vs debugger” is a false dichotomy; the right tool depends on stack, environment, and problem.

Culture, learning, and “shame”

• Several reject shaming around prints; what matters is speed and reliability of bug-fixing, not the specific tool.
• Others frame debugging style as a team-level concern: it affects documentation, onboarding, CI, and shared tooling.
• Common view: everyone should know both approaches well and choose pragmatically rather than ideologically.