Well, I wouldn't classify this as a lesson from the School of Hard Knocks, maybe a lesson from the School of Oblique Swipes. But I try to pay knowledge forward, so here you are anyway.
Backstory: Our senior QA person was out for a couple of days, and I had some code due to be shown to the client. So I more or less commandeered our junior QA person to cover my back--figuring that it was duplicate effort--but, hey, he's gotta learn sometime, right? Plus, testing your own code is like proofreading your own writing in that, with a few days' distance, you're actually fairly qualified to do it yourself, simply because you're no longer heads-down in it.
As rules of thumb go, it's not a bad one. Except when you try to fix bugs as you find them. (Or, more aptly, as the ambitious junior QA person finds them.) Why? Because you've gone from reading the dashboard dials right back to popping the hood and tinkering with the engine. At least if you're anything like me, you can't. And, as much as I pride myself on being a weirdo, based on my observations, I won't be surprised to find myself in the majority on this one.
Moral of the story for managers (and other assorted geek-herders): This is one of those instances where multi-tasking is not only a waste of time but hugely counter-productive besides. Don't go there.
