71–80 of 174 posts
> the problems were caused by not having an intuitive understanding of, for example, the difference between f(x+a) and f(x)+a Does the author really advocate that the instructor of advanced college course needs to spend his time on explaining the difference between f(x+a) and f(x)+a to his students? I don't have any idea how someone with such an understanding of algebra could even get into a college even if he wanted…
Earlier quoted context omitted.
I KNOW I'm better at debugging than at programming. My own working code is terribly simple and straightforward but I've fixed kernel sound drivers, buggy firmwares and complex interrupt-driven music players. Perhaps I find it easier to construct a mental model when presented with a finished system rather than when starting from scratch.
Neal Stephenson writes about this in my favorite "the diamond age," he calls it honer and forger. The type of engineer that is better at improving an existing thing vs. creating something new. There's a need for all types.
"Hackworth was a forger, Dr. X was a honer. The distinction was at least as old as the digital computer. Forgers created a new technology and then forged on to the next project, having explored only the outlines of its potential. Honers got less respect because they appeared to sit still technologically, playing around with systems that were no longer start, hacking them for all they were worth, getting them to do things the forgers had never envisioned."
Earlier quoted context omitted.
I KNOW I'm better at debugging than at programming. My own working code is terribly simple and straightforward but I've fixed kernel sound drivers, buggy firmwares and complex interrupt-driven music players. Perhaps I find it easier to construct a mental model when presented with a finished system rather than when starting from scratch.
I think you have touched on something important - you need a good mental model of the system being debugged.
While it focuses on time tradeoffs and such during resolving outages, one of the major themes is that engineers/developers tend to use heuristics and past experiences to drive problem solving. I think as developers we tend to do the same, we look for common patterns for types of problems we've encountered. The debugger is just a representation of log analysis.
So how do you teach those experiences? I think a lab-based approach with examples is probably the right course.
Sun Microsystems used to have a Fault Analysis class they taught for Solaris.. It was essentially just a lab of 50 broken systems/scenarios that you had to diagnose and fix. I think more of that sort of thing earlier on would be helpful.
Earlier quoted context omitted.
But at the same time more than half of the professional web developers I know don't really use a debugger. Equally problematic. I wonder how much that has to do with tooling? When programming in python I run everything in a debugger basically all the time. When doing JavaScript front-end work it's back to print debugging.
Which is so odd to me because the JavaScript debug tools are some of the most complete and easiest to use. They're right there!
TL;DR: "Writing down the solution" without "thinking real hard" is a much better method
People abuse debuggers (I see this esp with windows programmers). It's better to write test drivers and simulations to force the breakage. If this is how debugging is done you'll enhance your test drivers and simulations. Just running interactive debuggers on a main application you lose much of this. Honestl I spend less than 1% of my time in a debugger and all of that time as post mortem crash analysis. I also work…
Those aren't mutually exclusive. It's much easier to write a test for an issue if you know what the issue is.