Debuggers have logpoints as well as breakpoints. Learning to use a debugger grants you access to this kind of basic "log-debugging" with the option to use more advanced techniques (traditional breakpoints, break on value change, etc) at your fingertips.

> Also, every new job I've had, I've watched my coworkers spend like a week trying to figure out how to make the IDE work with whatever environment, which then changes later... I just skip that.

A single week to achieve better productivity? That's a sweet deal. It's about as much time as you need to figure out how the work email works, learn how to get to the cafeteria from your desk quickly, and so on. It's absurd to think that you'll be 100% productive that first week anyway, so why not use the opportunity to familiarize yourself with the tooling as well?

If it were a week to actually get better productivity, and that setup never broke later, then sure. It doesn't really help because of how few things are actually runnable in the debugger (basically just unit tests). Nobody else on my team even uses the debugger, they only use IDEs out of comfort, and so far they've had to switch IDEs 3 times in 3 years.

Past jobs had similar caveats. The only time I've ever been able to use a debugger consistently was in school.

Personally with visual studio and vcpkg, I never have an issues with setting up the environment. Vcpkg in particular makes it easy to note have to do manual linking, and it handles x86 vs x64 automatically as well.