Daily syncs allow the loud, not necessarily the most productive, to dominate. You cannot judge someones actual contributions by what they say.

I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc.

But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.

You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand.

Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.

Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.

Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.

You can see this when you join a (disfunctional) new team, notice the friction, then suggest improving it.

If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them?

I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.

I think you can certainly learn a lot by being curious and fishing out anything that smells, yeah.

But agreed that youll find more mistakes, if your manager also happens to be the best IC on the team.

Fewer or shorter daily syncs is a plus

I don’t see how you can understand something without being part of it.

It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing.

The same for working with the team - it is so much different than listening and trying to understand.

Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

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.