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

311–319 of 319 posts

Re: Should managers still code?

#311

Post by protocolture »

onion2k wrote: post #270
protocolture wrote: post #160

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

I cant work for someone who doesn't understand what I do. Why would you put a limit on your own progress like that?

What do you mean? Figuring this out has been the best thing for my career. Jettisoning jobs where I spend all my time managing upwards is career building.

Re: Should managers still code?

#312

Post by protocolture »

asdf6969 wrote: post #233
protocolture wrote: post #178

Earlier quoted context omitted.

>If your boss has a reasonably-sized team but is spending their day writing code They dont need to spend all day writing code, they need to spend their nights and weekends making sure their skills dont rust.

Do you read books about management in your evenings?

No but I do take time in my afternoons to learn new skills.

Re: Should managers still code?

#313

Post by nkmnz »

ironmagma wrote: post #260
nkmnz wrote: post #259

Earlier quoted context omitted.

This really calls into question your understanding of the difference between the words "what" and "how". I know and understand what a marketing intern does, but I don't know how to specifically record a TikTok that will appeal to Gen Z with an IQ below 115. And I don't care, because I can measure the performance and fire or hire the intern.

Can you measure the performance and accurately separate it from things like how well Tiktok as a platform is doing, the general economy, and public sentiment about your company? Of course not, unless you were also an expert on making Tiktok content for the same audience and could definitively say what should and shouldn’t work.

It's like a pianist thinking that his doctor can't operate on his hand because he can't read music.

Re: Should managers still code?

#314

Post by alkonaut »

roenxi wrote: post #101
alkonaut wrote: post #32

Earlier quoted context omitted.

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.

> But if the architecture is wrong, it's better to fix before than after. Although this is true; if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing. PR review is a great time to pick up subtle bugs, do last-line sanit…

> if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing.

That's the ideal yes. The problem with poor design/architecture is that it's never actually architected and designed. It just happens as part of a process where someone codes something without actually considering this to be a "design" (something that will affect future code, and solidify over time).

So the job of whoever it is (senior developer, manager, colleague, ...) is to point out the poor design. The hope then is that it can be fixed before it is merged AND that next time there will be no "accidental design".

Re: Should managers still code?

#315

Post by notepad0x90 »

MetaWhirledPeas wrote: post #131
notepad0x90 wrote: post #118

Big no! from me. Anyone in a people leadership role has to have a political mindset. You simply cannot be technically oriented and politically oriented at the same time. This is not a negative, the human brain, generally speaking, can't focus on two unrelated priorities at the same time. I have had a highly negative experience over this. When resolving technical conflicts, you expect technical merit and reasoning to…

> If you disagree with your manager, your performance review will suffer, you will be called disagreeable, hard to work with,etc I think your experiences sound like a case of a very bad coworker, whether manager or not. I don't want a manager who knows nothing about the applications and the architecture. I have no desire to punch a clock and be coddled with public mentions and work parties. I want to work with people…

Now that I think about it, I may indeed be biased by personal experience.

Re: Should managers still code?

#316

Post by protocolture »

zdragnar wrote: post #239
protocolture wrote: post #160

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

If your boss can do your job, one of you is redundant. Managers of engineers should be the interface to the business and other units within the organization. That's a big enough job without requiring coding skills on top of it.

I used to work for this guy. He was a network engineer by trade, and I understand a very good one.

However, his story goes, one day he was asked to design a telephony solution for a tech support call centre.

He fell in love with the call centre. He very quickly gained a deep understanding of what they were trying to achieve with the telephony solution and pulled a bunch of critical data out into a dashboard for them after learning how they operated.

He asked for a job and they gave him one. He was an effective manager because he had a deep understanding of the role of the 200 staff he managed, and was able to effectively spot issues with staff based on their metrics.

He could have done my job, but understanding it gave him the exceptional ability to add value to 200 staff at once. Neither of us was redundant.

Re: Should managers still code?

#317

Post by AdieuToLogic »

protocolture wrote: post #310
AdieuToLogic wrote: post #208

Earlier quoted context omitted.

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

How do you know what roadblocks are valid to remove if you dont understand what they do. How do you performance manage employees if you dont understand what they do.

> How do you know what roadblocks are valid to remove if you dont understand what they do.

Roadblocks are almost exclusively a "people problem" - politics, identifying stakeholder needs, inter-team coordination, etc.

> How do you performance manage employees if you dont understand what they do.

By working to identify value added to the organization via quantifiable metrics and working with team members to define professional growth tasks relevant to both the person and the organization.

None of the above requires a manager to know how to do what the people hired can do.

Re: Should managers still code?

#318

Post by protocolture »

AdieuToLogic wrote: post #317
protocolture wrote: post #310

Earlier quoted context omitted.

How do you know what roadblocks are valid to remove if you dont understand what they do. How do you performance manage employees if you dont understand what they do.

> How do you know what roadblocks are valid to remove if you dont understand what they do. Roadblocks are almost exclusively a "people problem" - politics, identifying stakeholder needs, inter-team coordination, etc. > How do you performance manage employees if you dont understand what they do. By working to identify value added to the organization via quantifiable metrics and working with team members to define prof…

"Hey we need money for tools for reasons" Is a pretty common roadblock.

Re: Should managers still code?

#319

Post by roenxi »

alkonaut wrote: post #314
roenxi wrote: post #101

Earlier quoted context omitted.

> But if the architecture is wrong, it's better to fix before than after. Although this is true; if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing. PR review is a great time to pick up subtle bugs, do last-line sanit…

> if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing. That's the ideal yes. The problem with poor design/architecture is that it's never actually architected and designed. It just happens as part of a process where so…

This is one of the situations where the ideal is in pretty easy reach. 5 minute conversation when handing out tickets. "Hey [insert employee number here] - how are you thinking about doing this ticket?". Or check in with them during standup.

That one question and a few minutes will both save hours of time and get better quality work. Letting the dev put time into work that gets redesigned in the PR is questionable management. Not the end of the world if it happens every so often but it suggests a lack of context in the job. If there is time to redesign during the PR there was time to think through what was acceptable quality before the work started.

Post reply on HN