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

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

jmoses.co

Post reply on HN
Print view View original

21–30 of 113 posts

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

#21

Post by eropple »

Dayshine wrote: post #2

"Process improvements" is a bit weird. You measure software engineering performance by their dev ops skills? It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system. Similarly, the explanation for "Debugging and troubleshooting complicated issues" is a bit odd. Why is knowing where the log files are,…

> It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge

In my experience, this skillet being measured is the critical indicator for high-quality development talent at a healthy shop. You might need one deep-magic wizard for a particular area. You need breadth everywhere. You need to kill "that's not my job" stone dead when you see it.

Writing code is easy. And it's usually an additive process, even when the code is subtractive. All the other stuff, the being-a-person-in-a-community stuff (because that's really what it is), is multiplicative. So I pretty unashamedly hire for curiosity and for breadth. When it's necessary, I contract out hard expertise until curious people can develop it internally.

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

#22

Post by vinceguidry »

perlgeek wrote: post #8

> Code reviews are probably the first thing a new engineer can start doing in a new role. That really depends on what you want the code review to achieve. Catch typos? Yes, a new engineer can do that. Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don't think a new engineer can contribute that from the start. > Creating metrics t…

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

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

#24

Post by Consultant32452 »

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 over 10 years. No one had ever "invested" in him. He had a great attitude and work ethic, but terrible skills. I taught him how to program. He left the company and doubled his salary. That was a year and a half ago. This week he called me to thank me because he was changing jobs again and doubling his salary again.

So my current employer went from a low skill high dedication worker to no worker because I invested in him. I'm going to continue help/mentoring people because I find it fulfilling, but if I'm honest it's bad for my employer. They currently pay good salaries in line with the market. There's no way they can justify giving a person who's been with the company for 10 years 4x salary growth in 2 years. How could they even reasonably measure the market value of his skills changing so much so quickly?

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

#25

Post by JamesBarney »

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.

Not having a team because you can't staff it, and having terrible moral because of frequent firings also impact team performance.

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

#26

Post by JamesBarney »

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…

This is especially tough because one important development skill is the ability to solve complex problems with simple solutions. This can sometimes make them look less productive because they've made a hard problem look easy.

One technique I've found that helps a little is having everyone individually estimate tasks before hand. Over time you can notice who is completing tasks faster or slower than the average. Of course this is just one data point that needs to be weighed against a variety of others.

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

#27

Post by closeparen »

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 been analyzed and localized to one or a few sites in the codebase is a bit more reasonable.

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

#28

Post by shados »

perlgeek wrote: post #8

> Code reviews are probably the first thing a new engineer can start doing in a new role. That really depends on what you want the code review to achieve. Catch typos? Yes, a new engineer can do that. Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don't think a new engineer can contribute that from the start. > Creating metrics t…

Code reviews have 2 purpose. Help the person whom's code is being reviewed improve quality/catch issues, BUT ALSO the reviewer gets familiar with the code being pushed and learn stuff. It's super important for new engineers to review code as soon as possible for the later.

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

#29

Post by jvagner »

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…

But this isn't usually the norm.

If this dev's trajectory is true, it's also something worth discussing with your management. There might be candidates for this kind of trajectory in your current dev pool, and any feelings contrariwise are to the detriment of your company.

Too often there's an emotional component to how employees are viewed. The employee today will be the same employee forever, if seen through the lens of a limited manager.

I'll say this: if you can do this 2-3 times, you should find your way to an org that can support and appreciate the lift you're able to provide. You shouldn't be holding yourself down to the poor standard of your current employer.

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

#30

Post by jrumbut »

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…

People say that no metric works but I think almost any metric works, for example PR count.

You, a human being, would never actually confuse the engineers with 0 PRs because they spent the last month playing online poker with the engineers with 0 PRs because you entrusted them with developing an automated deployment system for a legacy application and starting a mentorship program.

Many metrics will spot the outliers. But what is the business value of knowing when an engineer rated 82.13 vs 84.51?

Post reply on HN