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

#111

Post by Smithalicious » Sun, Jul 28, 2019, 8:44 AM UTC

sam0x17 wrote: post #95

jrumbut wrote: post #30

Earlier quoted context omitted.

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

Yeah but what about the highly skilled employee who spends 90% of their time playing online poker and spends 10% of their time producing output on-par with other people in the org that work 100% of the time. There is almost always one of these in any given org.

Well are they getting paid 10 times as much as the others?

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

#112

Post by closeparen » Sun, Jul 28, 2019, 11:47 AM UTC

commandlinefan wrote: post #61

closeparen wrote: post #27

Earlier quoted context omitted.

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…

> an extremely thorough understanding of the project Right - so no time like the present to get started understanding!

You can get started by doing smaller and better-defined projects first, rather than going for ~weeks before knowing whether you have any traction.

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

#113

Post by ses1984 » Sun, Jul 28, 2019, 12:57 PM UTC

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.

I don't think it's trivial to identify a bad hire in 3 months. Some are obviously bad, some are not.