Thanks for the link, Greg. I'll definitely read it later.
I especially loved this quote, and the timing's interesting:
The bottom line: to fix a problem, you need to understand the problem.
The timing's interesting becuase I'd just written a post about solving a problem in seconds that'd been plaguing a company for several months. And it was basically done by correctly identifying what the problem was. And that's usually done by not only identifying what kind of problem it is (software? hardware? bandwidth? memory? CPU?), but checking the easy stuff first.
Kinda like when I worked for a while as a motorcycle mechanic who would go to the motorcycle rather than having it brought to me. I remember one bike that the owner had put a lot of time into trying to get running, and he literally got very angry when I got it running by replacing a fuse under the seat then handing him a bill for $45 (my minimum). I don't know if he was angrier about my having gotten the bike running in minutes when he'd been struggling with it for so long, or because he was charged $45 for those minutes. Probably both.
I'm one of those weird programmers whose biggest thrill isn't from adding new features. I love to add new features, but what really turns me on programming-wise is to tweak the last little bit of performance out of something. I happily spend hours doing lots of coding to decrease bandwidth utilization by 5%. Same with CPU usage.
It might seem inefficient to spend hours doing something that saves milliseconds, but when those milliseconds are being saved millions of times per month, it adds up and is well worth it.
