The Better You Program, The Worse You Communicate(secretgeek.net)
secretgeek.net
The Better You Program, The Worse You Communicate
http://www.secretgeek.net/program_communicate_4reasons.asp
28 comments
The more conclusive your tone, the less valuable is your argument. Many great programmers are excellent communicators.
Many great programmers are excellent communicators.
In fact, in my experience there is a positive correlation between being a great programmer and being a great communicator (especially in writing). Being able to clearly understand a concept, break it down into its component ideas and their interrelationships, and then explain that structure to someone else is very similar to being able to program well.
In fact, in my experience there is a positive correlation between being a great programmer and being a great communicator (especially in writing). Being able to clearly understand a concept, break it down into its component ideas and their interrelationships, and then explain that structure to someone else is very similar to being able to program well.
I've seen this, too. However, it mostly seems to work well when they're writing to other programmers or similar people on subjects where it works to break down and restructure.
When there's a fluffy amorphic subject that needs to be pounded from various different angles in order to gain a vague idea of what it is, this approach is not so good. Either you simplify it and miss the point or construct a hugely detailed model and they miss the point.
Also, most non-technical decisions (and many technical ones too, in the end...) aren't dictated solely by the razor-sharp rational intellect but a fuzzy mixture of feelings, reasons, and seemingly unrelated interrelations between people and people and other things.
On the other hand, most of what makes communication work is listening, not talking or writing.
When there's a fluffy amorphic subject that needs to be pounded from various different angles in order to gain a vague idea of what it is, this approach is not so good. Either you simplify it and miss the point or construct a hugely detailed model and they miss the point.
Also, most non-technical decisions (and many technical ones too, in the end...) aren't dictated solely by the razor-sharp rational intellect but a fuzzy mixture of feelings, reasons, and seemingly unrelated interrelations between people and people and other things.
On the other hand, most of what makes communication work is listening, not talking or writing.
I disagree with the article too (and don't think it's well-argued), but...
Stating your position in firm (i.e. "conclusive") terms is generally an advisable practice. The reader can judge the merits of a position for themselves, and counter it if necessary; using wishy-washy language or the passive voice doesn't help anything.
Stating your position in firm (i.e. "conclusive") terms is generally an advisable practice. The reader can judge the merits of a position for themselves, and counter it if necessary; using wishy-washy language or the passive voice doesn't help anything.
I think you can go too far in either direction. I am a fan of Ben Franklin's advice against the obnoxiousness of appearing too certain. He wrote:
"I wish well-meaning, sensible men would not lessen their power of doing good by a positive, assuming manner, that seldom fails to disgust, tends to create opposition, and to defeat everyone of those purposes for which speech was given to us, to wit, giving or receiving information or pleasure. For, if you would inform, a positive and dogmatical manner in advancing your sentiments may provoke contradiction and prevent a candid attention."
He describes how he cultivated "the habit of expressing myself in terms of modest diffidence; never using, when I advanced any thing that may possibly be disputed, the words certainly, undoubtedly, or any others that give the air of positiveness to an opinion; but rather say, I conceive or apprehend a thing to be so and so; it appears to me, or I should think it so or so, for such and such reasons; or I imagine it to be so; or it is so, if I am not mistaken. ... When another asserted something that I thought an error, I deny'd myself the pleasure of contradicting him abruptly, and of showing immediately some absurdity in his proposition; and in answering I began by observing that in certain cases or circumstances his opinion would be right, but in the present case there appear'd or seem'd to me some difference, etc. I soon found the advantage of this change in my manner; the conversations I engag'd in went on more pleasantly. The modest way in which I propos'd my opinions procur'd them a readier reception and less contradiction; I had less mortification when I was found to be in the wrong, and I more easily prevail'd with others to give up their mistakes and join with me when I happened to be in the right."
"I wish well-meaning, sensible men would not lessen their power of doing good by a positive, assuming manner, that seldom fails to disgust, tends to create opposition, and to defeat everyone of those purposes for which speech was given to us, to wit, giving or receiving information or pleasure. For, if you would inform, a positive and dogmatical manner in advancing your sentiments may provoke contradiction and prevent a candid attention."
He describes how he cultivated "the habit of expressing myself in terms of modest diffidence; never using, when I advanced any thing that may possibly be disputed, the words certainly, undoubtedly, or any others that give the air of positiveness to an opinion; but rather say, I conceive or apprehend a thing to be so and so; it appears to me, or I should think it so or so, for such and such reasons; or I imagine it to be so; or it is so, if I am not mistaken. ... When another asserted something that I thought an error, I deny'd myself the pleasure of contradicting him abruptly, and of showing immediately some absurdity in his proposition; and in answering I began by observing that in certain cases or circumstances his opinion would be right, but in the present case there appear'd or seem'd to me some difference, etc. I soon found the advantage of this change in my manner; the conversations I engag'd in went on more pleasantly. The modest way in which I propos'd my opinions procur'd them a readier reception and less contradiction; I had less mortification when I was found to be in the wrong, and I more easily prevail'd with others to give up their mistakes and join with me when I happened to be in the right."
This is a truly worthless article.
Consider UDP (the protocol). It is not DRY, yet it works extremely well for some types of problems. The article suggests that programmers, by their nature, are unable to conceptualize that some problem domains require redundant information.
I'm quite surprised that this article made it to the front page of HN once, much less twice!
Consider UDP (the protocol). It is not DRY, yet it works extremely well for some types of problems. The article suggests that programmers, by their nature, are unable to conceptualize that some problem domains require redundant information.
I'm quite surprised that this article made it to the front page of HN once, much less twice!
Well, while applications that utilize UDP may not be "DRY;" I don't see how UDP is not DRY.
Although, I think using "DRY" in this context sort of misses the point. It's not just that we don't want to repeat code because it's sort of inefficient but it is hard to maintain as that fixing a bug in code block C requires making that fix in its repeat code block C'.
But I agree, the article is sort of odd.
Although, I think using "DRY" in this context sort of misses the point. It's not just that we don't want to repeat code because it's sort of inefficient but it is hard to maintain as that fixing a bug in code block C requires making that fix in its repeat code block C'.
But I agree, the article is sort of odd.
When receiving UDP packets, there is no guarantee that a packet that is arriving has not already been received.
I think this is particularly relevant for verbal communication, and less so for written communication (where, as an example, you can employ DRY as a confused reader can go back and re-read what you wrote).
Some of the key components of programming, however, are also key to good communication. Make a point, and progress directly to that point rather than waffling around. If a term is ambiguous, discuss possible definitions and agree on one (or use a different term).
What about Write/Communicate, Test, Iterate. Say or write something; ask or check if it was understood (eg, by having the person repeat it back to you); if what you get back isn't what you meant to communicate, communicate again.
And finally, take responsibility for your communication as you would for your code. Don't blame the listener any more than you would blame the program or language. If you wish to be understood, seek first to understand the other person's communication needs.
Some of the key components of programming, however, are also key to good communication. Make a point, and progress directly to that point rather than waffling around. If a term is ambiguous, discuss possible definitions and agree on one (or use a different term).
What about Write/Communicate, Test, Iterate. Say or write something; ask or check if it was understood (eg, by having the person repeat it back to you); if what you get back isn't what you meant to communicate, communicate again.
And finally, take responsibility for your communication as you would for your code. Don't blame the listener any more than you would blame the program or language. If you wish to be understood, seek first to understand the other person's communication needs.
I disagree. The roots of programming and writing are the same -- creativity constrained by rules. In programming, your creativity is bounded by what the computer will accept as valid input. In writing, the rules are procedures like grammar, spelling, and style.
A good writer knows that effective communication requires re-iterating the main point. This may conflict with "DRY", but it doesn't conflict with following the rules.
Anyway, there are many excellent programmers that are poor writers. This is probably not some sort of intrinsic property of the Universe, but rather due to the programmer's lack of practice in writing. If you don't do something, you aren't going to be good at it, programmer or not.
A good writer knows that effective communication requires re-iterating the main point. This may conflict with "DRY", but it doesn't conflict with following the rules.
Anyway, there are many excellent programmers that are poor writers. This is probably not some sort of intrinsic property of the Universe, but rather due to the programmer's lack of practice in writing. If you don't do something, you aren't going to be good at it, programmer or not.
Bleh. This seems like yet another article that starts out with a basic premise of "oh hey, programmers are special and have bad social skills because they're rationally-thinking ubermensch". Spare me.
I'm told our pedestals are in the mail
I'm not sure whether to take this seriously — basically the article states that programmers can't tell the difference between a computer, and a human being.. It's like saying great tennis players aren't good at ping-pong because they hit the ball too hard.
Great programmers can formulate complex ideas into tangible concepts, a skill necessary for good communication.
Great programmers can formulate complex ideas into tangible concepts, a skill necessary for good communication.
So, taking the contrapositive: The better you communicate, the worse you program? I don't think that's true at all. In fact, in my opinion, the mark of a truly great programmer is someone who can talk about his or her code.
Great communication is first and foremost about clear thought, as is great programming.
True, a final piece of code shouldn't repeat an idea. Then again, neither should a final essay. Repetition is for ideas half-formed and ill-explained. And in programming as in conversation or writing, an idea is repeated, refactored, reformed until its perfect expression is found--and then all the junk is removed. The final product in both cases should be an idea well-expressed and clear as crystal--so inevitable and straightforward that its essance requires neither repetition nor explanation to spur understanding, and its correctness seems self-evident.
Mediocre code compiles. Great code, you can't imagine that it wouldn't, or that there could possibly be bugs.
Great programmers are not particularly over-literal, either. Great code, great software design practices, can be absolutely stuffed with clarifying metaphor. Everywhere there are trees and packages and publishers and factories and decorations and tags. In a design context, even strictly mathematical terms like 'vector' and 'map' can be loaded with poetic meaning.
Mediocre programmers might choose excessively literal names for objects like 'AggregateCollection'. But it is the poet who chooses to name it something like 'SpaghettiTree' or 'BitVectorVector' with quiet philosophical humor that makes his point so blindingly clear.
True, a final piece of code shouldn't repeat an idea. Then again, neither should a final essay. Repetition is for ideas half-formed and ill-explained. And in programming as in conversation or writing, an idea is repeated, refactored, reformed until its perfect expression is found--and then all the junk is removed. The final product in both cases should be an idea well-expressed and clear as crystal--so inevitable and straightforward that its essance requires neither repetition nor explanation to spur understanding, and its correctness seems self-evident.
Mediocre code compiles. Great code, you can't imagine that it wouldn't, or that there could possibly be bugs.
Great programmers are not particularly over-literal, either. Great code, great software design practices, can be absolutely stuffed with clarifying metaphor. Everywhere there are trees and packages and publishers and factories and decorations and tags. In a design context, even strictly mathematical terms like 'vector' and 'map' can be loaded with poetic meaning.
Mediocre programmers might choose excessively literal names for objects like 'AggregateCollection'. But it is the poet who chooses to name it something like 'SpaghettiTree' or 'BitVectorVector' with quiet philosophical humor that makes his point so blindingly clear.
I've discovered, that communicating sth to "normal" people isn't more difficult because of programming. But it's sometimes less understandable what somebody is trying to say, when I'm in "strict thinking" mode.
It's the same with switching between natural languages - I've once met foreigner in Poland in place where I wouldn't think he can be. He was talking to me in English for more than a minute before I've recognized that I must mentaly switch to English to understand him :)
I think social contacts are difficult for programmers, because programming does not require listening to anybody.
It's the same with switching between natural languages - I've once met foreigner in Poland in place where I wouldn't think he can be. He was talking to me in English for more than a minute before I've recognized that I must mentaly switch to English to understand him :)
I think social contacts are difficult for programmers, because programming does not require listening to anybody.
Why are there so many comments disagreeing with the article on the grounds that good programmers are not poor writers when the article is quite obviously talking about verbal communication?
the article is quite obviously talking about verbal communication
How is that "quite obvious"? The article plainly talks about "communication" in general, not "verbal communication" in particular. That may well be the author's intent, but that is not what is written.
How is that "quite obvious"? The article plainly talks about "communication" in general, not "verbal communication" in particular. That may well be the author's intent, but that is not what is written.
Hmm, allow me to elaborate.
1) In his point about DRY, he speaks of humans not remembering very well. It seems unlikely that he would be referring to written communication here, since there would be no need for memory on the part of the audience. It's pretty much why writing was invented. To implement DRY for speaking.
2) Let people be people -- let them be vague and a little incorrect -- listen more for the gist of what they're saying than the exact terminology.
Be a compassionate speaker, a compassionate listener. Embrace the 'all too human' aspects of the strange bipeds you interact with.
"Listening" and "speaking" tend to be used to refer to verbal communication.
3) References to real-time, in-the-flesh actions and reactions, i.e. "yelling", "watch as the eyes glaze over" and "look at us with that 'freak' expression".
I do agree that if we subscribe to a literal interpretation of the post, then these points may not be conclusive, but then that would just prove the OP's point that us programmers find it hard to deal with ambiguity in communication. I don't know if that was a conscious intention on his part, but if it is, it's quite clever, especially given the reactions I mentioned in my first comment.
Of course, there's also the possibility that I am wrong, in which case, I've read too much into his post. :)
1) In his point about DRY, he speaks of humans not remembering very well. It seems unlikely that he would be referring to written communication here, since there would be no need for memory on the part of the audience. It's pretty much why writing was invented. To implement DRY for speaking.
2) Let people be people -- let them be vague and a little incorrect -- listen more for the gist of what they're saying than the exact terminology.
Be a compassionate speaker, a compassionate listener. Embrace the 'all too human' aspects of the strange bipeds you interact with.
"Listening" and "speaking" tend to be used to refer to verbal communication.
3) References to real-time, in-the-flesh actions and reactions, i.e. "yelling", "watch as the eyes glaze over" and "look at us with that 'freak' expression".
I do agree that if we subscribe to a literal interpretation of the post, then these points may not be conclusive, but then that would just prove the OP's point that us programmers find it hard to deal with ambiguity in communication. I don't know if that was a conscious intention on his part, but if it is, it's quite clever, especially given the reactions I mentioned in my first comment.
Of course, there's also the possibility that I am wrong, in which case, I've read too much into his post. :)
This might be worth a psychology paper somewhere. This seems easy enough to quantify. It's not much more than flimsy conjecture.
OP overlooks one critical detail:
When you write code, you are not only writing to the computer, you are writing to other programmers.
Once your code is compiled, the computer doesn't care what you said in your source code. It's only looking at the object code that the compiler created. (I omit the obvious case of interpreted code.)
But poor saps like me who have to maintain your source code are stuck figuring out what you meant.
OP has it backward...
"Good Source Code" = "Good Communication to the next Programmer"
When you write code, you are not only writing to the computer, you are writing to other programmers.
Once your code is compiled, the computer doesn't care what you said in your source code. It's only looking at the object code that the compiler created. (I omit the obvious case of interpreted code.)
But poor saps like me who have to maintain your source code are stuck figuring out what you meant.
OP has it backward...
"Good Source Code" = "Good Communication to the next Programmer"
[deleted]
When I see stuff like this on the main page, I wish to have a downvote button on the posts!
Dupe. This was posted last week.
is false bad end comment
Dupe.