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.
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.
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!
Saying something is important and easy to change is not the same thing as saying it's the most important trait. If you are an ok code monkey it's faster and better for your career to become a better communicator than it is to become a better coder. However, if you want to be thought of as a great developer you need to be a great coder. I am willing to work with a talented deaf programmer long before I will work with an idiot.
PS: Stop thinking about skills as a binary choice you can be a great coder, talented writer, and a poor public speaker at the same time.
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
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.
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.
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 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.
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.
15 comments
[ 2.7 ms ] story [ 41.1 ms ] threadThe 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.
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!
(http://news.ycombinator.com/item?id=226482)
P.S. Thanks for the URL :)
PS: Stop thinking about skills as a binary choice you can be a great coder, talented writer, and a poor public speaker at the same time.
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
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.
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.
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 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.