Tags Projects About License

Be the idiot

Be the idiot

The Caterpillar and Alice looked at each other for some time in silence: at last the Caterpillar took the hookah out of its mouth, and addressed her in a languid, sleepy voice.
'Who are YOU?' said the Caterpillar.
This was not an encouraging opening for a conversation. Alice replied, rather shyly, 'I - I hardly know, sir, just at present—at least I know who I WAS when I got up this morning, but I think I must have been changed several times since then.'
'What do you mean by that?' said the Caterpillar sternly. 'Explain yourself!'

The reality is — I'm an idiot.

Don't get me wrong, I am a physically healthy person, I just sometimes don't understand things that are said to me, and so I ask a lot of questions. Communication is complicated. When a person tells me something complicated in their terminology and abstractions — I try very hard to understand what do they really trying to tell me.

I know, it is annoying — the person seems to be asked an easy question, but he played dumb and instead of answering right away, starts asking a series of completely idiotic clarifying questions.

But I know that most failures happen only because someone is afraid to "look stupid". Being afraid to clarify or question the "obvious" things is a common problem.

Learning from military

When a conversation involves, say, one Senior engineer and one Junior engineer, the incredible thing happens: the "smart" Senior asks silly questions, while the Junior, on the other hand, tries to ask difficult questions and answers just as difficult. Although an outside observer would expect to see a completely different picture.

On the other hand, the conversation between the two Senior engineers is more like a dialogue between two robots. There are no winners or losers in these battles because the goal of androids is not to bring the opponent to a boil but to define the problem as precisely as possible and convey key information to the partner. These formal, sometimes dry, and sometimes completely unemotional dialogues are similar to the communication between two pilots:

Hawk 1: “Hawk 2, Hawk 1, over.”

Hawk 2: “Go ahead Hawk 1, over.”

Hawk 1: “Hawk 2, enemy tracked 2 km west, break …”

Hawk 1: “Take cover 2 km east at Delta Shack, read back, over.”

Hawk 2: “I read back: enemy tracked 2 km west. Take cover 2 km east at Delta Shack, over.”

Hawk 1: “Correct, over.”

Hawk 2: “Wilco, over.”

Hawk 1: “Roger, out.”

That's the talk.

It is dry, without emotion, but it conveys the essence and leaves no room for ambiguous interpretations. Note: In the military, the person initiating a conversation usually is the senior-ranking official. Out of respect, this individual normally will be the one to say "OUT" to end the transmission.

Effective transmission of information

If we go further, into the realm of the military, for whom data transmission is a matter of life and death, we can note two principles:

The principle of duplication of information. This is necessary when the transmitter is unsure of what is being heard. For example, U.S. system of structuring information is clear: "You must always repeat the mission twice so that any squaddies not paying attention have a chance to catch what it is they are meant to be doing."

The principle of additional information. According to this, one should choose such constructions and words that would exclude misinterpretation of the message. For example, The military uses specific lingo and prowords, also known as procedure words, designed to improve voice communication: Instead of the short "Yes", the more distinctive "Affirmative" is used. Instead of the droning "No", a clearer "Negative" is used. A lot of unnecessary letters, but less chance of misunderstanding.

A word to engineers

It is a misunderstanding that engineers try to avoid in their unemotional dialogues. So don't be offended by their excessive dryness.

If you're this engineer you shouldn't be rude either. You shouldn't come into the engineering team and ask why they are doing this or that. That might come across as rude and, worse, incomprehensible. Instead, it's better to ask "Is there any particular reason why we're using X for this part of the system?" The meaning is the same, but it sounds clearer showing the right direction.

I am, after all, an idiot, so I always assume that I am missing something by asking questions. Maybe eventually I will learn something new for myself.


When you look around you come to the conclusion that many people pay too little attention to what they say and how they say it. The inability to express one's thoughts, as well as the inability to listen and, at key points, to ask "stupid" questions, leads to misunderstandings and miscommunication, the main cause of most human and engineering problems.

Buy me a coffee

More? Well, there you go:

Soft Skills guide for Software Engineer

Cunningham's Law: The sun is flat, isn’t it?

What is the definition of a good software engineer?