Don’t look down on print debugging

If a good debugger is available, it is a great tool to have. But it is just one out of many tools. Some are more effective than others in different situations.

For example, I rarely used a debugger in my career as an Android driver developer (mostly C), for several reasons.

1. My first step when debugging is looking at the code to build working hypotheses of what sort of issues could be causing the incorrect behavior that is observed.

2. I find assertions to be a great debugging tool. Simply add extra assertions in various places to have my expectations checked automatically by the computer. They can typically unwind the stack to see the whole call trace, which is very useful.

3. Often, there only choice was command-line GDB, which iI found much slower than GUI debuggers.

4. Print statements can be placed inside if statements, so that you only print out data when particular conditions occur. Debuggers didn't have as much fine control.

5. Debugging multi threaded code. Prints were somewhat less likely to interfere with race conditions. I sometimes embedded sleep() calls to trigger different orderings to occur.

I agree with the title that you shouldn't look down on print debugging. You should look down on people who are slow at fixing bugs and who refuse to try tooling to be able to keep pace -- and using print statements can sometimes be a marker of this. But print debugging is just a tool and has its place, and the use of print debugging is not itself an indicator of poor developer performance. If you can find/fix bugs as quickly as I can with a debugger using print statements, then I don't care what you use. If you can do it faster, then I'm going to try to steal your techniques so I can be faster too. If you do it slower, then I hope you would steal my techniques.

Don't care about the tool care about the performance.

Anecdotally, debuggers are faster than print statements in most cases for me. I've been able to find bugs significantly faster using a debugger than with using print statements. I still do use print statements on occasion when I'm developing something where a debugger is very complicated to set up, or in cases where I'm dealing with things happening in parallel/async, where a debugger is less suited. I'm not going to shame you for using print statements, but I do hope that you've tried both and are familiar/comfortable with both approaches and can recognise their strengths/weaknesses -- something I'm not convinced of by this author, which only outlines the strengths of one approach.

Also not a fan of the manufactured outrage of saying people are being "shamed" for using print statements. Coupled with listing a bunch of hyperbolic articles -- many of which don't even seem to be about debugging but about logging libraries.

(Also as a side note: don't forget if you are using print statements for debugging to check if your language buffers the print output!! You'll likely want to have it be unbuffered if you're using print for debugging)

Agree, there are some time travel debuggers though but either only for some programming languages or expensive commercial or only for linux e.g. rr-debugger[0]. Also there is rerun [1] that is only for image processing pipeline debugging.

I wish there was something similar like rerun but for code: you record the whole program running and capture all snapshots then stop it running. Now you can analyze all app execution and variables even offline and use any data queries, modify prints without execution and feed it too AI as extra context. I guess RAM would be a big obstacle to make it work since you would either have to capture snapshot at every program modification or some less snapshot but some diffs between what changed.

[0] https://rr-project.org/

[1] https://www.rerun.io/

There are loads of articles discouraging print debugging, and it's a very real thing that people fight against (and for). Print style debugging is the first thing most programmers learn, and for some it absolutely becomes a bad habit.

And to be clear, print debugging and pervasive, configurable logging are very different things and the latter is hugely encouraged (even with logging levels), while the former is almost always suboptimal. Being able to have your client turn on "DEBUG" logging and send you the logs after some abnormal behaviour is supremely useful. Doing "prinftf("Here!")" in one's project is not, or at least not remotely as useful as better approaches.

> print debugging is problematic since the developer has to be diligent about removing it once it is not longer needed.

Linters make this a non-issue, and most modern development environments support them.

https://eslint.org/docs/latest/rules/no-console

https://docs.astral.sh/ruff/rules/print/

In situations where for whatever reason it's infeasible to use a linter, a basic grep can surface prints in a codebase reliably enough.