Legacy code 🍝: turning frustration to flow

I've been working on a software project recently that has some complicated code. The kind that's had me taking frequent breaks. Walks to the kitchen. Walks around the house. Maybe a stroll around the block - wistfully gazing at the late summer sky, hoping for an insight to come streaking in, like the sun peeking through clouds.

My eyes can see the code, but my brain doesn't understand how it works! So I look up documentation of a few of the third party tools used. Then I look back at the project code. Then I click through some function definitions - suddenly I'm in a very different part of the codebase, looking at models or viewmodels or some other abstraction. The names seem quite generic, and belie their true purpose - which I can only painstakingly figure out after flicking back and forth between online documentation and other parts of the code.

All the while my vision is narrowing. My breathing tightens up. I feel pressure mounting inside as my frustration grows. I am wranging with -gasp- legacy code.

I really like the above definition. It captures my situation so well. I need to change the code to implement a new behaviour, or modify the existing logic. But I'm feeling blocked by my lack of understanding. It's a recipe for frustration!

I spent quite a bit of time in this struggle, with a number of different tasks. Each time I found a way to build an understanding of the system, make my change and move on. But still, that initial frustration was there each time. I blamed the code for being too old or hastily written, I blamed by lack of understanding of the technologies involved, I blamed the documentation for being incomplete or vague when I needed clarity.

Eventually, I noticed this pattern kept recurring. And I noticed that something else was the same throughout each of these situations: the gap between my expectations and what the task actually required.

I unconsciously approached the task like a mechanical action to complete - like doing a set of shoulder presses at the gym: push the weight up, let it drop down, then repeat that about a dozen times. The movement is obvious, the end point is clear, and I know exactly how far along I am at any point during the exercise.

But most software development tasks are nothing like this. The movement (code change) is enigmatic, the end point is indeterminate, and I have no idea how far along with the task I am until it's nearly done! (Or I get a new error...)

So how can I shift this unconscious belief, so I can enjoy programming more and enter that elusive flow state?

I was on another walk when this insight came to me. Dealing with code I don't understand is like talking with someone I don't know. In conversation, I'm quite comfortable getting to know someone new: I might start with a shared connection if we have a mutual friend, or are at an event we're both interested in. Or I might ask them what they did last weekend, or mention one of my hobbies in turn to see if we have a common interest. In short, I'm exploring.

What does it look like if I take a similar approach to understanding legacy code? I can start by looking for a shared connection - parts of the code I do understand. Can I follow the structure of classes and methods at least? Do I understand the programming language in use? Is there a design or architecture pattern I recognise?

Next, I explore the parts I don't understand with curiosity. I can start a glossary of terms or keywords I haven't seen before. Or draw a map of the logic flow or class inheritances, even if I don't get understand the full picture. I can allow and even welcome my questions to lead to more questions. Go down some rabbit holes - what are the main libraries used? Is there a new design pattern being used that I haven't seen before?

In changing my approach to understanding the code, I relax and unconsciously let go of trying to achieve a particular result. I've found the more I step into this, the more I enjoy the process and find it even fun! And slipping into a flow state, where time zips by and solutions present themselves seemingly out of the blue, becomes more natural and frequent.

This particular metaphor of a conversation works well for me, but probably not for everyone. So reflect on situations where you're the most comfortable with uncertainty. It could be playing a sport or game, cooking a new dish, or doodling on a notepad.

Use this as your metaphor to transform your frustration into a state of flow.