assumptions - makes an ass of you and me
Assumptions are a natural part of life. Every day, we rely on them to make decisions, share information, or engage in conversations with others - whether with a spouse, a colleague, or a friend.
Mostly, we use our implicit assumptions (the ones we might be aware of, but the other side is not, our inside voice or through our unconscious mind), and sometimes we revert to explicit assumptions (where we state them or ask for clarification). Generally speaking, assumptions are reasonable; they help us move forward with ideas, projects, and conversations; they also allow us to learn - through feedback/validation (that person likes to be called small. Damn, I was wrong).
Back in the day, xkcd had a good comic, "When You Assume."
The meaning is that in daily life, we almost always make assumptions every time we speak, and these assumptions are only problematic when we are wrong. Probably everyone has had that moment in life with a BIG WORD in between, saying, "Why BIG WORD! I thought..."
While assumptions are a natural part of daily life, they can significantly impact the workplace, where decisions often affect teams, projects, and outcomes.
Assumptions at work
One of the things I used to do back in the day was getting to conclusions too fast, mainly trusting my assumptions of someone else: work, product, code, blog post, etc.
This code is not right; she should use that pattern/algorithm/framework method; she is not a good developer.
That monolith could be easily split into modules; who designed that?
Why are we on those expensive compute instances? Let's shift to X. Someone truly does not know anything about costs in the cloud!
Does this sound familiar? If not, I bet you can think of a similar one from your history. It's okay. It's nothing to be ashamed of; it's part of the learning process.
In the examples above, we can find inline assumptions:
Wrong method/pattern/algorithm used -> bad/junior developer
Monolith -> bad architecture/bad architect
Wrong compute instance -> person who is not aware of cloud and costs
It's the same as assuming the context of the written or oral communication. We assume this conversation is about X in context Y -> she has an issue with sidecar injections; she probably over-complicated the architecture.
The problem is that we:
build our opinion based on assumptions
we propose a solution based on assumptions
we kill ideas/projects based on assumptions
This influences how we work with the team and with the product, mainly through our subjective experience and failure to account for others' truths. Our opinion about a person will influence how we communicate, what tasks or jobs we will delegate, etc. Our opinion about the solution will probably lead to redesigning—like this would solve everything.
What can we do about assumptions?
The only way not to make an ass of you and me is to change how we communicate. To reduce unknowns and make assumptions explicit. I personally find the following techniques useful.
Ask or state the context
In any conversation at work, make sure that others and you understand the context. Ask for it or state it explicitly during the conversation. In written documents, make sure you add context as part of the description of the solution/problem.
Make assumptions explicit
If you want to assume, go for it, but make it explicit. Say or write that you are assuming X and Y.
I assume that our load is below 1000 req/s;
I assume that we are talking about Y in context Z.
This helps others jump on it and clarify whether assumptions are correct or wrong. Also, it helps when reading a document to look through the author's lenses.
Making them explicit also helps when we are blocked, i.e., when we need to design a solution but lack some data. Sometimes, the only way to unblock a specific stalemate is to make assumptions and write them down.
Also, when I'm doing my captain's log, if I make any assumptions, I like to tag them with the #assumption tag. It helps me later validate them, either through things that have happened or by directly asking someone else.
Change assumptions into questions
When in your mind an assumption popup:
This is terrible design; ask why it was designed this way?
We should use compute instance X; ask why we chose a specific instance type?
Try rephrasing what was said with different words
This is generally good advice in any conversation. Try saying back the same thing using your words. Sometimes, your assumptions will slip into that rephrasing, and your conversation partner can detect them.
Summary
Is it really important? There is a good old parable about it: blind men and an elephant. It describes a group of blind men deciding to inspect an elephant through touch. First touched the trunk and said the elephant is like a thick snake; another touched an ear and thought about a fan. Another one who touched the elephant's leg thought about a tree trunk. A different one who touched a side of the elephant thought of the wall. The last two touched a tail -> rope, and a tusk -> smooth and like a spear.
We all have our experiences, and we might have subjective assumptions about what we see or touch—which are true for us. However, we lack insight into other truths from other experiences/subjective experiences. Hence, we are not aware of other truths or the totality of the truth. The only way to learn about it is through discussions, conversation, and explicit assumptions.
Just like the blind men in the parable, we often see and experience only part of the picture. By communicating openly and making our assumptions explicit, we can gain a fuller understanding and make better decisions.