Live data from Hacker News

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

jmoses.co

41–50 of 113 posts

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

#41
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?

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

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

#42
post #12

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

Why do you say that?

Hiring people is very expensive. Finding and qualifying leads, creating job description, interviewing, on boarding, orientation, training, introduction to and getting familiar with the existing code base. Firing requires distributing that team member's work to other team members.

This can take months and a big investment from existing team members, to go from wanting to hire someone to a fully productive team member. And that's assuming your hiring process never accidentally hires someone even more incompetent than your "poor" team members.

Compare that to investing in improving existing team members to help them improve. Is that really more expensive than hiring and firing?

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

#43

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

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

One of these must be false. According to "the market", this employee is now worth 4x previous salary, so then how can your company be paying "in line with the market?"

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

#44

> Be a better management with transparent performance reviews and quick feedback with on focus areas. This article contains dozens of grammatical errors (starting right off with the title). Whenever I read something like this, I'm so distracted by the errors that I can't even focus on what the author is trying to say. The English language is dying.

It's not just English. :(

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

#45

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

> A surprise pay raise, catering lunches, taking them to an offsite

I don't think any of those things will increase team productivity at all.

Mentoring and training and encouraging learning new things and constantly giving new challenges and expanding responsibility and tying company financial success directly to employee paychecks, are the kind of investments that can improve a team's performance.

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

#46

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

[deleted]

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

#47
post #12

Earlier quoted context omitted.

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

Why do you say that? Hiring people is very expensive. Finding and qualifying leads, creating job description, interviewing, on boarding, orientation, training, introduction to and getting familiar with the existing code base. Firing requires distributing that team member's work to other team members. This can take months and a big investment from existing team members, to go from wanting to hire someone to a fully pr…

Attrition is a thing. You have to always be hiring, or very ready to hire, anyway.

Also accidentally hiring the wrong people can be devastating. It's better to identify and get rid of bad hires right away.

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

#48
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 measure software engineering performance by their dev ops skills?

Absolutely! That is the "dev" in dev ops.

I think there are few things that increases the productivity of a dev team more than improved processes.

> Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure.

Because if you don't know those things you are much less helpful to your product team.

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

#49
post #7

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

This!!! Nobody gained any skill from writing vanilla code or “hello world” type programs. Experience comes from spending days and sometimes weeks on ugly bugs. Bugs are perfect to level-up juniors quickly and find ones with weak motivation. Because having no progress for hours is really really frustrating. Went recently through this cycle teaching colleague. Found out, there is no motivation at all.

Some people thrive when bugs are assigned to them early, some people thrive when whole new functionalities are assigned to them. Usually intersection of sets of these two kinds of people is close to empty and the worst mistake is to assume bugs first are good or new stuff first is good automatically.

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

#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 strategies under simulation is to focus on developing the people you already have since fixing your quality through hiring is very difficult and expensive.

Post reply on HN