Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should managers still code?

theengineeringmanager.substack.com

Post reply on HN
Print view View original

91–100 of 319 posts

Re: Should managers still code?

#91

Post by mp05 »

scarface_74 wrote: post #85
mp05 wrote: post #33

> If you mean being the primary implementer of features, then probably not. It's my belief that any engineering manager worth their salt should push back on this and argue for a seat at this table, every single time. I don't want to work for someone who is disinterested in new functionality in codebases under their purview.

I want my manager to manage . I need them to play the politics to get what I need as far as resources, to set business priorities and to make sure I’m aligned with those priorities. I need them to then trust me to accomplish the objectives myself on smaller implementations or to lead the team on larger implementations.

I can't tell if you're agreeing or not?

I'm not asserting anything about if a manager should code, but rather calling out a statement in the article. A good engineering manager should never be surprised by some new functionality.

Re: Should managers still code?

#92

Post by convolvatron »

eevilspock wrote: post #66
n_u wrote: 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 think it depends on how it is done, and the kind of ICs you have on the team. It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.

I've found it really helpful to be a support programmer. not someone that takes on big tasks. nothing with a hard deadline. not something that someone else needs to do their work. leftover cleanup. testing. minor refactoring. build.

you need to keep your hand in the game just to understand what's going on with the codebase. but you're not an a-list player here.

Re: Should managers still code?

#93

Post by roenxi »

x0x0 wrote: post #42
n_u wrote: 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…

Also, I'm just fundamentally skeptical you can do a good job of running a team, or hiring, when you don't know how to do the thing the team does. Software development skill requires active use/work to maintain it.

Here here. There are a lot of decisions where there is no real contest between the choices to someone who has tried both options but are difficult to tell apart from a distance. EMs should be in a position where they are trying things in practice.

I'd draw an example of someone who hasn't used git before, making a choice between a git repo and managing code by keeping daily .zip files. Anyone (almost anyone) who is a career coder won't see a choice there.

That example is so basic I think most EM would get that right even if they didn't deal in code but the same dynamic turns up at every level of work. There are situations where there is a right option, the right option is obvious to everyone who is working on it and it is is a drain on the org when management gets confused and thinks that something that isn't an option is viable because they aren't on the ground working on it.

Re: Should managers still code?

#94

Post by tommykins »

I don't code much anymore, the vast majority is reviews the only time I really need to get on the tools is if it's a concept that I need to teach someone, or more likely, something has gone quite badly wrong and it's 2100 and I don't feel like waking anyone.

Re: Should managers still code?

#95

Post by lexandstuff »

mitthrowaway2 wrote: post #22
robotsquidward wrote: post #18

My best managers were ex-engineers who didn't touch the codebase. They understood how things worked, and could talk architecture & concepts, but they didn't expect to be able to sit down and write code at our level. Maybe they wished they would have the time/opportunity still, but realistically they were focused on leading.

My best managers did code! They didn't close tons of tickets but they did do small things, and by keeping active in the codebase they were very cognizant of the state of documentation and technical debt, and could make informed decisions without relying on second-hand reports. It kept their understanding of the codebase grounded in reality. They knew which features were held together with duct tape, what areas needed…

This is 100% my experience. I appreciate a manager who can jump into the codebase to fix the small stuff: typos, lint issues, updating minor dependencies, etc., unblocking devs from doing the main work. I like when they have some sense of the reality of the codebase, as you put it, and know who is actually contributing vs bullshitting.

The worst managers I've ever had were the so-called "technical" managers who had never looked at the code. They were often involved in technical decisions, but their opinions were entirely based on vibes. Since they were a manager, people felt obliged to listen to their input, even if it was disconnected from reality.

Either: a) be completely non-technical, and make sure you have a technical leader on the team who you trust, who does know the code or b) get involved in the code, enough to support and unblock your team.

Re: Should managers still code?

#96

Post by tschellenbach »

Yes, managers not coding was caused by ZIRP. It's a dumb idea.

- You need to understand the work to evaluate your team

- You need to understand the work to prioritize and rank what's important

- You need to understand the work to know which roles to hire for

- Good developers typically don't want to have a non-technical engineering manager

- The budget for a non-contributing team member reduces your budget for engineers

- It creates a more hierarchical and less flat org chart, which creates communication scaling challenges

I would only consider non-technical managers for companies with large budgets and a non-technical product. Not only should they be technical, they should be excellent.

Re: Should managers still code?

#97

Post by vrosas »

dietr1ch wrote: post #63
n_u wrote: 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…

> 1. Reducing dev friction. This is so important, my managers who didn't code pretended things weren't too bad and took a "just deal with it" attitude whenever I proposed going for a QoL improvement.

On the flip side I had a manager who had written a lot of the codebase before I joined and had a terrible time allowing anyone to touch his precious baby, regardless of how much his prior ”art” was hurting us, our productivity, and by extension the company.

Re: Should managers still code?

#98

Post by only-one1701 »

robotsquidward wrote: post #18

My best managers were ex-engineers who didn't touch the codebase. They understood how things worked, and could talk architecture & concepts, but they didn't expect to be able to sit down and write code at our level. Maybe they wished they would have the time/opportunity still, but realistically they were focused on leading.

In my experience, there's a time limit on how long these kinds of people can be good managers from the perspective of accurately assessing a) which ICs are contributing what and b) how long it it'll take to implement something. The fact of the matter is that an engineering manager who can't or won't write code will never know as much about his team or indeed the product as one who does.

It's a shame that the "maturation" of the tech industry has resulted in these non-coding eng managers whose main skillset is often bullshitting, managing up, or both.

Re: Should managers still code?

#99

Post by andoando »

n_u wrote: 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

Re: Should managers still code?

#100

Post by crazygringo »

breadwinner wrote: post #39

Steve Jobs on this topic: https://www.youtube.com/watch?v=bVKcxK_tVBM Summary: Managers who know how to manage, but don't know how to do anything are not the best managers. The best managers are the great individual contributors who never ever wanna be a manager but decide they have to be a manager because no one else is going to be able to do as good a job as them.

There's a third option that's missing from that dichotomy: people who are OK individual contributors but who are actually really good at managing people.

These are the best managers, because they have the disposition/skills to be a good manager, but also aren't going to make dumb engineering decisions.

IC's who become reluctant managers are generally terrible managers because it's not what they're good at and not what they enjoy.

Post reply on HN