

Most Important Programmer Skills: Communication Skills? Uh. No. - lbrandy
http://lbrandy.com/blog/2008/09/a-programmers-communication-skills/

======
mechanical_fish
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.

~~~
davidmathers
Why don't you have a blog?

~~~
mechanical_fish
I have a blog, <http://www.mechanicalrobotfish.com> . I never write on the
darned thing, despite good intentions, and despite the good arguments in favor
of doing so. Instead, I write here. I can't seem to help it.

Let's invite Zombie Feynman to explain:

<http://www.pitt.edu/~druzdzel/feynman.html>

 _When I was at Princeton in the 1940s I could see what happened to those
great minds at the Institute for Advanced Study, who had been specially
selected for their tremendous brains and were now given this opportunity to
sit in this lovely house by the woods there, with no classes to teach, with no
obligations whatsoever. These poor bastards could now sit and think clearly
all by themselves, OK? So they don't get any ideas for a while: They have
every opportunity to do something, and they are not getting any ideas. I
believe that in a situation like this a kind of guilt or depression worms
inside of you, and you begin to worry about not getting any ideas. And nothing
happens. Still no ideas come.

Nothing happens because there's not enough real activity and challenge: You're
not in contact with the experimental guys. You don't have to think how to
answer questions from the students. Nothing!_

HN features questions from the students -- literally, in some cases! It's very
inspiring. Even the craziest submissions can provide useful food for thought.

Having said that, I need to force myself to blog more. Thanks for the
inspiration!

~~~
jauco
Or just keep using HN as a blog

(<http://news.ycombinator.com/item?id=226482>)

P.S. Thanks for the URL :)

------
bayareaguy
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.

------
fendale
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.

------
maxklein
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.

~~~
run4yourlives
Talking a lot has nothing to do with being a good communicator.

~~~
MJConway
Totally agree. It is, in fact, the opposite. Over half of being a good
communicator is being a good _listener_ and that's often missed.

Yes, you have to be technically competent. Communicating clearly is a
technical skill and if you fail it, it is like saying you're competent, except
you know, with pointers.

------
keefe
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.

------
MaysonL
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.

------
hs
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

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

