There’s a particular kind of melancholy that hits engineering managers around the six-month mark. You’re in your fourth meeting of the day, you’ve just spent an hour on a spreadsheet, and you glance over at your team, heads down, headphones on, deep in the flow state you remember so well. And you think: I miss that.

I still feel it. After all these years, there are days when I’d trade every meeting on my calendar for four uninterrupted hours with a codebase and a problem to solve. The feeling doesn’t go away. But understanding it, what it actually is, and what to do with it, makes it manageable.

What You’re Actually Missing

When I dug into this feeling, I realised it wasn’t really about code. It was about three things that code happened to provide:

Flow state. Mihaly Csikszentmihalyi’s concept of flow, that state of complete absorption where time disappears and you’re operating at the edge of your ability, is one of the most satisfying experiences a human can have. Programming is one of the most reliable ways to achieve it. Management, with its constant interruptions and context-switching, is one of the least.

Tangible output. Code is concrete. You write it, you run it, it works (or it doesn’t, and you fix it). At the end of the day, you can point to something you built. Management output is abstract, conversations, decisions, relationships, and the feedback loops are measured in weeks or months.

Mastery. You spent years getting good at programming. You developed expertise, taste, and instinct. Moving into management means starting over as a beginner in a new discipline, and that’s uncomfortable for people who are used to being competent.

Understanding these three components helps, because they suggest different responses. If you’re missing flow, you can find it in other activities, writing, deep strategic thinking, even certain kinds of one-on-one conversations can produce a flow-like state. If you’re missing tangible output, the daily impact log that Jean Hsu recommends can help retrain your sense of what counts as productive. If you’re missing mastery, the answer is patience, you’ll get good at management too, it just takes time.

Channelling It Productively

I still carve out time to write code. Not because my team needs me to, they’re better at it than I am in most areas, but because it keeps my technical instincts sharp and gives me a few hours a week of the focused, creative work I find energising.

The key is being honest about why you’re doing it. If you’re writing code because it genuinely helps the team, internal tooling, developer experience improvements, small quality-of-life fixes, that’s productive. If you’re writing code because you’re avoiding a difficult management task, that’s avoidance dressed up as contribution.

Larson describes this pattern as “snacking”, doing small, satisfying tasks that feel productive but aren’t the highest-value use of your time. The PR review that could wait. The bug fix that someone else could handle. The refactoring that scratches a technical itch but doesn’t move the needle on anything important. Snacking feels good in the moment, but it comes at the cost of the strategic work that only you can do.

The honest question to ask yourself is: “If I weren’t doing this technical work, what management work would I be doing instead?” If the answer is “nothing, I’ve handled everything”, great, enjoy the code. If the answer is “well, there’s that performance conversation I’ve been putting off…”, you know what you need to do.

When It’s a Signal

Sometimes the feeling of missing code isn’t nostalgia, it’s a signal. If you’ve been in management for a year or more and you’re still consistently wishing you were back in an IC role, that’s worth paying attention to.

Not everyone is meant to be a manager. That’s not a failure, it’s self-knowledge. The industry has a bad habit of treating management as the only path to seniority and compensation, which pushes people into roles they don’t want and aren’t suited for. Some of the best engineers I’ve known tried management, realised it wasn’t for them, and went back to IC roles where they were happier and more impactful.

The question isn’t whether you miss code, almost everyone does. The question is whether you find enough meaning in the management work to make the trade-off worthwhile. If the answer is yes, the missing-code feeling is just a cost of doing business. If the answer is consistently no, it might be time to have an honest conversation about your career path.

Finding the Balance

The balance I’ve landed on after many years is this: I stay hands-on enough to keep my technical instincts sharp, but I don’t pretend I’m still an IC. I do code reviews, I write small tools, I attend incident reviews, I read technical RFCs. I don’t take on critical-path work, I don’t block my team’s decisions, and I don’t use technical work as an excuse to avoid management work.

Some weeks the balance tips more toward technical engagement. Some weeks it tips more toward people and strategy. The important thing is that the tipping is intentional rather than reactive, I’m choosing where to spend my time based on what’s needed, not based on what feels most comfortable.

And on the days when I really miss it, when the pull toward the keyboard is strongest, I remind myself why I chose this path. Not because management is more important than engineering, but because I found that helping a team of engineers be their best was more satisfying to me than being the best engineer myself. That realisation didn’t come quickly or easily, but it’s held up over time.

The code will always be there. The opportunity to shape how a team works, how people grow, and what an organisation can achieve, that’s the work that chose me, even on the days I miss the old work.