Should managers still code?

> I cant work for someone who doesn't understand what I do.

But you already do. Unless you're working for a tiny startup, your CEO or the Board probably doesn't understand the specifics of your code.

You can't run a large company by making every person super-involved in every detail. You have layers of abstraction that make it possible to reason about an org of hundreds or thousands of employees. The Board trusts the CTO to oversee technology. Your CTO trusts your director / VP / whatever to run a large chunk of it. That person delegates a smaller part of running the company to your boss.

The whole point of each layer is to abstract away some of the underlying messiness. They exercise professional judgment for day-to-day operations and provide a clean interface that provides health signals, requests resources as needed, etc. And I think what many folks miss is that it doesn't stop with their boss. It stops with you! Your boss generally trusts you to make design and implementation decisions and is expecting you to provide a reasonable interface to that. If your boss has a reasonably-sized team but is spending their day writing code, then honestly, why are they in a management position to begin with?

> I cant work for someone who doesn't understand what I do.

A better word might to 'appreciate' what you do. I'm mostly a manager/leader/vision person now and occasionally still code. Even though I've written a lot of code over the years, there's no way I could just drop in on a complicated project and understand all the intricacies without some ramp up right now. And that's ok. I appreciate the challenges everyone (engineering, customer support, operations, etc...) I manage faces and trust the people who do that work.

There is only so much time in the day, and if I'm tinkering with Node versions I'm not doing the work I need to get done.

> I cant work for someone who doesn't understand what I do.

Someone can understand what you do without being able to do it.

I guess I don't get what's objectionable about working for someone who doesn't understand how you do what you do. Isn't what matters being appreciated? I certainly can't work for someone who doesn't value what I do, but I can care less whether they actually understand how I do it.

I don’t know man. Can Bezos code? Can he operate a forklift? Would he still even recognize Powerpoint if you opened it for him? At certain points things need to be let go of if you want to keep growing. Some managers might keep technical skills sharp, but I’m not sure they’re much better managers for it.

> I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building"

> He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to.

Frankly, all this anecdote tells me is "don't behave like a condescending asshole". If he'd said the same thing but then managed to do some non-trivial aspect of your job for a few minutes, I think that would still have been a bad tactic. It's just as possible to have humility about skills you lack, and to lack humility about skills you've maintained.

> I cant work for someone who doesn't understand what I do.

Managers are responsible for maximizing what people they work with can achieve. This does not require them to be able to do what their team can do.

> I dont think a manager of software engineers needs to code the application he manages, but he should be continually coding something to remain sharp.

A counter to this is; a manager of software engineers needs to remove roadblocks impeding the success of the team.

Good managers enable their coworkers, micromanagers weigh in on or perform commits.

>>An unused sword rusts in its sheathe.

>>I dont think a manager of software engineers needs to code the application he manages, but he should be continually coding something to remain sharp.

I'd even go to the extreme of saying the coding skills/brains fade by inverse cube law. Skill =~ 1/t^3 (t = time since last practiced the skill). Musicians are known to say something along similar lines, like as little as a day of missed practice and they can feel it.

I used to be quite good at calculus as a teenager, and today I could look at the easiest problems there are and go blank. Only a faint echo of those days remains.

I have long suspected that Doctors suffer similar decline in ability as years go by from Medical school, and you can be sure in as little 2 - 5 years, most managers would struggle to imagine what writing code could look like.

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

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.

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

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

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 infra. You, as a manager and as an IC, have zero AI experience (you've never trained a model, never used a trained model, never using any of the various AI frameworks). Are you still okay to manage this team or should you be replaced with someone who does have that experience?

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

For me a good manager is a facilitator, not a leader. Someone who removes obstacles for us. Whether they themselves are affected or not. Someone only fixing an issue because they have to deal with it too seems like a pretty bad manager to me.

They're not for pushing targets or trying to weed out non-performance, I don't work at a playschool. My manager is there to make sure I can do my job and that I can reach my maximum potential (including making sure I'm in the right job)

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.

I think every team needs a TL. If the EM isn't filling that role, then another team member should be, and most of what you're talking about falls on the TL (with some sanity checking from the EM by talking to other team members about these things as well)

> your bottleneck really is just writing more code

You're characterising it as pure "code volume" question but it's completely not the point. Absolutely if they are coding just to directly increase the output of the team they are much better devoting that time to getting more output from the IC's they are managing.

But even better is coding in a way that helps the team overall work better. This can be because they do architectural work, they gain insight into the actual team challenges, it improves how they can estimate the time needed for different tasks, etc.

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.

> An engineering manager's job is: take long-term ownership for the performance of the team

This is a rather naive, mid-level management-style take.

The real EM job is to represent the team to the company, to be aligned with company priorities, and to be a backstop for the team. In other words, being the leader - the face, the prioritize, and the helper of the team.

Performance-style nonsense is what is used in warehouses and factories where the manager is responsible for number of units produced.

But in software, the goal is NOT to produce more but to produce correct/investigate correct/and maintain correct.

As such, EM is very different from warehouse-style management.

I've definitely seen this - managers reviewing or submitting code that was woefully unfinished. It forces the team to decide how much to push back against the person who decides if they get a raise in a way that's decidedly unfair. It also taints your perception among the team.

It's that old quote - better to keep silent and be thought possibly a fool than to speak and remove all doubt. If your job isn't primarily coding, and you parachute in to "help out" and end up making more work than you save, that burns a lot of goodwill that you can't really get back. You're not some junior dev that's going to get better with mentorship.

To "lose face" with a team shows a lack of trust. I think it's fine if you don't have a perfect solution, but require some eyes on your work. But you're right, if you don't have people your level (or better yet, more experienced) reviewing your work, getting an honest code review is challenging.

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?

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.

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.

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.

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.

A few comments also mention experience being out-of-date. I expect that's true in webdev, but an embedded C developer could take a 10 year break and still be using the same compiler version.

It varies a lot with context. Manager isn't even a well-defined term.

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 attention, and planned timelines and expectations accordingly.

This is exactly how it should be in my opinion. This matches my experience with who I saw as being good managers.

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.

“Your manager should be able to consistently make small contributions” is also a good litmus test for your developer env/tool/experience. If it takes more than 20 minutes to get set up and start working your team probably has a problem.

100%

> unfair competition for work

That's a very good indicator of a bloated institution. People have to compete for work instead of pushing it away or avoiding it because they already have their hands full.

But I don't believe there is a general rule that applies here.

Most great managers I had were deeply technical and involved in the nitty gritty of the projects, including coding the very spiky aspects of a project.

Most mediocre managers I had were very focused on relationship building. The kind of manager that would need a hobby project to keep current, instead of being the most knowledgeable person in the room.

IMO if an EM is taking the fun stuff, or the high-profile promo packet stuff, that's a symptom of a lot of very bad things. My boss is an upper-level EM and has at least a few PRs in a couple projects every sprint, and it's almost entirely boring-but-blocking stuff, or stuff that nobody wants to figure out, or stuff that is important but not sexy and not likely to get anyone noticed. He's not writing new features or writing UIs that are getting put in pitch decks or anything.

If I were an IC and my boss was picking the sexy work I would leave. If I was a director and one of my EMs was picking the sexy work I would fire them.

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.

While that is possible, I think a good manager recognizes these pitfalls. My philosophy is "everyone has to scrub toilets once in awhile - that includes me". You'd have to ask my direct reports but, I'd like to say I lean more toward taking the "grunt tasks" that I don't think are super helpful for my folks' career growth.

Then again, I've been called a bad manager on Hacker News so...

[dead]

It really only works in orgs that are large enough to accept a bit of bloat, mature enough to have good managerial practices and invest in growing managers, and where the new manager has only a couple reports (2 is the perfect number). So you take a very good, senior IC who wants to be a manager, you cut their IC duties by 25-50% and you give them 2, maybe 3 direct reports. This is after doing some sort of formal managerial training, internal or external, and with the acknowledgement from their director/senior manager that they're going to be spending more time with them for the next 2-6 months and having skip 1:1s to make sure everything is going ok.

How many organizations do you think check all those boxes and are willing to do that? It's not many.

Anything that can be done in a follow-up shouldn't have to block a PR. But if the architecture is wrong, it's better to fix before than after. You are speeding your teams throughput by pointing out the problem earlier rather than later.

But I don't think a manager necessarily needs to be at this level of detail.

If you as a manager have the time to do an in-depth code review like that... you're doing micromanagement and you're showing that you don't trust your subordinates. And clearly, you don't have anything more important to do.

Modulo the video, I did exactly this when I ran a team, only for what I thought were "important" or "gnarly" PRs. It works. I rarely had to spend more than an hour on a PR, because small, atomic PRs were all but mandatory on my team, with "atomic" taking precedence over "small". I would also review some of the PRs post-facto, after they are committed, as I was almost never a "formal"/blocking reviewer on them.

Recording a video seems excessive to me. No one has the time or desire to watch me bloviate about something that I could say in a few PR comments that can be quickly skimmed.

It should be unsurprising that we don't really have a science of what company policies work best. There are a lot of variables at play and they likely interact with each other in non-linear ways. Outcomes are hard to measure and may look different at different time horizons. For example, if policy A results in more productivity but makes retaining effective employees more difficult you may need several months or even a few years of observations to truly understand the effects. Companies are quite private about their information and they want control over their own company policy. Experiments are costly to perform. How would you perform one? Randomly select a bunch of companies and try to randomly get them to adopt different sorts of policies?

I think this is why you see a lot of herd behavior amongst companies. Some business leader who feels they just have an intuitive sense of what's best just tries something. Are they right? Who knows? But if the company does OK it is evidence the policy isn't a total disaster so more companies follow suit.

I upvoted your comment earlier and came back just now hoping I’d find it at the top with replies linking the research that must exist. But no; you’ve just been buried under a mountain of anecdata. Ohh well.

What profession does? You realize there are vested interests, competing interests and a varying degree of people optimizing for their individual careers, right?