Finding Balance In Programming

There's often a reason to continue programming. Maybe we're intellectually engaged, maybe there's a looming deadline, or maybe things just got personal between you and that bug, and you won't go to bed until it's squashed. Most of us have experienced solving that problem within minutes of sitting down at the computer the next morning, yet in the moment, letting go and stepping away remains a challenge every time. I want to expand on this dynamic, because I sense that this decision point is critical, has important downstream effects, and is a useful bellwether of how balanced a state of mind we are inhabiting.

Recognizing this moment in myself, and interrupting myself, sows the seeds of balance in my relationship with the practice of programming, and this balance is everything. It allows me to fix issues with more clarity of mind, to maintain a degree of excitement, it’s better for my sleep, and my stress levels. And because of this, it’s better for the code base, and for the end product.

The inverse of this is a state of mind imbued with stress, urgency, exasperation, frustration, and feeling overwhelmed. This is not a good place to make decisions from. And when we program, we’re constantly faced with decisions (large and small), such as assessing tools, deciding what kind of technical debt to take on, or whether or not to write a test for that edge case (spoiler: the answer is almost always "yes"). But this kind of tunnel visioning also narrows our field of possibilities when solving technical problems. If we give in to this state of mind, it results in buggy, ugly, untested products, and a code base full of repeated code, anti-patterns, and cut corners. And such code bases beget more frustration. In other words, this state of mind propagates. It ripples outside of the scope of the computer and its user: it can seep into human relationships as well. We don’t suddenly stop being frustrated when we leave the keyboard: we take it with us into meetings, and it chips away at our relationships. Of course, when we write debtful code under the spell of urgency and frustration, we create a code base that is only more likely to instill the same feelings in other maintainers.

So what can seem like a flash point, a small decision about how we handle one specific frustrating encounter with code, can in time snowball into an entire quagmire of a culture.

The quagmire stops with two behaviors:

• Talking about it as a group. This is therapeutic. We discover we’re not alone in facing the issue, we find help in solving it, and we build organizational awareness of the problem, which helps with…
• Paying attention when we code: noticing when we start to feel overwhelmed, and learn to let go / take a break, instead of leaning in and mashing our keyboard until it just works.

To sidestep a spiral into urgency, stress, frustration, and short term programming, a culture needs to promote a sense of balance. This means recalibrating our sense of urgency, encouraging breaks (leaves of absence, vacations, or just breaks throughout the day), communication, and self-expression.