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

51–60 of 113 posts

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

#51

Post by jimbokun »

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 product team, but those should be rare and require a strong justification.

This will have an amazing effect of clarifying prioritization of what to work on and figuring out how to deliver it as quickly and reliably as possible. Suddenly the whole team will be in the loop about what features are most important to the customers. Suddenly the things blocking new features demanded by the customers from shipping will be cleared away.

I think for any other metric you can devise, either intentionally or unintentionally, employee behavior will be optimized for satisfying the metric, and not customer satisfaction with the product.

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

#52

Post by Rooster61 »

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…

> Tie their compensation to the product's financial success.

This is an atrocious idea in anything much larger than a start-up. It leaves the engineering team beholden to bad decisions made in other facets of the company (sales, marketing, upper management). It's exceedingly frustrating to write a solid, stable, performant program only to have marketing or sales push it as something that it is not and nosedive the company due to customers calling bullshit.

Start-ups are somewhat immune to this because of the lower barrier of communication between departments, as many people will be wearing multiple hats due to there being more things to do than people to do them.

This is very visible when executives begin choking off benefits across the board. Nothing kills morale quite like losing your bonus because another department isn't doing its job properly. I've seen more than one mass exodus from a company as a result of this.

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

#53

Post by lmilcin »

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 stuff is still my favorite task when I join a new team. This is absolutely the best way to quickly learn about the project.

It is also important to select right kinds of bugs for newcomers.

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

#54

Post by [deleted] »

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.

[deleted]

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

#55

Post by [deleted] »

jolmg wrote: post #44
caymanjim wrote: post #4

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

[deleted]

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

#56

Post by dfeojm-zlib »

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…

Heck, you should try to give interviewees real bugs so they're solving real problems (not to exploit them but to see how they think and work) instead of theoretical chalkboard problems or standard brainteasters.

Certainly, guide them towards easy-ish bugs rather than complicated ones right away, because there is something to risk management of new people attacking gradually-increasingly critical code / difficult bugs. Of course you probably wouldn't give a random interviewee root access to a credit card processing system, but you should ratchet-up the level of trust incrementally as fast and as frequent as a staff member has proven themselves (treat people as adults, not kids).

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

#57

Post by 0xEFF »

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.

When you give someone new functionality to implement and they don’t have experience fixing defects, they’ll likely add more defects along with the new functionality.

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

#58

Post by dfeojm-zlib »

I think of software developers having multiple qualities:

- coolness (cooperation, proactiveness, professionalism)

- carefulness

- integrity (ethics)

- morale

- cadence (speed) of work

- skills competencies (matrix)

- grit (badassery)

- estimated time to completion multiplier

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

#59

Post by TimTheTinker »

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.

Our team always assigns a few cosmetic bugs to new developers during their first week - only because it helps them learn their way around our codebase.

Where they proceed from there depends on their strengths and interests.

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

#60

Post by commandlinefan »

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

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?

Post reply on HN