Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

developing.dev

Post reply on HN
Print view View original

41–50 of 109 posts

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

#41

Post by IanCal »

beebmam wrote: post #21
ZephyrBlu wrote: post #14

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.

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 team whose job that is? At what level? At a more senior position I shouldn't be looking into the small parts, the more effective use of time is ensuring the larger components are going in the right direction and/or we're not spending time on parts expected to be unused due to a strategic shift coming in. Maybe it's more important to focus on documentation right now, or perhaps it's important to get people working on different things because everyone's fixed on their small problem and not understanding the integration issues we have.

Code is important, but it's important for a reason. Create your artistically beautiful perfect codebase when that's the goal perhaps as a personal project, but businesses have different goals and its focus should be on achieving those.

"Focus" or attention I guess, is a limited resource. Spending it on one thing is not spending it on another. Balance is needed - 0% interest in the code is a big issue, but so is 100%.

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

#43

Post by qup »

jcparkyn wrote: post #40
tenpoundhammer wrote: post #18

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.

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

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

#44

Post by IanCal »

jcparkyn wrote: post #40
tenpoundhammer wrote: post #18

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.

An employee spinning their wheels getting nowhere for a month because they didn't ask a question that someone more experienced could answer in 5 minutes is not a good tradeoff.

Unless you work for free, you are taking.

It's important to explain this kind of thing though, and guide people to when it is and isn't appropriate to ask for help.

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

#45

Post by ZephyrBlu »

ryanlpeterman wrote: post #17
ZephyrBlu wrote: post #14

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. Leave the higher level problems for a little later down the line. Agreed that junior engineers should focus on code with most time (but not all). If you focus on the low hanging fruit outside of code you can have more impact overall without too much time investment there.

Taking a peek at your Twitter and Linkedin, I'm honestly not sure how useful this advice is for most people and whether it's based on reality, or what you wish happened.

For example, you say you got promoted from junior on "sheer volume of work" which is contradictory to focusing on "low hanging fruit outside of code" without "too much time investment".

https://twitter.com/ryanlpeterman/status/1623745298920255489

If a junior knew how to leverage "low hanging fruit outside of code" without "too much time investment" they would basically by definition not be a junior anymore, so I see this as a bit tautological. It seems like wishful thinking rather than something based on reality.

---

I also noticed on your Linkedin that you made Staff in 5yrs, which is extremely fast and likely means you are an exceptional engineer. I'm aiming for a similar trajectory, but I noticed a little while ago (Before I was even working as an eng professionally) that giving advice to people was very difficult. How do you explain that you just "get" things?

For example, my manager told me that he liked the fact that he only had to give me feedback once and then I would implement it. He also noted that weaknesses from my previous performance review became strengths in the next one. This is with only ~3 months between reviews as well.

There are a number of similar behaviour my managers have noted that I believe have been and will continue to be critical for my growth, but how do you teach those kind of things to someone who doesn't operate like that? I don't think you can.

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

#46

Post by idiotsecant »

qup wrote: post #43
jcparkyn wrote: post #40

Earlier quoted context omitted.

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

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.

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

#48

Post by ryanlpeterman »

ZephyrBlu wrote: post #45
ryanlpeterman wrote: post #17

Earlier quoted context omitted.

> Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line. Agreed that junior engineers should focus on code with most time (but not all). If you focus on the low hanging fruit outside of code you can have more impact overall without too much time investment there.

Taking a peek at your Twitter and Linkedin, I'm honestly not sure how useful this advice is for most people and whether it's based on reality, or what you wish happened. For example, you say you got promoted from junior on "sheer volume of work" which is contradictory to focusing on "low hanging fruit outside of code" without "too much time investment". https://twitter.com/ryanlpeterman/status/1623745298920255489 If…

My promotion from junior to mid-level definitely came from sheer volume of work. I think I could have dialed that back a bit and been more tactical with better results.

As a mentor, you need to understand that you cannot get everyone to have steller results. Your goal is to provide a lift with your advice so that they are in a better place than they would have been without you.

This became clear to me when I provided the same coaching to two engineers. One grew at a breakneck pace while the other grew more slowly.

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

#49

Post by Frost1x »

izacus wrote: post #20

So basically the mistakes were mostly not solving management problems as an engineer? Uhhh... ok.

Yea, I don't get it. Perhaps if while you're an engineer you think management shouldn't be doing these sorts of things you had some mistaken perspective.

Moving to management is not some inherently transcendental ascendancy into higher enlightenment and purpose, it's a change in responsibilities and goals. It's not for everyone, there are plenty capable of being managers and fully understand the roles but don't want to become them. This article reads like some journey to enlightenment that I think all but a junior engineer would read as pretty naive.

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

#50

Post by zwkrt »

vanjajaja1 wrote: post #33
quicklime wrote: post #9

> Hiring well is one of the best uses of your time When I was an engineer I used to think this, but now that I'm a manager, I'm not so sure... If you want to maximize your impact, and make the biggest contribution possible to your company, then yeah, sure, it's absolutely the best use of your time. But a lot of engineers are trying to contribute to the company in ways that are mutually beneficial to them, and the way…

Investing in 'hiring well' is worth it for the skill, sticking around in 'hiring' is probably not unless you're using it to swing some cool free international trips. There's a lot of value in knowing exactly how you'll be judged at your next job interview.

I think of the hiring loops that I am a part of as paid interview practice.
Post reply on HN