I work with a lot of different platforms/languages/programs, I've debugged code in various parts of the stack (kernel, firmware, virtualization, drivers, hardwa

I work with a lot of different platforms/languages/programs, I've debugged code in various parts of the stack (kernel, firmware, virtualization, drivers, hardware devices in the lab, serial-connected devices, etc). Sometimes I just want to see if the code I am deploying is hitting the right areas, if I am entering the right function, if a certain variable is a certain value that I expect or why it is crashing. I don't have time to learn the specifics of each language I use with each specific stack implementation that I'm working on (C for kernel and drivers, rust for virtualization infrastructure, C++ for some services, bash/sh for some startup scripts and glue code, python for deployment scripts and tooling, etc). I just want to be able to print something, have it show up in the logs, and take it from there. Print debugging just works fine and it's a great aid, and I've seen most of my coworkers make use of it. Debuggers are great for more domain specific usages, people who work on a very specific project or service or application should definitely set up debuggers, but in my day to day work I probably switch between something like 10+ different projects weekly. Most of those also operate in such a distributed/remote manner that it's simply not possible to (easily at least) install a debugger with breakpoints and instrumentation. I've done my fair share of gdb debugging for performance profiling, and that's fine, but that's also a much more involved process that is not as simple as simply writing print("we got here!") all over the code :)