If you play an instrument you may know the story. I have completely lapsed on practicing the piano. I used to be pretty good at it, but when I sit down to play these days my fingers are thumbs and my brain can’t connect with the keys like it used to. I can read the music, mostly, and I can remember how to play some pieces, but it’s almost painful to play because of the feeling of what I’ve lost. This is exactly the feeling I have when I try to write code these days.

I used to write code every day. Now I mostly talk about it.

At some point in many technical careers your job changes from building something to making sure something gets built. It’s a natural progression of leadership and responsibility if you go down that route.

But recently I realised something uncomfortable. When I sat down to actually write code again, I felt rusty.

Feeling Rusty

I recently went through a technical interview process for the first time in a few years and it was a bit of a shock to the system. The challenge was pretty simple: here’s a brief for a simple product, create it from scratch using the tech of your choice.

I knew the company was AI-first, so I prepared for that. I planned a BDD-style workflow and some starter projects so I could adapt quickly to whatever the brief turned out to be.

I piped the specification into a chat tool, generated some BDD features, opened Cursor… and then got very nervous.

Watching myself write code in interview conditions made it very clear that a lot of what I do isn’t actually writing code anymore. I was displaying my lack of hands-on ability by so heavily using AI - and I wouldn’t have felt comfortable writing it from scratch either as it’s so long since I have done. I tried to talk around the code but found myself saying out loud in the interview: “Is this what you want to see?”

I had spent days preparing for the possibility of being embarrassed, for feeling out of my depth, and for approaching the test in an AI-first way — without really confronting the underlying issue that I was rusty at writing code. That realisation hit hard and pulled into focus something I had been feeling for a while.

I am around code all the time, I read it, I review it, I design it… but somehow I never really write it in a meaningful way. Even when I do it at home, I short-circuit things with AI tools as it’s all I have time for.

What happened? Why do I feel like a junior developer fumbling my way through language features and basic syntax? I can admit, this was a very humbling experience after 5 years of stepping into technical leadership roles. How have I drifted so far from code?

The Drift

I’m not sure exactly when it started but it’s been going in a direction away from hands-on coding for a while now. The first role that took me that way was technical lead for a team of engineers. At the same time I picked up a squad lead role which meant I was both technical oversight for a team, but also managed people from across technical and non-technical backgrounds. I am good at managing people so this felt like a good step up but it meant that I had to find a way to incorporate a whole lot of leadership into my day-to-day, whilst also being naive enough to think that I could stay as close to the code as someone who did it all day every day.

In the beginning this meant many extra hours, outside of work time, to keep up with the code and the team. I was convinced it was something I needed to do to keep my eye in - and looking back I think that might have been a good instinct! Over time my focus had to change. I had to learn how to delegate, how to trust my team, how to step back and let them do their thing, and how to support them in doing that. I had to learn how to manage up as well as down, and how to navigate the politics of the organisation. All of this took time and energy, and it meant that I had less and less time to spend on the code itself.

This experience is not just mine, it’s been documented in the Lead Dev Engineering Leadership Report 2025 which found, compared to previous years:

• 38% of engineering leaders worked longer hours
• 58% spent more time on communication with team, customers and stakeholders
• 40% spent more time on people management and managing upwards
• 26% spent less time on coding and code reviews

Fast forward a couple of years and I went into a senior leadership role where I was responsible for multiple teams and my journey took me even further away from code. I wasn’t even reviewing it on a regular basis any more - was more involved in setting strategy, managing stakeholders, and trying to influence the direction of the overall project. I was talking about how to measure a good team with metrics, what culture and standards needed to be in place. Code was definitely there, but it was more of a high-level overview than getting into the nitty-gritty of writing it.

Things changed recently in the last year. I’ve gone back into a tech leadership role for one team. I haven’t quite managed to shake a whole lot of other responsibilities - I still line manage around 25 people and have both delivery oversight and stakeholder management responsibility to somehow incorporate into my day! This move has taken me closer to the code again as a direct technical escalation point and responsible for low-level design for a product. I’ve even written some code in the last few months!

The Moment of Realisation

Coming back to being more hands-on has made me realise just how much I had drifted away from hands-on coding. I don’t think in code like I used to, I think in terms of design, standards, patterns. I don’t have the muscle memory for syntax and language features that I used to have. I don’t have the confidence to just jump in and write code without a lot of planning and design first. I feel like I’m starting from scratch in some ways, and it’s a bit daunting.

I’m slower to understand how to solve problems with code, and I have to spend more time thinking about how to structure my code and how to use the language features effectively. I am back to that initial stage of entering technical leadership, where I’m trying to find the right balance but coming in from the opposite direction.

I’m also aware of all the things I’ve not experienced first-hand while I’ve been out of practice - changes to frameworks, edge computing, serverless, AI tools, cloud developments, language features. Facilitating others to use these things is not the same as doing it yourself. I feel like I’ve missed out on a lot of the fun that comes from experimenting with new technologies.

It’s like running a marathon and realising you’ve been on the wrong track for a few years.

How can I get back to that feeling of code under my fingertips? I want to imagine what I need, think in code and write it without hesitation. I want to just jump in and write code. I want to feel like I’m a craftsperson again, not just a designer or manager. Feeling like this is a humbling experience, but it’s also exciting in a way - it’s like I’m rediscovering the craft of software engineering.

Underneath all this is the realisation that:

• I miss writing code!
• I have lost something I once had
• If this continues, I’ll lose the thing that makes me a good technical leader - the ability to write software

I think this is the one thing that scares me the most about the drift - that I’m becoming worse at the thing that I love.

Why Craft Matters

Writing code yourself is satisfying in a way that designing it isn’t. It’s a different kind of creativity; there is nothing quite like the feeling of making something and seeing it work. I get a similar feeling from cooking, or pottery - there’s nothing quite like using your hands. I want to enjoy that again, I want to get past the theory of DevEx and flow and actually feel it.

I hate to admit it, but my instincts are dulled. I’ve spent too much time theorising about code but I’ve lost touch with how things work in practice. Debugging, building things, testing its limits and experimenting are all things that I used to do frequently. I don’t think you can really understand the tools you have without doing so. The people who build languages, frameworks, IDEs and developer tools are the true craftspersons - how can I understand their thinking better?

But beyond that, technical leadership requires technical depth. You don’t need to solve every problem for everyone but you need the ability to jump in and solve problems when needed. You need to know the codebase, know your engineers and their strengths, know the limits of the thing you are building and how it fits into the ecosystem it lives. You need to be able to sound credible, like you know what you are building and how it works. You need to be able to understand the trade-offs of different approaches and make informed decisions. You need to be able to mentor and support your engineers in their technical growth, and that requires you to have a deep understanding of the craft yourself.

I don’t want to dramatise things, but if I don’t do something about it I might as well be any other manager that uses buzzwords and doesn’t understand them - or is that person who says “I used to be a software engineer” and you think to yourself “why do they act like they don’t understand writing code then?”… I really don’t want to be them. I want to be the craftsperson leader, if that’s even possible!

The Experiment

The idea is simple. A blog.

Radical idea I know… but the focus is on sharpening my software engineering toolset and gaining back what I’ve lost. I want to revisit old languages and frameworks and see them through new eyes. I want to get hands-on, explore how it feels, and share the pain points along the way. It’s an experiment in finding out what sort of software craftsperson I am now. How do I get back to my technical core? I want to feel more technical while still being a leader. I need to try something to get me there.

I am rusty. I am not broken yet…

I’ll be writing about:

• Relearning Technology: rediscovering technical concepts, languages and frameworks
• Engineering Craft: geeking out about good code with hands-on experience
• Technical Leadership: explorations of my experience in leadership
• The Journey: some updates on where I am and how it feels to get back into it

The Plan

I don’t expect to become the engineer I was ten years ago but I do want to become the kind of technical leader who still knows how to build things like a true craftsperson.

An out of practice piano player can enjoy playing again. Software engineering is a craft, and like any craft, your tools get dull if you stop using them.

This blog is my attempt to sharpen them again.

I’ll be publishing my journey under return to engineering.

Now, back to practicing…