Debug Java Without Littering the Code With Print Statements
IntelliJ and Eclipse both support conditional breakpoints and live expression evaluation — most of what a stray System.out.println is trying to do, without touching the source.
Mentoring newer developers on a Java codebase, I've watched the same habit show up over and over: a bug shows up, and the first move is to sprinkle System.out.println calls through the method, run it, read the output, delete the println calls, and repeat once the next question comes up. It works, but it's slow, and it's exactly the kind of loop a debugger is built to shortcut.
Both IntelliJ IDEA and Eclipse support conditional breakpoints: right-click the breakpoint's red dot in the gutter, and there's a field for a boolean condition. Set it once — userId == 4471, say, or list.size() > 1000 — and the debugger only stops when that condition is actually true, instead of stopping on every single call and forcing you to click through the irrelevant ones.
Evaluate Expression (Alt+F8 in IntelliJ, Ctrl+Shift+I in Eclipse) is the other half of skipping the println cycle. Once execution is paused, you can type any valid expression — a method call, a field access, a comparison — and see its result immediately, against the actual live state of the program, without editing a single line of source to add a print statement first.
Both tools also support watches — expressions you pin so they re-evaluate automatically every time execution pauses, rather than re-typing the same expression into Evaluate Expression at every breakpoint. For a value you're tracking across several steps of a method, a watch turns a repeated manual check into something that's just always visible in the sidebar.
None of this replaces println entirely — sometimes you genuinely want a permanent log line, and that's a different problem than debugging. But for the specific, very common case of "I need to see this value right now, once, to understand what's going wrong," a conditional breakpoint plus Evaluate Expression answers the question without leaving anything in the code to clean up afterward.
The junior developers I've mentored who pick this up fastest are usually the ones who were already comfortable in the debugger for stepping through code line by line — conditional breakpoints and expression evaluation aren't a different tool, they're the same debugger doing more of the work for you.