Why, sometimes I’ve believed as many as six impossible things before breakfast
— Lewis Carroll
The reality is — I’m an idiot.
Don’t get me wrong — I’m a physically healthy person with a decent track record. I just sometimes don’t understand things that are said to me, and so I ask a lot of questions. A ridiculous amount of questions. Communication is complicated, especially for me, especially in engineering where everyone speaks in their own dialect of abstractions.
When someone tells me something complicated using their terminology and mental models, I try very hard to understand what they’re actually trying to tell me.
I know it’s annoying. You ask what seems like a simple question: “Can we just update the schema?” And instead of a clean yes or no, I start firing off clarifying questions: “Update which schema? The source or the warehouse? Are we talking about adding columns or changing types? What’s the backwards compatibility story? How does this affect downstream consumers?”
See? Annoying.
But here’s what I’ve learned: most engineering failures happen because someone was afraid to look stupid.
When a conversation involves one senior engineer and one junior engineer, something incredible happens: the “smart” senior asks what seem like silly questions, while the junior tries to ask sophisticated questions and give equally sophisticated answers. Although an outside observer, given the context, would likely expect the opposite.
I learned this pattern from watching military communication protocols. Before you roll your eyes — yeah, I know, military analogies are overused in business. Stick with me though, because the military has spent about a century optimizing for one specific thing: making sure people don’t die because of miscommunication.
The conversation between two senior engineers often looks like a dialogue between two pilots. There are no winners or losers because the goal isn’t to sound smart. The goal is to define the problem as precisely as possible and convey key information without ambiguity. These formal, sometimes dry, sometimes completely unemotional dialogues sound like this:
Hawk 1: “Hawk 2, Hawk 1, over.”
Hawk 2: “Go ahead Hawk 1, over.”
Hawk 1: “Hawk 2, enemy tracked 2 km west, break ... 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’s dry, without emotion, but it conveys the essence and leaves no room for ambiguous interpretations.
Notice the read-back? That’s not because the receiver is stupid. It’s because confirming mutual understanding is more important than looking smart.
In the military, the person initiating a conversation is usually the senior-ranking official. Out of respect, this individual normally will be the one to say, “OUT”, to end the transmission. It’s a protocol that removes ego from critical communication.
The military has two core principles for data transmission that every engineer should tattoo somewhere visible:
The Principle of Duplication of Information
This is necessary when the transmitter is unsure of what is being heard. The 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.
In engineering terms, this looks like:
See the difference? The second version repeats the critical information in multiple ways: types, docstrings, explicit parameter names. It assumes the next person reading this is going to misunderstand, so it over-communicates.
The Principle of Additional Information
According to this, one should choose constructions and words that would exclude misinterpretation. The military uses specific lingo and procedure words designed to improve vocal communication: Instead of the ambiguous “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.
In our world, this means being annoyingly specific:
I’ve developed a mental checklist of “stupid” questions that have saved me more times than I can count. When someone describes a technical approach, I ask:
“What happens when it fails?” — Not if. When. Because everything fails. I once watched a team design an entire data pipeline assuming S3 would have 100% uptime. When S3 had a 4-hour outage in 2017, their entire data platform went dark. No one had asked the stupid question: “What if S3 is down?”
“How do we know it’s working?” — Seems obvious, right? But I can’t tell you how many systems I’ve inherited that had no monitoring, no alerts, no health checks. They just ran. Until they didn’t, and no one noticed for three weeks because there was no way to tell the difference between “working” and “silently failing”.
“What does ‘done’ look like?” — This one kills projects. Everyone has a different mental model of “done”. Does done mean “code merged”? “Deployed to staging”? “Fully migrated with old system decommissioned”? I’ve seen teams argue for months because they were using the same word to mean different things.
“Can you show me an example?” — Abstract discussions are great until you realize you’ve been talking about completely different things. An example grounds the conversation in reality. “Real-time processing” becomes “here’s a sample event, it arrives at this timestamp, and we need the result available in this table within 100ms”.
Misunderstanding is what we engineers should try to avoid in our dialogues. So don’t be offended by or afraid of excessive dryness. It is not cold; it is precise.
As an engineer, be careful to learn the difference between precise speech and rudeness though. You shouldn’t come into the engineering team and ask “Why are we doing this idiotic thing?” That might come across as aggressive, or worse, incomprehensible. Instead, ask: “Is there any particular reason why we’re using X for this part of the system?”
The meaning is similar, but it sounds clearer and signals that you assume there is a reason, you just don’t know it yet. This is the stance of a proper idiot — assuming you’re missing context, not assuming everyone else is wrong.
I am, after all, an idiot, so I always assume I’m missing something when I ask questions. And you know what? About 80% of the time, I actually am missing something important. The other 20% of the time, nobody really knows why we’re doing it that way, and my question triggers a useful conversation.
Both outcomes are good.
Insufficient facts always invite danger
— Spock
So here’s what I’ve come to believe after years of being the idiot in various rooms:
Being the person who asks clarifying questions isn’t a weakness. It’s a superpower. The teams that ship quality software are the ones where asking “stupid” questions is not just tolerated but expected.
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 clearly, combined with the inability to listen and ask “stupid” questions at key points, leads to misunderstandings and miscommunication — the main cause of most human and engineering problems.
Your job as an engineer isn’t to sound smart in meetings. Your job is to build the right thing. And you can’t build the right thing if you’re not willing to look stupid long enough to understand what “right” actually means.
So be the idiot. Ask the obvious questions. Demand clarity. Repeat things back to confirm understanding. Over-communicate. Write things down. Draw diagrams. Show examples.
Because the only thing more expensive than looking stupid in a meeting is building the wrong thing because everyone was too proud to ask.