Live data from Hacker News

Should managers still code?

theengineeringmanager.substack.com

131–140 of 319 posts

Re: Should managers still code?

#131

Big no! from me. Anyone in a people leadership role has to have a political mindset. You simply cannot be technically oriented and politically oriented at the same time. This is not a negative, the human brain, generally speaking, can't focus on two unrelated priorities at the same time. I have had a highly negative experience over this. When resolving technical conflicts, you expect technical merit and reasoning to…

> If you disagree with your manager, your performance review will suffer, you will be called disagreeable, hard to work with,etc

I think your experiences sound like a case of a very bad coworker, whether manager or not.

I don't want a manager who knows nothing about the applications and the architecture. I have no desire to punch a clock and be coddled with public mentions and work parties. I want to work with people (including my manager) who want to solve problems together, and solve them the right way.

There may be problems that arise because my manager is busy trying to do technical work but I'll take that any day over a manager who can barely speak the same domain-specific language, constantly gets facts wrong, gets upset as a result of their misunderstandings, applies arbitrary deadlines and expectations, and calls for endless status requests in the midst of all this. No thanks.

Oh and forget any kind of technical direction! Because your manager is forced to accept what people tell them, it becomes a free-for-all where the programmer with the biggest ego wins.

And yes, I too am essentially just describing a hypothetical bad coworker. There are probably some great managers out there who are ignorant of the technology. (Ugh.) But I will put my money on 'technically proficient' or 'involved in the code' every single time.

Re: Should managers still code?

#132

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 makin…

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.

Re: Should managers still code?

#133
I've seen plenty of managers who increased team output 10% for a few months by coding and completely lost the thread in the meantime. That's how your entire team gets laid off. Leadership doesn't care how much code your team writes, they care that you're working on the right stuff.

An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, marketing your team's work internally, hiring, performance management, team bonding, planning, retros, oncall coverage etc. etc, although sometimes you'll have a PM/tech lead/HR contact who handle some of these.

Every now and then, your bottleneck really is just writing more code (more common in smaller companies). In that case, jump in.

Re: Should managers still code?

#134
post #119

People never discuss company size along with this question. If you're at a giant company, the answer is likely no, there's enough politicing and paperwork where the highest impact thing to be done by a manager is likely not coding. If you're at a startup / smaller more nimble org in a big company, the answer is likely yes, if you've gotten to the point where you're a manager, in theory you're a very good engineer and…

Agreed. This debate is useless without discussing the context of company size.

If you’re a manager at a big company with a project that intersects with 5 other teams and you have a dozen people who call themselves stakeholders for your work, you’re not going to have any time to code.

If you’re a manager at a small company where everyone knows each other and team sizes are small, there might be something wrong if your calendar is full of meetings.

I’ve been at a couple small companies that hired big company managers. They felt obligated to create more meetings, documents, and discussions to fill their time and look busy. We finally had to start screening for managers who knew how to fill their time with something productive, whether it’s coding or going out and working with customers.

Generating meetings until your calendar is full is a game in itself at a lot of companies.

Re: Should managers still code?

#136
post #37

Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…

> or worked on hard problems because of comments and Git blame.

Oh lord we'd better hope they have absolutely IMPECCABLE git fu if they are going to be using this metric. Unfortunately here on HN I've seen people essentially brag that they only know just enough git to get by and "who cares if I don't know all the other commands deeply." In any event, this scenario REQUIRES that a manager know exactly how to determine who originally introduced something, or, exactly where it was significantly improved if they are going to be reading comments and blaming to see "who performs."

The very fact a manager might be doing this has got me a little worked up, mainly as I know great managers who don't do this and who are scared of something as simple as the reflog.

Re: Should managers still code?

#137
post #122

Earlier quoted context omitted.

I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs

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.

Re: Should managers still code?

#138

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 makin…

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 d…

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

Re: Should managers still code?

#139
post #37

Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…

I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs

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

Re: Should managers still code?

#140

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 makin…

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…

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.

Post reply on HN