Hacker News Reader

Comment by tenpoundhammer | Hacker News Reader

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.

View on HN

Yeah, I sort of had the same impression. Imagine as a junior engineer having the following conversation with your manager: "Guess what? Yesterday I managed to triple my productivity going forward!" "Great! How did you do that?" "I hired two more engineers as good as me!" "You did what?" "Of course I had to pay them more than my own salary. Finding engineers as good as me who also work as cheaply as I do is basically impossible, I have no idea how you did it. I guess that's why you make the big bucks!"

Not sure if you've read Chris Hadfield's book (Astronaut's Guide to Life On Earth) but he talks about a similar system. In his words you can be one of three team members:

A Negative One -- You're a drain on the team and other people have to cover for you. Not so good if you're in space with limited resources.

A Zero -- You're capable and have your own shit covered. Most people in space are a zero.

A Plus One -- You're contributing to the success of the mission and helping others succeed as well.

He talks about arriving on the international space station and just making sure that he was a zero. And taking over as mission commander and on the first couple days, just trying to be a zero because the plus one fancy heroics can come later.

I really like the way you categorized different SWE levels. Thank you for the insights!

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

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.

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.

Agreed there is a balance. I wrote a little about when and how to ask questions as a junior engineer - https://twitter.com/ryanlpeterman/status/1628803643171557376

>An employee spinning their wheels getting nowhere for a month

I get aggravated when juniors ask me questions right off the bat without researching. It's because they are lazy and want a quick answer and of course submitting to this just leads to more questions more often, which leads to me getting less work done.

This is also bad for them because they don't learn how to figure it out for themselves through google / code research / debugging / etc. Learning how to learn is the essence of growing in the field. I've been dumped into codebases I didn't know before with little to no help, and it sucks; but you certainly learn how to learn.

I think spinning your wheels for a month is the opposite of that. If it takes someone a month to not figure something out, that would be a red flag for me.

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.

I should have added more detail but I was attempting to be brief. I meant that a junior engineer should focus on learning how to do the basics of their job so that they can provide features that help our group meet business objectives. A large part of getting there will be needing mentorship and asking lots of questions. The context is that often juniors need so much hand holding that the cost of their mentors time is more expensive than the value of the feature being produced. I wasn’t even considering their salary.

Reply on news.ycombinator.com