Stop Coding Under Stress: Avoiding Bugs & Catastrophes

Software engineers spend most of their time sitting and thinking. Web developers do the same. So how can jobs like this be stressful? Vague requirements, unrealistic expectations, and a humorless outlook can put any programmer at risk.

The nasty effects of unmanaged stress are often discussed in the media^[1] and scientific journals^[2], but many of us try to live as though it doesn’t exist. “Why am I irritable?” we ask, as excess cortisol floods through our bloodstream and our brain’s amygdala arouses a fight-or-flight reflex. Our heart starts thumping, beads of sweat form on our brow, and our minds shut out everything except the object of our fear.

Fight-or-flight may work when fleeing a grizzly bear (though experts advise against it^[3]). But it fails us when the object of our stress is an abstract concept. To where must one flee to avoid a feeling of overwhelm?

As the demands of life overwhelm our ability to perform, we experience chronic stress^[4]. Every day, the weight of our failure to meet the demands placed on us accumulates. Hormones that were helpful in the short-term become destructive as time goes on. These rogue hormones suppress the immune system and can even lead to heart disease.

You may object that stress is not bad for us. That is true. A moderate amount of stress spurs us to action. “You need some stress,” says Michael D. Watkins, “Without it, not much happens—you stay in bed munching chocolates.”^[5] Unless we all want to be chocolate-munching bed-dwellers (which has a certain appeal) we need a bit of positive stress in our lives. We must learn to maximize positive stress and mitigate the negative side of stress.

Stress and the Programmer at Work

When I am having a bad day, my words may carry an unintended negative tone. I may overreact to the requests or critical feedback of others. These responses amplify stress for everyone around me. But far more worrisome things result from chronic stress on programmers at work.

Under prolonged stress, we can become pessimistic. This makes creative thinking and learning impossible. “Positive emotions are critical to learning, curiosity, and creative thought,” says usability expert Don Norman.^[6] Without a sense of well-being a programmer’s drive to learn and grow will stagnate. Long-term, we become sub-par developers who write low-quality software.

“We have long known,” continues Norman, “that when people are anxious they tend to narrow their thought processes, concentrating upon aspects directly relevant to a problem.” This narrow thinking limits our approach to problem solving. As television detective Burl Loomis says on the show The Good Cop, “It’s been my experience, when a man has been stabbed in the chest that’s pretty much all he wants to talk about.”^[7] There are moments of absolute clarity, when only one thing matters. But when we see only the immediate concerns of life, we stumble as we pursue elegant architecture, maintainable programs and bug fixes.

Context matters, and it can dramatically affect how we work as a team. I recall a day when a junior member on my team interrupted me with a question that intrigued me. I helped him work through the problem with as much speed as possible and got back to work. When we deployed his code to production, it became clear that he had introduced a bug. He had consulted with me before writing the code, and I had failed to direct him to a better solution. My tunnel vision caused me to ignore the context of another developer’s problem. When bugs make it past the development team and into production, customers feel the pain, and the cost of production bugs is high.

Stress can also cause a bad user experience in less obvious ways. A pressure-filled design process misses many of the nuances important to users. We forget to hold critical collaborative discussions that clarify issues. We overlook empathy for the user in favor of bottom-line thinking. The end result is far less than what should have been.

Few business leaders can test the security of a Web application. This creates another opportunity for stress to do some damage. Developers, under duress, sometimes sacrifice security for expediency. In their haste, they overlook architectural flaws and bugs in code that open our businesses to hackers. Software development and design teams need a safe place to innovate. Time to think through the impact of each design decision and line of code is essential for security.

With a healthy team we can predict the future and close security holes before we lose data to hackers. When criminals stole customer information^[8] from a California property management company, they changed Web platforms to prevent future attacks. What prevented them from upgrading their out-of-date security measures before the attack? Stress may have been a contributing factor.

When stress takes hold, it propagates through misunderstanding and miscommunication. We can react to stress by withdrawing from others. We replace honest conversation with assumptions. We work feverishly to avoid disappointment but produce results no one requested. As we have seen, the cost of such behavior is high.

Managers should see missing communication from a team member as a warning sign. It never hurts to check in and see how a team member is feeling.

Causes of Programmer Stress

We are always in a hurry. Pell-mell completion of half-considered work is a knife in the chest of creativity and a significant cause of stress. The more frenetic the pace, the greater the stress. And when rushed code gets into production, a bad user experience produces a bad developer experience. Managers then apply more pressure without realizing they are compounding the problem. This produces the result we fear: mediocrity and missed deadlines.

This adds to the frustration of a team of motivated software developers. As the time for a production release approaches, anxiety mounts. This unease, Nicole Ferguson says, “highlights the friction and disconnect that exist between the activities used to develop and test software and the work done to maintain and keep software operational.”^[9] An effective manager can shield their team from such toxic unrealistic expectations.

The pace of change is also a stressor, and change in software development tools, languages, and methods is unrelenting. Last year’s innovations belong in this year’s dustbin. Many of our mental models remain, but our tactics are in continual flux. We must keep up. We must always be learning. But time spent learning is inefficient. It requires experimentation and time for reflection.

We will never read all the technical articles, take all the courses, or try all the programming languages. Each new publication is a product vying for our attention. “Try this new framework.” “Check out this fancy new language!” “All the advertising, promotions and pressure employed to tempt us one way or another,” Simon Sinek says, “ultimately yields one consistent result: stress.” ^[10] Filtering out the noise and focusing on what we need to know each day is a critical ability.

Stressed? Write Good Code Anyway

Respond thoughtfully. In an environment prone to stress, how should software engineers respond? Though external stressors are unavoidable, we can slow down and react to them on our own schedule. “When you are on the receiving end of a sudden change,” Says Rabbi Daniel Lapin, “you are seldom under any obligation to respond while your soul is still coping with the initial stress.”^[11] Take a moment, as much time as you need, before responding to shifts in priority. Don’t risk misunderstanding because you feel a need to respond in the moment.

Insist on clarity. Which is better? An hour spent thinking, discussing, and writing, or an hour writing code? It’s a trick question. If I am clear on what I must do, I will choose the hour of writing code. But in the absence of clarity, an hour spent writing code is a profligate waste.

When given a task, my first job is to clarify the requirements for the work. Programmers, the people closest to the problem, are well-suited to plan effective solutions. I rarely receive tasks with enough clarity to warrant writing code immediately. We need time for research and planning. It may be nice to skip all that planning, but it would deprive us of using our strategic abilities.

Manage “found work.” Planning the implementation details of a new feature often uncovers additional unplanned work. Agile software development acknowledges this problem and recommends breaking work into chunks that a team can complete in a short period of time (often two weeks). This “sprint” includes time for collaborative planning and estimation before work begins. During this process we discuss any found work, plan, and communicate changes to our stakeholders.

Traditional software development does not recognize the problem of found work. As one department throws specifications over the wall to another, consternation and change requests multiply. Effective communication mitigates the stress of traditional software development, but an agile approach to planning can simply bypass it.

Take time to play. “Rule-busting innovation requires a sense of play, a sense of delight, a refusal to be corralled int a strict method,” says Marty Neumeier, “Design is a ‘ludic’ process, from the Latin LUDERE, meaning ‘to play’.”^[12] Everyone who writes a line of code is a designer. From the formatting our code to the way we name our variables and methods, we either clarify or confuse the problem. And play helps us see the problem clearly.

Stress narrows our focus. Play opens up possibilities. Though it may be hard, a good response to stress and anxiety is to shrug it off. Step away from the keyboard. Take a brief walk or lean back in your chair and turn the problem over. Be kind to yourself and let your imagination play with a problem. When you can see more than one solution, it may be time to write some code.

Take a walk. When pushing on an intractable problem makes your heart start racing and you feel a glimmer of desire to change careers, get up. Leave your desk and walk around a bit. You can walk around inside your office building. Look out a window. Step outside and get some sun on your face.

Whatever you do, change your frame of reference and let your subconscious work on the problem for a bit. You might gain an insight that lets you re-frame the problem in a way that is much more easily solved. You’ll save your heart the extra wear and tear as well.

Learn strategically. We cannot learn it all. This is not a moral judgment, it is a brute fact. Cope with this reality by learning as much as you can on the job. Take a strategic approach to acquiring new skills and knowledge relevant to your work. Subscribe to technology podcasts, read articles and books, and talk to others in your field. Stay informed about the changes coming your way.

With your knowledge of emerging trends, build some relevant learning time into your work. Communicate this to your managers and stakeholders to manage their expectations. Learning adds to the scope of the project, but it is justified if the new technology gives your employer a strategic advantage.

Learning on the job is hard to balance. On one hand, we could pad every project with time to learn a new programming language or framework. On the other, we could put off learning and soldier on without new skills. The first approach leaves a trail of programming languages and frameworks used once and discarded. The second sticks us with out-of-date skills and frameworks that others have long since abandoned. How you find your balance depends on the culture and priorities of your company. Weigh any technology choice you make today against their impact on your entire team and your company’s software.

With some knowledge of your company’s needs you can plan to learn on your own time. This takes some of the burden of your professional development off your employer. Andy Hunt advises software engineers, “Model your knowledge portfolio with the same care you would manage a financial investment portfolio.”^[13] So take steps each day to learn skills that will add value for your employer. Any learning you can do on your own time takes pressure off you and your team.

Adjust Unrealistic Expectations Many of us are somewhat introverted. We prefer the neat structure of ideas to the messy web of interactions that make up human relationships. But we cannot avoid communication. If we insist on clarity, there will be many times we give potentially unwelcome news to our superiors. This is not a bad thing. Clear communication is part of every software engineer’s job.

Business stakeholders often give deadlines to their superiors to justify your next project without any knowledge of the details. As you plan your work, communicate about potential missed deadlines as soon as you become aware of them. Explain the likely delay so your stakeholders can justify the change with the company leadership. Otherwise, your concerns will backfire—making you seem hesitant and fearful rather than assertive and responsible.

Forgive yourself. As professionals, we hold a high opinion of our abilities and expect a great deal of ourselves. We add to our stress when, if we fall short of our own internal standard, we berate ourselves. In most cases, no one else cares about your personal missed expectations. Set goals. Work hard. Forgive yourself.

Cultivate a Sense of Humor It’s easy to forgive yourself if you learn not to take yourself too seriously. For most of my life, I have been intense, driven, and self-critical. It’s hard to forgive myself if the weight of the world rests on my shoulders. But here’s something to remember: none of us bears our burdens alone. Team members, customers, friends, and loved ones who see our flaws continue to work with us, buy from us, spend time with us, and love us. Sometimes, we can join them in laughing at our mistakes. This helps us let go and move forward.

Letting go can make our work fun and our products fun to use. “Good design is often slightly funny,” says venture capitalist Paul Graham, “I think it’s because humor is related to strength. To have a sense of humor is to be strong: to keep one’s sense of humor is to shrug off misfortunes, and to lose one’s sense of humor is to be wounded by them. And so the mark—or at least the prerogative—of strength is not to take oneself too seriously.”^[14]

Save the World

Stress management may not save the world, but it may save us from early aging and health problems. We can take a load off of our coworkers, customers, friends, and loved ones. And, managing or eliminating stress can save our lives.

Stress is a killer. One of my friends has experienced this in a profound way. During his career, he had several heart attacks due to stress. He says, “I now know stress almost killed me. Not sure how you can control yours, but you need to.” Take his words to heart. You might save the world—or at least your world.

Footnotes

Harvey A. Ramer

Harvey has been writing code for twenty years. He builds web applications with React, Node.js, and MongoDB and deploys them to the cloud with CI/CD pipelines. He talks and writes about the Christian worldview, technology, startups, and how differences can become a collaborative asset.