[HN Gopher] Mistakes I Made as an Engineer, but Had to Become a ...
___________________________________________________________________
Mistakes I Made as an Engineer, but Had to Become a Manager to See
Author : ryanlpeterman
Score : 45 points
Date : 2023-03-10 21:31 UTC (1 hours ago)
(HTM) web link (www.developing.dev)
(TXT) w3m dump (www.developing.dev)
| angryGhost wrote:
| Technical skills are teachable to a coachable person, soft skills
| not so much
| HellDunkel wrote:
| Technical skills are not really teachable much unless its a
| full time job.
| 13of40 wrote:
| I'd go a step further and say that there will be times when you
| can sit across the table from a grown adult and explain to them
| the behind the scenes details of the performance review
| process, explain that you want them to do X Y and Z so you can
| build a case to get them promoted this year, just to have them
| tell you to fuck off because X isn't coding, Y is boring, and Z
| is below their skill level. "But please still promo me ASAP."
| munchbunny wrote:
| Soft skills are also teachable to a coachable person. I've seen
| it in action. However, far fewer people are receptive to
| coaching on soft skills because fewer people understand what
| "soft skills" are and why they matter.
|
| I've met plenty of engineers (anecdotally, not a majority, but
| enough that it's a clear pattern, and strongly correlated with
| how junior they are) who lump soft skills into a single
| category represented by broad labels like "charisma" or
| "schmoozing" or "eloquence". But it's really a very big
| category of practicable skills.
| Jensson wrote:
| "When I was an engineer I focused on work that improved my
| career, but then I became a manager and realized that my
| engineers actually should work to improve my career!"
|
| Funny how that works.
| stingraycharles wrote:
| Depends on what you're looking for in an engineer. I consider
| the author's learnings to be relatively obvious, of course and
| engineer that "gets to know their colleagues" is doing great.
|
| Fact of the matter is that there are a whole lot of people that
| aren't necessarily into that, but are great individual
| contributors, and should just be left to their devices as long
| as they're a positive contribution, not just to your codebase,
| but towards your organisation as a whole.
| Jensson wrote:
| Making the team stronger often doesn't make your career
| better though. This guy says he didn't and he got promoted to
| manager anyway, and now suddenly he wants the people under
| him to make his team stronger rather than focus on their
| career like he did. That smells like a corporate climber who
| just started to eye his next promotion rather than a new
| insight.
| ryanlpeterman wrote:
| I agree it's easy to see it that way as an IC (I thought the
| same!). I think the more senior you become the more you will
| view impact from the lens of your team/org, even as an IC
| Jensson wrote:
| There is a strong bias to focus on things that helps
| yourself, that is only natural. So IC's will focus too much
| on things that improve their career, managers will focus too
| much on things that improve their career, directors will
| focus too much on things that improve their career etc.
| izacus wrote:
| Although, the more senior you become the more you also
| understand about using the best tool for the job. And burning
| away engineers time to do management tasks is not that.
| givemeethekeys wrote:
| Couldn't agree more. For a long time, I'd be one of the last
| people to quit when a shitty manager was brought onboard. I'd
| give them their due time. Other senior engineers saw the writing
| on the wall and jumped ship. So far they've always been better
| off for leaving than me for sticking around.
| ZephyrBlu wrote:
| 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 things
| I needed to learn. 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.
|
| I've thought about hiring and am interested in doing it and
| getting good at it because I see that it's very high value, but I
| don't think it's the right time. There are more important skills
| and behaviours for me to develop right now.
|
| I try to focus on things 1 or 2 steps ahead of where I currently
| am, no more. Otherwise it's too far away from reality.
| ryanlpeterman wrote:
| > 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.
| ZephyrBlu wrote:
| I disagree you can do that without much time investment. The
| time investment is in learning, not executing.
|
| If you're a junior by definition you don't understand how to
| operate outside of code very well or at all, and you are
| still learning about operating in code.
|
| Trying to learn multiple skills at the same time is always
| tricky. Most people struggle to get good at one thing at a
| time, let alone multiple.
|
| Unless you are already becoming a more independent coder
| (I.e. 1-2 steps behind this point), stacking non-coding
| skills on top of that seems like a bad decision unless you
| are a very quick learner and can juggle multiple new skills.
| beebmam wrote:
| > 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.
| gardenhedge wrote:
| Tldr: people problems are problems, having a good team is
| important, socialising is important.
|
| This is such a non-article.
| tenpoundhammer wrote:
| 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 their own. As they approach
| the top of this level start getting involved in architecture and
| design.
|
| Senior/level 3 should focus on helping the team to be successful
| as a whole, mentoring, producing value quickly when needed, and
| should be able to solve most problems independently including
| starting a project from scratch or solving complicated
| performance/technical problems.
|
| Hiring and people problems are engineering manager problems.
|
| Getting to know your coworkers is a good career move for anyone.
| guhcampos wrote:
| The article contains way too few mistakes. I suspect there's a
| whole series coming.
| izacus wrote:
| So basically the mistakes were mostly not solving management
| problems as an engineer?
|
| Uhhh... ok.
| HellDunkel wrote:
| I dont get it.
|
| Why would you care or think much about hiring as an engineer? You
| probably would not even be asked to attend interviews. If you
| vibe with the company and share the vision okay but this is not a
| matter of perspective.
|
| Why would you NOT be interested in getting to know your
| coworkers? Why NOT have interesting conversation or a good laugh
| at lunch? This has nothing to do with beeing an engineer or
| manager either.
|
| Obsession with code maybe more important for an engineer. Does
| not mean it was ,,wrong".
| MisterBastahrd wrote:
| Why?
|
| Because you will eventually have to work with these people and
| their problems will become your problems, especially if you are
| seen by management as someone who can fix those issues. Young
| adults tend to group together and cling to co-workers because
| they haven't learned to cope with life independently of the
| situation they find themselves in. I generally like my co-
| workers, but I have no inclination to spend any independent
| time with them. It's not that I don't want to make friends at
| work, it's that I don't want a condition of my friendship to be
| tied to the workplace. If I'm not seeking that person
| independently now, then I'm probably not going to do it later
| after switching jobs.
| HellDunkel wrote:
| I did not state anything about ,,problems". Not sure what you
| refer to.
| gonzaloalvarez wrote:
| Because as you become more senior as an IC, your personal
| growth is directly related with your ability to influence
| others and deliver through others. What's best way to do it
| than to ensure you bring and groom the right talent.
| glonq wrote:
| ...will we see this followed up with "mistakes I made as a
| manager, but had to become an executive to see"? ;)
| ryanlpeterman wrote:
| Hahah also good clickbait. Maybe one day if I'm lucky
| quicklime wrote:
| > 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 that a lot
| of companies set up interviewing is not. It's a thankless job
| that takes time away from things that can actually be put a
| performance review, so only the more selfless engineers will do
| it.
|
| The article reads a bit like manager-to-engineer advice, but the
| advice to managers would be: keep track of who is helping out
| with interviewing, and who is interviewing _well_ , and reward
| them for it.
___________________________________________________________________
(page generated 2023-03-10 23:00 UTC)