The Better You Program, The Worse You Communicate
secretgeek.net
secretgeek.net
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.
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.
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 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."
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!
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.
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.
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.
Great programmers can formulate complex ideas into tangible concepts, a skill necessary for good communication.
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.
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.
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.
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. :)
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"
I don't think so...