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

http://twitter.com/secretGeek/status/1870937085

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

My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.