Coding at work (after a decade away).
Since joining Imprint a bit over six months ago as the CTO of a ~50 engineer team, I’ve merged 104 pull requests, which is slightly over four per week. Many of them are very minimal configuration and documentation tweaks, and none were the hardest or even most time-sensitive task available at any given time; I’m much more of a pull request scavenger finding opportunities that don’t disrupt the operating teams’ rhythms.
That said, a decent chunk represent meaningful software development tasks, and these 104 pull requests are more pull requests than I’ve completed combined in my prior decade of work, where Uber was the last time I was substantially submitting pull requests (well, whatever Phabricator called its pull request equivalent). Since then, I’ve been predominantly managing managers, and not writing software with my own hands at work.
This has been a fascinating shift, and I wanted to write down some thoughts on whether this is good for software, good for me, whether it’s fun, and how I’ve personally worked to adapt to the current era.
Unrelatedly, I did enjoy Peter Seibel’s Coders at Work (2009).
Dubious return-on-effort of manager coding
I was a computer science major, and worked as a software engineer prior to becoming an engineering manager. I continued to write software when I was a line manager, and continued to write small projects in my free time after becoming a manager. The idea of writing software at work has always been appealing to me.
However, when I became a manager of managers, I stopped writing software at work. I wanted to write software, but it simply felt like a lower return on time than doing something else. For example, if I focused my time on hiring another engineer onto the team, they would undoubtedly do more than I would. Similarly, if I spent time improving our plans, that would have a higher impact than me writing a piece of software. Ultimately, I got stuck in the trap that it was always clear that writing software would be valuable, but it would always be less valuable than another endeavor. Each hour I spent writing software was bad for the business overall, and a sign of questionable judgment.
The same wasn’t true when it came to understanding the codebase, and I’ve tried–to various degrees of success–to build a workable degree of awareness of the codebases I’ve managed. That being said, since I left line management roles, I’ve never been truly successful at doing this beyond the superficial level. My experience is that only writing software can build a truly effective understanding of unreasonable software, and that most startup software is unreasonable due to its origin of being iteratively designed by a shifting cast of characters with an evolving understanding of the domain they are modeling.
You can get very far with a minimal understanding of a codebase and surrounding yourself with strong engineers who you can ask useful questions to and get honest answers. For the big things, this is generally sufficient, but it means you can’t really engage with the small questions without spending engineers’ time on it or making low-judgment decisions.
Whether manager coding is valuable comes down to whether you believe making large decisions more quickly with fewer interrupts for context pulling–and the ability to make numerous small decisions that are otherwise too expensive to make effectively–builds into meaningfully more impactful management. This isn’t a proclimation for others, but for me, I’ve really enjoyed getting back to writing software at work, in large part because the time commitment to do so has dropped significantly over the past couple years.
Finding small pockets of time to write software
The biggest specific challenge for me when it came to writing software as a manager was finding blocks of thinking time to either understand a problem, or to implement the solution. Even simple fixes require an effective mental model of the codebase being worked on.
This becomes inescapably true when you’re focused on long-term impact of your work. For example, adding a bunch of tests might be useful, but it’s often the case that poorly designed tests get thrown away over time because they overlap with other existing tests, are flaky, or are slow in aggregate. I think traditionally, a lot of manager coding has fallen into this bucket of optically useful with somewhat dubious long-term value. Doing high quality work simply requires too complete a mental model for folks jumping in and out of writing software.
The new wave of AI tooling like Claude Code or OpenAI Codex are extremely susceptive to creating low-quality commits, but my experience is that used effectively they also provide several opportunities for creating useful code contributions as well. They are effective at:
- answering questions into a codebase, e.g. “what are our most common patterns for working with authn and authz? what are good examples of each?”
- writing code that fits the existing codebase’s patterns and structure, particularly with a well-written
AGENTS.md’s guidance - taking general feedback to revise the approach, e.g. “look for existing utilities that solve date math within our codebase and reuse those”
Most importantly, you can do each of those in a few minutes at a time. Between meetings at work, I generally pop back into one of several Claude Code sessions to see where it got to on a given task, review the code, and suggest next steps.
It’s worth acknowledging that there’s a significant learning curve to doing this well. I’ve spent a meaningful amount of time in the last year learning to write software this way, and each month there are new caveats that I’ve had to understand. Slowly but surely, I’ve built a mental model of both how writing software with AI works, and how Imprint’s codebases work.
As I’ve gotten more knowledgable at both, I’ve refound my ability to write software at work because I can make progress in the small chunks of time between other projects, combined with an hour or two over the week to think more deeply about my approach to more complex issues.
Judgment / problem selection
While new AI tools make it easier than ever for managers to write useful software at work, they also make it easier than ever to write unhelpful software at work. Particularly in senior roles, it’s very easy to write software that makes you feel helpful, but is genuinely unhelpful to the team, and leaves them busier than they were before.
The handful of rules that I’ve found useful for myself here are:
Never contribute to something that is truly time sensitive unless it’s a very constrained thing that I can solve end-to-end today. When that isn’t the case, I’m usually going to slow things down despite trying to help.
Prioritize projects that are hard for teams to get to, but are obviously valuable over time. For example, technical debt clean up, small user-requested features, or missing instrumentation.
Infrequently take on a strategic company project which doesn’t have an owner, and which I am able to complete myself. A real example of this has been writing our first pass of a new Interactive Voice Response built on an AI agent, which was clearly valuable but difficult to prioritize over the team’s existing work.
Hold myself to a higher bar than I would hold others in terms of fully releasing my software, monitoring its release, and solving bugs it creates. If I don’t have time to do those things, then I am stealing time from the team rather than helping them.
Err towards implementing feedback in pull requests, even if I consider it generally neutral. The cost of giving feedback to me is so high for folks, that I’m responsible for going out of my way to incorporate it when it is given.
These rules have meant that I didn’t work on some projects that I wanted to, but I think they’ve done a fairly good job of allowing me to build my judgment about how our software works without getting in the way of the teams who are doing the vast majority of the heavy lifting. I’m sure there are better versions of these rules, but in general I’d guess that managers ignoring them are close to the border of being unhelpful.
Should you be coding at work?
I’m pretty sure that “Should managers be coding at work?” isn’t nearly as interesting a question as folks want it to be, and a meaningful answer depends on each situation’s details. However, what’s been clearly true for me is that the overhead of writing software at work is substantially lower than it was a few years ago. If you weren’t writing software at work because it simply took too much time away from managing the team directly: the constraints have shifted in a profound way after you learn the new wave of tooling.
The learning loop for writing software with agents is definitely not zero, but it’s something you can learn for a few dollars of tokens and a couple dozen hours spent writing personal projects that are safe to throw away afterwards. That feels like a worthwhile investment to remain effective in one’s chosen profession.