But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code.

If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask.

As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC

How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.

I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on?

Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects

After thinking about what you wrote here I have some conclusion:

If someone is "good manager" that does all those things whether he writes the code or not he is going to be a "good manager" anyway. Explicitly writing code might not be best use of time but hey if person feels like he needs it that is on him.

If someone is "bad manager" that doesn't bother to deal with technical details and wants only to do "important management stuff" and thinks he can manage by proxies like counting story points or counting closed tasks, does not care about HTTP client A or B and learning the system, he is going to be a "bad manager" and will never even care about writing code.

Finally "bad manager" and "good manager" - is hard to tell because "bad manager" can be good for the company or a team as much as "good manager" and depending on many other factors it can be that "down to earth, hands dirty, good manager" might be really bad for the company or a team depending on business context.