A software engineering manager guide to measuring an engineer’s performance
1–10 of 113 posts
Re: A software engineering manager guide to measuring an engineer’s performance
#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, and knowing how to do complicated test setups for your specific environment a performance measure. Again, that's not really measuring skill but familiarity.
The other two measures are just "Do they complete tasks" and "Do they follow code review guidelines", neither of which are very good measures beyond pass/fail.
The conclusion is: > Once a set of skill areas for a role is landed and agreed upon you will want to make sure your team knows in advance what they are being measured on
So, to do well in your business, I need to pick easy tasks, snipe code reviews, make pointless CI tasks and spend all my time learning the build/test processes not actually developing the product? :)
Re: A software engineering manager guide to measuring an engineer’s performance
#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, this is a GREAT litmus test for the standards of your documentation, and ease of environment setup.
Re: A software engineering manager guide to measuring an engineer’s performance
#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.
Re: A software engineering manager guide to measuring an engineer’s performance
#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 quality? I.e. do they go out of their way to document how they tested it? Reproduction steps? Do they invest time in making code reviews as easy to review for other people as possible? Or does their code reviews always take multiple rounds of review due to sloppiness?
Re: A software engineering manager guide to measuring an engineer’s performance
#6Are we really going to pretend that managers in sillycoin valley even bother to be objective like this?
Re: A software engineering manager guide to measuring an engineer’s performance
#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.
Re: A software engineering manager guide to measuring an engineer’s performance
#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 through issue trackers and time sheets
Which metrics? It's far too easy to create metrics that are easy to measure, rather than metrics which actually increase the business when optimized for (and developers will optimize for / game a metric when it's used to assess their performance).
Re: A software engineering manager guide to measuring an engineer’s performance
#9> 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…
"Most improvements come from investing in your team"
Very well said. Completely agree. Which is why I think the ability to "learn" as you go is so valuable. You don't want to hire a Know-it-all. You want to hire a Can-learn-it-all.
Re: A software engineering manager guide to measuring an engineer’s performance
#10> 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…
Exactly. Fixing bugs is one of the best ways to learn a new codebase. Assuming you have a process for code reviews and some form of testing in place, it's not like there's much risk of a bad change getting out.
I'd actually lean the other way: No one should be adding new features to an existing codebase without having successfully done some fixes first.