Should managers still code? • Hacker News Board

Re: Should managers still code?

#151

Post by nine_zeros » Tue, Mar 04, 2025, 11:59 PM UTC

tibbar wrote: 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…

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

Re: Should managers still code?

#152

Post by summerlight » Wed, Mar 05, 2025, 12:04 AM UTC

I think reliable managers probably don't have enough time to write codes (unless they work 70~80 hours week), but at least they should be able to review other's code.

Re: Should managers still code?

#153

Post by sesm » Wed, Mar 05, 2025, 12:09 AM UTC

They should be able to automate their work with code: analytics reports, bots, etc. Committing code to product codebase - probably no.

Re: Should managers still code?

#154

Post by andoando » Wed, Mar 05, 2025, 12:13 AM UTC

jaggederest wrote: post #147

andoando wrote: post #143

Earlier quoted context omitted.

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.

I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on?

Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects

Re: Should managers still code?

#155

Post by jamesfinlayson » Wed, Mar 05, 2025, 12:14 AM UTC

etamponi wrote: post #140

bastardoperator wrote: post #123

Earlier quoted context omitted.

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.

This so much - I had a manager early in my career who had written code many years ago, but in his management role he touched no code at all - I think he probably spent a bit of time watching Youtube at his desk. But if someone tried to dump work on the team, messed up a shared environment, tried to bother one of the team with an out of band request he absolutely pounced on them and tore them to shreds. He well and truly understood his job was to make sure we could do ours.

Re: Should managers still code?

#156

Post by dustingetz » Wed, Mar 05, 2025, 12:14 AM UTC

too much context switch (and no good answers here)

Re: Should managers still code?

#157

Post by tibbar » Wed, Mar 05, 2025, 12:16 AM UTC

nine_zeros wrote: post #151

tibbar wrote: 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…

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

I'm not quite sure where you're getting "performance = maximizing units of output" from my post, as the whole point was the difference between squeezing out a little more code vs. keeping the team on track doing actually valuable stuff. Either way, I think we mostly agree here: the EM is the face of the team who makes sure the team, as a unit, is doing valuable work as a sustainable pace that's understood as such internally.

However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance, which is a complex and subjective metric, and the manager is generally the one held responsible for it at the team level.

Re: Should managers still code?

#158

Post by dataflow » Wed, Mar 05, 2025, 12:18 AM UTC

nine_zeros wrote: post #151

tibbar wrote: 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…

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

> The real EM job is [...] being the leader [...] of the team

That's quite a confusing description. Then what does the team lead do? Manage the team?

Re: Should managers still code?

#159

Post by tony-allan » Wed, Mar 05, 2025, 12:23 AM UTC

As an aside, I like the implied job description in the article:

    - Hiring and retaining great people.

    - Owning the team's strategy and roadmap, and ensuring efficient execution.

    - Making decisions to ensure that the team is working on the right things and saying no to the things that don't matter.

    - Dealing with fires, escalations, and other crises that pop up all of the time.

    - Building a strong culture within the team so that people are engaged, challenged, and motivated.

    - Mentoring and coaching your reports so they get better and can have more work delegated to them, thus increasing output further.

    - Managing the team's stakeholders so they can offer their steer to the team early and often.

    - Actively performance managing the team so that superstars can continue to shine and underperformers can be coached or exited.

    - Building close working relationships with other teams so that smooth collaboration happens across the organization, leading to a better and more cohesive product.

Re: Should managers still code?

#160

Post by protocolture » Wed, Mar 05, 2025, 12:27 AM UTC

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

An unused sword rusts in its sheathe.

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.

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.

TBH one of my current clients produces hardware and software, medium to large enterprise with close to 200 staff. Their CEO can operate all their products, operate the machines that place chips on the circuit boards, operate the injection moulding machines, write SQL queries to pull data out of their CRM and write code. He tries his best not to do it, but he maintains the skills. That's the goal I reckon. Someone who understands the job all the way to the top.