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 :)
