Explaining Programming to a Goldfish

Today I had one more in a very long series of conversations with a manager that seems to want to understand the technical details, but I suspect really only wants to be able to appear to understand them. Basically, he wants to write a good email, and appear to really have a complete and deep understanding of the technical issues surrounding the problem. While I admire his desire, the exercise really comes off as The Great Pretender.

He's not technically trained, and while he may have some Excel "programming" or Matlab experience, it's not the same as really writing a system. Which means he believes he can understand the ins and outs of all technical decisions, and to a point, he probably can. But there has to come a point when he accepts his limitations on understanding and trusts those people he has asked for their opinions.

For example, I shouldn't ask the car dealer about the specifics of the on-board computer with regards to the spark advance during high-torque intervals when the humidity is greater than 90%. It's certainly a technical question, but the real issue for me, as a driver, is Will the car drive as I expect it to? I don't need to know every single detail, but I'm sure there are automotive engineers that do know all this, and good for them.

I'm not arrogant enough to think my opinion is essential, but if you ask for it, and then try to argue with me about it because you believe you have the salient technical facts, then it's a bit... oh... let's call it "excessive". Let's say he's asking about how to build a database. Specifically, what hardware should he buy to get what he wants? In my opinion, he needs to ask what storage he needs, then balance that with the costs of a few different alternatives. In the end, he shouldn't be grilling people about the difference between 1GB drives and 2GB drives - that's a detail that he really doesn't need to be involved in because his area of expertise and responsibility is not which drive to pick - it's the basics of balancing the technical needs with the business needs.

This happens at least a few times every week.

Today it was an email about the packet contents Hemlock receives from it's satellite processes. He asked if it was XML? Nope, it's tab-delimited ASCII. He then asks about the XML he's seen on my monitor. Yes... that's XML, but that's coming out of Hemlock, not going in? OK, so what's going in, a text file? No... it's tab-delimited ASCII data stream. And so on...

I'm not trying to make it difficult, I started saying "it's text", but he kept digging, knowing that wouldn't sound technical enough. And while I admire his desire to use the proper terminology, if it were only that, he'd have written down ""tab-delimited ASCII" the first time I told him. Not wait for me to explain away his confusion and then write it.

If you want an answer, ask. But don't then argue about it. Just take it and go. Because i know he's not using this as a traditional classroom situation where he's not going to ask again. It's like this several times on each point.

In the end, I'm just annoyed.

I remember my Econ class at Purdue - the professor used this quote:

Don't try to teach a pig to sing, it'll only frustrate you and annoy the pig.

and that's exactly what I feel I"m doing with this manager. Very frustrating.