Wednesday, May 04, 2016

Too Thorough? part deux

In part 1, I tried to make the point that when a VP or Director calls someone “too thorough,” s/he may mean
“You're giving me too much detail (which I don’t want/need to know); let's get to the high-level information (which I do need to know).”
In other words, sometimes our presentation doesn't match the audience. I resemble this remark, I hope progressively less so as the years have passed.

Another way we're sometimes “too thorough” is that sometimes we spend too much time delving into details that have no bearing on the problem we're trying to address. By the way, I sincerely do mean “we,” as this post attests. About 3/4 of the way through that post, I wrote, “In other words, I was done.” I could have stopped there. Arguably I should have, since I demonstrated that my explanation fit all the facts, and that my code change banished the symptom.

That last sentence is the key. We are not FreeBSD maintainers; we are FreeBSD users. As such, once we know enough to plausibly assert we know what's going on, and to demonstrate that we can make the symptom vanish, we know enough, period.

So why did I continue there? No doubt some of it is a kind of engineering curiosity, not altogether a bad thing. It was exactly that engineering curiosity that drove me to ask my colleague to configure a virtual machine with a disk that could take coredumps, and to find the uninitialized struct component. That is, a certain amount of engineering curiosity is required if we're to make progress. I'll claim it's worse to have too little curiosity than too much, though the truth is probably more nuanced than that.

Early in my career, my manager wrote on a review that I tended to work fast and rely upon experiment. This was a nice way of saying that I sometimes rushed in with an answer without fully assessing the situation. He was right, of course. Back in those days, I would never have written that blog post, because the experimental result would have fully satisfied me; I'd be on to the next thing.

Is it just curiosity then? I guess there's some sort of pride in there, too—the desire for mastery. I love it when I have a complete explanation for how something happened—when I've mastered it. Of course that's not what my employers pay me for; they pay me for solutions to problems that they choose.

The next question for an engineer is: What problems are worth my attention, my curiosity? Senior people are supposed to just know; if something looks odd, is that something worth looking at today, or can it be safely ignored until it becomes a real problem? Is the "obvious answer" truly the answer, or does it simply make the "root cause" harder to find?

Well, we don't know. We need to look far enough to feel confident enough to make a decision, and we need to be lucky enough to not get blindsided too much.

So what's my plan? I'd like to say that the next time I'm hot on the trail of something, I'll stop and think, "Do I truly need to be investigating this?" and make a sober assessment of whether I'm being compulsive, vs. just exercising due diligence.

Maybe that's like saying, "The next time I'm about to say something stoopid, I'll bite my tongue." Does that sound totally useless? Well, if I can remind myself that I have this tendency, or limitation, that's the first step, right? As the engineering guru Clint Eastwood said, "A man's got to know his limitations." Or weaknesses. And of course women do, too.

Well, that was a lame ending. That's because I don't really have this one figured out. Maybe you have some ideas? Leave me a comment :)

No comments: