In my time working with and managing software developers, I have noticed some interesting personality traits which have the uncanny ability to make one completely nuts. Engineers in general have a reputation for being socially difficult; stereotypes range from the bearded stinky overweight guy to the geeky skinny guy with too-short pants and taped glasses. Reality is somewhere in-between, of course.
The Pedantic Programmer is the guy who refuses to think, unless it is to solve an immediate technical problem. He refuses to consider the needs of the customer, business, or any other human being. As far as he is concerned, the only solution to a problem is the ‘technically correct’ solution to the problem, regardless of the fact that humans are quite often not ‘technically correct’. The Pedantic Programmer often has a lot of experience, and often prefers a ‘back-office’-type environment where they are well-insulated from actual customers and users.
A Pedantic Programmer will never consult reality for guidance in his problem solving. He will always defer to the ‘architecture’ of the system. The limitations of the system will always trump the need for the system to serve the user who pays for it. The Pedantic Programmer doesn’t like fuzzy ideas. He doesn’t like incongruous business rules. He wants everything nice, tidy, and predictable, just like a computer. Common sense is his enemy – since it can’t be quantified.
The Pedantic Programmer’s best skill is Language Lawyering. He’s especially good at taking quasi-meaningful terms like “Profile” or “Master” and flipping them around at will, especially when he’s justifying a drop-down list of thousands of duplicate records, or explaining why he can’t change the size of that field because he’d have to ‘radically change the architecture’.
Some systems, especially those inherited from others, can make simple, trivial changes very difficult to implement in a clean way. While we all want to improve a system, sometimes it just doesn’t make sense to spend the money necessary to improve the system to solve a trivial problem. Sometimes, you have to eat a hack to live to fight another day. Most developers do understand this, but to the Pedantic Programmer, this is an opportunity to re-factor, re-engineer, and give a 5-day estimate to display “WA” instead of “Washington”. While admirable in his zeal to solve a problem, if we do this enough times, our customer will disappear.
Pedantic Programmers always want a spec. If you box them into a corner, they will always play the ‘spec card’ which is some combination of ‘give me a spec’ or ‘you never gave me a spec’. This is a programmer-speak for “Covering Your Ass”. Should I give a senior software engineer with 10 years experience a spec for “Show WA instead of Washington”? This makes managing the Pedantic Programmer very, very tough.
So what does a young professional do when confronted with the challenges of managing a Pedantic Programmer? You can write very detailed specs, but they will always end up wrong, outdated, or unread. You can micro-manage, but Pedantic Programmers don’t like social interaction and no one really likes micro-managing. You can argue with them, but they are often quite sensitive and tend to be easily disgruntled. You can cave in and allow the guy to spend 10 days solving things ‘the right way’, but your boss, the PM, and the CFO won’t like that idea much either.
In the end, you might just be screwed, especially if the Pedantic Programmer is the only guy who really understands some particularly wicked bit of the system. If you’re smart (or lucky) you’ve read Eric Sink’s Developers not Programmers and avoided the Hazards of Hiring and haven’t saddled yourself with a Pedantic Programmer. If you’re not that smart, well, there’s always booze.