I think eng managers should rely on their ICs to inform them of what is going on, and the manager should be the advocate for IC dev needs. Devs should be able to tell their manager what the pain points engineering is experiencing and the manager should advocate on behalf of their team.
They did know how to code. It just wasn't their job anymore.
It's very easy to turn "but I code" into a weird ego trip for a manager to try to look good while just making their team slow down to deal with the fact they're bad at code review or coding at all.
It's not like there's a lack of work to do for most managers that's not coding.
Why spend time being good at something you don't care about being good at any more?
It is purely a personality thing however for me I would like to continue moving up the career ladder and you rarely see CTOs, VpEng rolling up their sleeves and sifting through CloudWatch logs. I want my focus to be on working the skills associated with those roles.
As a people manager that works with many incredibly capable engineers that are aspiring to be managers, I share with them this advice, 'excellent engineers compound their value by making other engineers excellent. It's far more difficult to do that when you are writing code.'
I wish managers would understand that it's not their job to do that any more - I've had a few technical managers in my time and the best one was totally hands off, except when he recognised a scenario that had caused him grief in the past (e.g. boolean fields in a database or anything completely over-engineered). The other ones have just rapidly descended into "I'm the manager therefore my opinion is final" (including one who had never worked with Java, PHP, MySQL, serverless or AWS but didn't let it stop him from having strongly held technical opinions).
At a smaller company, a manager of a small-ish team might not have enough meetings and planning work to fill the workweek.
I’ve been at small and medium companies where managers were hired from big companies and felt obligated to keep their calendars full. They would invent new meetings, come up with new ideas, and churn the roadmap to fill the time and look like they were doing something. It was depressing.
Is your environment too complicated to set up? Is the process of deploying something too onerous, and you'll still be trying to get it into production by this time next week? Do you not have any easy bugs to work on, and is that because they all get fixed or just because nobody's recording and triaging them? Is your tech stack too complicated for an infrequent contributor to understand?
These are all really important things to know! And you would know them if you tried to write some code! Any code at all, written at any frequency less than a year apart, would help understand your team.
The reason managers should code is more so that they maintain familiar with the state of the codebase. There's no particular output rate required for this, they don't even need to merge their changes, but they should be getting their hands dirty and making sure they still know how the pieces fit together.
I wouldn't trust a long term plan from someone with their head in the clouds. They have to be able to see the ground to draw a roadmap.
If they close a few tickets here and there, that's just icing on the cake.
TFA says the manager should be in the code but not necessarily writing code. I disagree. The only way to be in the code is to write it, even if you throw away what you write. I agree with TFA that the manager should not be in the critical path (unless there's some sort of crisis). But I don't think they can keep current in the state of the code by just reviewing PRs, unless they're a real coding genius.
ppl here always say "politics" is just learning to work with other people. So your manager is shieding you from working with other ppl ?
That's not "working with other people" - that's office politics.
- Other director comes and says: why should we work with your team instead of rolling out the same product ourselves (and getting your team laid off)?
- Our director comes and says: your team is too slow, why? You should do X instead of Y. Z Is super urgent: cancel your plans and do it.
- Other manager: my team is better than your team! My people deserve a raise/promo/whatever more than yours.
- Write and design your packets (if in a corporation), or your career path (if in a smaller company)
- Align with other teams, get consensus, shield you from politics beyond your level.
- Make long term planning and making sure your team and neighboring teams follow it.
- Listen to you and your colleagues and handle conflicts.
EDIT: forgive me for not reading TFA first. I won't change my comment as it aligns very well with the article. I still think that the answer to the "should code" question is no, not maybe... Let's not try to overload and overcomplicate what "coding" means.