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

71–80 of 319 posts

Re: Should managers still code?

#71

Post by peterldowns »

tdeck wrote: post #46

A lot of what's in the article resonates with me. Specifically, I've seen cases where managers unwittingly use coding (a problem they feel comfortable with) as a way to escape from facing more serious manager responsibilities (problems they don't feel comfortable with). When you've got 10 years of experience doing X, and you just started doing Y two years ago, it's natural to try to play to your strengths by doing X.…

I’m in favor of managers being engineers but everything you wrote is true. I wish I had read this comment a few years ago, it would have saved me and my teams some trouble.

Re: Should managers still code?

#72

Post by ryathal »

A manager of developers should know how to code, but any formal expectation of them coding shouldn't exist. This holds for medium to large organizations. The managerial duties should be enough to require the vast majority of their attention. Expecting development on top of management is a way to add fake capacity to a team to help ensure burnout.

Re: Should managers still code?

#73

Post by jedberg »

I'm a good coder, not a great one. I hire great coders to work for me so that if I had to write code I would be the worst and least productive person on the team.

Therefore it is to everyone's benefit that I don't touch code. I do sometimes put on an engineering hat and help with brainstorming how we will build new things, or asking questions about open issues that no one has asked, but that is the extent I will get involved in engineering. I try to only get involved when it's something where my decades of experience will add a lot of value.

And historically all the best managers I ever had were the same -- former engineers who could understand everything we were talking about, but did not get involved in coding or code reviews.

Your manager should never be a blocker to getting things done.

Re: Should managers still code?

#74

Post by jedberg »

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.

This comes from the perspective of someone who manages managers. So if you're looking to hire managers, and don't care about retention, perhaps this is good advice to follow.

But if you're looking to evaluate your manager, or hire managers who can retain great people, maybe not the best advice.

Re: Should managers still code?

#75

Post by bionhoward »

Isn’t one of the best gifts a manager can give to their team, the gift of clarity?

A manager able to give their team programmatic tests to pass brings a level of precision which makes it much easier for them to know when the work is done.

If managers communicate requirements in the form of acceptance tests more often, then the problem of projects running over time and over budget will occur significantly less often, because there will be clear finish lines for dev teams to run towards and cross, and reproducible pass/fail outcomes to inspire confidence.

Re: Should managers still code?

#76

Post by calufa »

bionhoward wrote: post #75

Isn’t one of the best gifts a manager can give to their team, the gift of clarity? A manager able to give their team programmatic tests to pass brings a level of precision which makes it much easier for them to know when the work is done. If managers communicate requirements in the form of acceptance tests more often, then the problem of projects running over time and over budget will occur significantly less often,…

clarity, purpose and a path for career growth

Re: Should managers still code?

#77

Post by LeafItAlone »

bryanlarsen wrote: post #36
LeafItAlone wrote: post #6

Earlier quoted context omitted.

As an engineering manager, I actually pick up the stuff other people don’t like to do or stuff I notice that is hanging out there. My goal is to move the team forward. I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.

> I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun. I've had managers do this to me. What an awful experience. Because they're the manager you can't push back against the awful design decisions they made. They feel it's almost done so don't understand that it takes a lot of time to deal with all the side eff…

That’s very valid feedback.

I hope I don’t come across that was and do have some evidence (not to be laid out here) supporting that I don’t.

I think I’ve created a team and structure where the developers I manage are comfortable telling me I’m wrong or what I didn’t consider. It happens weekly. We value honest feedback highly. We do it with respect, but we do it.

We just have some developers on the team that are resistant to ideas that don’t follow a pattern until they see it. And sometimes my communication around the initial idea is poor and the best way I can communicate is an implementation.

Re: Should managers still code?

#78

Post by oliwarner »

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…

Friction can be more of a problem too though. If your manager is objectively better than the team, estimates can get cut short and failing to meet those adds tension.

Obviously a good manager might pitch in, understand their teams capabilities but it's not always a natural transition for senior devs moving to management.

Re: Should managers still code?

#79

Post by massung »

My view - as a manager - is that as I get older (simply put) I’m not as good any more as my younger team! While I help them, I also learn a lot from them as well. And I love that.

I have experience: project management, real life, edge cases, dealing with C-levels and customers, risk mitigation, being calm when sh*t hits the fan, mentoring, etc. These are things the team benefits from far more than my fingers typing away.

At the same time, if I’m actually doing my job well, I really don’t have time to code.

I also want my team (senior and junior) to have a feeling of ownership. The company has goals and directives, but what’s being built belongs the team, not me. All the successes are theirs, and the failures are mine alone.

When do my fingers hit the keyboard? When there’s a time crunch (if I’m not willing to work more how can I ask the team to?), when the team is having a difficult time with a particular problem, or maybe when there’s some downtime and I can fix a few outstanding bugs or work on something extremely isolated (I never want to get halfway through something and then have to hand it off to the team).

Re: Should managers still code?

#80

Post by scarface_74 »

bryanlarsen wrote: post #36
LeafItAlone wrote: post #6

Earlier quoted context omitted.

As an engineering manager, I actually pick up the stuff other people don’t like to do or stuff I notice that is hanging out there. My goal is to move the team forward. I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.

> I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun. I've had managers do this to me. What an awful experience. Because they're the manager you can't push back against the awful design decisions they made. They feel it's almost done so don't understand that it takes a lot of time to deal with all the side eff…

A POC should just be a happy path to prove a concept. I had a CTO who would routinely throw together code just to prove out an integration or another concept with hard coded values everywhere and drop the code in Dropbox for me to lead the effort of making it production ready as the architect. He would go back and forth with the vendor until things worked.

This helped me out by leaps and bounds. I was usually swamped with other research. I would then make it ready for production or lead the team to and take care of the edge cases, integration with our config system, logging and alerting, etc.

There is a huge difference between a POC and an MVP. An MVP should be properly designed and scaffolding that you can build on, a POC doesn’t take those things into account.

Post reply on HN