Debugging Abstractions: The Benefits of Mindfulness for Software Engineers

This lesson was originally published at https://algodaily.com, where I maintain a technical interview course and write think-pieces for ambitious developers.

Code Mode

It's been a wild week. You and your team have been engaged in an all-out war with the codebase for the past two sprints. There's this new integration with a partner that's close to being shipped, and it promises bountiful revenue and voluminous web traffic. And you've been working on the part of it that'll seal the deal and let your squad deploy, come Monday morning.

You find yourself on the Friday night before launch, 6pm, absolutely fried at your desk. Everyone else on your team already left to attend the company happy hour, or has gone home seeking sanity from work. For the past several hours, you've been tracking down a nasty, horrendous bug that could prevent the feature from shipping next week.

But you introduced it.

Caught late in the game, with the marketing team eager to deploy, there were no other options. Thankfully, you're close to patching things up. Your thoughts have been a web of abstractions all night, looking something like this:

I've looked at SuperClass, but the stack trace is from ChildClass.
Alright, so ChildClass imports the function from HelperModule...
HelperModule uses a bunch of functions from CrazyLibrary. Let's do a search. Great, CrazyLibrary has no documentation.
Wait, did I check out the latest master yet?
Oh wait, the error wasn't actually on the server. Let's look at the client.
HugeReactComponent is making the call. Maybe the type is wrong?
Oh man, it uses DatabaseModernClientApi... I don't know DatabaseModernClientApi.
Wait no, it's in MiddlewareClientServer...

At 7:30pm, you're sure you've nailed it. It was a silly conditional that got in the way. Boom, problem solved. After merging a PR that switched the broken ternary statement around, off to the happy hour you go.

Beaming with pride from merging the bug fix, you walk in, and notice your team chatting with folks from a sister team. You recognize some members of the sister team, but not everyone. You go and try to introduce yourself.

"Hey y'all, what's happening?!"

Both your team and the sister team sheepishly smile at you. "Hey man", one of them says, "long day?" You look around, and suddenly notice that some people have startled looks on their faces. Then you realize they had been having a low-key conversation, and that you'd jumped into the conversation at quite the high decibel.

"Yeah, haha", you play it off, "Oh boy, working on the PartnerIntegrationProject this week was awful! Whoever wrote SuperClass created a complete mess. Must've taken 10 hours away from my life."

Everyone in the circle stops smiling. Eric, who wrote that class, nervously chuckles. "Yeah, I guess it could be better, huh?" Oops. Bad move. You feel the energy drain out of the conversation they were having.

You stay silent for the next half hour or so, and everyone keeps chatting, but it feels weird. You keep noticing people's expressions and body language. There's some more forced conversation before a few folks excuse themselves. Then everyone disperses.

And for the rest of the evening, you can't shake off the feeling that everyone's thinking something about you. That you did something wrong. You get a sense that the energy was off, and blame yourself.

But you're not to blame! Everything was probably fine, and no one was judging you. You were just in code mode.

What Happens In Your Brain When You Program?

Ask any developer, and "code mode" is a real thing. We seem to be so drawn into our innermost thoughts of classes, modules, syntax, and systems-- that we lose track of how to mentally function the rest of the time. Some call it "monkey mind" or restlessness, but we all recognize it. It's the brain on hyperdrive, going 200 miles per hour when the speed limit's about 50.

It's the thinking, or rather, the overthinking, that is almost always unnecessary. And for reasons unbeknownst, this always tends to happen when we need to deal with other people.

Now, that doesn't seem problematic, right? Being stuck in code mode is harmless. So you overthink the occasional small talk session, and can't really pay attention to long films, but is it really harmful?

No, not really. But understanding why it happens helps us understand how to make the gear switch a little bit smoother, which is behind my upcoming pitch for meditation. If you're able to leave the programmatic thought patterns behind anytime you'd like, you have greater control over your life.

Of course, we want to be sure of our assumptions. After all, the argument for meditation requires a somewhat well-formed paradigm of what's happening when we read and write code. It's important to take into account exactly which thought patterns we "execute" while in code mode.

What's Going On Up There?

There was a push in recent years to allow programming to replace the study of a foreign language. Around that time, Norman Peitek, Janet Siegmund, and a team of researchers while they were comprehending short source-code snippets. Their key finding was that despite the stereotype of math and logic being the major concern in programming, the brains of the participants showed greater activation of its language centers than expected.

Now, this may be confusing to you, as it seemingly contradicts the idea of code mode. After all, if the language centers are activated, shouldn't we, as social beings who communicate through the use of language, not be affected by these lingering cognitive thought patterns?

This could be so. But if we dig deeper into the results of the sudy, we actually find that the programmer mind is activated more traditionally than the above finding would suggest:

In essence, we found five relevant activation clusters, all in the left hemisphere.

The function of the left hemisphere is thought to be for control of the right side of the body, and "is the more academic and logical side of the brain". The right hemisphere is associated with creativity, visual/spatial perception, and emotional management and expression.

Because this has been disputed recently, I took a look at what naysayers of the "left-brain, right-brain myth" were saying. It turns out, most of the rejection of this "myth" stems from the fact that people are not usually left-brain or right-brain dominant. However, the fact of the matter is, the left hemisphere is still associated with logical operations and analytical functions, and the right with more "emotional" or "creative" activities.

In fact, a 2013 University of Utah study on brain lateralization examined the brains of more than 1,000 people and found no evidence for people having a dominant side of the brain. Even though each side of the brain does more work for certain functions, such as language being localized on the left and attention on the right, this doesn’t vary by person. All of the study participants, whether they were engineers or musicians, used their entire brain equally, debunking the left-brain right-brain myth.

In addition to programming being left hemisphere dominant, there's also a lot going on. The earlier study referenced found that the activated regions while coding found were:

Middle frontal gyrus (division of attention, silent word reading, verbal/numeric problem solving)
Middle temporal gyrus (categorization)
Inferior parietal lobule (verbal/numeric problem solving)
Inferior frontal gyrus (verbal/numeric)
Inferior frontal gyrus (silent word reading, problem solving)

If this sounds like a surprisingly high amount of brain activity merely for understanding source code, I would agree. And if it sounds like you'd be surprised if all this happened when trying to sleep or talking to a friend, you'd probably be right. Thus, I'd argue that one should choose to believe that quite a bit is going in mentally when we program, and mostly in the left hemisphere.

But Isn't It Fun?

An interesting note to add is that this kind of intensive brain activity sounds painful in a challenging way, but is actually desirable. Many call it the "flow" state. Courtland Allen and Vincent Woo talked about it in their interview on IndieHackers:

Courtland says:

That's funny because it reminds me of the first two years after I moved to San Francisco. I started a startup and I basically just coded for sixteen hours a day, every day for two years, and the problem is that if you're in flow for that long and you don't vary your activities... you don't make new memories, everything just blurs together, so I have a two year block of time in my life where there were zero memories, and I swore that I would never do that again.

To which Vincent replies:

That's kind of what I suspected happened to that sixty year old plus guy at Amazon, I think he just sat down to code one day and then he woke up, and he was sixty. I don't know, I think flow is both really seductive and also kind of boring in it's own way.

A fascinating take-away of the above conversation is the conflation of two different ideas: flow state and code mode. From our good friend, Wikipedia:

In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.

Here, I argue this point, and I want to be succint: flow and code mode appear to be two sides of the same coin. That specific coin is neurotransmitter-fueled activity, causing us to hone in one problem (or consecutive problems) for an indefinite period of time. However, we generally use the term flow to refer to the good parts of it, and I'm using code mode as the detrimental aspect.

I think we'd all agree that 16 hours spent on something is not good for your health, mentally or physically. Especially the art of programming-- your back aches, your eyes burn, and you leave the coding session feeling unsatisfied. This is what we want to avoid, and the mental fatigue this imparts on you will carry over to other parts of life.

In fact, here's a follow-up passage from the above Wikipedia article on flow state:

The flow state shares many characteristics with hyperfocus. However, hyperfocus is not always described in a positive light. Some examples include spending "too much" time playing video games or watching television and getting side-tracked and pleasurably absorbed by one aspect of an assignment or task to the detriment of the overall assignment. In some cases, hyperfocus can "capture" a person, perhaps causing them to appear unfocused or to start several projects, but complete few.

But you may be wondering, does this state really carry over to later activities? Can't we "easily turn off" this abstractions level sort of thinking after we're done with it?

Shouldn't the code mode end, and lead to-- say, "happy hour mode"?

Turns out, it's not that easy.

The Stickiness of Code Mode

Patterns of thought stick around. Ever switched schools or jobs, and found yourself en route to the old place?

In Source Code and Cross-Domain Authorship Attribution, the concept of stylometry is discussed. Stylometry is a marker of author identity through writing style, and can be used in source code to identify the author of a program. When I first read this paper, it blew my mind, especially this snippet:

Programmers can obfuscate their variable or function names, but not the structures they subconsciously prefer to use or their favorite increment operators. Following this intuition, we create a new feature set that reflects coding style from properties derived from abstract syntax trees. We reach 99% accuracy in attributing 36 authors each with ten files.

So essentially you have a "handwriting" in crafting software. Your placement of if statements versus ternary statements, your naming conventions, the complexity of your calls, etc.-- they're never pulled from thin air. Rather, you cultivate and inhabit these patterns over time, which is why we recommend studying problem-solving patterns for technical interviews. The patterns also appear to linger in later work.

But of course, we cannot assume causation from this. How you think while programming certainly carries over to other times you write code, but we still haven't substantiated concrete evidence that it's sticky in the rest of life. Why does this pattern of thinking remain when we go to happy hour?

Unfortunately, there doesn't appear to be research on this exact claim, but the mere existence of articles like 7 Tips On Turning Off Work Mode When You’re Not At Work and Your Company (Not to Mention Your Family) Needs You to Stop Taking Work Home shows it's a problem that people deal with. Software engineers are not excluded:

I just really started my life in the professional world. I am a very active, 24 year-old. I am used to lifting/running 3-5 times a week, maintaining a blog on the weekends, and going out 1-2 nights per week. Since I started the new job, I am coming home DESTROYED. I can't motivate myself to workout, clean my room, or anything. The job itself isn't very stressful, though I am sitting down for long periods of time. Any ideas on whats going on or how to get out of this funk would be most helpful!

I won't continue to belabor the point. Clearly, your work as a software engineer has sticky, lingering effects on the rest of your life, especially with regards to patterns of thought-- and how much you think. Those patterns, be they negative or positive, will lead to other thoughts of the same nature and magnitude. Learning to control this mechanism, and not letting it master us will prevent overthinking and the overuse of programmatic paradigms outside of writing code.

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities,” said Edsger Dijkstra, of Dijkstra's Algorithm “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

The awkward social interaction presented at the beginning is merely one manifestation of this. The necessary amount of thinking and abstraction-handling to correctly fix a bug is overkill for other situations. Knowing when to, quite literally, get out of our heads, can be tricky. Luckily, there's a tool everyone knows about but probably doesn't practice.

The Mindful Programmer

What’s happening in the brain when meditating?

I can't speak for other techniques, but when you practice mindfulness, you're doing one of two things:

Simply noticing feelings and thoughts as they come, and more importantly, go away.
You're coming back and re-focusing on being aware of the present moment.

Originally an ancient Buddhist meditation technique, in recent years mindfulness has evolved into a range of secular therapies and tools for the restless mind. And the term"restless" doesn't need to be chronic-- in fact, challenging software engineering leads to this type of mental chatter, for the mental dialogue we turn on helps us solve hard problems.

The purpose of meditation is to help one see the world more clearly. Programming, I would argue, is the opposite-- there are quite literally abstractions (that is, layers of models) that take us away from real life.

How I've Benefitted From Meditation

As a programmer, I noticed I used to live the beginning scenario all too often. Between work and side projects, I was constantly sucked into a screen, practicing the act of holding onto a million things in my head and ignoring everything in search of that hit of dopamine. I stayed in the mode for hours, even after logging off, overthinking every interaction and situation. I found I had a serious inability to just enjoy the present moment, and let go.

Now, if I find myself in that mental position, I meditate, even if just for a few minutes. It's like a release valve that waves goodbye to the day's work, and moves me onto the next activity. The simple act of focusing on my breath, noticing my environment, and feeling my body appears to release the body's problem-solving tightness.

It lets me move beyond the code, the internet, and the world of screens.

Because when all is said and done, you might be like Vincent Woo.