[Avalyst]

Programming is a skill just like management. I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill.

If you come from a strong technical background when first promoted (Being the go-to expert on the team or similar) then you can probably keep the respect of the team for a while but eventually others will rise to fill the gap (After all there is 95% of a rockstar programmer's time missing in the team). At that point your comments on code reviews will mostly be seen as micro management.

I would say that there are two ways to go about it, either fully trust your developers and let them develop and review their own code or stay as an active member of the team, doing as much coding as you can fit into your schedule. Which route you pick of course depends on the workload of managerial duties.

[sanderjd]

This doesn't mesh with my experience. The skill of programming is not in writing code, it is in constructing solutions using code. For someone who has already written software for a long time, I believe critical reading and discussion of code keeps the skill just as sharp.

Reading lots of code also gives a broader perspective than writing lots of code, which requires a sort of tunnel vision. Both the deep and the broad perspective are useful on a team.

[BeetleB]

>I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill.

The amount a developer (not manager) should code varies from domain to domain. In my work, 5% may be on the low side. But I'd argue in most domains, if you're spending more than 20-30% of your time coding, you're overdoing it and creating too much technical debt.

I'm not a manager, but if I were, I'd promote the folks who find (good) reasons not to code than to code. Some problems need software to solve a problem. But writing software should be a last resort.

Of course, if you're writing throwaway code on a code base that won't last more than a year or two, code away. Technical debt is not a big concern.