Most Important Programmer Skills: Communication Skills? Uh. No.

I kept trying to figure out if this was a deliberate joke.

The author sets out to be contrarian with this thesis statement:

Communication skills are completely and utterly overrated for the position of software developer.

Then the essay goes on to eloquently argue the opposite, complete with quotes from Steve Yegge and Jeff Atwood as well as Diana Larson of 37signals, and with a fairly decent five-point argument in favor of communication skills. All of which takes up most of the post.

The impression is that of an author who is desperately at war with his own subconscious mind. It's like watching Doctor Strangelove write a blog post: The author occasionally has to seize his right hand with his left in order to stop it from undermining his stated goals.

Anyway, just in case this isn't all tongue-in-cheek: Yes, it's true that you also need to know programming as well as communication to be a good programmer, just as a good runner needs a right leg as well as a left one. But there are good reasons why communication is often prized as highly, or higher. The essay offers several; here are two more.

First, a great programmer who cannot communicate cannot argue with you. You'll tell him to build X, and with his brilliant insight he'll know that X is the wrong thing and that he should really build Y, but he's not verbally facile enough to win an argument with you so he'll either go off and build a beautifully optimized version of the wrong thing, or he'll sit around sulking until you finally figure out, weeks later, that his mumblings about Y were actually a stroke of genius. Either way, you waste time and money.

A more serious problem is this: The great programmer who cannot communicate will build you a fast, well-designed, robust piece of software that is almost entirely opaque. When you ask the other workers on your team to maintain that software, they will come back to you two weeks later with the news that they just can't understand it, that the Silent Genius can't or won't explain it to them, and that your company therefore has no choice but to throw it all away and rebuild it in Enterprise Java. This is a huge problem that happens time and again. Even hiring a brilliant communicator can't always save you -- PG can write and argue, and yet Yahoo rewrote his Lisp software anyway -- but at least it gives you a fighting chance.

Software is the art of building a structure inside your own head. (The computer is just an accessory.) But professional software engineering is the art of pinning that structure down, making it work, and keeping it working independently of you and your head, because your brain doesn't scale. And the latter task is all about communication.

This has changed over time. Communication was not as important as reasoning or problem solving when programming was difficult and computing time expensive. I can remember when programmers were expected to spend considerable time preparing to make good use of their programming session. One of my worst programming experiences was the time I was forced to work with a friendly, sociable but otherwise poor programmer on a task where we collectively had only 2 hours a week to use the hardware.

Communication is more important now that machines and people are relatively plentiful and the most difficult issue programmers face is knowing exactly what problem to solve.

I was having a conversation about communication skills with a few colleagues just today.

I work with a lot of off-shore people based in India, and yes most of them are just code monkeys. While their English is generally (but not always) excellent, the single worst trait we have spotted is terrible communication skills.

If you work on something that is technically difficult and requires a great coder and not a code monkey, then perhaps great coding trumps communication at all times, however in the big enterprise world, I already know I am going to encounter countless code monkeys, but if they cannot communicate its just sole destroying attempting to set their direction and manage them.

This can be in several ways:

* Extracting information is a painful process - they are never keen to offer it up and when they do, they leave vital pieces out, or forget bits and don't tell you about it until you ask as second or third time when you suspect things don't seem quite correct.

* Developers send you emails with questions or explanations devoid of context assuming you can read their mind - This just wastes everyones time, as I have to then reply asking for more information or call them.

* The communication is so bad, that they explain something in a way that it allows it to be assumed to be something else entirely, and the team/project/whatever heads off in the wrong direction entirely, until someone hopefully catches it!

* They give managers extra anxiety, as they never send progress report of keep him up to date on what is going on, which means the manager has to spend a lot of time chasing things up.

At my university, the WORST people to work with are the people who love talking. They always argue and want things to go their way, and it just stalls projects. The best are those who simply do what they are supposed to do, quietly and competently.

The problem with the blogging is that it's not the non-communicative ones who are out there talking, it's the ones that love talking.

People who know intricate details about hardware do not have time or inclination to write all the time about it - the audience is small, and usually just as competent.

I don't think "good" communication skills are the requirement but rather just adequate skills in a field populated by people notorious for having rather poor communication skills, thus making the basics look good.

If you can't communicate well with your compiler, communicating well with other humen beings about the software you're trying to write will most likely not be in your skillset.

it reminds me about an article of comparing US and German customer support

The US CS have better communication than technical -> "your call is important, the problem will be resolved within 24 hours bla bla bla" ... but things rarely get done

The German CS don't talk much but their competency is high so things get done quickly ... much faster than the US

"Good communication skills" go hand in hand with "easy to manage."