Sometimes, The Better You Program, The Worse You Communicate.
secretGeek .:dot Nuts about dot Net:.
home .: about .: sign up .: sitemap .: secretGeek RSS

Sometimes, The Better You Program, The Worse You Communicate.

A couple of weeks ago I put out a twitter post I've been meaning to come back and explain:

"the habits of a good programmer are not simply orthogonal to good communication -- frequently they're in direct opposition."

This is a pretty startling and upsetting result: I'd like to think that the heart of good programming is crisp and direct communication. That all of my efforts to be better at programming will, somehow, make me a better all-round person. If only it were true.

Here's a bunch of ways that good programming practices are directly opposed to good communication practices.

In bullet form:

  1. D.R.Y. Does Not Apply.
  2. Humans don't mean what they say.
  3. Compilers don't need to see an example.
  4. Programs love definitions; Humans get flummoxed.

And in detail:

1. D.R.Y. Does Not Apply

The golden rule of programming is D.R.Y. -- don't repeat yourself. This is the heart of effective programming. But this is the opposite of effective communication.

Let me say that again:

The golden rule of programming, DRY, is the opposite of effective communication. ;-)

Say everything once and only once -- go ahead -- then be amazed as everyone misses your point!

Humans are not machines. Memories made of this gooey, spongy stuff called a brain are nothing like memories made of silicon.

With Humans, nothing sinks in the first time. And furthermore, you may be surprised to hear that NOTHING sinks in the first time.

Human, All Too Human
"Human, All Too Human"

Nietzsche preferred the
company of a good compiler
over that of a human.

"Compilers never make fun
of one's moustache,"
--Ibid., pg 293.

2. Humans don't mean what they say.

Compilers are of course perfectly literal. They don't care at all what you mean, they are always hung up on precisely what you say.

Even if you didn't start off life as an anal-retentive git, you'll slowly gain the requisite faculties over years of trying to please a compiler.

The art of trying to please a compiler consists of the ability to logically, dispassionately, analyse what you've said, to discover and remove any mistake or ambiguity -- to always produce an output that is perfectly comprehensible to the strictest of master.

Try being like that around real people. Just try it.

People are barely literal at all. If you take them literally when their meaning differs from their words -- they will get quite irate with you. They won't see that the mistake is theirs.

When the words they use differ from their intent, you may feel an overwhelming desire to 'correct' their mistake. You may even think you are doing them a favour.

This is a natural feeling, amongst programmers, who would be happily spared the torture of spending time trying to remove all ambiguity from the words they provide to a parser.

But please (please) hold back. You might score a small point in the 'intelligence' column for pointing out their 'mistake'. But you'll also score about a bajillion points in the 'what a freaking dork' column.

3. Programs don't need to see an example.

Explain a function to a compiler, and it will be able to calculate the answer.

Explain a function to a human... and then give them an example, and draw them a picture, and give two counter examples, and draw another picture, plus provide an interpretive dance on the topic of functions -- and maybe, just maybe, if you've danced very nicely, they will begin to see "what you're trying to say."

"What I'm trying to say?" I'm saying it damn clear! I'm saying it directly, concisely and with perfectly constructed phrases! I'm not trying to say anything! I'm succeeding, you're just not listening, you freaking imbecile!

And don't take that tone with me. With humans I mean. There's no point yelling. Their rational mind shuts down, their sympathetic nervous system takes over. They get ready to fight or flee. Your point is lost when you get them angry.

Computers don't mind if you type angry. Humans think the anger is more important than the words themselves.

When you have the customer in a headlock, knocking their face against the ground with every syllable: the syllables themselves are no longer of tremendous consequence.

True: that bit about beating up the customer may not be a typical trait amongst great programmers. Perhaps I included it just for entertainment purposes. Continuing...

4. Programs love definitions; Humans get flummoxed.

In programming we define new terms all day long. We define class names or function names or variable names.

We immediately attach a specific definition to them -- and then we use that definition throughout our code.

I imagine that some part of the brain is associated with the ability to define a new term and then hold onto its definition. That part of the brain would be monstrous in programmers. Very over-developed. Gigantic -- a tiger amongst kittens.

But define a new term in front of an audience of non-programmers: watch as the eyes glaze over. Heads slump forward. They start planning their weekend.

Let's call this our Neologismic Synaptic Aptitude, or NSA. Actually: let's not call it our NSA, because if we do, then programmers will start bandying the terminology around like it's something we've known about all their life. And the normal people will just look at us with that 'freak' expression, and we'll be even further from ever making it into the boardroom.

I think this aptitude for new terms is what makes TLA's so abundant in the IT world. I do hope you realise it scares everyone else.

So please, I implore you...

Stop defining new terms. Stop expecting non-programmers to understand the specific and concrete definitions you attach to funny little abbreviations.

Stop striving for brevity and conciseness.

Stop correcting other people.

Stop expecting people to understand you first time around.

Start giving examples -- real examples, earthy examples.

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.

Then drop me an email and please, for the love of god, tell me how you managed it.

'peSHIr' on Fri, 05 Jun 2009 10:39:57 GMT, sez:

So *this* is why I communicate so horribly! ;-)

'Mike Woodhouse' on Fri, 05 Jun 2009 11:34:33 GMT, sez:

My Wife [giving some typically incomplete instructions]: You know what I mean
Me: I don't.
[a thermo-nuclear Row ensues]

My wife doesn't program.

'DylanW' on Fri, 05 Jun 2009 11:56:36 GMT, sez:

I have never before felt like my chosen career was actually doing me harm. Not until I read this article.

(Kidding. Sort of.)

'Doekman' on Fri, 05 Jun 2009 12:06:01 GMT, sez:

So what you are saying is actually that you have less than average programming skills? ;-)

'wpfleischmann' on Fri, 05 Jun 2009 12:56:12 GMT, sez:

re: (1)
Human communication is a lossy medium, so it requires significant redundancy.

'Stephan L.' on Fri, 05 Jun 2009 13:19:35 GMT, sez:

Like Doekman says, you can read this the other way around: here are four reasons why the better you communicate with typical human beings, the worse you are as a programmer :-)

'Kyle Lanser' on Fri, 05 Jun 2009 13:55:44 GMT, sez:

>The habits of a good programmer are not simply orthogonal to good communication practices -- frequently they are in direct opposition.

I Disagree.
The habits of a good programmer...
A programmer wears many hats, many of which translate very well into conversation tools:

Business Analyst, - What is going on?
Requirements Analyst - What is needed?
Coder - Trying to take an idea, code it(/speak it) and make an interpreter(compiler/person) understand it.
Tester - Design and Run Unit Tests(/examples) to verify the results of what was coded(/spoken/communicated)
Debugger - Find a bug(/misunderstanding), re-code, re-test, repeat until it works (idea is successfully transmitted)

'Kyle Lanser' on Fri, 05 Jun 2009 14:32:27 GMT, sez:

These same developer skills translate even better to running a meeting or presentation with HSMB's.

**Programmer Note: Remember to import needed libraries a.k.a. DEFINE YOUR VOCABULARY, most HSMB's will tolerate this.

+-Homo Sapien Meat Bag
+-A Machine engineered with a unique and complex set of interface and storage requirements.

In a meeting, you attempt to present an idea. After presenting the idea, then attempt to run a unit test to confirm understanding by giving an example. If the example fails, you keep giving new examples until one passes. With the idea correctly presented, the people in the meeting do a code review, and their own testing of the idea.

Finally with the idea successfully transmitted, and accepted as true, you begin writing the data to long term storage.

This is the part that messes most of us up, we forget how to interface with the HSMB's.

Their storage is fragmented, redundant, and can really only successfully store 3 items into long term storage. So the write process involves repeating your 2 favorite flavors of ice cream, and the 1 instruction "Buy Me Ice Cream" at least 8 or 9 times. at the end of the meeting, then keep them in their chairs for at least 2 minutes while the HSMB storage system transfers this data from short term to long term storage. This can be done with donuts, fruit, or even just some talk about stuff you know they will ignore.

Tada, programming skills successfully used to re-program HSMB's to bring me ice cream, or remember the topic of your meeting/presentation, whichever you prefer.

'Stopthat' on Fri, 05 Jun 2009 15:15:50 GMT, sez:

That'll be why we old Fortran programmers make good lovers:
1. We don't plan ahead
2. We have habits
3. We are not clinical
4. we make it up as we go along
5. GOTO 1

'target4cactus' on Fri, 05 Jun 2009 15:50:53 GMT, sez:

OK, programmers don't communicate very well, but neither does anyone else.

D.R.Y. -- agreed, I really mess up on this a lot.

Programs don't need examples, but TDD is just that -- you write your tests first (your examples), then you write your code :-)

Human communications is also incomplete -- here's a recent conversation with my wife --

her: Crab's until 10, right?
me: <puzzled look> huh???
her: <aggravated look> T h e c r a b i s u n t i l 1 0 , r i g h t ?
me: <really puzzled look> The crab is until 10?
her: <really aggravated look> The restaraunt that we are taking the kids to -- it has the crab special until 10 tonight, right?
me: Yes...

Can you imagin writing an RFC for this type of protocol?

'Toz' on Fri, 05 Jun 2009 16:16:40 GMT, sez:


'failmaster' on Fri, 05 Jun 2009 16:40:45 GMT, sez:

i just learned 2 new definitions

me- anal retentive
my gf- anal expulsive

'Pies' on Fri, 05 Jun 2009 17:15:29 GMT, sez:

I want someone to have a lot of your babies.

'Jesse' on Fri, 05 Jun 2009 17:36:43 GMT, sez:

haha. this was a great post. no more DRY conversations for me!

'abby, the hacker chick blog' on Fri, 05 Jun 2009 17:57:24 GMT, sez:

We like to think we're so much smarter then everyone cuz they can't comprehend us half the time, but maybe it's just because we really stink at communicating ;-)

Great post! :-)

(really, great post)

I once read that we have to be exposed to something on average 9 times before we really get it. Man, that's a painful thought for people who can't stand repeating themselves!

'dysfunctor' on Fri, 05 Jun 2009 18:46:27 GMT, sez:

> Then drop me an email and please, for the love of god, tell me how you managed it.

How did I manage it? I started a romance with a good-natured but short-tempered lady who had only a smattering of English.

I had to:

1. Repeat myself endlessly.
2. Learn to live with ambiguity, and just hope that she got the gist.
3. Give lots and lots of examples. xkcd-style cartoons help.
4. Stick to a minimal vocabulary.

In matters of the heart, interpreters & compilers just get in the way.

'Ho-Sheng Hsiao' on Fri, 05 Jun 2009 18:50:35 GMT, sez:

I call bullshit.

I've cross posted this from

What programming to a computer and speaking to another person share in common is the ability to resolve ambiguities. Communicating effectively requires sufficient skill in listening.

I used to be big on being DRY in my communication. It bothered me when I have to repeat myself. I'm not bothered by that as much anymore. Introspecting, it used to bother me more because of these two reasons:

(1) Just speaking to a person requires coming out of my shell. I didn't want to.

(2) When I do speak, I get irritated when I'm not listened-to. It doesn't feel as if the other person get what I'm saying. This frustration usually reinforces the shell and encourages behavior (1).

There is simple (though not necessarily easy) fix: learn how to mindfully listen. This is a skill that requires practice.

(1) Mindful is the opposite of mindless. The part of the brain that triggers, "wake up, this is a new experience, pay attention" is the exprience of mindful. The part of the brain that sas, "oh, seen this a million times, ignore it" is the exprience of being mindless. Driving into an unknown city for the first time and taking in everything is mindful. Zoning out on the drive back home and suddenly finding yourself at the front door without any recollection of how you got there is being mindless.

(2) Mindful listening means paying attention to the other person as if it were a new experience for the first time. You accept whatever comes in without judgement or forming any opinion. This allows you to not only take in the person's words, but also his tonality and his body language.

(3) Mindless listening is the common state of typical social interactions. It takes a lot more energy to mindfully listen than it does to listen mindlessly.

People with long-standing verbal fights usually go through the song-and-dance. They are not really listening to each other. You can often see the pattern in which they engage each other. Sometimes, you can catch one of the participant's facial expressions saying, "Geez, I know I just keep repeating this same pattern..." yet at the same time looking competely helpless in changing it.

(4) Interrupting usually means you stopped listening. Making a comment in your head even if you do not speak it out loud is a form of interruption -- you listened to the subvocalized thought in the head instead of the other person.

(5) People talking do eventually wind down.

(6) Mindfully listening is the most effective method of gaining insight about the other person. Those insights allow you to communicate much more concisely and effectively with the other person. Sometimes, you can even say something once if you have gained insight and speak at the opportune moment.

(7) Most people will not pay attention and listen to you unless you have mindfully listened to them first.

(8) Mindful listening is a skill that transfers to programming. You can use it as a form of introspection to resolve ambiguities and shape the the code. The technique of speaking to a person and programming a computer may be superficially different, however, the skill of mindfully listening is the same in both domains.

'Ivo' on Fri, 05 Jun 2009 18:55:45 GMT, sez:

Hacker news massively disagrees:

'Ian' on Fri, 05 Jun 2009 19:31:52 GMT, sez:

Some of the best communicators I know are engineers. Of course, there are also plenty of savant types who you want toput inside a black box, let them generate code, and never have them speak to anyone, but that's a minority.

Talking about the differences between computers and people is a far cry from proving that skills in programming and communication are opposed. They're just not. The tendency of some programmers to communicate in absolutes and geek-speak has more to do with professional, scientific shorthand (and in some cases a lack of social experience) than with a lack of ability to communicate.

'James robinson' on Fri, 05 Jun 2009 20:30:21 GMT, sez:

class appreciation extends conversion
var $g = "post";
var $e = "good";
var $t = "thanks";

public static function appreciate()
return parent::smallTalk().$this->e.$this->g.$this->t;

echo appreciation::appreciate();

'Stephen Paul Weber' on Fri, 05 Jun 2009 21:11:49 GMT, sez:

The Better You Program, the Worse you Communicate with Mortals

I'm not sure this is actually a problem. If we couldn't communicate with each other, then we'd have a problem :)

'Eric' on Sat, 06 Jun 2009 07:53:45 GMT, sez:

Rule for communicating with humans:

The less rational you are, the better.

'Emopuf' on Sat, 06 Jun 2009 16:19:48 GMT, sez:

I'd say is the opposite. Programmers are masters at clear communication, people in general are not. They just think they are.

The human language is a broken language.

'Kitschmaster' on Sat, 06 Jun 2009 18:17:32 GMT, sez:

Only my son gets me, he is 20 months old.

'Chetan Sachdev' on Sat, 06 Jun 2009 18:42:47 GMT, sez:

Totally agree with you. Programmer are kind of less social too so their communication skills does affect. They communicate online, messages etc. I would say programmer speak less and type more :)

'Oracle' on Sat, 06 Jun 2009 18:52:21 GMT, sez:

I don't think we're better or worst communicating than other people. I do believe however that there's an impedance mismatch between our thinking process and the rest of the humans.

"If you don't know what you did wrong I'm not gonna tell you!" - java37 compiler to programmer, 22-02-2112

'BW' on Sun, 07 Jun 2009 02:11:23 GMT, sez:

As a wiki author and a programmer, I'm often at odds with my nature. On the wiki I contribute to, I'm writing technical documentation and stuff for beginners... in the same articles. It's hard to find balance. It's good to see an article that addresses this issue. Oh people have complained but they haven't been so articulate; they haven't identified the problems so clearly. It's good to see that some of your suggestions are in line with our goals.

'bek' on Sun, 07 Jun 2009 19:23:48 GMT, sez:

I am a girl programmer and neither men nor compilers understand me. (and to my utter dismay and complete frustration, I don't understand them either!) ARRGGHH!

'Dale' on Sun, 07 Jun 2009 19:57:43 GMT, sez:

I think i see what you're trying to say, but, really, you should have said so the first time. :-) Great article.

'jean' on Sun, 07 Jun 2009 21:29:21 GMT, sez:

I am thinking about DRY and Agile methodologies. Lots of repetition is what makes things hum:
- product backlog item ranking
- product owner conversation about item
- tester test that drives design
- unit tests that verify code
- code
- demo that code passes tests and conversation
- review and retrospect about what just happened
- rinse and repeat

So, it isn't just about coding anymore and that is why DRY is grossly insufficient for real valued working software. It's only good for code.

'blackball' on Mon, 08 Jun 2009 00:59:43 GMT, sez:

well,I love mathematics,which makes me more...

'kawika' on Mon, 08 Jun 2009 10:05:51 GMT, sez:

AWESOME post. Thanks for the read!

'Doron' on Mon, 08 Jun 2009 10:46:24 GMT, sez:

So true, so sad. I am sending this article to my wife...

'Junda Ong' on Mon, 08 Jun 2009 10:54:51 GMT, sez:

This is really a meaningful post. It is time to reflect on how to communicate effectively, to non-programmers!

'SDC' on Mon, 08 Jun 2009 16:16:50 GMT, sez:

That = True

'John Haugeland' on Mon, 08 Jun 2009 16:51:58 GMT, sez:

This is a genuinely meaningless post. Programmers _do_ need examples; try reading a high quality manual sometime. Repetition is indeed poor form; it's merely a way to keep people's attention when your original prose is too vague or longwinded. Good speakers do indeed mean what they say; you just don't speak well enough to follow through. Definitions are great, and the foundation of traditional rhetoric; it just takes you so long to say something that nobody can tolerate it.

Your entire problem is brevity. This whole post was two paragraphs of material, but you've blown it up so much that it's barely even skimmable. Tattoo tl;dr on the inside of your eyelids, or read Ambrose Bierce or Emma Thompson.

You're like one of those people that thinks Liberace was a great pianist. Stuffing more in isn't the way to win; you want to be Glenn Gould by the piano, or Voltaire by the pen; your work is not finished when there is nothing left to add, but rather when nothing remains to be taken away.

The fact that you couldn't even squeeze out a grammatically desirable title sentence really tells the whole tale. It's not software that's making you a poor writer; it's that your English is crap.

It never ceases to amaze me how Dunning Krueger the blogs are. Please wait until you can write before trying to teach others.

'Rev Ofdanerdz' on Mon, 08 Jun 2009 17:10:37 GMT, sez:

Bad communication isn't because programmers are smarter or more logical(even if it may be true)then the average person(non programmer). In order to be a programmer you have to give up copious amounts of your time to your craft / profession. The more time you devote, The better you become. All of the time spent at your desk doesn't leave much time for social interaction and thus rendering you socially inept. Many other skills / careers have time consuming antisocial side effects which renders then horrible communicators, but programmers seem consistently arrogant when it comes to their views on the issue.

Sorry if I came off rude... It wasn't intended that way. Its a great read regardless. Good work.

'lb' on Mon, 08 Jun 2009 19:03:40 GMT, sez:

@John Haugeland
re "This is a genuinely meaningless post. Programmers _do_ need examples;"

I said "**Programs** don't need examples." You misread it as "Programmers".

Before telling me I can't write, you might want to polish your monocle and see if it's your reading skills that are letting you down.


'Frank Silbermann' on Mon, 08 Jun 2009 19:06:48 GMT, sez:

Depends what you mean by "good programmer."

Lots of programmers can get the computer to do amazing things, but if readers of the program are always thinking "WTF?" then the programmer isn't good. So a good programmer writes programs for _human_ readers.

The method body tells precisely what the method does; the method name is specific enough to let the reader know the purpose and scope of the method (redundant, in that this info could be deduced from the code), and the method comments include a concrete example (more redundancy).

'arkx' on Mon, 08 Jun 2009 20:03:19 GMT, sez:

Luckily programmers are usually excellent in context shifting. Programming and communicating to humans are two different contexts which require two different sets of skills. It is very important to excel in both.

'karthikeyan' on Mon, 08 Jun 2009 20:09:11 GMT, sez:

Interesting & funny.I just forwarded this to my wife with the subject "gives a good idea why i am the way i am :D"

#2 especially is true in my case... we've had so many arguments where I dissect her sentence and tell her what the dictionary meaning of the words are and what *exactly* is the meaning of what she said, while all she says back is that it was not what she *meant* and that it was my fault for not understanding her correctly... sigh...

well then... time to get back to coding

'Jeremy Gray' on Mon, 08 Jun 2009 23:38:00 GMT, sez:

I call bullshit. Good programming is preceded by, interspersed with, and followed by communication that must be "good" in order for the programming to even matter, let alone be "good". If you aren't communicating well then you certainly aren't programming well either, as the former is a definite prerequisite of the latter.

'Eric Manning`' on Tue, 09 Jun 2009 00:00:58 GMT, sez:

Haha i dont program muich but i do know some and i used to get intot he habit of saying that somwthing was =1 or "true" when some one asked a question or said a statement.

such as:

someone: did you like the movie?
me: true

or if i want to say i am going some where

cd C:/Places/new place
or...i cant remeber my better example i said once but it was a good one!

'Giles Bowkett' on Tue, 09 Jun 2009 00:20:31 GMT, sez:

Dude, this is sad pathetic bullshit. The solution is very simple. Read the research on human brains. Brains operate in vastly different ways. They're like powerful self-programming computers governed by chaos math and nonlinear fluid dynamics. Machines are identical or near-identical or predictable and clearly defined in their variation. You communicate with machines using very narrow channels and very regular protocols. You communicate with human beings over very rich, multidimensional channels, and with very irregular protocols.

Communication skills are different from programming skills. If you expect a person to respond to you like a machine does, then of course your efforts to communicate will fail. But that's because you're treating an apple like an orange. Like any naive programmer, you've got a hammer you like and you're treating every problem as if it was a nail.

Just learn some fucking communication skills. It's not hard. This bullshit about "The better you program, the worse you communicate" is ridiculous. You shouldn't be using the same skills to program and communicate. You should be using separate skills. Use programming skills to program and use communication skills to communicate and you're fucking DONE. You shouldn't even be working with the same semantics in communicating with humans that you work with when programming, let alone the same ways of articulating your thoughts.

'Farmer Jeb' on Tue, 09 Jun 2009 00:49:28 GMT, sez:

@John Haugeland
re "Your entire problem is brevity"
Practice what you preach man, your post is 5 paragraphs long.

'lb' on Tue, 09 Jun 2009 01:00:58 GMT, sez:

@Jeb thanks

I'm really dissappointed by your comment.

You actually seem to agree with me:

"You shouldn't be using the same skills to program and communicate"

But then you inrersperse it with a lot of personal attacks. Why?

I just flipped a little bit that means 'Giles Bowkett is a bozo'. Pity.


'Don2' on Tue, 09 Jun 2009 01:25:43 GMT, sez:

Where did all the rude people arrive from?

Don't worry about it Leon: Giles is well known in the ruby world for being a bozo. He prides himself on being rude and think it makes him cleverer than everyone else.

I think "John Haugeland" takes the cake though. He fails at reading then tells you you can't write.

Clearly, programmers need all the advice about improved communication they can get.

Keep up the great communication.

'OJ' on Tue, 09 Jun 2009 01:56:34 GMT, sez:

I find it amazing that even in this day and age, posts like this are interpreted by the masses and STILL completely misinterpreted.

Looks like Hacker News has turned into the new Reddit. Mindless zombies skimming posts and bashing the author without seeing or understanding the subtleties.

Come on guys, it's 2009! Surely by now you would have learned that posts like this are not preachy, flamebait or anything on the negative side.

It's supposed to make you think. If you think that what's being written is bullshit, I'd suggest you first look for some other deeper or hidden meaning before you rant and rave. You're coming across like a total bunch of uneducated twats.

@Giles: I was going to have a go at you for saying "sad, pathetic bullshit".. but then I saw and realised that you're an authority on the subject!

Wind your neck in mate. Comments like that are totally unnecessary.

'James S' on Tue, 09 Jun 2009 04:24:00 GMT, sez:

I might add that this seems to also apply to Systems Admins and probably everyone involved in working with Networking. More so for Linux than Windows Admins, by observation.

'Josh' on Tue, 09 Jun 2009 04:43:26 GMT, sez:

"Trying being like that around real people."

¿Muy inteligente, no? Pero usted hace errores también, como los demás, como la gente real.

In my opinion, programmers are multi-lingual and incredibly gifted for it. I don't expect that anyone versed in a variety of languages will have a complete mastery over nuance, or be able to instinctively differentiate between literal, implied or societal definitions within those languages. To that end, I don't expect the programmers in my office to communicate well or even be grammatically correct After all, they are human too you know. (I can't tell you how many e-mails I have from them about how their department is so "adapt able" or flex able.")

I do think you have made this post far too tedious, as am I with this comment. It may just be symptomatic of the company I work at, but poor programmer communication generally comes down to one issue only. Programmers are often incredibly pretentious and nobody enjoys a conversation with a self-righteous braggart. In that sense, your 'what a freaking dork' points turn into 'what a freaking jerk' points. Particularly after making a mistake of your own.

'sholvar' on Tue, 09 Jun 2009 05:17:21 GMT, sez:

I want that point in the intelligent column. ;-)

These points are really insightful, but point 3 is not reality, I think. In reality a programmer needs to make examples while programming, too. Sure, the compiler does not need them, but the programmer does. Otherwise he can't understand his own code good enough to not make many mistakes. Just because these examples are called "unit tests" you should not be confused. Good unit tests are usage examples for the programmer (or his comrades).

'G' on Tue, 09 Jun 2009 05:35:20 GMT, sez:

"Hacker news massively disagrees" : who the hell cares ?

What is to agree or disagree ? It's a rather light funny text, take it this way, not has a criticism.

'merl' on Tue, 09 Jun 2009 07:35:26 GMT, sez:

Of course practises relate to context and "good practices" are no exception.

Taking a practice from one context to apply it to another (in this case from programming to human communication) will more often than not fail.

So, imho this is actually not about how good/bad programming skills relate to bad/good communication skills but to be aware of the context you're acting in and to apply the right practices to the right context.

So no need for any egos to be hurt :)

'Ergün KOÇAK' on Tue, 09 Jun 2009 08:27:26 GMT, sez:

Thanks for great article :) it was very fun to read this. I pointed to your article in my blog in Turkish and summarized a little :)

'http://' on Tue, 09 Jun 2009 09:55:51 GMT, sez:

8 years in therapy and I'm getting closer... I still don't have that 'don't type angry' thing down... but, I'm closer.

'davee' on Tue, 09 Jun 2009 09:59:37 GMT, sez:

I think the real difference is that programming requires the ability to think in absolute literal terms, while communication with people requires a great deal of figurative thought. Naturally, good programmers tend to fall into the literal camp because it helps to be able to think like a computer when you're trying to coax one into action. On the other hand, people spend a great deal of time trying to figure out what other people mean when they are spoken to. This comes, no doubt from a lifetime of dealing with other people who seldom mean what they say or they use words with so many conflicting meanings that it's impossible to really understand what was said.

Good programmers do make good communicators, but only when they realize that the other party to a conversation is not someone who thinks literally and consciously adapts his communications style to the other's figurative processing methodology. Unfortunately, most good programmers don't like to think in such fuzzy ways as it goes against everything they know is right, clear, concise, with no ambiguity. Programmers are more like Mr. Spock with emotions, logic almost always gets through to us because logic is so much a part of our daily lives.

Great article!

'Xoes' on Tue, 09 Jun 2009 10:50:20 GMT, sez:

This explains why I'm such a crappy programmer...
The compiler never understands my examples...

Maybe a career change...

'ccc' on Tue, 09 Jun 2009 11:01:11 GMT, sez:

Thanks. That's why I hate "Am I fat?".

'lb' on Tue, 09 Jun 2009 12:09:52 GMT, sez:

@Ergün: Thanks for translating!

I've decided to make some changes to the article.

It's very easy to misread 'Programs don't need to see an example' as 'Programmers don't need to see an example' -- so i'll substitute the word 'Compilers' instead.

I'm changing the title, adding the word 'Sometimes' at the start, so that people who don't have time to read the whole thing are less likely to take a black and white interpretation. It's pretty much all shades of grey.

And i'll attribute the first paragraph in the way I originally intended. Maybe when people see that i'm quoting a tweet they'll realise i'm not trying to represent this stuff as serious academic work, but just some random ideas.

Also, I intend to have Greedo shoot first,
several additional tie fighters, and a bigger, busier Mos Eisley. ;-)

'Ann' on Tue, 09 Jun 2009 18:55:06 GMT, sez:

Came up as 'Offensive: profanity' using work computer :(

'Zed' on Wed, 10 Jun 2009 09:12:06 GMT, sez:

@Giles RE:
>Read the research on human brains.

e.g. this article from 'THE ZOMBIE RESEARCH JOURNAL'


'BSquared' on Wed, 10 Jun 2009 19:29:17 GMT, sez:

Thanks, nice post.

--all the rants give me a headache.

'Bob Armour' on Fri, 12 Jun 2009 09:20:42 GMT, sez:

LOL - I am SO guilty of point number 2!

'jimadamski' on Sat, 13 Jun 2009 02:35:05 GMT, sez:

Excellent points - not easy to understand if you are a newbie to an evironment as big say JAVA.

'Flynn' on Sat, 13 Jun 2009 04:17:05 GMT, sez:

This is so true. You nailed it...

'Casey' on Sat, 13 Jun 2009 12:41:51 GMT, sez:

>>But you'll also score about a bajillion points in the 'what a freaking dork' column.


'Inkslinger' on Sun, 14 Jun 2009 19:16:18 GMT, sez:

I'm not a programmer. What I got out of this post is that Programmers are not Human.

"I know you understand what you think I said. What you don't seem to realize is that what you heard is not what I meant".. Anon.

'Siderite' on Mon, 15 Jun 2009 04:30:32 GMT, sez:

Ah ha ha ha, the captcha called me a meatbag!

Great post and I think very true. You should do a followup on all SOLID principles :)

And I also agree with dysfunctor (I really tried to say 'some guy in the comments', but I just had to be precise and scrolled up). All we need is love! :)

'William Pietri' on Wed, 17 Jun 2009 13:16:44 GMT, sez:

Not only is this true, but it also makes us worse programmers!

As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

So often I come across code that happens to work, but is either meaningless or actively misleading. Unless you want your projects to die when you move on to something else, your code has to communicate your meaning.

That's especially true with good examples, which make excellent automated tests.

'Dave' on Thu, 18 Jun 2009 11:04:15 GMT, sez:

I see it more as "the ramifications of specificity".
A project requires a significant amount of time and energy on the part of the programmer. In order to arrive at the desired outcome, we need some pretty specific instructions. (I was watching "In The Shadow of The Moon" the other night, and in it they mentioned the elegant conciseness of Apollo's purpose: "Take a man from the earth to the surface of the moon and return him safely to earth.")
"The rest of the world" (eg: marketing types) prefer to speak in generalities. Not only are they (by nature) not good at being specific, their existance dictates that they avoid specifics... specificity precludes deniability, and being able to say "that's not what I wanted, let's redo it" is core to their existance.
Which brings us to the issue investment.
Just as with procreation (male investment:10 minutes; female:20 years), the disproportionate investment of time/energy causes friction. Redo's are maddening to programmers because what cost the marketer 15 minutes to conjure up cost the programmer 15 days to create, and after maybe 2 redos it becomes painfully clear to the programmer that you'll never satisfy the marketer's credo of "do what I meant, not what I said".

'Stickle' on Fri, 19 Jun 2009 11:33:14 GMT, sez:

Tuppence: The amount of money i just spent on this reply

This article was fwd'd by my sis (a newspaper editor) via my girlf (a QA person) and bounced of my best friend (a builder) and made me chuckle on a friday.. now, I have issues to address with my circle of friends with particular focus on how all the girls spoke to a different boy first, but..
I'd like to thank the author for bringing a possible rule of thumb to light on a friday afternoon

'SteveJ' on Fri, 19 Jun 2009 16:40:00 GMT, sez:

As someone who is currently writing 60+ pages of docs to describe 14 simple features....ARRARARGH! Spot on, great work.

It won't end well, but I bet those first couple days of working for Skynet will be blissful.

'Brett' on Sun, 21 Jun 2009 10:04:12 GMT, sez:

Perhaps a better way to achieve success is for everyone too take a long hard look in a mirror and get on with life

'Paul' on Wed, 01 Jul 2009 05:17:22 GMT, sez:

As I work with a lot of programmers, these are interesting theories. I hope I will understand them better in future.

'Reboltutorial' on Thu, 02 Jul 2009 16:51:50 GMT, sez:

I like your post, though I don't think you can't cope with both machines and humans :)

'David Knewtson' on Sun, 05 Jul 2009 00:02:38 GMT, sez:

that explains that. I wondered what was so bizarre about the way my friends talked.

Also, just so everyone knows. the word in my captcha is "meatbag"

'2true' on Sat, 11 Jul 2009 00:06:12 GMT, sez:

Everyone at work hates this programmer who keeps talking in 'code-speak'

I want to feel sorry for him, but it's pretty hard to help someone who gets on your nerves.

I think that humans simply become what they do in life. If they haven't had much exposure with different people, then programming will tend to make them very anal. It takes a long time for them to readjust to become human again.

Cheers for spelling this out to everyone.

'Dave Aronson' on Fri, 31 Jul 2009 12:51:00 GMT, sez:

One word: Toastmasters! (No, not meatbag....)

'iThoughts' on Fri, 31 Jul 2009 20:16:08 GMT, sez:

GF (standing in front of the mirror in the bathroom): "Can you give me the ... thingy?"

Me: *making a stupid face, thinking about answering 'yes' and walking away; thinking about giving her the book beside me (or anything else in reach); frowning for a millisecond; looking at her, figuring out what she meant and what she usually does in her scheudule of actions in the bathroom; taking the hairbrush, giving it to her*: "Here you go"

'TGray' on Thu, 13 Aug 2009 11:09:14 GMT, sez:

I believe many commentators may be making a logical fallacy here: "Correlation does not imply causation".

Just because there appears to be an inverse correlation between good programming and good interpersonal communication, does not imply that bad interpersonal communication is caused by being good at programming.

They may have misinterpreted your post. I believe it was your intention to just point out the correlation without implying the causation.

'John W' on Wed, 02 Sep 2009 10:21:57 GMT, sez:

I like the article, but I think you got it wrong entirely. Programmers are actually better at communication than others. We are rational, to the point and unambigious. We are more effective in communication, especially amongst each other, and leave little to interpretation.

Although I understand this may be a problem for the majority of non-programming human beings, it still isn't so that when the majority doesn't feel it's right, it must be wrong....

'Andrew' on Sat, 12 Sep 2009 10:34:19 GMT, sez:

Error checking...vital to programming, ostracizing when used with "those people"

'KIZILSUNGUR' on Fri, 16 Oct 2009 12:34:44 GMT, sez:

Great article!!!


'Marcos Watanabe' on Sun, 18 Oct 2009 23:40:53 GMT, sez:

if (reader==human){


'Jardel from brazil' on Mon, 26 Oct 2009 00:38:12 GMT, sez:

hey yo dude
great article!!!

i suffer with the same problem, but i think the first cause of this lack in communication is the fact that we don't have human contact like other professionals (e.g. salesman) and without practice we can't even learn new languages!

'Rance Mohanitz' on Sat, 11 Dec 2010 03:02:45 GMT, sez:


'Bimal sharma' on Thu, 10 Mar 2011 08:00:06 GMT, sez:

Those things human discovered or invented in hundreds of hundreds of years,we are entertaining those things in less than 20 years.And we are dying to achieve similar kind of worldly greatness in one or two years.There are no reasons not to be frustrated.

'pschon' on Tue, 03 May 2011 18:01:18 GMT, sez:

John W is correct. Simply because the majority cannot maintain focus does not mean we are wrong.

Most jobs do not require intense concentration. Most people do not grow the muscles that require that.

That said, we should be able to identify our environment and operate effectively in it. Personally I much prefer an environment where I need to concentrate to keep up than concentrate to slow down.

'LeBron James' on Wed, 25 Apr 2012 02:07:44 GMT, sez:

'LeBron James' on Wed, 25 Apr 2012 02:08:26 GMT, sez:

<a href="">NBA Jerseys</a>
<a href="">Atlanta Hawks</a>
<a href="">Boston Celtics</a>
<a href="">Chicago Bulls</a>

'LeBron James' on Wed, 25 Apr 2012 02:08:58 GMT, sez:

[url=]Carlos Boozer[/url]
[url=]Carmelo Anthony[/url]
[url=[url=]Chris Paul[/url]
[url=]Dirk Nowitzki[/url]

'knock off coach purses' on Fri, 27 Apr 2012 06:19:23 GMT, sez:

<a href=>knock off coach purses</a>
<a href=>fake coach purses</a>
<a href=>knockoffs coach</a>

'cheap true religion jeans' on Fri, 27 Apr 2012 06:23:35 GMT, sez:

<a href=>wholesale true religion jeans</a>
<a href=>true religion jeans wholesale</a>
<a href=>cheap true religion for men</a>

'wholesale true religion jeans' on Fri, 27 Apr 2012 06:25:06 GMT, sez:

<a href=>wholesale true religion jeans</a>
<a href=>true religion jeans wholesale</a>
<a href=>cheap true religion for men</a>
<a href=>cheap true religion men</a>


website (optional)

enter the word:

comment (HTML not allowed)

All viewpoints welcome. Incivility is not tolerated, such comments are deleted.


I'm the co-author of TimeSnapper, a life analysis system that stores and plays-back your computer use. It makes timesheet recording a breeze, helps you recover lost work and shows you how to sharpen your act.


NimbleText - FREE text manipulation and data extraction

NimbleText is a Powerful FREE Tool

I wrote this, and use it every day for:

  • extracting data from text
  • manipulating text
  • generating code

It makes you look awesome. You should use NimbleText, you handsome devil!



The Canine Pyramid The Canine Pyramid
Humans: A Tragedy. Humans: A Tragedy.
OfficeQuest... Gamification for the Office Suite OfficeQuest... Gamification for the Office Suite
New product launch: NimbleSET New product launch: NimbleSET
Programming The Robot from Diary of a Wimpy Kid Programming The Robot from Diary of a Wimpy Kid
Happy new year 2014 Happy new year 2014
Downtime as a service Downtime as a service
The Shape of Your Irrationality The Shape of Your Irrationality
This is why I don't go to nice restaurants any more. This is why I don't go to nice restaurants any more.
A flowchart of what programmers do at work all day A flowchart of what programmers do at work all day
The Telepresent Man. The Telepresent Man.
Interview with an Ex-Microsoftie. Interview with an Ex-Microsoftie.
CRUMBS! Commandline navigation tool for Powershell CRUMBS! Commandline navigation tool for Powershell
Little tool for making Amazon affiliate links Little tool for making Amazon affiliate links
Extracting a Trello board as markdown Extracting a Trello board as markdown
hgs: Manage Lots of Mercurial Projects Simultaneously hgs: Manage Lots of Mercurial Projects Simultaneously
You Must Get It! You Must Get It!
AddDays: A Very Simple Date Calculator AddDays: A Very Simple Date Calculator
Google caught in a lie. Google caught in a lie.
NimbleText 2.0: More Than Twice The Price! NimbleText 2.0: More Than Twice The Price!
A Computer Simulation of Creative Work, or 'How To Get Nothing Done' A Computer Simulation of Creative Work, or 'How To Get Nothing Done'
NimbleText 1.9 -- BoomTown! NimbleText 1.9 -- BoomTown!
Line Endings. Line Endings.
**This** is how you pivot **This** is how you pivot
Art of the command-line helper Art of the command-line helper
Go and read a book. Go and read a book.
Slurp up mega-traffic by writing scalable, timeless search-bait Slurp up mega-traffic by writing scalable, timeless search-bait
Do *NOT* try this Hacking Script at home Do *NOT* try this Hacking Script at home
The 'Should I automate it?' Calculator The 'Should I automate it?' Calculator

Archives Complete secretGeek Archives

TimeSnapper -- Automated Screenshot Journal TimeSnapper: automatic screenshot journal

25 steps for building a Micro-ISV 25 steps for building a Micro-ISV
3 minute guides -- babysteps in new technologies: powershell, JSON, watir, F# 3 Minute Guide Series
Universal Troubleshooting checklist Universal Troubleshooting Checklist
Top 10 SecretGeek articles Top 10 SecretGeek articles
ShinyPower (help with Powershell) ShinyPower
Now at CodePlex

Realtime CSS Editor, in a browser RealTime Online CSS Editor
Gradient Maker -- a tool for making background images that blend from one colour to another. Forget photoshop, this is the bomb. Gradient Maker

[powered by Google] 

How to be depressed How to be depressed
You are not inadequate.

Recommended Reading

the little schemer

The Best Software Writing I
The Business Of Software (Eric Sink)

Recommended blogs

Jeff Atwood
Joseph Cooney
Phil Haack
Scott Hanselman
Julia Lerman
Rhys Parry
Joel Pobar
OJ Reeves
Eric Sink

InfoText - amazing search for SharePoint
LogEnvy - event logs made sexy
Computer, Unlocked. A rapid computer customization resource
Aussie Bushwalking
BrisParks :: best parks for kids in brisbane
PhysioTec, Brisbane Specialist Physiotherapy & Pilates
home .: about .: sign up .: sitemap .: secretGeek RSS .: © Leon Bambrick 2006 .: privacy

home .: about .: sign up .: sitemap .: RSS .: © Leon Bambrick 2006 .: privacy