There will always be smiling, happy folks who majored in anything except computer science involved in your programming project. Perhaps they married the boss's kid; perhaps they were in the right place at the right time. But the boss made them manager, even as they're trying to figure out the buttons on their BlackBerry. What's worse, they don't have a single ounce of Asperger's in them, so they insist on staring at your eyes throughout the meeting.
There are some programmers who like these glad-handers because fooling them is easy. If you tell them the Johnson DB is failing big time, they'll believe you and pass this ominous news up the chain. Someone has to take the flak from the upper managers. But others recognize that these guys just call meetings and get in the way. They can give little guidance, and the best they can offer is a bit of quality testing.
While programmers may grouse about having to interact with nonprogrammer managers, they often quietly say that managers with programming talent can be worse -- sometimes much worse.
The former geniuses might decide to micromanage the project and rip out large swaths of code because they had a new vision. Or maybe they'll prattle on about how they did the same thing in half the code back when they programmed in 8080 assembler or C or Java. In any case, they can get more obsessed with technical details than with the big picture, though they were hired to keep their eyes on the latter.
While it is always enjoyable for programmers to blame the suits and glad-handers over on the sales team for every problem and any disruption, the programmers must also admit that some of the problems can lie with themselves. Programmers are hired for their computer skills, not their people skills.
Programmers are bad at communicating, and they're not known for thinking of feelings or ego. They can latch onto some technical argument like a pitbull will lock onto a steer's leg bone. It doesn't matter if the client wants something different; the programmers get hung up on the technical arguments, and they'll still be hashing it out at the company picnic in two years.
While programmers can often filter out each other's idiosyncrasies, teams can fail when programmers knock heads. It's common for two people with different political views on, say, dynamic languages or NoSQL to end up on the same team. The decision on what is right for the project becomes a referendum on everything these programmers have held dear. Then nothing ever gets accomplished. Everything is tied up in the next battle of the 100-year war.
Did you just get a null pointer from his code? That's your job to catch that. And you better think twice about passing in a zero because the self-absorbed coder doesn't check for divide-by-zero errors. That's your job.
The narcissist coder's work is supercool and superfast but only because it leaves much of the bulletproofing and testing to you. That's your job to handle the mundane chores so that it doesn't crash.
Many teams end up finding this out too late. The blocks of code work fine during the early tests, but after someone starts pushing real data through them, everyone realized that no one was checking for problems. Oops.