Rediscovering craft

When you step out of the rhythm of writing code every day, it is easy to forget how much muscle memory there is in programming. The shortcuts, the debugging rituals, the half-remembered syntax quirks that once felt instinctive begin to fade. Years spent in leadership roles have their own demands: building teams, setting strategy, and navigating organisational complexity. Those are equally challenging, but they are different in nature from the focus of sitting in front of an editor and bringing a system to life line by line.

Over the last few months, I have been returning to personal projects, and it has been a very humbling experience. I am used to operating at a scale where my role is about direction and orchestration, not necessarily about writing the implementation myself. Coming back to the code has reminded me how easy it is to underestimate the cognitive load of switching between leadership and hands-on craft. Suddenly, I am the one hunting through documentation, chasing down why a container build has failed, or trying to recall the right data structure for a particular use case. It is slower, messier, and at times frustrating. But it is also extremely energising and something I have missed.

There is something grounding about being confronted with your own limitations in a way that leadership rarely does. As a leader, you get feedback indirectly, through outcomes and through others. When programming, the feedback loop is immediate and unforgiving: the code compiles, or it does not, the test passes, or it fails. The clarity of that loop is refreshing. It strips away the abstractions and politics and takes you back to first principles.

Another challenge is the pace of change. The ecosystem keeps evolving, with new frameworks, languages, and approaches emerging at a speed that makes even seasoned engineers pause. I am comfortable with the underlying system design and architecture, but fluency comes from practice, not theory. The gap I feel is less about knowledge and more about rhythm. The shortcuts that once felt instinctive now require more deliberate thought. The tools themselves are familiar, but the way of working with them has shifted. These personal projects are not about learning everything again, they are about regaining fluency, sharpening intuition, and building confidence in applying ideas directly rather than only guiding them from a distance.

What I have found most valuable is reframing the experience. This is not about proving that I can still code as fast as the engineers I have the priviledge of leading. It is about empathy. It is about reminding myself what it feels like to be deep in the weeds, where nothing is obvious and progress comes through trial, error, and persistence. That perspective sharpens my ability to lead. It makes me more attuned to the real effort behind the delivery timelines we casually discuss in leadership meetings. It also reconnects me with the craft of being a builder, which was why I began this career in the first place.

What I enjoy most is the freedom to build side projects without pressure. They give me space to explore new domains, test ideas, and deepen my understanding in ways leadership alone cannot. The code is not always elegant, but the learning is, and even something as structured as Leetcode has a way of humbling me more often than I expect.