"In an investigation, assumptions kill", is something Jack Reacher says often in the series Reacher. They don't do much good in software development either.
You assume you know the requirements and start building, only to find out you don't. You assume you understand the scope and the priority, leading to working on the wrong things. You assume others' responsibilities while others assume yours, so critical tasks fall through the cracks. You assume your manager knows exactly what you're doing, what your constraints and pain points are, then discover they think you're underperforming. You assume project timelines and realize, a little too late, that you're behind schedule. You assume you know the problem in your code, which leads to good solutions for the wrong problems. You assume you know users' intent and expectations, and skip talking to them, only to learn that your product sucks.
With most software applications, assumptions don't kill, at least not literally, and not directly, but waste something precious: time. If you recognize time as the ultimate and finite currency you have, anything that reduces the time you spend on useful, meaningful things is, in a way, killing you, albeit perniciously. A lot of people don't perceive time that way because we assume there's plenty of it. Those who do, care about it a lot.
That said, assumptions aren't always bad. They are unavoidable and often necessary. They are fascinating cognitive shortcuts our minds take to navigate the complex world.
They help us filter and organize the vast amounts of sensory information we process at all points of time. They also provide us with evolutionary advantages. People who learned from the past and could make accurate assumptions about the future had better chances of survival. Ancient humans who assumed danger in the rustling bushes fared better than those who didn't. As we interact with the world, we build mental models based on repeated experiences, which become the foundations for future assumptions. Learned helplessness, for example, is when we learn and believe that change isn't possible or isn't in our control.
Even in software development, complete certainty isn't possible. You must employ intuition and make educated guesses - rely on assumptions. The question is not whether to make assumptions but knowing when to make them and when you do, how to make better ones.
Having managed teams and projects for a few years now, I've developed instincts about what others might assume. It's beneficial because it prompts me to initiate conversations and validate them. When I'm right, we avoid potential mistakes and save time for the stakeholders involved. When I'm wrong, I've paid a minor price compared to the upside. It comes down to trade-offs. Like with the rustling bushes, it's about evaluating the pros and cons and taking action that is least harmful. Or, as we say in software development, "going with the least worst option".
How do you get better at making assumptions? There's no best way. But there are several good ways.
Start by paying attention. While there are some things we unconsciously learn, most intentional learning happens with deliberate effort. A fancier way to put it is to say, practice active listening. When people talk, and make assertions, it helps to listen carefully and think about whether each sentence makes sense. When you do that, you catch little leaps of faith people make.
Be open to changing your mind and acknowledge that you don't know something. Ask clarifying questions without being self-deprecating. Validate early and often. Sometimes our insecurities and other times the culture around us make it hard to ask questions or acknowledge not knowing. That's especially true when you're considered the expert in something or in a position where your success depends on projecting certainty and confidence. Resisting that force requires sustained practice.
Be willing to act upon the knowledge you've gained from validating your assumption. It's what brings assumptions into life. It helps us put them out in the world and validate, learn from it, and change our mental models, all over again. Document assumptions, when you can. Making them visible allows others to challenge them before they cause problems, or think about their own. It allows a group to improve their shared understanding. I often find myself stating the obvious in a lot of meetings, whether it's repeating the requirements or goals of a project, or communicating the division of responsibilities and so on. What I'm really doing is calling out my assumptions.
When you're new to an environment - a team, an organization, or any other social circle - be more cautious than usual—over-communicate rather than under-communicate. You don't know the people, you aren't familiar with the process or culture, so assumptions can easily lead you astray. A few years ago, when I joined a team that had some of the most brilliant engineers in the company, there was one senior developer who was often sarcastic in Slack. I assumed he was proud, rude, and condescending - a jerk, in short. After mustering the courage for a one-on-one conversation with him about how his comments made me feel, I discovered a different person entirely. I didn't have to assume about his personality or intentions anymore. Years after he left the company, I'm still close with him. In this case, my incorrect assumptions nearly cost me an important relationship. It'd have been an expensive mistake.