What I Forgot About Building

I recently participated in GeekCombat, a hackathon organised at To The New. I review code, get into technical discussions, and occasionally debug things with the team. So it’s not like I’ve been completely away from the craft.

But this felt different.

At some point, I put my headphones on, played the same song on loop, and started working through a problem on my own. No coordination. No delegation. No shared ownership. Just me trying to make something work.

Slowly, everything else faded. I wasn’t checking emails or glancing at messages. I wasn’t thinking about the broader architecture, long-term trade-offs, or how this would impact three other systems. I was just focused on getting this one thing to run.

Trying something. Watching it fail. Tweaking it. Running it again. That simple loop felt oddly satisfying.

And when it finally worked, that quiet spark of joy felt very familiar. Not because I had forgotten how to code, but because I had forgotten how it feels to be fully immersed in one problem without carrying the weight of everything around it.

What stayed with me wasn’t just that I enjoyed coding. It was how uncomplicated those hours felt.

In my current role, most days are layered. I’m aligning teams, balancing priorities, thinking about downstream impact, protecting timelines, coaching people, and making trade-offs that aren’t always visible to everyone else. Even when I’m close to something technical, part of my mind is still scanning the bigger picture.

At the hackathon, that layer was gone.

The problem didn’t represent a roadmap commitment. It wasn’t tied to delivery pressure or cross-team dependencies. It wasn’t something that would ripple across plans if it slipped. It was just a problem waiting to be solved.

As you grow in your career, your scope and influence expand. You operate with more context and responsibility, shaping outcomes across teams instead of just within your own work.

You operate at a higher altitude, which means you rarely get to zoom all the way in. The more strategic your role becomes, the less often you get to live inside a single problem. You gain scope and impact, but you lose immersion.

That day made me realise something slightly uncomfortable.

I haven’t lost my ability to build. But I have gradually moved away from building as a primary act. Most of my energy now goes into enabling, guiding, deciding, and unblocking. It’s important work. It creates impact. But it’s different.

There’s a certain kind of clarity that comes when you’re deep inside a problem, when your only job is to make something work. I hadn’t realised how much I missed that clarity until I felt it again. It reminded me that a part of me still feels most alive when I’m building. Building something with your own hands does something to you. It sharpens you. It energises you. It reminds you why you started.

Growth comes with trade-offs. The higher you go, the more value you create through others. But somewhere along the way, you stop creating things directly.

I don’t regret the direction my career has taken. But this reminded me of something I don’t want to lose.

I value the role I have today. I value being able to shape direction, mentor people, and influence outcomes beyond my own output. That shift didn’t happen by accident. I worked toward it, and it has changed how I think about work.

But that depth of focus still matters to me. Deep, uninterrupted work isn’t something I’ve outgrown. It’s something that quietly disappeared as my calendar filled up.

I don’t want to go back to writing code full-time. But I also don’t want to drift so far from building that I forget what that state feels like. Even if I’m not doing it every day, I want to stay close enough to the craft to remember why I started.

Maybe growth doesn’t have to mean complete detachment from the craft. It might just mean being intentional about returning to it once in a while.