Live data from Hacker News

Should managers still code?

theengineeringmanager.substack.com

141–150 of 319 posts

Re: Should managers still code?

#141

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

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

I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc.

But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.

Re: Should managers still code?

#142
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

I don’t see how you can understand something without being part of it.

It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing.

The same for working with the team - it is so much different than listening and trying to understand.

Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

Re: Should managers still code?

#143
post #142

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

I don’t see how you can understand something without being part of it. It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing. The same for working with the team - it is so much different than listening and trying to understand. Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code.

If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask.

As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC

Re: Should managers still code?

#144

Curious why large open source project (like linux) have no manager for all the political stuff but works well but every private company have a huge management chain for less complex stuff.

I'm pretty sure the majority of Linux contributions are made by corporations these days, which almost certainly have internal management structures.

Re: Should managers still code?

#145
post #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, m…

As an aside: If you're a line manager of a small coding pod, and your manager is very engaged in company planning and generally competent, then you can probably do a lot more coding. Someone has to do the organizational engineering work, and it's your manager, in this case. Now, if this individual ALSO wants to spend their time coding, then things can go very wrong indeed.

The worst possible scenario is that a manager doesn't know how to prioritize amongst their existing team, and/or doesn't want to say a difficult 'no' and tries to make up for it by coding in the evenings. That's someone who hasn't learned how to really fly the airplane yet.

Re: Should managers still code?

#146
I don’t think you can answer this for all managers of all teams all at once. Most of the time the answer is probably no but sometimes it’s not. Sometimes good managers want to code and they need to in order to stay happy. Sometimes your team is fast moving and small and your manager needs to code to keep up. Sometimes your manager is so busy managing they can’t. It just depends.

Re: Should managers still code?

#147
post #142

Earlier quoted context omitted.

I don’t see how you can understand something without being part of it. It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing. The same for working with the team - it is so much different than listening and trying to understand. Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code. If you're really listening and asking the right quest…

How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.

Re: Should managers still code?

#150
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 tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work. Like imagine you were a coding manager 10 years ago with AI experience. Sometime over the last 10 years your team does AI…

> I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work.

Many directors started in other roles in the movie industry, typically as writers, PAs, or other subspecialties. Chad Stahelski was a stuntman and stunt coordinator before he started directing John Wick, and it really shows.

I think the clear distinction is between someone who understands a part of the job, and someone who is good at part of the job. If you don't understand how costuming works, as a director, you're going to have a hard time getting good costumes, but by no means does that mean you're able to pinch hit in that role. I personally believe that it's difficult to replace hands on experience as a way to truly understand something.

In software engineering, I think there's a huge gap between managers who worked in some other industry and transferred over, versus having previously been an engineer, even a mediocre one. Knowing how the sausage is made is hard to replace.

Post reply on HN