[mitthrowaway2]

My best managers did code! They didn't close tons of tickets but they did do small things, and by keeping active in the codebase they were very cognizant of the state of documentation and technical debt, and could make informed decisions without relying on second-hand reports. It kept their understanding of the codebase grounded in reality. They knew which features were held together with duct tape, what areas needed attention, and planned timelines and expectations accordingly.

[lexandstuff]

This is 100% my experience. I appreciate a manager who can jump into the codebase to fix the small stuff: typos, lint issues, updating minor dependencies, etc., unblocking devs from doing the main work. I like when they have some sense of the reality of the codebase, as you put it, and know who is actually contributing vs bullshitting.

The worst managers I've ever had were the so-called "technical" managers who had never looked at the code. They were often involved in technical decisions, but their opinions were entirely based on vibes. Since they were a manager, people felt obliged to listen to their input, even if it was disconnected from reality.

Either: a) be completely non-technical, and make sure you have a technical leader on the team who you trust, who does know the code or b) get involved in the code, enough to support and unblock your team.

[noirbot]

I think this is kinda the best way. If you're a manger who used to code, do the sort of tedious tech debt stuff for your team. Update dependencies. Build small tooling improvements. Do the sort of stuff your devs probably want to do but have higher priority work that will get in the way. That's likely work that doesn't require you to have deep knowledge of how everything works, but still provides value.

If your project is complex enough that's not an option, then write onboarding docs and other technical stuff. IMO, the manager shouldn't be writing code much, but they should always keep a running version of the project. They should be able to run tests, confirm that PRs function locally, just keep a basic attachment to things.