[KMnO4]

Learn how to use a debugger. It sounds like the code base you’re working on a small enough that print statements are fine, but that won’t always be the case.

Imagine you’re working on a bug that’s extremely hard to reproduce (say, a race condition), takes a lot of time to reproduce (maybe at the bottom of a long running function), or is somewhere you can’t easily access (a remote device). Your print statement shows that $foo is -1, which doesn’t make sense. Better check what $bar is. So you now have to rerun the program, only to see $bar prints “???????” because for some reason it’s bytes but you’re printing it as UTF8. So now you have to modify and rerun your program to print out the hex values to figure out if there’s any meaning to them.

Congrats, you spent an hour getting three pieces of information.

If you just set a breakpoint, you can go for lunch and come back to a paused program where you can check the state, display information and data structures in whatever way you’d like, and proceed one step at a time to see what happens at each line of your code.

[zeroEscape]

Well, most of the time we're working in Dart/Flutter. I admit that a debugger seems useful for race conditions on the back end. However, when I do systems programming in my free time in Rust or Haskell, I would try to prevent these issues which to my knowledge the languages should do by default unless you're using unsafe Rust or Haskell. So is a debugger in this case not just a bandaid?

Perhaps this is why I've never needed a debugger: prevention is the best cure.