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

#11

Post by tracer4201 » Fri, Jul 26, 2019, 4:22 PM UTC

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…

> “But most improvements come from investing in your team.”

I agree on this but you have to cut your losses at some point. Some people just aren’t motivated. A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result, and that could be sufficient if your goal is just X and it’s in the line of sight, but sometimes raising the bar on your team means finding a different spot for the unmotivated folks, and if they’re not investing even in that, then cut your losses and let them go.

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

#12

Post by kevan » Fri, Jul 26, 2019, 4:24 PM UTC

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.

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

#13

Post by JamesBarney » Fri, Jul 26, 2019, 4:27 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…

Definitely this. Bugs are great for new devs. Nothing teaches why code quality matters and what types of code quality matter like investigating bugs and why they happen.

Also jr. devs require lots of sr. dev time to verify their work. But bug fixes are usually easier to verify then features because the ratio of code written to investigation is much smaller.

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

#14

Post by AstralStorm » Fri, Jul 26, 2019, 4:27 PM UTC

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,…

You'd find a cushy job in a few corporates by doing just that.

Someone else then gets to do hard tasks and gets bad reviews because they're slower at this and the numbers do not tick up.

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

#15

Post by januzis » Fri, Jul 26, 2019, 4:34 PM UTC

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 judge the ability of individual team members, but I'm having a hard time objectively judging productivity. Simple count of PRs doesn't really tell the whole story, and some tasks look simple in hindsight, when in reality it took a lot of effort to find a good solution. There are also a lot of other complications I'm not going to dive into, but the end result is that it's hard to have an objective productivity evaluation based on the engineer's output only.

I'd be interested to know how other people evaluate individual productivity?

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

#16

Post by sanderjd » Fri, Jul 26, 2019, 4:36 PM UTC

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,…

Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing feature code; it benefits all features written in the future.

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

#17

Post by ashishuthama » Fri, Jul 26, 2019, 4:41 PM UTC

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…

A new engineer can learn a lot from being on code reviews earlyon. Anything from the team coding style to the application architecture.

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

#18

Post by Dayshine » Fri, Jul 26, 2019, 4:45 PM UTC

sanderjd wrote: post #16

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,…

Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing…

No, of course other things are important.

But if you measure only ancillary things, that's a pretty bad measure.

I don't expect every one of my team members to understand the entire build system, testing setup, logging system. That's a waste of their time. They should know some, and perhaps one of the areas in depth.

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

#19

Post by uwuhn » Fri, Jul 26, 2019, 4:58 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.

Hiring better people doesn't mean much if you can't get them to stick around for more than a year.

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

#20

Post by mieseratte » Fri, Jul 26, 2019, 5:02 PM UTC

tracer4201 wrote: post #11

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…

> “But most improvements come from investing in your team.” I agree on this but you have to cut your losses at some point. Some people just aren’t motivated. A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result, and that could be sufficient if your goal is just X and it’s in the line of sight, but sometimes raising the bar…

Absolutely agree. Some people are just beyond saving. Sometimes this a matter of skill, and sometimes a matter of will but the result is the same. If you're hiring pipe-hitters and grafting them onto a JV squad the results will often not be what you'd hoped for, unless you have a particularly high-tolerance for projects being over (time-)budget.

Having personally burned myself down in such an environment, a good interview question to ask is if everyone has gone through the same hiring process and if not ask what the previous process was and why things have changed.