March 25, 2006
I must confess to a sick fascination with the spectacle that results when a non-technical person parrots engineers’ truisms. Most of the time, in my experience, s/he ends up misunderstanding it so completely that s/he undercuts or even entirely reverses the meaning of the phrase.
For instance, I’ve often heard engineers say “A good engineer is a good engineer regardless of programming language”. Usually this is shorthand for a longer statement like, “Jerry prefers Java, but after a few months of working in a mostly-PHP environment, he wrote a standalone ad server in the most beautifully-structured object-oriented PHP I ever saw.” Note that this statement doesn’t at all preclude the notion that Jerry still prefers Java, or that his PHP is extremely Java-esque, or that unlike many PHP projects his server had no UI component, or anything else that negates the ingrained habits of mind, practice, and specialization that come with being the devotee of any particular programming language. All it means is that with the proper motivation, it’s not unrealistic to expect most engineers to be able to produce code similar in scope to that which they’ve written before in alternate programming languages within a short period of time.
To my wide-eyed delight, however, I have heard non-engineers use this phrase to mean something much more like, “A senior C++ engineer will be better than a PHP engineer for getting a new website up and running because a C++ engineer is a better engineer.” Leaving aside the question of whether a C++ engineer is actually more of an engineer than a LAMP dude, I’ll just ask: if you were going to hire a salesperson to sell networking equipment, would you go for one who had sold networking equipment before? or would you rather have someone who had sold a similar-priced item like cars?
Some more of my favorite misused quasi-engineerisms:
* Invoking Brooks’s Law as an excuse to overwork engineers to the point of near-death.
* Asserting that “the most productive engineer is 100X more productive than the average engineer” to avoid disciplining a jerk.
* Excusing a very slow pace of development on a website because “more time spent on architecture now will save time later”.
I don’t mean to be overly harsh on non-engineers who need to work with engineers, because they are in a difficult and often paranoia-inducing situation. But I sort of figure that people who can misunderstand engineering truisms so badly are not coming at it in the correct spirit of humility and desire to learn… in my experience, they just want a shortcut to understanding by reducing a lot of delicate practice into a bumper sticker.
And by the way, in this situation I tend to encourage rather than discourage the speaker’s misconceptions so they’ll fail faster. You can’t make them understand anyway, so we might as well have some fun while being yammered at.