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

91–100 of 113 posts

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

#91

Post by BeetleB »

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

This is not a given, and in fact, I would not recommend it.

For small code reviews with only one reviewer, the reviewer gives feedback and they have a conversation about it, but with only one reviewer the developer should have the final say. The problem with giving the final say to a single reviewer is you'll get plenty of pointless code changes to suit the reviewer's individual preferences. Don't waste time on what is a perfectly reasonable difference in opinion.

If you have more than one reviewer, but still a small code review, the final say should be with the reviewer(s) - if their is consensus (you could also go with voting, with its pros and cons). Having multiple reviewers prevents the likelihood of individual preferences dominating.

If it's a significant code review, the final say should be with an experienced moderator.

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

#93

Post by bitL »

0xEFF wrote: post #57
bitL wrote: post #49

Earlier quoted context omitted.

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.

I am in the group that prefers new functionality; I can build state-of-art $10M business from the scratch in 3 months but if you ask me to debug old stuff for longer periods of time, I'll most likely leave or underperform. It's good to know what people you have on your team instead of assuming certain traits.

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

#94

Post by Consultant32452 »

jimbokun wrote: post #43
Consultant32452 wrote: post #24

Earlier quoted context omitted.

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…

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

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

#95

Post by sam0x17 »

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

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.

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

#96

Post by Consultant32452 »

jvagner wrote: post #29
Consultant32452 wrote: post #24

Earlier quoted context omitted.

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…

But this isn't usually the norm. If this dev's trajectory is true, it's also something worth discussing with your management. There might be candidates for this kind of trajectory in your current dev pool, and any feelings contrariwise are to the detriment of your company. Too often there's an emotional component to how employees are viewed. The employee today will be the same employee forever, if seen through the le…

Honest question: are there places where you can be a mid-level developer making $80k/yr and over the course of two years get raises and promotions lifting you up to $300k+? I've never heard of such a thing happening. In my experience, industry-wide, the only way to make that kind of raise is to leave.

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

#97

Post by brianpgordon »

commandlinefan wrote: post #60
kevan wrote: post #12

Earlier quoted context omitted.

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?

I've been on many interview debriefs where the discussion came down to a question of our team's appetite for taking on a more relatively junior hire vs holding out for a more solid candidate. Some "weaker" hires can be OK, but in order to be fair to them (and the team) you have to make sure you have the resources to develop them by giving them the opportunity to work with more experienced people and get one-on-one mentoring. So yes, the extent that you want to "hire better people" is very much an intentional judgment, and you can calibrate your hiring process accordingly based on your current team composition and the work on your plate.

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

#98

Post by jammygit »

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…

When I was an intern I spent most of the year fixing bugs, between other assignments. It was the most beneficial educational experience I could have had. I got really good at it by the end too.

There isn’t a better way to learn a codebase and new tech than one issue chosen by you at a time

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

#99

Post by hysan »

Consultant32452 wrote: post #96
jvagner wrote: post #29

Earlier quoted context omitted.

But this isn't usually the norm. If this dev's trajectory is true, it's also something worth discussing with your management. There might be candidates for this kind of trajectory in your current dev pool, and any feelings contrariwise are to the detriment of your company. Too often there's an emotional component to how employees are viewed. The employee today will be the same employee forever, if seen through the le…

Honest question: are there places where you can be a mid-level developer making $80k/yr and over the course of two years get raises and promotions lifting you up to $300k+? I've never heard of such a thing happening. In my experience, industry-wide, the only way to make that kind of raise is to leave.

In my brother’s company, they don’t pay anyone that much (yet), but what they’ve done to keep most of their juniors is to bump their compensation quite a bit when it’s clear that they have high potential and are realizing it. So raises end up being on the order of $10k+ a year in some cases. Combined with increased benefits (time off, etc) the longer you stay with the company, and they’ve found a formula that keeps their employees from jumping.

If you think about it from the perspective of the employee, you are working for an employer who is giving you sizable raises, continual career growth, long term benefits, and a team you enjoy working with. You can perhaps maximize your pay by going through the whole interview cycle and ending up with $10-20k bump, but is that worth it? There is no certainty that the next employer gives such large raises or invests in employees.

As for your case - $80k to $300k jump - that is exceptional. It is not going to be the norm. Not if continual investment happens. Based on your example (10 yrs experience), if they kept investing in that employee, they would have surpassed $100k long ago. If they hit the salary ceiling after 4-5 years, then conversations would shift. Maybe more days working from home, etc.

In my opinion, if you see such jumps happening regularly, then it is 100% on the employer for creating an environment that breeds large wage-skill gaps.

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

#100

Post by JamesBarney »

januzis wrote: post #37
JamesBarney wrote: post #26

Earlier quoted context omitted.

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…

I don't think developers spend that much time gaming metrics unless they are objectively measured against them.

And you would notice if someone's estimates are always higher for the work they are assigned compared to others.

Post reply on HN