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

#31

Post by indigochill » Fri, Jul 26, 2019, 5:34 PM UTC

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…

Maybe it's not so bad for the employer in the long term if it leads them to realize "Hey, we need to do better about assessing the value of our employees."

I'm curious what the data point is that leads you to think your company's paying a good salary if the hard-working, motivated, skilled people can easily find work that pays quadruple, because that sounds like the market is saying otherwise (unless the missing variable is location, like moving from Nebraska to Silicon Valley or something).

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

#32

Post by jolmg » Fri, Jul 26, 2019, 5:37 PM UTC

closeparen wrote: post #27

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 requires an extremely thorough understanding of the project, so much that you can not only find each responsibility in the code, but anticipate their emergent properties, what mistakes might have been made, and how their interactions might go wrong. Debugging a system successfully is the culmination of successful on-boarding, not a starting point. Doing the actual code changes to fix a bug which has already…

> Debugging requires an extremely thorough understanding of the project

That's precisely why it's great for a starting point. It's work that mostly consists of research of the current code, to look for inconsistencies that cause a well-defined misbehavior. It involves writing little code and therefore involves little decision-making if any, so you avoid the newcomer making changes or adding stuff that, in ways, may be inconsistent with how things are done in the project.

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

#33

Post by z3t4 » Fri, Jul 26, 2019, 5:42 PM UTC

lnsru wrote: post #7

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…

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.

I was very fortunately that my skill level followed the complexity of problems, only several years into my career I had to deal with systems level complexity and scaling issues, working as a high level web developer. Some things are just magic for a beginner. As a manager you should make people feel confortable, and some people do not have the mindset for constant self improvement. And some people you need to protect or they would over-work themselves. The trick is to have a load/capacity balance. Take games for example you usually progress the difficulty, you do not start with the end boss, or most players would quit, and those that pass would find the rest of the game boring.

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

#34

Post by jolmg » Fri, Jul 26, 2019, 5:46 PM UTC

shados wrote: post #28

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…

Code reviews have 2 purpose. Help the person whom's code is being reviewed improve quality/catch issues, BUT ALSO the reviewer gets familiar with the code being pushed and learn stuff. It's super important for new engineers to review code as soon as possible for the later.

> BUT ALSO the reviewer gets familiar with the code being pushed and learn stuff.

The reviewer is supposed to determine what goes in or not, so how can this be an opportunity to learn from what goes in? They're the one who's supposed to determine that! Is your idea of a reviewer someone who just spectates all code going through? It's like saying people who don't know a subject should grade work from students taking a class in that subject, as it's a great opportunity to learn from what gets turned in.

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

#35

Post by Paul-ish » Fri, Jul 26, 2019, 5:48 PM UTC

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…

> 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. How could they even reasonably measure the market value of his skills changing so much so quickly?

If he was doing the same job I could see why he would get the same pay. If he had taken on greater responsibilities or become more productive though, why not?

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

#36

Post by yalogin » Fri, Jul 26, 2019, 5:50 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…

Yes. Agree completely. Giving new hires bugs is the best way to bring them up to speed. They get to delve into the whole software stack, interact with people, understand data flows, familiarize themselves with code names if any, and generally get an appreciation and understanding of the product. This is my go to move for new hires.

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

#37

Post by januzis » Fri, Jul 26, 2019, 5:55 PM UTC

JamesBarney wrote: post #26

januzis wrote: post #15

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

This is especially tough because one important development skill is the ability to solve complex problems with simple solutions. This can sometimes make them look less productive because they've made a hard problem look easy. One technique I've found that helps a little is having everyone individually estimate tasks before hand. Over time you can notice who is completing tasks faster or slower than the average. Of co…

Measuring against estimates incentivizes over-estimating, especially if the team is small, and team members know roughly who will do what during the estimation process. Big complicated tasks also tend to be under-estimated, so they would be avoided, because they would usually influence the perceived productivity negatively.

I would like to find a feasible approach to productivity evaluation using the output only (PRs, reviews, basically all the data points the article mentions), because I feel that’s the only way of creating an environment, where team members can proactively take a bit more time when it benefits the end result, without fearing any negative repercussions.

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

#38

Post by jolmg » Fri, Jul 26, 2019, 5:57 PM UTC

ashishuthama wrote: post #17

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.

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.

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

#39

Post by januzis » Fri, Jul 26, 2019, 5:59 PM UTC

jrumbut wrote: post #30

januzis wrote: post #15

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

People say that no metric works but I think almost any metric works, for example PR count. You, a human being, would never actually confuse the engineers with 0 PRs because they spent the last month playing online poker with the engineers with 0 PRs because you entrusted them with developing an automated deployment system for a legacy application and starting a mentorship program. Many metrics will spot the outliers.…

Yes, the extreme cases are easy to spot, but the nominal cases are not that minuscule, more like one developer being twice more productive than the other, which, I feel, should be recognized and rewarded accordingly.

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

#40

Post by fatnoah » Fri, Jul 26, 2019, 5:59 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…

>Please don't listen to this. Give junior engineers bugs right away.

Right?!? That's how I get every junior developer into the code. Hell, that's how I get myself into the code at a new job.