^ This post scratches the surface on a timely and relevant question many teams face, but the author seems to throw hands up and say everything is subjective.

Our work suggests otherwise: https://blog.gitprime.com/check-in-frequency-and-codebase-im...

Ofcourse there are people who do this much better/faster than me, but the nature of the job still means the actual code output is pretty low.

I can imagine many other functions where code output is super high (adding lots of text of any kind - blogs, templates, new library/config) or super low. I don't think code output correlates well to productivity.

'Programmers' is a coherent grouping in terms of "people who write code as a job", but it doesn't generalize well to "people whose daily work is similar". At the extremes, it's a bit like calling a typist, a copy editor, and a poet all "writers" because they produce text. That's a useful grouping when you're designing Microsoft Word, but it's a lot less useful when you're judging everyone on "lines written today". (I worry that there's a value implication in those three careers, and it's not intended; I just wanted vastly different daily workflows.)

And so the GitPrime result seems useful to know about, but there are clear cases like yours where its inapplicable. I suspect it would also run into issues with things like embedded or critical-failure code - NASA's commit patterns might have nothing in common with the industry standard. Even in my largely standard work, I realize that of my last two projects, one had ~50 commits and the other had ~3. The 3-commit one was a tech-debt project with lots of reading and documentation work, and I'm skeptical the two are at all comparable.

Even within similar work, I imagine things like branching strategies and test coverage alter commit frequency. For the near future, we'll probably continue to see the value of a given assessment stay company-and-role specific.

Those that self-identify as programmers may or may not be current HS or undergrad students. They often know a single language moderately well, maybe a second. Though they know the language, they often don't know what is available to them in the language of choice's standard library, so they often fall victim to re-inventing the wheel.

A developer has a few seasons under their belt. They may know several languages, and even have a fair grasp upon what the standard library of those various languages offer and so less likely to reinvent the wheel (although they still sometimes do). They're more likely to have a larger toolbox and decent grasp on when it's reasonable to use a certain tool (language or framework to tackle a new problem).

An Engineer is more likely to involve tools to solve problems. Got a performance problem? Going to profile instead of running by gut feel. If your company can afford it, vTune is a great tool here. Engineers are more adapt and comfortable using tools such as gdb, valgrind and strace on Linux or say Windbg on Windows. Bonus: they usually don't need to refer to the manuals to specify the correct commands or interpret the results. This doesn't come from accident or pure reading - you have to have real world practice and experience to know when and which tool is appropriate for the problem at hand.

The Senior Engineer knows all of the Engineer as I've briefly outlined above, but also takes the time to teach/mentor/coach the juniors around him or her when they see room for improvement in the junior. And this should not be in the form of "you're doing it wrong, do this instead", but there should be a "why" component in the "you're doing it wrong".

As a bonus for you, I will also try to write good code.

If you base someone's livelihood on a number, expect them to attempt to maximize that number, probably at the expense of other numbers that you may or may not be considering.

This is a big part of why we think engineering metrics are a tough nut to crack: there’s a fair bit of research that suggests tying KPIs to compensation is a huge anti-pattern for certain types of work (chiefly those involving lots of novel problem solving).

Highly recommend Daniel Pink’s “A Whole New Mind” on this topic; it’s pretty fascinating stuff.

Correction, the Pink title I was referring to was "Drive: The Surprising Truth About What Motivates Us"

Pink does a great job unpacking research that demonstrates how this type of 'affect my pay' dynamic backfires for engineering.

What does this mean? The best developers tend to have the most commits?

From what I've seen, a high frequency of commits means either:

  - Has very little understanding and churns out code one day and removes it the next.
  - Thinks a lot about their code, and divides them into digestible, independent chunks.

It's one of the only clear-metric breakdowns that actually makes sense in light of my programming experiences. I'm hesitant about the idea of using it as a management tool (easy to game, and high commit count or even 'high impact' isn't proof of quality). And, as some other people noted, it's quite role-specific - a performance engineer's commit count won't be comparable to a line engineer.

But as a personal insight, or a mentoring tip? This seems excellent. I know I want to write good code, I'm not going to game my personal metrics, so a clear guideline like "break up code more" is a great thing to have.

But yeah, my co-founder has a pretty interesting take on gaming the system.

TL;DR: So, can you game the system? Absolutely. The point is to game the system: https://intercom.help/gitprime/general/cant-you-just-game-th...

Adversarial work does seem like it's largely a sign of communication breakdown. I think 'gaming' isn't always as adversarial as it seems, though. I was considering it in terms of Goodhart's Law, where even with good intentions, representative metrics become less representative as you organize around them. The "active days" entry in your link seems like an example; if everyone pushes most days for the sake of pushing, then active days isn't feedback on programmer skill.

Of course, your link touches on that. "Everyone pushes every day" is a great outcome, even if the metric is no longer clear. The common trend is to pick good metrics, then struggle to keep them relevant. I really like the alternative of just setting metrics that will be good after people optimize.

This is a situation where I feel gaming the system is not an inherently adversarial relationship.

Something your chart doesn't show is people who make a lot of commits/work but the quality is subpar. They behave as prolific programmers but still need to improve.

Idk, I worry that people will interpret this backwards and rather than having characteristics of a good developer ape those characteristics to appear as a good developer.

As a management metric, I would find this concerning - perverse incentives and false positives all over the place. But as a personal observation, I'm going to take it to heart.

This (like most other metrics) seems most useful from a starting point of "while doing my daily work and seeking to write good code, I will apply this". That doesn't make a good tool for deciding who's talented, but I'm still going to remember it.

It might not even be as overt as that. It is a well known phenomenon that what you measure, you improve.

So as soon as you have a quantitative metric for work performance, almost by definition, it can become problematic to use, unless you are very careful how it is used.

This is not to say that finding a qualitative method is useless, far from it. It can lead to valuable insights and improve overall quality of the team/business.

Can you guys supply an RSS feed link? If you have one, I wasn't able to find it.

I've also noticed that experienced programmers do their commits more frequently and they do the right job - they spend less time on unimportant details.

It also depends on the codebase. A programmer who works on similar codebases for 10 years is more likely to have a high impact than the one who work less and consider these codebases rather new. While their approach and skill set may be similar.

Note that every metric can be gamed, by the way.

Junior Developer isn't an insult, it's just someone who may need about 1/3 of your time to showing them around.

A "Developer" without Junior or Senior should require 1 day out of 14 for advice/assistance.

A Senior Developer should only require assistance when the building is on fire.

In my mind the difference between a junior developer and a senior developer is the ability to recognize tasks/issues and accurately prioritize them in alignment with organizational objectives. In particular I've found that when left to their own devices junior engineers tend to focus on irrelevant items and metrics such as lines of code or genericness for genericness' sake where senior engineers target important bugfixes and features that bring highest benefit to the company and customers. There are parallels with this statement and the premise of the parent comment but I think the latter draws with too broad of a brush.

Intellectual strength isn't the same as senior developer. There might be correlation but it's probably not super strong. I agree that someone not asking for help is definitely junior. But I might also argue that someone who does need to ask for help probably isn't as senior as you seem to think they are.

Even the worst developer can eventually develop fluency in a poorly-designed codebase and seem much more competent than they actually are, compared to a new hire.

A principle engineer invents new kinds of fire.

(Douglas Adams, https://books.google.co.uk/books?id=YKHJ6WQKD3YC&pg=PT142&lp... )

Kindle. Fire. I'll see myself out.

When someone is at the level of SE, they have proven they have skills beyond slinging well-formed code - that's entry stakes for second-tier. They demonstrate a wider understanding of how their work fits into the overall product development, an understanding of customer perspective, and many other attributes. Most if not all of these derive from knowing the right questions to ask, the right people to ask them of, and the right time to do so.

The biggest differentiator is that the Senior developer should know when she needs to ask questions to proceed.

But a senior will definitely ask when he needs help, and won't wait until someone comes to him. And even without the right help, he'll still figure out some way to move forward. Usually, he can figure out his own problems while also offering assistance or guidance to others.

I mgiht guess that a senior developer asks for assistance when it will save them time - they could work it out, but it'll be more efficient for everyone involved if they get some assistance - whereas a junior developer would be lost without it.

But ultimately, anyone can get stuck hunting for a typo causing an inexplicable problem. Sometimes you just need someone to explain your problem to, just to help your own head to solve it.

Senior developers require assistance all the time. Once problems are complex enough there isn't much that can be done as a solo ninja.

That said, it's totally possible you were there, yes. The pacing of promotions vs the abilities needed for them are not always correlated appropriately.

Age is not a good predictor.

A mid-level developer, let's call him Dave, becomes a critical employee after a few years with the company. He silently become "senior" without anyone really asking him to. Other developers notice this and often come to him for help. Management, however, doesn't notice, because nobody in management is exposed to Dave's actual contributions to the team. All they see are completion metrics – story points, etc. – and a project moving forward. Dave is too humble to point out that he did 80% of the work, and he doesn't have regular meetings with his supervisor anyway, so the subject would never come up. After a few years with the company, Dave gets bored and finds another job.

The company now has to pay recruiting costs and the ramp-up time that comes with a new person on the team. Dave, meanwhile, gets what he wanted – a promotion, and a higher pay check. The company could have saved money by giving Dave a 20% raise and a promotion (even a nominal promotion, to make him feel valued) but the management structure wasn't there.

This is how it normally goes, and this is exactly why there is such a short length of tenure in the tech industry compared to other industries.

This is a great story by the way. For me this is a good way to keep your staff loyal while signaling to others that they aren't performing up to snuff while not making it completely awkward.

Granted, many would say it's equally absurd to have so many members of the bottom of your engineering talent on one team, but I've seen it happen over and over again in real life.

I do think that the self-directed criterion is an excellent one, though. With that standard, you could promote an entire team if they're doing good work, or have non-senior engineers stretching up into your top decile. That makes the 'senior' title a clear assertion of "can handle these tasks without substantial oversight".

Later on, I had a member assigned to the team. They were going to fire this person, but asked me if he could have a chance on our team. I said sure. Turned out that this person needed a bit more guidance than they had received before, and when they got it, really began to shine. This person went from almost being fired to being a really valuable contributor on our team.

Myself, I left that company long ago, looking back I think it was a high point of my career. Never before or since have I had that level engagement with the domain or company.

How much was the raise?

Because giving 10% is easy. But when it comes to giving 50-100% there is suddenly zero support from the organization.

I transitioned away from engineering to data science in 2008. FreshBooks took a risk on me but they obviously were going to pay me as a junior data analyst.

I got 2 bonuses and 2 real raises in a year and a half because they could tell I was drastically improving my skills and had much more of an impact than they had originally anticipated.

If your organisation can't identify who is making a difference and do what it takes to keep them, then they're not going to win. That being said, most people asking for a 100% aren't being realistic.

It's not enough to identify the "talent". You have to identify it AND admit that you failed at identifying him earlier AND admit that other companies will poach him if you don't try anything AND you gotta know market-rate right (it can be really hard to find out, even for recruiters in your companies) AND you need to actually pay market rate (most companies don't) :D

By the way, if you get 2 bonus and 2 raises, if likely means that you were incredibly underpaid and it's possible that you still are.

Most companies don't pay market rate? That's a tad incoherent? If most companies aren't paying 'market rate' then what should we all call the rate the market is paying?

Hint: what most companies pay is by definition 'market rate'

Offers at or above the average rate appear, get filled, and disappear. Unrealistic offers below the market rate stay "on marked" for a long, long time - so if you're looking at "what's on offer today" you're seeing a very different list of numbers from the actual prices at which deals are getting closed.

It's same as in stock market - the 'market price' is the average of closed deals, but the visible company job offers is the equivalent of outstanding 'ASK' bids which are not really representative of market price.

You took the job at 15 => Your market rate is 15, all the other companies didn't pay market rate.

Usually, your market rate is the best you got. There aren't many "best" by definition.

The 11 and 12 accepted offers were for other people, that maybe couldn't get better than 11 and 12. Maybe they are less experienced? maybe the 15 company would have hired them both too... but only at 11?

We could say that the cheap companies are under market or that they're only in the market for junior level <profile> (even though they don't advertise it).

We both agree we have to look at the closed deals and the details of the deals =)

- Even if the individual in question had 2x the productivity of the other developers on the team, doubling their salary relative to other employees trades that one developers risk of leaving with the entire rest of the teams.

- If you have enough divergence in compensation that two people at the same level of the hierarchy doing the same role (i.e. an intermediate vs. a senior) can have pay differ by 2x or more, you should be absolutely sure there's no bias to your decisions, whether it's along an identifiable group, or just plain ol' favouritism.

- Frankly, I haven't seen much need for such lavish differentials in salary in the first place. Most people are only motivated by salary to a point. Star performers want to be recognized, and not just with a pat on the back, but give people a good place to work and pay well in general, and you shouldn't need to worry about crazy raises like that.

The first thing you need to be in a > 50% raise situation is an employee that was acquired for incredibly cheap. (Epic combination: one of this first jobs + don't know the market + just came from abroad). [That makes your first two points moot because that guy is the one making significantly less money and he's not identified at the right level].

The second thing is that he's actually good and he's been working for 1 year here, doing valuable stuff. He's gained a lot of value in the meantime and he can totally leverage the job he's done to sell himself in an interview.

Let's give some numbers. The dude started at $80k base with little advantage. Over time, maybe he's gone up to $90k and you got an incredible healthcare plan. It's fine from your point of view.

From the point of view of your competitors. Your guy has been vetted by your company. He's proven and he may even have rare skills that are now easily noticeable. They will offer "market rate" and fight each other mercilessly. The package will be around $150k base (which is nothing extraordinary for that position) + $40k in yearly bonus/stock that he didn't have at your company + various other advantages + they'll also pay $50k in recruiter fees cuz he went through a recruiter.

Now, you've got a guy that is paid $90 at your place that other companies are willing to pay upfront $240k to acquire. Hope they'll never find out about your gold ;)