Overcoming Informational Risk

Introduction §

As a software engineer, performing intensive intellectual work makes you susceptible to burnout. It's easy to imagine that digging ditches 12 hours a day would wear out your body. It's also possible to wear out your mind. Mental exhaustion may come as a result of the following informational risks:

• Contradiction. New information that contradicts previously held beliefs. For example, if a user reports a bug. Or a new requirement is added to a task after a significant amount of work has been completed. Or code comments don't match observed behavior.
• Saturation. So much information that it breaks continuity of thought. This includes writing a feature that has many requirements. Or reading documentation for a new library or API. This can also happen because of external factors like using social media.
• Scarcity. Not enough information that it requires eliciting requirements or research. For example, task descriptions with vague or cryptic details. Or taking over a complex task after a team member leaves along with their tacit knowledge.

In my definition, burnout is a symptom of being caught in a negative feedback loop induced by an informational risk. Informational risk can cause frustration and exhaustion leading to overcompensating actions and unforced errors. The loop eventually collapses into itself resulting in burnout.

So how do we break out of said negative feedback loop? In my experience, curiosity, humor, and connection are helpful. Developing these attributes can help counteract informational risks. Let's dig deeper into how that's possible.

Contradiction

For example, it's easy to become frustrated when a system doesn't behave the way you expect. Instead of becoming frustrated take a step back and put on your lab coat. Codebases are basically a giant science experiment. Writing tests is a great way to isolate behaviors and establish ground truth.

Codebases are constantly evolving due to external and internal factors. External factors might include time, budget, and team culture. Internal factors include things like bugs, deprecation, platform, and software architecture. Understanding the pressures that are shaping your codebase can help you form heuristics when faced with contradictions.

Contradiction itself can be quite humorous (i.e. irony). When our expectations of "what we wish to be" and "what is" clash, humor gives us an escape hatch. A study ¹ about learning and humor found that:

Humor and laughter may not directly cause learning; however, humor creates an environment that promotes learning. Evidence documents that appropriate humor, and humor that relates to course material, attracts and sustains attention and produces a more relaxed and productive learning environment. Humor also reduces anxiety, enhances participation, and increases motivation.

Humor has positive physiological effects, such as decreasing stress hormones like epinephrine and cortisol and increasing the activation of the mesolimbic dopaminergic reward system.

I find that in practice, programming is full of contradiction. Embracing that was not easy. Coming out of school, I had mighty high ideals of what programming should be. My first production codebase quickly reset my expectations.

I'm sure that every developer at some point asks themselves "Why was this written this way?". It's easy to become angry or frustrated in those moments. I think it's important to put yourself in the shoes of your fellow developers and empathize with the constraints they might have faced. Code is a deeply human artifact and I relish in the tension it produces.

Saturation

I define saturation as too much information at once (either by mass or by density). In this case, you should slowly ease yourself into the information. For research or scholarly work I recommend the top-down approach prescribed in "How to Read a Paper" ². By starting at a high level you can avoid overwhelming your curiosity.

I find it's useful to raise or lower abstractions as needed. For example, when I learned about gRPC for the first time it was helpful to think about it as function calls layered on top of HTTP. Over time, I refined my mental model until I could effectively reason about it. It's important to remember that we're not flying magic saucers. There is usually a good explanation for the way things are.

We also have to defend our minds from the overwhelming amount of shallow information available through social media. Anecdotally, I have found that consuming short-form content negatively impacts my mood and ability to concentrate. Adding this type of media consumption on top of intensive mental work is a recipe for disaster. One study ³ found that:

The concurrent model revealed that on days when social media use was high, individuals reported more memory failures. The lagged model further revealed that higher previous-day social media use was associated with more memory failures on the subsequent day, controlling for previous-day memory failures.

Scarcity

I find that scarcity of information is the most fruitful place to exercise your curiosity. In fact, it allows me to have more ownership of the outcomes. If a task is loosely defined then I get to flesh out the idea and gather requirements without being constrained by previous work.

This wasn't always the case for me. Scarcity would paralyze me. With experience I was able to learn how to expand on an initial idea. My favorite example of this comes from Zen and the Art of Motorcycle Maintenance ⁴. In the book, the main character, a professor at Montana State University struggles to help his students learn to write essays. The following excerpt describes his attempt.

He'd been having trouble with students who had nothing to say. At first he thought it was laziness but later it became apparent that it wasn't. They just couldn't think of anything to say.

One of them, a girl with strong-lensed glasses, wanted to write a five-hundred-word essay about the United States. He was used to the sinking feeling that comes from statements like this, and suggested without disparagement that she narrow it down to just Bozeman.

When the paper came due she didn't have it and was quite upset. She had tried and tried but she just couldn't think of anything to say.

He had already discussed her with her previous instructors and they'd confirmed his impressions of her. She was very serious, disciplined and hardworking, but extremely dull. Not a spark of creativity in her anywhere. Her eyes, behind the thick-lensed glasses, were the eyes of a drudge. She wasn't bluffing him, she really couldn't think of anything to say, and was upset by her inability to do as she was told.

It just stumped him. Now he couldn't think of anything to say. A silence occurred, and then a peculiar answer: "Narrow it down to the main street of Bozeman." It was a stroke of insight.

She nodded dutifully and went out. But just before her next class she came back in real distress, tears this time, distress that had obviously been there for a long time. She still couldn't think of anything to say, and couldn't understand why, if she couldn't think of anything about all of Bozeman, she should be able to think of something about just one street.

He was furious. "You're not looking!" he said. A memory came back of his own dismissal from the University for having too much to say. For every fact there is an infinity of hypotheses. The more you look the more you see. She really wasn't looking and yet somehow didn't understand this.

He told her angrily, "Narrow it down to the front of one building on the main street of Bozeman. The Opera House. Start with the upper left-hand brick."

Her eyes, behind the thick-lensed glasses, opened wide.

She came in the next class with a puzzled look and handed him a five-thousand-word essay on the front of Opera House on the main street of Bozeman, Montana. "I sat in the hamburger stand across the street," she said, "and started by writing about the first brick, and the second brick, and then by the third brick it all started to come and I couldn't stop. They thought I was crazy, and they kept kidding me, but here it all is. I don't understand it."

Neither did he. But on the long walks through the streets of town he thought about it and concluded she was evidently stopped with the same kind of blockage that had paralyzed him on his first day of teaching. She was blocked because she was trying to repeat, in her writing, things she had already heard, just as on the first day he had tried to repeat things he had already decided to say. She couldn't think of anything to write about Bozeman because she couldn't recall anything she had worth repeating. She was strangely unaware that she could look and see freshly for herself, as she wrote, without primary regard for what had been said before. The narrowing down to one brick destroyed the blockage because it was so obvious she had to do some original and direct seeing.

This story strongly relates to my own experience of overcoming scarcity. I actively have to work against the rigid structures of my mind. The education system at its most naive tends to reinforce the idea that problems have a single fixed solution. Whereas the more you learn the more you realize that many problems are open to interpretation. This is where connection makes up the gap.

I firmly believe that other people are our greatest resource. The collective wisdom of humanity is not held by a single person. This simultaneously relieves us of the burden of having to know everything and also drives our need for connection.

Conclusion §

Software engineering requires us to wade through a lot of information. If we are not careful it can lead to burnout. We can mitigate those risks by developing attributes of humor, curiosity, and connection.

Of course, none of this happens all at once. Our need to process information ebbs and flows. With enough time we can coalesce around patterns and practices that work for us individually.

Footnotes §