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

71–80 of 113 posts

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

#71

Post by stcredzero »

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…

How could they even reasonably measure the market value of his skills changing so much so quickly?

Let the market do it. When someone comes with an offer, give a counteroffer and convince them to stay.

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.

Why not? Markets are better at pricing things than bureaucracies.

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

#72

Post by wolco »

bitL wrote: post #49
lnsru wrote: post #7

Earlier quoted context omitted.

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.

I like both as long as they as smaller items. Bugs will help you to understand what is there and new functionality can be a good bridge where a new person can leverage existing experience.

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

#73

Post by januzis »

jimbokun wrote: post #51

I think there's only one metric that is really effective for measuring and evaluating software teams. Tie their compensation to the product's financial success. This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any pro…

This doesn’t solve the issue of individual team member performance evaluation, even if it improved the overall performance of the team, you still wouldn’t know who are under and over-performers.

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

#74

Post by rifung »

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…

> Some people just aren’t motivated.

Is it really that people aren't motivated or that they aren't motivated by the incentives you're offering?

> A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result

I imagine what might be more effective is actually talking to them and figuring out what they actually care about.

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

#75

Post by yowlingcat »

januzis wrote: post #70
yowlingcat wrote: post #65

Earlier quoted context omitted.

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.

Sure -- some parts are, but some parts aren't. It's intrinsic to the nature of working in a team or coaching a team. If you notice weak spots consistently, is it a fluke? Probably not. If you notice complaints about the ability of the team, division and org to collaborately smoothly, is that a fluke? Again, probably not. By the time you fine-tune all the weak spots properly, you have a very high functioning team. But it takes a lot of iteration.

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

#76

Post by wolco »

commandlinefan wrote: post #60
kevan wrote: 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.

> hiring better people You say that like it's some sort of epiphany, but do you honestly believe that there's anybody who wasn't trying to hire better people in the first place? If the problem is the quality of the people you've been hiring, maybe your boss should consider replacing you with somebody who's better at finding better people to hire, eh?

I wonder if that happens. Some hiring processes are flawed so they filter out the better candidates at the HR levels and the engineers filter out the candidates who are left over. This can go on for a long time until the company is so understaffed they hire anyone and it works out..

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

#77

Post by wolco »

ses1984 wrote: post #47
jimbokun wrote: post #42

Earlier quoted context omitted.

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.

Why.. getting yourself out of accidentally hiring someone who has a standard 3 month trial period is easy.

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

#78

Post by wolco »

jolmg wrote: post #38
ashishuthama wrote: post #17

Earlier quoted context omitted.

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

A reviewer is not there to learn. If anything, they're there to teach. What good is a reviewer that can't grade others on their adherence to the coding style and application architecture of the project? They're supposed to determine what goes in or not.

They wouldn't be the only one reviewing or reviewing at all. It would help them understand the process if they see it in action.

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

#79

Post by goatinaboat »

wolco wrote: post #77
ses1984 wrote: post #47

Earlier quoted context omitted.

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.

Why.. getting yourself out of accidentally hiring someone who has a standard 3 month trial period is easy.

Exactly. Spolsky did enormous harm to us all with his assertion, blindly accepted, that a single bad hire will destroy your company overnight. All the toxicity in the current hiring process should be laid at his door.

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

#80

Post by lunias »

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, this makes no sense to me (sounds like something an "engineering manager" might recommend). If not defects, then what? Surely it's not the recommendation that someone who struggles to fix bugs should be given greenfield work...
Post reply on HN