Engineering Managers Should (Sometimes) Write Code

I spent the last few evenings polishing the trip planner feature that an intern built for the OneBusAway iOS app. Not reviewing the code, not providing architectural guidance, but actually writing Swift to handle edge cases in the UI and fixing layout bugs that only appear when someone enters a destination with a really long name.

This is exactly the kind of work that conventional management wisdom says I shouldn’t be doing. As an engineering manager at a healthcare technology company by day, I’ve internalized the standard advice: managers who write production code create bottlenecks, undermine their teams, and avoid the harder work of building organizational capacity. All of that is basically true.

But I write far less code today than I did five years ago, and I’m finding that occasional hands-on work has a value that transcends the immediate pull request. The OneBusAway project, which I help run in my spare time as part of the nonprofit behind it, has become my laboratory for staying connected to the craft of software development in ways that matter.

The difference between reviewing code and writing code is the difference between knowing about something and knowing something. When I review a pull request, I can spot architectural issues, suggest better abstractions, and catch obvious bugs. But I’m evaluating someone else’s solution to a problem I haven’t personally wrestled with.

When I’m the one fixing the layout bug, I remember what it feels like to debug iOS Auto Layout constraints and hunt down why the destination label keeps getting truncated. I remember the cognitive overhead of keeping the entire view hierarchy in my head while finding the one constraint that’s causing the problem. I remember the satisfaction of finally getting it right.

That visceral experience recalibrates my expectations in ways that pure code review can’t. It’s easy to casually suggest “just add a loading state” in a PR comment. It’s different when you’re the one implementing it and discovering that the loading state needs to handle three different error conditions, animate smoothly with the existing UI, and work correctly when the user rapidly switches between tabs.

This isn’t nostalgia for my IC days or unwillingness to let go of technical work. I genuinely spend less time coding now because that’s the right trade-off for the leverage I get from enabling my team. But completely disconnecting from the act of building software would make me a worse manager.

The polish work is particularly instructive. The intern did substantial work getting the trip planner feature functional and working well. But there’s a well-known adage that the last 20% of the work takes 80% of the time. Getting it to feel genuinely polished requires attention to dozens of small details that each individually seem trivial but collectively determine whether users love or tolerate your app. The difference between a trip planner that works and one that feels polished is animations that don’t stutter, error messages that actually help, and UI that doesn’t break when someone has accessibility text size cranked up.

When I’m doing this work myself, I develop empathy for how much effort polish requires. This changes how I prioritize work, how I talk about quality with my team, and how I push back on product requests that assume polish is free.

There’s also something valuable about working in a codebase where the stakes are different from my day job. The OneBusAway iOS app serves real users who depend on public transit, but I’m not on-call for it. If I ship a bug, it’s embarrassing but not career-limiting. This creates space to experiment with Swift features I haven’t used before or try architectural patterns that would be risky in production healthcare software.

The key is knowing the difference between hands-on work that keeps you sharp versus hands-on work that makes you the bottleneck. Polishing an intern’s feature after they’ve moved on? Probably fine. Becoming the only person who can deploy releases? Definitely a problem. Fixing bugs in the iOS app you maintain as a side project? Good. Jumping into your team’s critical path work because you don’t trust them to do it right? Bad.

I’m not arguing that managers should spend half their time writing code. If you’re doing this right, you’re probably talking about 5-10% of your time at most, and ideally in contexts where you’re not blocking anyone else’s progress.

But staying completely away from code as a manager means letting your mental model of software development calcify around however things worked the last time you regularly wrote production code. The tools change, the frameworks evolve, and the constraints shift. Writing code occasionally, even in side projects, keeps that model fresh.

The trip planner feature will ship soon, and users will get a genuinely useful tool for planning their transit trips. The intern did the hard work of building the core functionality. I just added the last 20% that makes it feel finished.

That 20% took longer than you’d think, and I’m better at my day job for having done it.