Sometimes "just thinking harder" works, but often not. A debugger helps you understand what your code is actually doing, while your brain is flawed and makes flawed assumptions. Regardless of who you are, it's unlikely you will be manually evaluating code in your head as accurately as gdb (or whatever debugger you use).
I think a lot of linux/mac folks tend to printf debug, while windows folks tend to use a debugger, and I suspect it is a culture based choice that is justified post hoc.
However, few things have been better for my code than stepping through anything complex at least once before I move on (I used to almost exclusively use printf debugging).
We use barycentric (both in high performance software rasterizers and in hardware) because attribute interpolation is significantly more costly than in-bounds checking (both due to the total number of interpolates, and the precision). The in-bounds check is going to be just a few instructions (a few fmas and some sign checking) for two dimensions (x, y); whereas attribute interpolation could be needed for 30–128 'dimensions'. It's easier to push the interpolation to the use-site in the fragment shader, and let the compiler do its magic.
I'm willing to bet 99.99% of the time you hear music from outside a car it's not due to someone being hard of hearing, unless they caused that issue themselves by listening to music too loud.
However, if you are hard of hearing to the point where you are actually disturbing others, I would recommend headphones.
It is not generally legal to drive while wearing headphones. In some US states it is specifically banned, and in many others you will get pulled over for distracted driving. (The thinking is partly because it makes it more difficult to hear emergency vehicle sirens).
Realizing that you enjoyed being forced to listen to music you didn't decide to listen to doesn't mean you might be an asshole for not enjoying it at other times. That's ridiculous.
I'm guessing, just guessing, that most of the people who don't think slow execution is bad are probably not that interested in what the machine actually has to do to execute their code, and hence, are not actually well educated in making those tradeoffs.
I think a lot of linux/mac folks tend to printf debug, while windows folks tend to use a debugger, and I suspect it is a culture based choice that is justified post hoc.
However, few things have been better for my code than stepping through anything complex at least once before I move on (I used to almost exclusively use printf debugging).