The Psychology of "Must": When the Language of Engineering Follows Us Home

Every day, software engineers, business analysts, architects and project managers write one of the most powerful words in the English language: must.

It appears in almost every requirements document, functional specification and technical standard. The system must authenticate users. The application must encrypt sensitive data. The API must respond within two seconds. The word is so common that most of us stop noticing it altogether. It becomes part of our professional vocabulary, a tool we reach for instinctively whenever we need to define certainty.

Within engineering, that certainty is not merely desirable—it is essential. Entire industries depend upon precise language to remove ambiguity and ensure that systems behave predictably. A bridge must support its intended load. Medical software must produce reliable results. Authentication systems must prevent unauthorised access. Replacing must with should or may can fundamentally change the meaning of a requirement, introducing uncertainty where none can be tolerated. In this context, the word is doing exactly what it was designed to do.

Outside the workplace, however, the psychology of the word becomes considerably more interesting.

For decades, psychologists have studied the language people use when talking to themselves. One of the pioneers in this field, Albert Ellis, the founder of Rational Emotive Behaviour Therapy (REBT), observed that emotional distress is often fuelled not by events themselves but by the rigid demands we place upon ourselves and others. Ellis jokingly referred to this habit as "musturbation"—the tendency to fill our internal dialogue with statements such as I must never fail, People must like me, Everything must go according to plan, or Life must be fair.

His criticism was never aimed at the word itself. Rather, it was aimed at the mindset behind it. These statements are not descriptions of reality; they are absolute demands imposed upon reality. When those demands inevitably collide with an imperfect world, frustration, guilt, anxiety and disappointment often follow.

This distinction between a preference and a demand is subtle, yet psychologically significant. Compare the statements I'd really like today's presentation to go well and Today's presentation must go perfectly. Both express the same desired outcome, but they carry very different emotional weight. The first allows room for imperfection and adaptation. The second leaves little room for anything other than success. One encourages effort; the other creates pressure.

This raises an intriguing question for those of us who work in technology. If we spend years, or even decades, writing mandatory language as part of our profession, does that style of thinking gradually become part of our everyday communication?

The honest answer is that we don't know. There is no compelling evidence to suggest that writing technical specifications causes anxiety or damages mental health, and claiming otherwise would be both inaccurate and unfair. Engineers have been writing requirements for decades without any indication that the profession itself creates widespread psychological harm. Nevertheless, psychology does tell us something equally interesting: the language we habitually use influences how we frame problems, organise information and communicate with others. Our professions shape not only what we know, but also how we think.

Every occupation develops its own mental models. Doctors learn to diagnose. Lawyers instinctively evaluate risk. Teachers naturally explain complex ideas through analogy. Engineers learn to remove ambiguity wherever they find it. Over time these habits become almost automatic, extending well beyond the workplace. Project managers organise family holidays with timelines and dependencies. Architects sketch floor plans on restaurant napkins. Developers mentally optimise everyday routines. It is hardly surprising that our professional vocabulary might also accompany us home.

Many engineers will recognise this in their own conversations. We find ourselves saying, We must leave by eight. I must clear my inbox today. The kids must clean their rooms before dinner. Sometimes these statements describe genuine obligations. More often, however, they are simply preferences that have quietly been promoted into absolute requirements. Without noticing it, we begin to treat everyday aspirations with the same mandatory language we use to describe safety-critical software.

Why does that matter?

Because language influences perception. When we repeatedly frame situations as obligations rather than choices, we subtly alter the emotional experience associated with them. Consider four nearly identical statements: I want to exercise. I'd like to exercise. I should exercise. I must exercise. The activity remains exactly the same, yet each sentence feels progressively heavier. The difference lies not in the action but in the perceived freedom surrounding it.

Modern motivation research consistently suggests that people tend to engage more effectively with goals when they experience a sense of autonomy. We naturally resist coercion, even when we are the ones doing the coercing. Reframing I must exercise as I choose to exercise because I value my health does not reduce commitment; it simply changes the reason for acting. The behaviour stays the same, while the emotional burden often becomes lighter.

This is not an argument against discipline, ambition or high standards. Nor is it an invitation to replace every obligation with wishful thinking. Some things genuinely belong in the category of must. Paying the mortgage, complying with the law, protecting patient safety and wearing a seatbelt are not optional preferences. The challenge lies in recognising how many of our everyday "musts" are, in reality, self-imposed expectations masquerading as necessities.

Engineers, perhaps more than anyone else, are uniquely positioned to appreciate this distinction because our profession already classifies requirements according to priority. Every well-written specification differentiates between must, should and may. Mandatory requirements are separated from recommendations and optional features because not everything deserves the same level of urgency. Ironically, we rarely apply the same disciplined thinking to our own internal dialogue. Instead, we allow dozens of relatively minor preferences to accumulate in the "must" category until every task feels equally important.

Imagine applying the same requirements management principles to your own life. Protecting your family might genuinely be a must. Maintaining your health is probably a should. Organising the garage this weekend may simply be a may. Suddenly, not everything feels like an emergency. The standards remain high, but the unnecessary pressure begins to ease because priorities become proportionate rather than absolute.

Perhaps this is where engineering has something valuable to teach psychology, just as psychology has something valuable to teach engineers. Engineering reminds us that precision matters. Clear expectations prevent misunderstandings and improve outcomes. Psychology reminds us that people are not software systems. Relationships cannot be reduced to deterministic workflows, and emotions rarely conform to carefully documented acceptance criteria. The mindset that produces excellent technical solutions is not always the mindset that produces resilient, adaptable human beings.

That does not diminish the importance of precision. Rather, it highlights the importance of context. At work, certainty is often a virtue because ambiguity introduces risk. At home, uncertainty is unavoidable because people are wonderfully inconsistent. Trying to apply engineering logic to every aspect of life is a little like trying to debug a sunset or optimise a conversation with your child. The tools are brilliant; they are simply designed for a different problem.

Perhaps the most useful question, then, is not whether we use the word must too often, but whether we use it intentionally. Every time we write a requirement, it serves a clear purpose. Every must earns its place because something important depends upon it. Imagine bringing the same discipline to the language we use with ourselves. Does this genuinely belong in the category of mandatory, or is it simply something I would very much like to achieve? That small distinction can dramatically change how we experience setbacks, mistakes and ordinary imperfections.

The word must is not the villain of this story. It is one of the most useful words in engineering, and many of the systems we rely upon every day would be less safe without it. Yet words do more than communicate instructions; they reinforce habits of thought. When we repeatedly practise one way of framing the world, we should not be surprised if that frame occasionally appears outside the environment for which it was designed.

Perhaps the healthiest approach is to embrace both mindsets without confusing them. Write requirements with certainty. Build systems with precision. Remove ambiguity wherever people's safety, security or success depends upon it. But when speaking to yourself or those closest to you, remember that not every preference needs to become a mandatory requirement. Sometimes replacing must with would like, hope, or choose is not lowering your standards at all. It is simply recognising that the richness of human life lies not in absolute certainty, but in our remarkable ability to adapt when certainty proves impossible.

If the language of engineering teaches us how to build better systems, perhaps the language of psychology can help us build a kinder relationship with ourselves. The real challenge is knowing which vocabulary belongs in which environment—and having the wisdom to switch between them.