Seriously. This should be a full subject addressed in detail, and early, unto itself. Instead it's typically a sink-or-swim byproduct of trying to pass any other science/engineering class.
Related to debugging and troubleshooting, I would assign Zen and the Art of Motorcycle Maintenance and work through its applicability to software development. Robert Pirsig, (who I believe had a genius IQ and worked for a time as an IBM tech writer), hit on many topics that serve developers well. His ideas around values, rationality and gumption traps have served me well.
“The truth knocks on the door and you say, "Go away, I'm looking for the truth," and so it goes away. Puzzling.”
― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
It's been probably a good decade and a half since I read that book, and I remember enjoying it, but I don't remember anything being a specific parallel to debugging, necessarily (do you mean how he maintained his motorcycle, I guess?) Anything in particular stick out for you that might jog my memory?
My Pascal lecturer in 1984 recommended 2 books. The official "Findley & Watt" course book and "Zen & The Art of Motorcycle Maintenance". I loved it, but I suspect I was the only one who both bought it and read it.
Agreed. Debugging is an art and discipline in and of itself, and one that so many developers lack. In the last couple of years I've taken a great interest in learning to debug efficiently, and yet despite my best efforts most web devs I work with still rely on variations of "printf debugging". A shame really, considering the sheer depth and breadth of tools that are available these days, even in languages like PHP.
I totally agree with "Debugging is an art and discipline in and of itself" for issues that are difficult to reproduce. With a reproduction, debugging should be straightforward for any engineer.
For reproducible issues, it's scientific method plug and chug for me: observe an interesting behavior, theorize about cause, test, rinse, repeat.
Unfortunately, I am too often amazed at the engineers that don't go through this exercise before asking for help.
For those 'hard to reproduce' issues, it's about knowing what debugging and forensics tools are out there and making sure that the systems you deploy support postmortem debugging and issue analysis. Things like creating crash dump files, then giving your field technicians or customers an easy way to get this data to you with an incident report (or even having the system do it automatically if applicable); logging systems that can be left switched on all the time and dynamically reconfigured (so that there's less chance of the damn thing being off when an issue does occur).
Also awareness of things like tools that analyze or try and provoke race conditions, etc.
The reason the 'printf debugging' might be so prevalent is the professors as well. I got told "printf debugging is incredibly useful, so in this class you can only use printf debugging to debug your program" in one of my classes. We also were to compile everything using Make and could only use Vi. It was still a good class, but maybe that's why so many students think they HAVE to debug with printf.
printf debugging isn't the best method, but it's almost universally applicable. I don't always get to pick which part of my stack is broken, so I need to be prepared to debug in any language, and I don't have time to learn all the debuggers (or the patience to use gdb for everything -- I've debugged user space php with gdb... it's much quicker when I can just error_log my way to the source of the problem).
Sure, I can appreciate that. But when you're talking about user-space PHP, why not leverage XDebug? Even using it as a "better" printf debugger, it's infinitely nicer than relying on "var_dump(); die;" -- and coupling it with any IDE or something like Codebug and you get a proper call stack to work with, variable inspection for the entire scope and even a REPL inside your live code at any point in your execution...
Seriously. This should be a full subject addressed in detail, and early, unto itself. Instead it's typically a sink-or-swim byproduct of trying to pass any other science/engineering class.