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.

Right - so no time like the present to get started understanding!

> 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?"

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

Let the market do it. When someone comes with an offer, give a counteroffer and convince them to stay.

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.

Why not? Markets are better at pricing things than bureaucracies.

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 lens of a limited manager.

I'll say this: if you can do this 2-3 times, you should find your way to an org that can support and appreciate the lift you're able to provide. You shouldn't be holding yourself down to the poor standard of your current employer.

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?

I don't think any of those things will increase team productivity at all.

Mentoring and training and encouraging learning new things and constantly giving new challenges and expanding responsibility and tying company financial success directly to employee paychecks, are the kind of investments that can improve a team's performance.

Is it really that people aren't motivated or that they aren't motivated by the incentives you're offering?

> A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result

I imagine what might be more effective is actually talking to them and figuring out what they actually care about.

Having personally burned myself down in such an environment, a good interview question to ask is if everyone has gone through the same hiring process and if not ask what the previous process was and why things have changed.

Hiring people is very expensive. Finding and qualifying leads, creating job description, interviewing, on boarding, orientation, training, introduction to and getting familiar with the existing code base. Firing requires distributing that team member's work to other team members.

This can take months and a big investment from existing team members, to go from wanting to hire someone to a fully productive team member. And that's assuming your hiring process never accidentally hires someone even more incompetent than your "poor" team members.

Compare that to investing in improving existing team members to help them improve. Is that really more expensive than hiring and firing?

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?

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.

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.

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.

I mean, you're screwed anyways if those people can't do their jobs. No sales means no revenue means engineers taking a pay cut or getting laid off.

So the sales and marketing and product management responsible for your project, need to be on the same product team as the engineers, and have their compensation tied to the product's success.

If the engineers see themselves as the natural enemies of sales and marketing, the product is probably already doomed.

Could add in factors for customer retention and customer satisfaction, for example.

Everyone on the team should share responsibility for figuring out what will make the customer's happy with the product and how to deliver on those things.

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.