Live data from Hacker News

Mistakes I made as an engineer, but had to become a manager to see

developing.dev

51–60 of 109 posts

Re: Mistakes I made as an engineer, but had to become a manager to see

#51
I like this post but is it really only about "people skills"? Of course a manager would have more of an interpersonal focus because that's their job; ICs need to focus on their job as well (while being personable enough obviously). I'm all for interpersonal skills but think this post falls short a quite a bit for helping out engineers/ICs.

Edit: inter- not intra-

Re: Mistakes I made as an engineer, but had to become a manager to see

#52
I agree with the social stuff but it doesn’t have to be drinking alcohol and forced fun. Just grabbing coffee every day, organise some board games, low key stuff is good too. I can see why the party oriented social events can put off shy / religious / parents etc. But you can get to know people without that and make connections.

Re: Mistakes I made as an engineer, but had to become a manager to see

#53
post #41
post #21

Earlier quoted context omitted.

> Focusing on code is probably a good thing when you are a junior. I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.

You need focus on other parts though, you can have the most beautiful codebase with the most efficient algorithms, the highest coverage and the most extensible yet simple and elegant architecture but if you're not solving the business problems someone's going to eat your lunch with a hacked together excel sheet. The other view I have on this is around trust. Do I need to "focus" on the code if I have people on the te…

> businesses have different goals and its focus should be on achieving those

For most businesses, still being around and profitable is an implicit, if not stated goal.

Re: Mistakes I made as an engineer, but had to become a manager to see

#54
tl;dr Play the game. Watercooler politics mean more than your code when it comes down to who gets promoted.

Why all the stuff about hiring? As an engineer, hiring isn't even your job. You may end up participating in the interview process and offering feedback, but ultimately you're not making the hiring decisions unless you're a manager anyway, so ignoring hiring isn't really a mistake you make as an engineer.

Re: Mistakes I made as an engineer, but had to become a manager to see

#56
post #21

A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relationships with your co-workers are things that I have realized are important over the last couple of years (Haven't done any hiring yet). In saying that, I'm not sure it would have been wise to focus on these things earlier than I did. There were too many other th…

> Focusing on code is probably a good thing when you are a junior. I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.

> Code should always be focused on; it should be constantly rewritten,

Your PO: I've noticed you've been rewriting a lot of methods in the code base. Can you please tell me which stories on the board this sprint those rewrites are attached to? We need to focus on sprint work, and as we established as a team last PI Planning meeting, the emphasis this quarter is on shipping features from the Customer Experience epic. Please refrain from needless refactoring not accounted for in your sprint work.

Re: Mistakes I made as an engineer, but had to become a manager to see

#57

I think of all of these problems as being the managers problem and not the engineers problems. Maybe a better title is "10X Manager tasks, I wasn't aware of as an engineer". To help engineers maximize their career I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. Midlevel/Level 2 engineers should becoming independent and solving lot's of their problems on th…

> I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. This feels like it could backfire, by encouraging people to ask less questions. It's easy to provide more value than you take if you never take.

I don't think the implication is that the junior engineer should be carefully calculating their coworker's hourly rates and estimating the dollar value of what your slack DM to them will cost the company. Just that you do a good enough job that your work brings in more money than your salary costs.

Re: Mistakes I made as an engineer, but had to become a manager to see

#59
post #43

Earlier quoted context omitted.

The take is your salary, in my experience. I'm not sure what you mean about questions.

It seems obvious - if you scare a junior engineer they will sit in their office and build an abomination to avoid asking a simple question that could be answered in 3 minutes. It's a real thing and it doesn't help the junior engineer or the business.

Which would not be contributing value to the company. I think his point was that a junior should learn that just working blindly like that is not always the right thing either.

Re: Mistakes I made as an engineer, but had to become a manager to see

#60
post #56
post #21

Earlier quoted context omitted.

> Focusing on code is probably a good thing when you are a junior. I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.

> Code should always be focused on; it should be constantly rewritten, Your PO: I've noticed you've been rewriting a lot of methods in the code base. Can you please tell me which stories on the board this sprint those rewrites are attached to? We need to focus on sprint work, and as we established as a team last PI Planning meeting, the emphasis this quarter is on shipping features from the Customer Experience epic.…

Then again, if I had been given a cent every time I had to tell a member of my team "please, do the job we pay you for before doing the thing you find fun but have no actual business value" I would be a rich man by now.
Post reply on HN