Everything's FUBAR. Oh, wait, now it's perfect. | Cypress Semiconductor
Everything's FUBAR. Oh, wait, now it's perfect.
We engineers pride ourselves on sweating the details. But when you are head's down on a detailed problem, it is easy to lose sight of the big picture. And since engineers build an emotional attachment to their projects, one detailed bug can completely obscure thousands of successes. So that's why we seem so bipolar when it comes to accessing a project. It is either amazingly rosy or irretrievably screwed up.
I've also seen (never been guilty of this) the situation where "I don't understand how this code works" quickly becomes "I don't understand how this code could ever work". It's that emotional attachment again. So what's a manager to do?
There was a recent online post by Chuck Hill (www.eetimes.com/electronics-blogs/pop-blog/4207358/How-to-train-your-boss-in-the-proper-bug-etiquette)that started with the above phenomenon and took it to its absurdly logical conclusion: You must train your boss to only ask for status during the correct "pole". I disagree, I think there are several possible approaches, so let's look at the alternatives:
A) Train your boss to wait for status until you are smiling: this is Chuck Hill's conclusion, which means one of two things; either 1) I (the engineer) will act like a blathering idiot while debugging a hard problem, so the only way to find out true status is to catch me between bad bugs, or 2) managers only want the good news.
B) Train yourself to look for your boss's smile (the right kind, not the evil "take over the world" one) before dumping on him your latest unsolvable bug and the inevitable cataclysm to come. This is the corollary to A) above, and while managers may want to hear only good news it is much more fun to deliver bad news when they least expect it.
C) Prozac: don't let anything excite you and go along your merry way with a lot of other lemmings. It is what it is and that's all it ever will be.
D) Understand that projects and people are both complex organisms, and one-liner reactions or status will never give a good picture. Both the engineer and the manager of engineers must understand the question asked and the answer given are not the end of the story. What is the question behind the question and the answer behind the answer, as well as the answer (expected) behind the question and the question (not asked) behind the answer.
Don't you hate it when tests are constructed to make the right choice obvious; it is of course letter C (although generic substitution is allowed).