A software engineering manager guide to measuring an engineer’s performance • Hacker News Board

Re: A software engineering manager guide to measuring an engineer’s performance

#61

Post by commandlinefan » Fri, Jul 26, 2019, 6:51 PM UTC

closeparen wrote: post #27

weliketocode wrote: post #3

> It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career. what? Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project. Even if he/she needs to be guided to the solution…

Debugging requires an extremely thorough understanding of the project, so much that you can not only find each responsibility in the code, but anticipate their emergent properties, what mistakes might have been made, and how their interactions might go wrong. Debugging a system successfully is the culmination of successful on-boarding, not a starting point. Doing the actual code changes to fix a bug which has already…

> an extremely thorough understanding of the project

Right - so no time like the present to get started understanding!

Re: A software engineering manager guide to measuring an engineer’s performance

#62

Post by yowlingcat » Fri, Jul 26, 2019, 6:51 PM UTC

kevan wrote: post #12

guitarbill wrote: post #5

> The Lake Wobegon Strategy famously coined by Google and Peter Norvig claims that you should always hire above your team average. Doing so increases the quality of your team. Ugh, not this again. Obviously don't hire people who aren't good at their job. But most improvements come from investing in your team. > are they putting their code up for review [...] Missed one: Are their code reviews/pull requests high quali…

You could reasonably argue that the highest impact investments a manager can make in a team are hiring better people and firing worse ones.

Careful. How did the team get there in the first place? Why would better people want to join if the manager can't coach an existing team? You can argue that it doesn't matter and you just need to clean house. But that runs the risk of cover up the root cause and not addressing it.

Re: A software engineering manager guide to measuring an engineer’s performance

#63

Post by yowlingcat » Fri, Jul 26, 2019, 6:53 PM UTC

Consultant32452 wrote: post #24

guitarbill wrote: post #5

> The Lake Wobegon Strategy famously coined by Google and Peter Norvig claims that you should always hire above your team average. Doing so increases the quality of your team. Ugh, not this again. Obviously don't hire people who aren't good at their job. But most improvements come from investing in your team. > are they putting their code up for review [...] Missed one: Are their code reviews/pull requests high quali…

Investing in workers is hard. I'm in a mentoring/leadership position. I approach this in two ways. One is the general mentoring everyone gets during regular stuff like code reviews. The other way is sometimes I see someone who I think has real promise and kind of take them under my wing, give them lots of 1on1 attention, etc. They improve exponentially and then leave. One guy I mentored had been with the company for…

It's not bad for your employer. It's the truth. Your employer is bad for your employer if they let someone remain at the company for 10 years, paying salary without investing in said employee nor treating them like an investment.

Re: A software engineering manager guide to measuring an engineer’s performance

#64

Post by nilkn » Fri, Jul 26, 2019, 6:55 PM UTC

weliketocode wrote: post #3

> It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career. what? Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project. Even if he/she needs to be guided to the solution…

I couldn't imagine having a new developer go several months without looking at a single bug. Sure, I'm not going to give them something that I know is going to be really difficult and frustrating, but I generally try to get people in the swing of development within the first week.

Re: A software engineering manager guide to measuring an engineer’s performance

#65

Post by yowlingcat » Fri, Jul 26, 2019, 6:56 PM UTC

januzis wrote: post #15

It seems to me there are two sides to engineer's performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he/she execute, and the productivity measures the actual amount of work done. Able programmer is not necessarily productive, and productive programmer might not be able to do tasks of high complexity. As a technical lead, I feel that I'm able to judg…

You talk to them and the people they work with or whose work depends on them. How quickly, autonomously and completely do problems get solved?

Metrics are a distraction unless in the service of answering that question.

Re: A software engineering manager guide to measuring an engineer’s performance

#66

Post by yowlingcat » Fri, Jul 26, 2019, 6:58 PM UTC

slaymaker1907 wrote: post #50

Lake Woebegon is a horrifically bad strategy under even the most basic of assumptions. There are not enough engineers in the world available for hiring to create a single large tech company under such a strategy even with zero turnaround. A fixed level of achievement can give you similar quality (assuming you do have some level of attrition) but at a much faster rate. The best strategy after looking at various strate…

It's a substitute for a strategy: in reality, it is a wishful thought masquerading as a strategy. It doesn't give you any strategic framework for achieving that by hiring, mentoring and retaining in a competitive landscape. I find it of limited use and anachronistic.

Re: A software engineering manager guide to measuring an engineer’s performance

#67

Post by e40 » Fri, Jul 26, 2019, 7:03 PM UTC

weliketocode wrote: post #3

> It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career. what? Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project. Even if he/she needs to be guided to the solution…

Agreed. We do this and it has worked out amazingly well.

Re: A software engineering manager guide to measuring an engineer’s performance

#68

Post by rleigh » Fri, Jul 26, 2019, 7:03 PM UTC

jolmg wrote: post #41

vinceguidry wrote: post #22

Earlier quoted context omitted.

Maybe have a senior review the code afterward so the new guy can see what's being expected?

So the new guy is just watching the reviewer? That sounds neither productive, nor an efficient way to get familiar with the project.

That's not what they said.

You learn by doing, and also by example. So they can do the review themselves, but also see what other people pick up on. It sets expectations, and also shows how other people think.

I always find it interesting when I do the same review as one of my co-workers. We might pick up on the same things, but often they are completely different. It shows the value of having multiple perspectives on a team. Not just for review, but for design, implementation, validation, debugging, and the rest. It widens people's perspectives, serves as a means for ongoing improvement and learning, and makes the team better as a whole. We all have different backgrounds and expertise, and having people share and pass on some of their knowledge and skills is highly valuable.

Re: A software engineering manager guide to measuring an engineer’s performance

#69

Post by NicoJuicy » Fri, Jul 26, 2019, 7:43 PM UTC

weliketocode wrote: post #3

> It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career. what? Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project. Even if he/she needs to be guided to the solution…

Yeah, our software manager gives everyone new new projects, that of course are never completed.

Lol, some "managers"

Re: A software engineering manager guide to measuring an engineer’s performance

#70

Post by januzis » Fri, Jul 26, 2019, 7:49 PM UTC

yowlingcat wrote: post #65

januzis wrote: post #15

It seems to me there are two sides to engineer's performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he/she execute, and the productivity measures the actual amount of work done. Able programmer is not necessarily productive, and productive programmer might not be able to do tasks of high complexity. As a technical lead, I feel that I'm able to judg…

You talk to them and the people they work with or whose work depends on them. How quickly, autonomously and completely do problems get solved? Metrics are a distraction unless in the service of answering that question.

That’s the default, I guess, my main concern is that it’s very subjective.