[robotsquidward]

My best managers were ex-engineers who didn't touch the codebase. They understood how things worked, and could talk architecture & concepts, but they didn't expect to be able to sit down and write code at our level. Maybe they wished they would have the time/opportunity still, but realistically they were focused on leading.

[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.

[giantg2]

This is exactly how it should be in my opinion. This matches my experience with who I saw as being good managers.

[fifilura]

Were they happy with it or did they become miserable after a while?

[giantg2]

They were happy with it. On the opposite side, almost every dual role manager I've known have been miserable. Most of the ones I knew dropped out and went back to dev only work. A few stuck it out and got promoted into a no-code management role.

[only-one1701]

In my experience, there's a time limit on how long these kinds of people can be good managers from the perspective of accurately assessing a) which ICs are contributing what and b) how long it it'll take to implement something. The fact of the matter is that an engineering manager who can't or won't write code will never know as much about his team or indeed the product as one who does.

It's a shame that the "maturation" of the tech industry has resulted in these non-coding eng managers whose main skillset is often bullshitting, managing up, or both.