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

#101

Post by sanderjd » Sat, Jul 27, 2019, 3:58 AM UTC

Dayshine wrote: post #18

sanderjd wrote: post #16

Earlier quoted context omitted.

Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing…

No, of course other things are important. But if you measure only ancillary things, that's a pretty bad measure. I don't expect every one of my team members to understand the entire build system, testing setup, logging system. That's a waste of their time. They should know some, and perhaps one of the areas in depth.

My point is: Those things aren't ancillary. They aren't a waste of time. Good developers can figure out how to use logs to debug issues. They can figure out how to fix the build and deployment system when it's broken. They can figure out how to set up testing environments. If not them, then who? Managers look for people who are self sufficient. All of this stuff is a necessary and important part of the job.

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

#102

Post by blub » Sat, Jul 27, 2019, 6:34 AM UTC

Consultant32452 wrote: post #94

jimbokun wrote: post #43

Earlier quoted context omitted.

> They currently pay good salaries in line with the market. > 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. One of these must be false. According to "the market", this employee is now worth 4x previous salary, so then how can your company be paying "in line with the market?"

Ok, so it's more like the business is in the market for a $80k/yr developer, and not a $300k+ developer. The words changed but the result is the same. The work they're doing, it honestly doesn't make sense to pay anyone that much.

This is what many are missing: for some jobs the company can only get so much value, no matter how great the developer.

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

#103

Post by januzis » Sat, Jul 27, 2019, 9:45 AM UTC

jimbokun wrote: post #87

januzis wrote: post #73

Earlier quoted context omitted.

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.

Because that is counter productive to increasing productivity. Having team members focused on getting themselves ranked higher than their teammates, means incentivizing them to not help each other or do something they might not get credit for, even if it's in the best interest of the product or the team.

Even if you've tied team compensation to the results of the company, you still have to decide how it will be shared among the team members. So how do you go about compensation, bonuses, etc.? The same for everybody?

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

#104

Post by januzis » Sat, Jul 27, 2019, 9:55 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.

I would actually be OK with it, as long as I can objectively say that even though someone is slacking most of the time, he/she is very productive in short bursts, so the overall productivity is on par with the team average.

The problem is that if you don't have an objective approach to evaluating productivity, all sorts of biases come in, e.g. if I see someone coming to the office at 11am and leaving at 4pm, I would subjectively rate their productivity lower, even though objectively the results might be the same as for someone who comes in early, and leaves late.

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

#105

Post by wolco » Sat, Jul 27, 2019, 11:54 AM UTC

goatinaboat wrote: post #79

wolco wrote: post #77

Earlier quoted context omitted.

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.

This Spolsky quote is so outdated. The average great developer will apply for 4 jobs unless he is trying to work remotely which will require 100 aplications / 50 tests / 75 take home assignmennts / 14 interviews per position and one job offer for below market rate for the third world.

"The average great software developer will apply for, total, maybe, four jobs in their entire career."

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

#106

Post by stevens32 » Sat, Jul 27, 2019, 1:49 PM UTC

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.

Reviewers not willing to learn anything during a code review is probably an easy tell for a crappy code review culture

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

#107

Post by jolmg » Sat, Jul 27, 2019, 3:37 PM UTC

stevens32 wrote: post #106

jolmg wrote: post #38

Earlier quoted context omitted.

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.

Reviewers not willing to learn anything during a code review is probably an easy tell for a crappy code review culture

This discussion is about newcomers that know basically nothing of the project. When I say they're not there to learn, I mean their primary function as reviewers isn't to learn from what gets submitted. They can learn depending on what gets submitted, but if 90% of the time their ignorance doesn't permit them to properly determine if what's submitted to them is good or not, then what's the point of their review?

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

#108

Post by techslave » Sat, Jul 27, 2019, 6:25 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…

I think this comment misses the point by being myopic.

The great majority of devs are not very good. (Same for managers.) Here at HN you are only seeing the pretty good to great devs. Not boot camp grads and unranked school grads.

The other thing is that this comes from the management school of management. One where managers mentor ICs and managers drive skill growth. As opposed to the SV ideal (rarely met) where mgmt gets out of the way. They remove blockers, not give opportunities. They communicate information, not hoard it.

So, from the management school of management style, managing lackluster devs (the 90% that you reject at phone screen), it’s true. These devs get in over their head when the first thing they have to do is actually understand the spaghetti codebase. This is not a road to success for these devs.

With that POV and that reality in mind, the advice is sound.

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

#109

Post by techslave » Sat, Jul 27, 2019, 6:31 PM UTC

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.

i took it to be ESL author and gave some slack in that regard.

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

#110

Post by tkxxx7 » Sun, Jul 28, 2019, 5:53 AM UTC

jolmg wrote: post #34

shados wrote: post #28

Earlier quoted context omitted.

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…

> The reviewer is supposed to determine what goes in or not, so how can this be an opportunity to learn from what goes in?

You specify multiple reviewers. That's it.