Hacker News Reader

Comment by etamponi | Hacker News Reader

No. The amount of work that a manager has to handle to do their job right is incompatible with coding at a professional rate. If you have a manager that codes, then they won't have (enough) time to:

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

View on HN

I've seen manager calendars, and their days are packed with meetings. Expecting them to do in depth code reviews, pairing, is unrealistic.

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.

It has been interesting what both groups of 'yes' and 'no' chime in here. Personally I am on the side of 'no' but for a rather simple reason. I ask myself the following question:

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

Depends, I always took a sprint task, certainly less than the team itself, but how do I design a career path if I'm blissfully unaware of the work that is being done? How do I plan long term if I don't understand the technical complexity of the problems being faced? Why would I waste time on conflict resolution when I can spend time enabling and building people? You want to argue about your colleague, or make do you want to advance and make more money?

I am not gonna argue because I totally see your point. I'll keep my "No" because I think you can still do everything positive you listed without coding. I know it because I had great managers for 10 years, and none of them touched a line of our code.

They did know how to code. It just wasn't their job anymore.

This so much - I had a manager early in my career who had written code many years ago, but in his management role he touched no code at all - I think he probably spent a bit of time watching Youtube at his desk. But if someone tried to dump work on the team, messed up a shared environment, tried to bother one of the team with an out of band request he absolutely pounced on them and tore them to shreds. He well and truly understood his job was to make sure we could do ours.

Strong agree. The best managers I've worked for have been capable of coding and were often former devs, but didn't insert themselves into the team's flow like that.

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.

If you can't make a half-day of time once a quarter to fix a bug or make a minor UI change, then I would argue that you are wilfully avoiding doing it, and that some introspection as to why you are avoiding it would be helpful.

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.

I am a manger and the best I can do is occasionally fix minor bugs and improve public docs. I feel like doing that is very important to better “stay in touch” with the product.

Kudos for that! And lucky :) I think we agree that no much time is left a part from minor bug fixes :)

This depends entirely on the company and its size. At a big company it’s likely a manager’s calendar will be packed with meetings.

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.

This is a tough question since what's best for the team and what's personally best for the manager's career may be in conflict, at least when it comes to the long-term. A manager who doesn't do any coding will over time get rusty and get further and further away from the current best practices, latest library/framework hotness etc. This can lead to awkward conversations of the type where the manager suggests "let's do/use X" where X was the best practice 5+ years ago and then it has to be diplomatically explained to him/her that's no longer the best practice. It can also be dispiriting to the manager if they got into software development because they enjoy coding, but now they have to deal with planning, people management etc., which they might be good at, but it may not bring them the same level of job satisfaction.

> This can lead to awkward conversations of the type where the manager suggests "let's do/use X" where X was the best practice 5+ years ago and then it has to be diplomatically explained to him/her that's no longer the best practice

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

What do you mean by "coding at a professional rate"?

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.

This has not been my experience; at Apple most of my managers were very good and were also coding.

> shield you from politics beyond your level.

ppl here always say "politics" is just learning to work with other people. So your manager is shieding you from working with other ppl ?

There are orgs where you ask another team for help unconditionally with your problem affecting the company and there are orgs where no one will help you, huge problems be damned and you can't even get your coworkers to cooperate without going to your (and their) boss.

That's not "working with other people" - that's office politics.

Good call. I am not referring to that though :) I mean scenarios like:

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

Reply on news.ycombinator.com