15 ms·

Why do most top performers have the highest count of commits and pull requests?

159 points by thathoo 6y ago

jariel 6y ago
Not to take away from the premise offered in the article ... But is there a selection bias here? Some kinds of work invariably involve more github activity, small fixes and the like. Those things are generally, unambiguously 'productive' and 'leave the code better', which lends us to believe 'top performers'. Surely, this might be true but I think within a specific context. If find solving new or novel problems involves a lot of work that is hacky, experiemental, quick trial, often the kinds of things that in most cases don't even get checked in.
- kevin_thibedeau 6y ago
  By such a metric people who write the final implementation on the first commit are complete slackers.
- lmm 6y ago
  Why not? Doing experimental things that might not work out, or need radical revisions, is exactly when VCS helps the most.
  - jariel 6y ago
    Because the scratch code is usually pointless, it's the 'key notes' that matter. 200 lines of crazyballs scratch code is not 'the insight' really 'the insight' was that the API works 'really slowly upon first iteration, but very quickly after n iterations' - which implies x, y, z possible courses of action. I suppose you could jam it in the VCS but I've never personally cared. Now that I think about it ... it's interesting because that's definitely not what a VCS is for, though it could absolutely be used in that way. A VCS really is not that great to store arbitrary, secondary related activity and notes wherein 'the code' really isn't the important thing. What's missing here is really a form of document/information sharing that just hasn't caught on very well. Or perhaps I'm still caught up in the ridiculous Confluence/Atlassian garbage, which is the worst wiki ever made.
tracerbulletx 6y ago
I don't disagree this could be true and the reasoning (makes sense)™ but it would be nice to have some hard data when making such assertions.
pan69 6y ago
In the olden days they used to measure performance by SLOC, Source Lines of Code. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code
- stevekemp 6y ago
  Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
  - bch 6y ago
    Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
    - gentleman11 6y ago
      Yet, if you had to build the aircraft out of metal shavings one sliver at a time in a laborious, error prone process, you might not know how far along you are but “well, we’re halfway there by mass” at least gives some measure for the project as a whole. If you game any metric it becomes trash
      - detaro 6y ago
        That assumes you have a finished plane design and know the target weight, which I don't think is what the analogy is after.
    - redis_mlc 6y ago
      > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. Actually, aircraft are evaluated on weight, the less the better. The A380 was initially 5.5 tons overweight, and that is one of the reasons it was a doomed product. That's equivalent to 55 passengers plus luggage (per trip), so Airbus would have to compensate on pricing, or provide fuel subsidies. https://www.aviationpros.com/home/news/10395627/airbus-a380-is-55-tons-overweight-customer-reports https://www.aviationpros.com/home/news/10395627/airbus-a380-... Several other airplanes were also doomed for being overweight. Boeing spent hundreds of millions of dollars to reduce weight on the 787 (I believe they saved 600 pounds): https://www.flightglobal.com/787-weight-saving-is-costly/71036.article https://www.flightglobal.com/787-weight-saving-is-costly/710... (The 787 was heavily (and famously) outsourced, so Boeing had little control of what went into it. Using more composites often increases weight initially.) OTOH, the Lancaster bomber was considered to be a great airplane because it could carry its own weight in payload (fuel and bombs.) In fact, one of the greatest bombers of all time.
zug_zug 6y ago
Lol, when I worked at a unicorn one of my buddies got an award for "most testing code commits" He confided after drinks it was because he didn't know how to squash/amend his commits. So I'm not so sure about that metric....
- Uehreka 6y ago
  Is that why people are always saying you should squash commits? To help with collecting metrics?! I view it as a clear antipattern (since the history within a branch can be valuable later if you need to cherry-pick apart a feature or find a bug with git-bisect) and have asked superiors in numerous places why they require it, and the response is usually a vague mention of “it cleans things up” and “history isn’t important”. It feels like the kind of practice that was mentioned on a screencast and just got cargo-culted, but I have to think it originally had some purpose.
  - Others 6y ago
    I think that squashing commits sometimes make sense. Like is it worth retain two commits if the second one is just fixing the formatting, logs, or metrics from the first one? Also in open source I think it can be easier to keep track of the history if one commit == one PR. I agree people kinda just cargo cult it though, good to be thoughtful about the trade offs for your team or project.
  - FeepingCreature 6y ago
    To me it's rebase > squash > merge. Nobody wants to read a commit history and see a page-long list of "fix audit", "fix typo", "retry ci", "test: change foo", "Revert: test: change foo", "Revert: Revert: retry ci"... That's why you rebase into a sequence of logical, if fictional, worksteps. But if you can't do that, squash is second-best.
    - OJFord 6y ago
      My preferred is rebase (exactly as you describe) but keeping the original fork point, (unless it becomes necessary to depend on some other later work from another branch, the original base or not) and then merge. So you end up with a cleaned-up branch history via rebase, and a master branch that's similarly clean, with a higher level view of 'logical commits' that 'merge X feature', 'merge Y bug fix'.
emerged 6y ago
I’m somewhat self conscious about the sheer volume of commits that I make. The reason there are so many is that I want each atomic unit to be distinguishable. Part of that is motivated by the will to save often in case something goes wrong. Part is to let continuous integration validate with high granularity. Part is to allow for binary search on revision history to reproduce rare bugs and isolate the specific change which introduced it. These considerations may explain the correlation with “top performing” - although for what it’s worth I try to make commits which remove more lines of code than they add whenever possible.
- rendall 6y ago
  Same. I got self conscious when a co-worker mentioned it once, but at my most productive I commit when I complete a unit of thought, usually at a pace of 3-10 commits per hour. Edit: I do think the considered criticisms of this piece are valid, especially the idea that when a correlated measurement (e.g LOC) of a thing (e.g productivity) becomes rewarded, it blows that correlation as everyone starts optimizing the measurement rather than for that thing itself.
vii 6y ago
Being considered the go-to person means you are first in line to make small tweaks (and config changes in code). This increases the change count. If there is a review process where another engineer has to approve work, this exacerbates the gap, as the go-to person can get their reviews done quickly. If they're trusted, the reviews might not be thorough. This increases the rate at which changes go in. These and other factors suggest that it's hard to split cause and effect here. Being seen as productive increases change count :)
- freshhawk 6y ago
  This also seems to be labeling people as "top performers" based on how much code they get done. And then measuring how many commits they do and wondering why those are correlated? Even besides the good reasons you point out ... this seems very obvious. Also, my experience has shown that smaller commits are easier to work with so people with experience tend to make more smaller commits. This also seems to be fairly widely talked about.
- diogenesjunior 6y ago
  With GitHub's API, commits are so easy to game. I'd never use commits as a measure of how good of a programmer someone is. I made a Python script in 15 minutes to commit to a repo every second, and the repo is sitting at about 750,000 commits.
  - geek_at 6y ago
    are you the guy hosting that "time as a service" github repo? Where the time is always updated and you can curl the json or whatever and get the time?
    - diogenesjunior 6y ago
      Nope, not at all. Do you have any links to what you're talking about?
      - 6y ago
est31 6y ago
IDK I've made PRs with multiple trivial commits within an hour. I've also spent over 30 hours on PRs with only 3 commits. It's a useful heuristic but doesn't map very well to work invested.
pikseladam 6y ago
Maybe, just maybe... the person you think is a Top Performer is not actually the Top Performer and you are creating a fake correlation to their high number of commits and pull request. Maybe we need to define who is the Top Performer in the first place.
- a0zU 6y ago
  I mean I won't disagree with your first point but if you read the article you would know that the author very explicitly defines 'Top Performer.'
  - pikseladam 6y ago
    I read it and don't think a go to person is a Top Performer. I wasn't talking about the author view of Top Performer but the realty. I think i can't tell what I'm talking about this KPI situation correctly with a comment. I will try to write a blog post about that asap. I noticed I have a lot to talk about creating KPI for humans. :)
strogonoff 6y ago
“Top performer” here means “top performer in a team, relatively to teammates”, which narrows the definition substantially. There are mysterious geniuses who can deliver a great piece of software just as an experiment/PoC out of the blue, but they don’t tend to shine in such environments—they could be founders or indie consultants, or it could be their side-project persona. (I.e., stating the obvious, if you are intensely working on something on your own, magically starting to atomically commit each change with a thoughtful message will not make you better but can easily eat 1/3 of your time. It’s OK for your commits to be “fat” as long as you yourself manage to keep track of your work in meantime.)
- justinko 6y ago
  I batch it based on what could possibly make sense to revert.
  - franciscop 6y ago
    When I batch, I batch it based on what could make sense to lose. More often than not it's small quick-fire tweaks though. I even made a small CLI tool to quickly deploy it `happy "Message"` and even optionally release an npm version `happy --minor`.
  - Kiro 6y ago
    I batch it based on "ok, I need to commit and push this in case my computer dies".
- temac 6y ago
  3 years latter good commit messages are extremely useful, and most of the time very short ones and/or giant commits are mostly useless. I occasionally read back multiple pages commit message I wrote and wished I dumped even more info from my brain at the time. If you work on small and short projects, you can do pretty much anything though. Of course it can still be unreasonable, but that's quite like anything else. But if in doubt, I would say write more; because if you really track your time in a detailed way, you will see that the marginal additional time is often shorter than you feel. And it taking 1/3 of your time may even be justified in some cases (but maybe you should write some doc in another way then). And I would not be so sure about it not magically making you better though: it is sometimes extremely useful to just write things down, quite like it is useful to explain a bug to a rubber duck.
gfody 6y ago
“top performer” is meaningless unless you’re looking back with enough distance to quantify all manner of contributions.. the people who generated the most complexity the fastest are just as likely to be dangerous forces of chaos.
blisse 6y ago
`git shortlog -sne --oneline --since='Jan 1 2010'` I like running the above command because it gives a good sense of coding productivity at the very least. And then you can dig into specific people to understand why exactly they have lots of commits or not. Most people use Git in a very similar fashion so you can very quickly make a generalization about how they commit if you look through their last N commits. Some 'high commit count' people have lots of low value commits, e.g. lots of 'fix it' commits. Other 'high commit count' people are very productive but mix in a lot of atomic commits, e.g. lots of 'another commit to change this comment', leading to a PR of 9 super small commits + 1 real commit, that's readable alongside their actual work. Others are actually just more productive than other people. That might be because their code changes are simpler, or in an area that's easier to be productive in and write lots of code. Or they just work more. Or they work at a higher velocity because they understand the codebase and domain better. Definitely don't _only_ use these metrics because some people just code slower and put out 1 large PR, but I can definitely believe a pattern of people at the top end of productivity who put out both small and large PRs at a higher velocity than the 'less productive' people. I would honestly just attribute those high value, high commit count people to being stronger developers overall, in my limited experience. Overall as in, not weak in any particular area, and quite strong technically in every area. The people you can put in any situation in the domain and they'd probably succeed. Because they're strong across the entire codebase, their productivity is just generally higher no matter what they're doing.
howlgarnish 6y ago
Obligatory: https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history (does just what it says on the tin) "I don't encourage people to cheat. But if anybody is judging your professional skills by the graph at your GitHub profile, they deserve to see a rich graph"
sgtnoodle 6y ago
Perhaps some of the more productive workers are the ones that don't hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing. I have noticed that pretty much every software engineer to some degree has problems that they procrastinate on. Folk can spend 10x more time talking about doing something than it takes to do it. For hard problems, that discussion is necessary and beneficial, but lots of problems just need someone to open up the text editor and get it done.
- codegladiator 6y ago
  I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there commented out, only a week later to find we need it now.
  - reificator 6y ago
    Have I been working in a bubble? I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them. Are they comfortable branching?
    - chrisandchris 6y ago
      I think it‘s less about version control and more about that the change is then associated with the employees name and if something ever goes wrong, it would be possible (easy?) to blame him therefore he‘s being scared about doing something because it could cause trouble for him somewhen in the future. And, imho, that goes back to not enough testing nd no safety nets to check for code errors (like code review, static analysis, ...).
      - 6y ago
jodrellblank 6y ago
> "the top performer's commits out number the second highest by 50% or more. [...] This might indicate some form of Pareto principle at play. Perhaps?" Price's Law? "50% of the work is done by the square root of the total number of people who participate in the work" -> "You are working on a team, and there are the superstars who do most of the work or seem to produce most of the outcomes and then there is everyone else." https://expressingthegeniuswithin.com/prices-law-and-how-it-applies-to-everything/ https://expressingthegeniuswithin.com/prices-law-and-how-it-...
yudlejoza 6y ago
> ... top performers ... highest count of commits and pull requests > ... define top performers as ... a go to person So circular logic. Got it. In a related story, why employed engineers have code contribution to the company that's way higher (actually infinitely higher) than those who are not in the company.
jfoutz 6y ago
I've worked with some amazing programmers that produce fabulous amounts of code. and, often, that's who you need. I have been envious of their prodigious production. I think, often, those folks solve problems by adding more code. I think, sometimes that mountain of code starts to become a liability. I'm a little better at reading a lot of code, consolidating, and fixing bugs. Importantly, fixing bugs without breaking other stuff (usually. coding is hard) if you buy the adage "make it work, make it right, make it fast", you'd probably buy that most people fall into one of those categories and excel (there are rare jewels that are amazing at all three. Carmack maybe is a good example). Anyway, I'm not a top performer. I have my moments of glory, and I think I deliver good value. I try to avoid git stats. I peek from time to time, and I'm super pleased that I've deleted about 2x the amount of code I've added but, that's maybe me protecting my ego. Everybody needs code, some people need code to be right, even fewer people need code to be fast. Different people bring different skills to the table. Be real careful about how those different aspects play into reaching goals.
- andy_ppp 6y ago
  Deleting code saves so much money for your organisation as it’s deleted for every person who touches the codebase! I don’t think this is ego protection at all, maybe the people who write shed loads of code are protecting their egos just a little.
- op03 6y ago
  It would help if people had more awareness of the personality spectrum in the population and the distribution of traits within a team. Not knowing leads to lot of misunderstandings. https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Temperament_and_Character_Inventory https://en.wikipedia.org/wiki/Temperament_and_Character_Inve... Different traits become strengths or weaknesses depending on the type of problem being solved. If the solution is known the disciplined/conscientiousness trait holders shine. If the solution is unknown the neurotic shines cause they dont methodically explore the search space (matters a lot if its large). If there is lot of conflict everyone loves the agreeable trait holder. And teams full of introverts get boring as people don't develop deep personal connections that extroverts enable etc etc etc
WalterBright 6y ago
One reason not mentioned (or maybe it's only me): If I've got bunch of problems, I'll work on the easiest ones first, saving the hardest for last. This clears my mind from the drag from the easier problems, and as a side effect I wind up committing more. There's no particular correlation between how hard a problem is to solve vs how much time it takes to solve them. So hit the easy ones first and make your users happy!
cryptica 6y ago
Wow, the premise of this article is very wrong; it's deeply concerning that people are falling for this. Those who make a lot of commits are not top performers, they are mostly engineers who are overly concerned with their 'optics'; they are engineers who are good at projecting themselves as 'top performers' but if you actually look at the results of their work a few years down the line, you will see that they are in fact low performers of the worst kind because they tend to add a lot of unnecessary complexity and technical debt because they don't think through things enough and just implement. I'm absolutely shocked to learn that people are falling for this.
- atraac 6y ago
  That's why there's 'most' in the title. Noone here assumes that more commits = better, but the article simply points out a correlation that MOST top performers, tend to have most git activity, and I see a similar thing in my professional experience. That doesn't mean I think that anyone with a lot of PR reviews or commits is better than other people...
  - cryptica 6y ago
    I disagree with the 'most' premise as well. Totally a false signal. In my view, the opposite is true. The top performers tend to commit less. People who are genuinely passionate about coding don't tend to put that much effort into the more pedantic aspects of the process; they're more focused on big ideas such as the structurally important parts of the architecture. The developers who make a lot of commits are often more concerned with optics and they will argue for hours over unimportant tedium while sometimes missing the big very important ideas (the ones which will have real impact and flow-on effects for years to come). Basically they can't tell the distinction between what is important and what is not. They can't tell apart bureaucracy from value creation. Obsessive focus on commit size and other tedium is a key signal that someone doesn't know what is really important. They tend to be conventional thinkers (driven by peer pressure and peer approval) and their idea of productivity is distorted by false consensus (like the one this article attempts to instigate).
    - 6y ago
fxtentacle 6y ago
Because they are willing to take the risk of publicly being wrong. Committing your source code to the company git makes it very easy for others to point at you later, if things break. And it's pretty much impossible to undo once someone else has pulled your change. In my opinion, many top performers are simply people who do what needs to be done, and when it's needed.
- bavuy 6y ago
  These types often protect themselves and their clique with a CoC that effectively prohibits criticism from people who care about correctness and a lean code base.
m_rpn 6y ago
I hope that someday this "version control craze" will end, this perpetual race where everybody is urging to fire PRs to up his stauts in the team, this sensation that before being a good engineer you have to know git dark arts to the core, in order to rewrite "HISTORY", and amend each misdoing as you see fit. We need to remember what is our job: writing software that makes sense, not commiting code.
- Mauricebranagh 6y ago
  "version control craze" ! Really! version control is one of the big improvements to software development I have seen. Now if we could get the rest of the customer chain to start version controlling their requirement docs and properly minuting meetings and action points
  - ryandrake 6y ago
    Version control is great as a productivity improvement tool and a way to organize contributions from multiple developers. It's not great when treated as a social network or productivity measuring tool. When you're firing off PRs to get your name up there again or to fill in your square on the calendar, you're kind of abusing the tool.
- rendall 6y ago
  I don't get this. Version control is essential. I've worked at places that didn't have it and it's absurdly unnecessarily unpleasant. If you really don't like git try Mercurial. I haven't worked with it in years but it was very easy to work with
dmpetrov 6y ago
In a mature project, the number of removed lines is a stronger proxy to productivities. It is related to the unavoidable tech debt that any project has and only the strongest people see it and work on it.
thrower123 6y ago
Because most people don't do anything at all. Even trying to do something puts you in the top half, even if it's poor quality, because a huge fraction of people are completely useless and don't ever do anything productive at all.
pwdisswordfish0 6y ago
The problem lies in the question. In the worst circumstances, it's indicating survivorship bias, and in the best circumstances the only truths it reveals are tautological. Using number of commits to measure productivity is the new version of thinking that the more number of lines of code that a programmer writes, the better. Not that this will stop a segment of the industry from flushing a non-trivial amount of resources down the drain learning this lesson, and inevitably leaving a chunk of stalwarts who never really learn anything. It was clear that was going to happen when the "social coding" site that everyone was flocking to put so much emphasis on activity measured in number of commits, forks, and other administrative details. Things which were only any good for advertising the site's own user engagement in its pre-IPO/-acquisition phase, and too many people mistaking it as a measurement of something else.
ndepoel 6y ago
The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, sloppy, riddled with issues and a nightmare to maintain. And it would inevitably fall upon us "lesser" performers to actually investigate and fix all those issues, making us look less productive in the process. In my opinion a better metric to quantify someone's performance is to count the amount of problems they solve vs. the amount of problems they create. I bet that many of the rockstar programmers out there would land on the negative side of that particular scale.
- pydry 6y ago
  Most problems are multi causal and if you have blame culture will degenerate into a litany of finger pointing.
  - lucideer 6y ago
    I'm not sure what "blame culture" is, but any professional software team should ideally have some kind of "accountability culture". Whatever the fallout from people feeling "blamed" may be, attrition of all of your genuine programming talent due to tech-debt-machine peers being promoted ahead of them is not exactly an ideal outcome either. What's more, very often genuine potential in naturally talented new programmers can be stunted if they're rewarded for lazy faux "productivity". I've seen this: a programmer has a genuine interest and passion for quality, but loses it over time due to a focus on doing (different) work that gets them promoted. Code ownership (being required to "own" ones work along with the bugs & maintenance burden that come with it) is one of the most valuable ways programmers learn. This needs to be balanced, as one runs the risk of having a bus factor of 1, but it's still vital.
    - pydry 6y ago
      Blame culture is when bugs, downtime, etc. happen and people both look for somebody to blame and simultaneously look to exculpate their own behavior. It leads to CYA behavior, backstabbing and massive risk aversion. It can also lead to or be a result of a toxic work environment. In multi causal bugs it can lead to people downplaying causes which they had something to do with and exaggerating the effect that co-worker thry don't like had something to do with. This often leads to confused attribution and poor rectification of systemic issues - e.g. writing more unit tests even when more unit tests won't really help. "Accountability culture" sounds like it could be the same thing. Or not. I'm not really sure.
notacoward 6y ago
OP mentions three things: staging their work, velocity, and sense of agency/ownership. All three are problematic. Often those who have worked with a component the longest and/or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I've been one myself) it's simply easier to get commits in, not necessarily because you're better at the work but because of the role itself. You never have to re-work your commits to conform to someone else's idea of how things should work. People trust you, so reviews are often cursory. Many maintainers return that courtesy by subjecting others' work to excruciating review, slowing them down. Sometimes it's intentional, sometimes not, but the result's the same. Also, a maintainer often has many commits that started off as someone else's idea but that person didn't have the time or knowledge to complete them, so those are kind of low-hanging fruit that inflate the numbers. A mediocre maintainer will usually still have more commits than even the most talented non-maintainer. Calling them "top performers" because of something that's part of the role seems a bit circular. So much for velocity and ownership. As for the part about staging commits, I'd like to see some evidence. In my experience there's no difference, or sometimes the maintainers are even less likely to break up commits. This can be because maintainers are often charged with making commits with lots of internal dependencies that make them harder to break up, or because it's easy to get a stamp even on a questionable commit from people who are dependent on their goodwill to get their own commits in.
- modernlearner 6y ago
  It does sound from the article as if incumbents will always have a huge advantage and will be more likely to be labeled top performers.
- temac 6y ago
  OTOH I'm tired of people who don't "have the time or knowledge to complete [their ideas]". Ideas are cheap. Show me the code. Asking, explicitly or implicitly, for others to "implement/finish" their ideas is easy. I would even call never finishing / polishing anything very disrespectful: I'm not (should not be) here to cleanup after "talented" individuals. This is detrimental to my own "ideas." So at least, if not anything else, I better be recognized for the boring and tedious maintainership work I do and that talented people with their "ideas" refuse to perform...
exabrial 6y ago
The two top performers in my organization definitely don't have a lot of commits. Instead, I would say their strongest skill is written communication; in emails, log messages, code review comments, and chat messages.
AlanSE 6y ago
> If they find an issue along the way, they make a note of it and come back to fix it. Or they might fix in as they go. One consistent tension is that the old-hand developers have a "mental issue queue" that is enormous, but without fail, every time, they just can't be transferred. These can't be made into issues and farmed out to other people. Inconsistencies in the data model, for instance, might exist, but a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better. Once you've contributed enough of the main functions of a code base, you just never lack for something to do. All code is bad, because the business focus is on expansion of responsibilities over refinement of the existing ones. Those ghost issues are best communicated with a code change, at which all observers say WOW WHY DID WE NOT SEE THIS?! But the issue without the code change gets gawking blank stares. EDIT: but fixing unrelated issues as you go is bad, don't do it!
- qes 6y ago
  > old-hand developers have a "mental issue queue" that is enormous > a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better > Once you've contributed enough of the main functions of a code base, you just never lack for something to do. Hello, friend, I see we know each other well.
mumblemumble 6y ago
I suspect that it's nearly impossible to separate one's definition of a top performing developer from some sense of how often they commit. For better for for worse. I've worked on teams where I had colleagues who were incredibly deliberative. They would spend lots of time working with stakeholders to deeply understand their problems, and then produce elegant solutions that made their jobs drastically easier. Small changes with huge payoff. But management, and even most other team members, didn't recognize this. They just saw a slow programmer. Credit tended to go almost exclusively to other teams, when their members started using those tools to radically improve their own processes. The company's dev org largely didn't care about that effect, because it didn't positively influence their own KPIs.
- deleted 6y ago
  [deleted]
bumblebritches5 6y ago
...Because they work hard...
trident1000 6y ago
When you have a lot of commits you are working off yourself while everyone else needs to get caught up on what you did and then contribute after. Its essentially twice (or whatever) as much work as a laggard. It becomes 1 persons project and the others are observing. For better or worse because just running with something is often faster than deliberating at every turn. But also can backfire in many ways. Its similar to group projects in college.
pmayrgundter 6y ago
Old maxim: "If you want something done, give it to a busy person"
giantg2 6y ago
I was a top performer on my team in the past for a couple years. It was nice being an expert, but they never promoted me and were always playing games. I think it's better just be a average or below average person and not have to deal with the BS that comes with being a top performer. At this point in my career I doubt I'll ever make it back to that level of skill anyways.
- rendall 6y ago
  Why not?
  - giantg2 6y ago
    Why won't I get back to that level? I have a kid, so I don't have any time to study outside of work or put in tons of extra hours. After years of being screwed over and passed over, I don't really have the drive/hope to get to that level since it wasn't rewarded the first time. Also, the work is very boring now and isn't transferrable to other groups or companies, so I don't have any interest in being an expert just to throw away that knowledge (like I was forced to do in the past).
    - rendall 6y ago
      > "... since it wasn't rewarded the first time" Our industry, unfortunately, doesn't promote from within. We almost always have to leave the company to another that is willing to give you a better title and salary.
      - giantg2 6y ago
        Yeah. My problem is that there aren't very many companies using FileNet or NeoXam.
        rendall 6y ago
        Hmm. If they are important to the companies that use them, you may be in a good position to move, assuming that is also hard to find people experienced in those technologies
CydeWeys 6y ago
If you look at it from a slightly different viewpoint, there's nothing remotely surprising or controversial about this. You wouldn't be surprised to hear that the best factory workers tend to produce the most widgets per hour, or that the best butchers process the most meat per hour. Productive output is definitely highly correlated with job skill, almost tautologically so. Yes, a code commit isn't exactly the same thing as a widget, but it's similar enough in broad strokes to still be a useful measurement.
corpMaverick 6y ago
For me at least. I am the most productive when I can do many SMALL commits and able to push them to prod. You have to be able to make your change; either a refactoring or a functionality change and get it through the QA, review, deploy process. Now days I spent a lot of time, dealing with multiple branches and deployment environments and my productivity is in the floor. In a previous job I was able to deploy 2 or 3 changes a day in prod. It was very full filling.
- corpMaverick 6y ago
  Actually that seems to be one of main points of the blog post. Being able to stage their work.
Ozzie_osman 6y ago
There's a pretty subtle pitfall that teams can fall into here. Let's say a team has 2 developers. Josh is 20% "better" than the John, or simply started earlier and has more context on the code base. So initially, Josh is 20% faster, but now John has to spend an extra 20% of his time reviewing Josh's code in a pull request (or understanding Josh's code so he can make a change) instead of making forward progress. So now, actually John is even 20% less effective than he can be, and he has less time to actually code. And since he's even less productive, Josh has __more__ time to code, so he's even faster, which means he writes more code. It kind of compounds, and even an initial slight advantage in speed or context for one developer can amplify itself over time. A good engineering manager or senior engineer can detect when that's happening and try to correct the balance. But often the team kind of settles into a mode where Josh is known to be better and more productive and everything is funneled to him.
- specialist 6y ago
  Paraphrasing: Josh has the initiative, forcing John to react. -- In my experience, Josh is a firehose of chaos, doesn't test their own work, colors outside the lines. So in addition to John reviewing Josh's torrent of bs, John is always playing catchup, always has to do more rework. Further, it's not a balanced relationship. Josh creates urgency to fast track approval for their own PRs. Then will goal tend John's work. Pedantry over everything. Let PRs get stale, so John has to remerge, reseting the whole process. Insist the commits are "too big", "hard to understand", and therefore need to be broken up. Etc. Individual agility and velocity are evil, rewards dysfunctional behavior. If the whole team isn't committed to getting the whole team across the finish line, it's not a proper team. PS- Additional dysfunction if John is constitutionally incapable of refactoring, removing dead code, and other good citizenry.
- datagram 6y ago
  I've found myself in this sort of situation a lot, including on 2-person teams. While I'm pointing out all the bugs, maintability issues, etc. on their commit, they're busy writing a new commit full of the same types of issues. And on the flip size: because I self-review my code with the same attention, I rarely have any of those same sorts of issues in code that I make others review. I'm lucky in that my company recognizes and appreciates the quality that provide with my work and encourage from others, but I'm not sure of how to actually address the imbalance. Many times I've thought of just asking engineers to put more effort into self-reviewing their code, but I always feel like it would just be too rude.
jeffreyrogers 6y ago
Top performers do more work (generally, not always). This is contrary to the HN conventional wisdom that lines of code are a bad metric, and I see where those people are coming from. But generally people capable of writing more code faster are also capable of writing the right code.
- nrmitchi 6y ago
  > Top performers do more work (generally, not always). Yes, that is true by definition. What is not necessarily true is that all of that work involves writing code. > generally people capable of writing more code faster are also capable of writing the right code I disagree here though, and is highly dependent on what you consider to be "the right code". In my experience the people capable of writing more code faster are the people who don't necessarily take the step back and think "should this code even be written at all?".
  - jeffreyrogers 6y ago
    Maybe, but I see speed as a proxy for ability. If all I know about someone is they can write code fast then I would bet on them being an above average programmer.
pizza234 6y ago
My theory: simply put, a large number of commits (without considering excess/cheating for the sake of themselves) can indicate lots of qualities of a good software engineer: order, planning, precision and capacity of partitioning a problem in smaller units.
msoad 6y ago
This is inline with my experience as well. I know it is the common wisdom to not measure performance with lines of code or number of commits. But in a large picture it's always the top performers that make the most commits. If I was a manager and asked to lay off X percent of the engineers, I would totally take into account number of commits among other signals.
zimbatm 6y ago
Once you are the top-committer in a project, you have the advantage. You know most of the code, even if it doesn't have tests. It's easy to figure out where reported bugs are, that you have introduced. Meanwhile, the rest of the team is busy reviewing your code and rebasing their PRs. I have seen this pattern so many times. It'a a good strategy to be recognized by management. Also what happens when the top-committer leaves, suddenly the rest of the team can breath and flourish.
seahawks78 6y ago
Could not disagree more. The article's main argument is wrong and dangerous to an extent! A software engineer's productivity depends on the quality of his thinking that goes on between his two ears - not on the number of lines of code (LOC), number of commits and some other meaningless measure. I don't think the author knows/understands what it takes to operate at a Senior/Staff level and beyond. Yeah, may be for someone just out of school productivity can be measured in terms of lines of code. OTOH, if a Principle Engineer in the team comes to me and says that he feels great just because he added 500 commits/30k lines of new code to the code base I will just say one thing: "run for your life"! as soon as possible.
- jyriand 6y ago
  It's not really constructive to start your comment with a "utter piece of crap".
  - seahawks78 6y ago
    Since this comment was downvoted let me elaborate this with a personal experience (of course it is anecdotal). In June of this year, my entire team was struggling after moving to a new Kafka cluster because of low throughout in one of the backend services (about 250k/min with approx 32 instances). This was causing issues for our downstream dependencies as we were not able to reply back within one hour of consuming the record from upstream and our L2 support was daily getting numerous pages which were also escalating to us. Then my manager asked me to take a look at what is going on and if we can improve the throughput somehow. After almost spending one week of banging my head against different theories and tons of experiments in QA I finally figured out that the new Kafka client we were using had a setting where it required acks from all brokers (which has increased to 5 in the new cluster from 3 in previous one) and this caused a huge increase in the blocking time even though we were using an Async framework. The async task just waited too long for completion and once completed could not get the threadpool back due competition with other threads. Solution: simple, I just changed the Kafka producer ack from "ALL" to "ONE" requiring acknowledgement from one broker only. Throughput with same 32 instance jumped from 250k/min to around 700k. I ask the intelligent readers of HN - do you think that based on this I should be penalized since the change was only in one line of config code? Yes, that's all what it took to resolve this outstanding issue - one line of config change/one commit albeit one week of thinking and experimenting time!
dathinab 6y ago
One important point missed: - Top performers tend to be motivated. - Just because someone is a "top performer" in one project/team/company doesn't mean this person will be one in another project/team/company. Reasons can be manifold, motivation can play a big role between someone being a good and someone being a top performer.
ram_rar 6y ago
Top performers are motivated and do more work. But that does not necessarily translate into real progress. If you shit the bed and clean it up, its not real progress. Unfortunately, management doesnt see that way. I wont consider myself a top performer. But I have my moments of glory. Most of my impactful commits were deleting unwanted code and needless libraries in the codebase.
colinrand 6y ago
Another interesting characteristic I've seen over the years from top performers is that they also have deleted the most code.
m3kw9 6y ago
Quality is usually how fast they can complete features with least bugs for a faster release while navigating feature changes they go. That’s where rubber hits the road.
WesolyKubeczek 6y ago
I worked once on a piece of software to track construction projects. The CEO was always grumbling about the pace of development, citing the example of programmers who added Gantt charts to it in two days, and why was I so much slower at “simpler” features. Fast forward a couple of months, and we had a customer complain about the Gantt charts being off. I had a closer look at the thing, and it turned out that the bars on the chart had been drawn using the Math.random() function. They came out different each time you refreshed the page and were in no way related to the real thing.
jl2718 6y ago
I’m trying to understand the DevOps of this concept. Is everybody working in the same repo, or are these personal forks that get hammered until nice merged PRs can be submitted? Do devs complete whole features before submitting, or do they submit partial work that everybody else is trying to contribute to? Are multiple developers working on the same code modules, or have they been split out? Are there tests and interfaces written ahead of time, or do they do tasking by prose? The goal of software management is to keep everybody productive. If you have an imbalance in commits or pull requests in the main repo/branch, that’s a strong sign of a broken process. Tasks should be given according to familiarity and skill so this doesn’t happen. This also says something about software design. Good design is easy to split up. Bad design requires a ‘go to’ person. Therefore, a ‘go to’ person is by definition not a good software engineer, because their design was bad, and/or they never fixed it. And if it worked the first time, you wouldn’t have to ‘go to’ anybody. The skill ladder of software engineering goes something like: watching, practicing, contributing, designing, teaching, leading. Every developer goes through this process from scratch in every project. Getting stuck is a problem (as is skipping steps). Preventing other people from progressing is a bigger problem. Perhaps rethink this.
juancn 6y ago
That's plainly not true. There are top performers that do not produce the largest number of commits and PRs. They produces the most difficult ones to get right. There are mediocre performers that produces an awful lot of commits and PRs, confusing volume with substance.

159 points by thathoo 6y ago

Not to take away from the premise offered in the article ... But is there a selection bias here? Some kinds of work invariably involve more github activity, small fixes and the like. Those things are generally, unambiguously 'productive' and 'leave the code better', which lends us to believe 'top performers'. Surely, this might be true but I think within a specific context. If find solving new or novel problems involves a lot of work that is hacky, experiemental, quick trial, often the kinds of things that in most cases don't even get checked in.

kevin_thibedeau 6y ago
By such a metric people who write the final implementation on the first commit are complete slackers.
lmm 6y ago
Why not? Doing experimental things that might not work out, or need radical revisions, is exactly when VCS helps the most.
- jariel 6y ago
  Because the scratch code is usually pointless, it's the 'key notes' that matter. 200 lines of crazyballs scratch code is not 'the insight' really 'the insight' was that the API works 'really slowly upon first iteration, but very quickly after n iterations' - which implies x, y, z possible courses of action. I suppose you could jam it in the VCS but I've never personally cared. Now that I think about it ... it's interesting because that's definitely not what a VCS is for, though it could absolutely be used in that way. A VCS really is not that great to store arbitrary, secondary related activity and notes wherein 'the code' really isn't the important thing. What's missing here is really a form of document/information sharing that just hasn't caught on very well. Or perhaps I'm still caught up in the ridiculous Confluence/Atlassian garbage, which is the worst wiki ever made.

tracerbulletx 6y ago

I don't disagree this could be true and the reasoning (makes sense)™ but it would be nice to have some hard data when making such assertions.

pan69 6y ago

In the olden days they used to measure performance by SLOC, Source Lines of Code. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code

stevekemp 6y ago
Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- bch 6y ago
  Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
  - gentleman11 6y ago
    Yet, if you had to build the aircraft out of metal shavings one sliver at a time in a laborious, error prone process, you might not know how far along you are but “well, we’re halfway there by mass” at least gives some measure for the project as a whole. If you game any metric it becomes trash
    - detaro 6y ago
      That assumes you have a finished plane design and know the target weight, which I don't think is what the analogy is after.
  - redis_mlc 6y ago
    > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. Actually, aircraft are evaluated on weight, the less the better. The A380 was initially 5.5 tons overweight, and that is one of the reasons it was a doomed product. That's equivalent to 55 passengers plus luggage (per trip), so Airbus would have to compensate on pricing, or provide fuel subsidies. https://www.aviationpros.com/home/news/10395627/airbus-a380-is-55-tons-overweight-customer-reports https://www.aviationpros.com/home/news/10395627/airbus-a380-... Several other airplanes were also doomed for being overweight. Boeing spent hundreds of millions of dollars to reduce weight on the 787 (I believe they saved 600 pounds): https://www.flightglobal.com/787-weight-saving-is-costly/71036.article https://www.flightglobal.com/787-weight-saving-is-costly/710... (The 787 was heavily (and famously) outsourced, so Boeing had little control of what went into it. Using more composites often increases weight initially.) OTOH, the Lancaster bomber was considered to be a great airplane because it could carry its own weight in payload (fuel and bombs.) In fact, one of the greatest bombers of all time.

zug_zug 6y ago

Lol, when I worked at a unicorn one of my buddies got an award for "most testing code commits" He confided after drinks it was because he didn't know how to squash/amend his commits. So I'm not so sure about that metric....

Uehreka 6y ago
Is that why people are always saying you should squash commits? To help with collecting metrics?! I view it as a clear antipattern (since the history within a branch can be valuable later if you need to cherry-pick apart a feature or find a bug with git-bisect) and have asked superiors in numerous places why they require it, and the response is usually a vague mention of “it cleans things up” and “history isn’t important”. It feels like the kind of practice that was mentioned on a screencast and just got cargo-culted, but I have to think it originally had some purpose.
- Others 6y ago
  I think that squashing commits sometimes make sense. Like is it worth retain two commits if the second one is just fixing the formatting, logs, or metrics from the first one? Also in open source I think it can be easier to keep track of the history if one commit == one PR. I agree people kinda just cargo cult it though, good to be thoughtful about the trade offs for your team or project.
- FeepingCreature 6y ago
  To me it's rebase > squash > merge. Nobody wants to read a commit history and see a page-long list of "fix audit", "fix typo", "retry ci", "test: change foo", "Revert: test: change foo", "Revert: Revert: retry ci"... That's why you rebase into a sequence of logical, if fictional, worksteps. But if you can't do that, squash is second-best.
  - OJFord 6y ago
    My preferred is rebase (exactly as you describe) but keeping the original fork point, (unless it becomes necessary to depend on some other later work from another branch, the original base or not) and then merge. So you end up with a cleaned-up branch history via rebase, and a master branch that's similarly clean, with a higher level view of 'logical commits' that 'merge X feature', 'merge Y bug fix'.

emerged 6y ago

I’m somewhat self conscious about the sheer volume of commits that I make. The reason there are so many is that I want each atomic unit to be distinguishable. Part of that is motivated by the will to save often in case something goes wrong. Part is to let continuous integration validate with high granularity. Part is to allow for binary search on revision history to reproduce rare bugs and isolate the specific change which introduced it. These considerations may explain the correlation with “top performing” - although for what it’s worth I try to make commits which remove more lines of code than they add whenever possible.

rendall 6y ago
Same. I got self conscious when a co-worker mentioned it once, but at my most productive I commit when I complete a unit of thought, usually at a pace of 3-10 commits per hour. Edit: I do think the considered criticisms of this piece are valid, especially the idea that when a correlated measurement (e.g LOC) of a thing (e.g productivity) becomes rewarded, it blows that correlation as everyone starts optimizing the measurement rather than for that thing itself.

vii 6y ago

Being considered the go-to person means you are first in line to make small tweaks (and config changes in code). This increases the change count. If there is a review process where another engineer has to approve work, this exacerbates the gap, as the go-to person can get their reviews done quickly. If they're trusted, the reviews might not be thorough. This increases the rate at which changes go in. These and other factors suggest that it's hard to split cause and effect here. Being seen as productive increases change count :)

freshhawk 6y ago
This also seems to be labeling people as "top performers" based on how much code they get done. And then measuring how many commits they do and wondering why those are correlated? Even besides the good reasons you point out ... this seems very obvious. Also, my experience has shown that smaller commits are easier to work with so people with experience tend to make more smaller commits. This also seems to be fairly widely talked about.
diogenesjunior 6y ago
With GitHub's API, commits are so easy to game. I'd never use commits as a measure of how good of a programmer someone is. I made a Python script in 15 minutes to commit to a repo every second, and the repo is sitting at about 750,000 commits.
- geek_at 6y ago
  are you the guy hosting that "time as a service" github repo? Where the time is always updated and you can curl the json or whatever and get the time?
  - diogenesjunior 6y ago
    Nope, not at all. Do you have any links to what you're talking about?
    - 6y ago

est31 6y ago

IDK I've made PRs with multiple trivial commits within an hour. I've also spent over 30 hours on PRs with only 3 commits. It's a useful heuristic but doesn't map very well to work invested.

pikseladam 6y ago

Maybe, just maybe... the person you think is a Top Performer is not actually the Top Performer and you are creating a fake correlation to their high number of commits and pull request. Maybe we need to define who is the Top Performer in the first place.

a0zU 6y ago
I mean I won't disagree with your first point but if you read the article you would know that the author very explicitly defines 'Top Performer.'
- pikseladam 6y ago
  I read it and don't think a go to person is a Top Performer. I wasn't talking about the author view of Top Performer but the realty. I think i can't tell what I'm talking about this KPI situation correctly with a comment. I will try to write a blog post about that asap. I noticed I have a lot to talk about creating KPI for humans. :)

strogonoff 6y ago

“Top performer” here means “top performer in a team, relatively to teammates”, which narrows the definition substantially. There are mysterious geniuses who can deliver a great piece of software just as an experiment/PoC out of the blue, but they don’t tend to shine in such environments—they could be founders or indie consultants, or it could be their side-project persona. (I.e., stating the obvious, if you are intensely working on something on your own, magically starting to atomically commit each change with a thoughtful message will not make you better but can easily eat 1/3 of your time. It’s OK for your commits to be “fat” as long as you yourself manage to keep track of your work in meantime.)

justinko 6y ago
I batch it based on what could possibly make sense to revert.
- franciscop 6y ago
  When I batch, I batch it based on what could make sense to lose. More often than not it's small quick-fire tweaks though. I even made a small CLI tool to quickly deploy it `happy "Message"` and even optionally release an npm version `happy --minor`.
- Kiro 6y ago
  I batch it based on "ok, I need to commit and push this in case my computer dies".
temac 6y ago
3 years latter good commit messages are extremely useful, and most of the time very short ones and/or giant commits are mostly useless. I occasionally read back multiple pages commit message I wrote and wished I dumped even more info from my brain at the time. If you work on small and short projects, you can do pretty much anything though. Of course it can still be unreasonable, but that's quite like anything else. But if in doubt, I would say write more; because if you really track your time in a detailed way, you will see that the marginal additional time is often shorter than you feel. And it taking 1/3 of your time may even be justified in some cases (but maybe you should write some doc in another way then). And I would not be so sure about it not magically making you better though: it is sometimes extremely useful to just write things down, quite like it is useful to explain a bug to a rubber duck.

gfody 6y ago

“top performer” is meaningless unless you’re looking back with enough distance to quantify all manner of contributions.. the people who generated the most complexity the fastest are just as likely to be dangerous forces of chaos.

blisse 6y ago

`git shortlog -sne --oneline --since='Jan 1 2010'` I like running the above command because it gives a good sense of coding productivity at the very least. And then you can dig into specific people to understand why exactly they have lots of commits or not. Most people use Git in a very similar fashion so you can very quickly make a generalization about how they commit if you look through their last N commits. Some 'high commit count' people have lots of low value commits, e.g. lots of 'fix it' commits. Other 'high commit count' people are very productive but mix in a lot of atomic commits, e.g. lots of 'another commit to change this comment', leading to a PR of 9 super small commits + 1 real commit, that's readable alongside their actual work. Others are actually just more productive than other people. That might be because their code changes are simpler, or in an area that's easier to be productive in and write lots of code. Or they just work more. Or they work at a higher velocity because they understand the codebase and domain better. Definitely don't _only_ use these metrics because some people just code slower and put out 1 large PR, but I can definitely believe a pattern of people at the top end of productivity who put out both small and large PRs at a higher velocity than the 'less productive' people. I would honestly just attribute those high value, high commit count people to being stronger developers overall, in my limited experience. Overall as in, not weak in any particular area, and quite strong technically in every area. The people you can put in any situation in the domain and they'd probably succeed. Because they're strong across the entire codebase, their productivity is just generally higher no matter what they're doing.

howlgarnish 6y ago

Obligatory: https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history (does just what it says on the tin) "I don't encourage people to cheat. But if anybody is judging your professional skills by the graph at your GitHub profile, they deserve to see a rich graph"

sgtnoodle 6y ago

Perhaps some of the more productive workers are the ones that don't hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing. I have noticed that pretty much every software engineer to some degree has problems that they procrastinate on. Folk can spend 10x more time talking about doing something than it takes to do it. For hard problems, that discussion is necessary and beneficial, but lots of problems just need someone to open up the text editor and get it done.

codegladiator 6y ago
I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there commented out, only a week later to find we need it now.
- reificator 6y ago
  Have I been working in a bubble? I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them. Are they comfortable branching?
  - chrisandchris 6y ago
    I think it‘s less about version control and more about that the change is then associated with the employees name and if something ever goes wrong, it would be possible (easy?) to blame him therefore he‘s being scared about doing something because it could cause trouble for him somewhen in the future. And, imho, that goes back to not enough testing nd no safety nets to check for code errors (like code review, static analysis, ...).
    - 6y ago

jodrellblank 6y ago

> "the top performer's commits out number the second highest by 50% or more. [...] This might indicate some form of Pareto principle at play. Perhaps?" Price's Law? "50% of the work is done by the square root of the total number of people who participate in the work" -> "You are working on a team, and there are the superstars who do most of the work or seem to produce most of the outcomes and then there is everyone else." https://expressingthegeniuswithin.com/prices-law-and-how-it-applies-to-everything/ https://expressingthegeniuswithin.com/prices-law-and-how-it-...

yudlejoza 6y ago

> ... top performers ... highest count of commits and pull requests > ... define top performers as ... a go to person So circular logic. Got it. In a related story, why employed engineers have code contribution to the company that's way higher (actually infinitely higher) than those who are not in the company.

jfoutz 6y ago

I've worked with some amazing programmers that produce fabulous amounts of code. and, often, that's who you need. I have been envious of their prodigious production. I think, often, those folks solve problems by adding more code. I think, sometimes that mountain of code starts to become a liability. I'm a little better at reading a lot of code, consolidating, and fixing bugs. Importantly, fixing bugs without breaking other stuff (usually. coding is hard) if you buy the adage "make it work, make it right, make it fast", you'd probably buy that most people fall into one of those categories and excel (there are rare jewels that are amazing at all three. Carmack maybe is a good example). Anyway, I'm not a top performer. I have my moments of glory, and I think I deliver good value. I try to avoid git stats. I peek from time to time, and I'm super pleased that I've deleted about 2x the amount of code I've added but, that's maybe me protecting my ego. Everybody needs code, some people need code to be right, even fewer people need code to be fast. Different people bring different skills to the table. Be real careful about how those different aspects play into reaching goals.

andy_ppp 6y ago
Deleting code saves so much money for your organisation as it’s deleted for every person who touches the codebase! I don’t think this is ego protection at all, maybe the people who write shed loads of code are protecting their egos just a little.
op03 6y ago
It would help if people had more awareness of the personality spectrum in the population and the distribution of traits within a team. Not knowing leads to lot of misunderstandings. https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Temperament_and_Character_Inventory https://en.wikipedia.org/wiki/Temperament_and_Character_Inve... Different traits become strengths or weaknesses depending on the type of problem being solved. If the solution is known the disciplined/conscientiousness trait holders shine. If the solution is unknown the neurotic shines cause they dont methodically explore the search space (matters a lot if its large). If there is lot of conflict everyone loves the agreeable trait holder. And teams full of introverts get boring as people don't develop deep personal connections that extroverts enable etc etc etc

WalterBright 6y ago

One reason not mentioned (or maybe it's only me): If I've got bunch of problems, I'll work on the easiest ones first, saving the hardest for last. This clears my mind from the drag from the easier problems, and as a side effect I wind up committing more. There's no particular correlation between how hard a problem is to solve vs how much time it takes to solve them. So hit the easy ones first and make your users happy!

cryptica 6y ago

Wow, the premise of this article is very wrong; it's deeply concerning that people are falling for this. Those who make a lot of commits are not top performers, they are mostly engineers who are overly concerned with their 'optics'; they are engineers who are good at projecting themselves as 'top performers' but if you actually look at the results of their work a few years down the line, you will see that they are in fact low performers of the worst kind because they tend to add a lot of unnecessary complexity and technical debt because they don't think through things enough and just implement. I'm absolutely shocked to learn that people are falling for this.

atraac 6y ago
That's why there's 'most' in the title. Noone here assumes that more commits = better, but the article simply points out a correlation that MOST top performers, tend to have most git activity, and I see a similar thing in my professional experience. That doesn't mean I think that anyone with a lot of PR reviews or commits is better than other people...
- cryptica 6y ago
  I disagree with the 'most' premise as well. Totally a false signal. In my view, the opposite is true. The top performers tend to commit less. People who are genuinely passionate about coding don't tend to put that much effort into the more pedantic aspects of the process; they're more focused on big ideas such as the structurally important parts of the architecture. The developers who make a lot of commits are often more concerned with optics and they will argue for hours over unimportant tedium while sometimes missing the big very important ideas (the ones which will have real impact and flow-on effects for years to come). Basically they can't tell the distinction between what is important and what is not. They can't tell apart bureaucracy from value creation. Obsessive focus on commit size and other tedium is a key signal that someone doesn't know what is really important. They tend to be conventional thinkers (driven by peer pressure and peer approval) and their idea of productivity is distorted by false consensus (like the one this article attempts to instigate).
  - 6y ago

fxtentacle 6y ago

Because they are willing to take the risk of publicly being wrong. Committing your source code to the company git makes it very easy for others to point at you later, if things break. And it's pretty much impossible to undo once someone else has pulled your change. In my opinion, many top performers are simply people who do what needs to be done, and when it's needed.

bavuy 6y ago
These types often protect themselves and their clique with a CoC that effectively prohibits criticism from people who care about correctness and a lean code base.

m_rpn 6y ago

I hope that someday this "version control craze" will end, this perpetual race where everybody is urging to fire PRs to up his stauts in the team, this sensation that before being a good engineer you have to know git dark arts to the core, in order to rewrite "HISTORY", and amend each misdoing as you see fit. We need to remember what is our job: writing software that makes sense, not commiting code.

Mauricebranagh 6y ago
"version control craze" ! Really! version control is one of the big improvements to software development I have seen. Now if we could get the rest of the customer chain to start version controlling their requirement docs and properly minuting meetings and action points
- ryandrake 6y ago
  Version control is great as a productivity improvement tool and a way to organize contributions from multiple developers. It's not great when treated as a social network or productivity measuring tool. When you're firing off PRs to get your name up there again or to fill in your square on the calendar, you're kind of abusing the tool.
rendall 6y ago
I don't get this. Version control is essential. I've worked at places that didn't have it and it's absurdly unnecessarily unpleasant. If you really don't like git try Mercurial. I haven't worked with it in years but it was very easy to work with

dmpetrov 6y ago

In a mature project, the number of removed lines is a stronger proxy to productivities. It is related to the unavoidable tech debt that any project has and only the strongest people see it and work on it.

thrower123 6y ago

Because most people don't do anything at all. Even trying to do something puts you in the top half, even if it's poor quality, because a huge fraction of people are completely useless and don't ever do anything productive at all.

pwdisswordfish0 6y ago

The problem lies in the question. In the worst circumstances, it's indicating survivorship bias, and in the best circumstances the only truths it reveals are tautological. Using number of commits to measure productivity is the new version of thinking that the more number of lines of code that a programmer writes, the better. Not that this will stop a segment of the industry from flushing a non-trivial amount of resources down the drain learning this lesson, and inevitably leaving a chunk of stalwarts who never really learn anything. It was clear that was going to happen when the "social coding" site that everyone was flocking to put so much emphasis on activity measured in number of commits, forks, and other administrative details. Things which were only any good for advertising the site's own user engagement in its pre-IPO/-acquisition phase, and too many people mistaking it as a measurement of something else.

ndepoel 6y ago

The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, sloppy, riddled with issues and a nightmare to maintain. And it would inevitably fall upon us "lesser" performers to actually investigate and fix all those issues, making us look less productive in the process. In my opinion a better metric to quantify someone's performance is to count the amount of problems they solve vs. the amount of problems they create. I bet that many of the rockstar programmers out there would land on the negative side of that particular scale.

pydry 6y ago
Most problems are multi causal and if you have blame culture will degenerate into a litany of finger pointing.
- lucideer 6y ago
  I'm not sure what "blame culture" is, but any professional software team should ideally have some kind of "accountability culture". Whatever the fallout from people feeling "blamed" may be, attrition of all of your genuine programming talent due to tech-debt-machine peers being promoted ahead of them is not exactly an ideal outcome either. What's more, very often genuine potential in naturally talented new programmers can be stunted if they're rewarded for lazy faux "productivity". I've seen this: a programmer has a genuine interest and passion for quality, but loses it over time due to a focus on doing (different) work that gets them promoted. Code ownership (being required to "own" ones work along with the bugs & maintenance burden that come with it) is one of the most valuable ways programmers learn. This needs to be balanced, as one runs the risk of having a bus factor of 1, but it's still vital.
  - pydry 6y ago
    Blame culture is when bugs, downtime, etc. happen and people both look for somebody to blame and simultaneously look to exculpate their own behavior. It leads to CYA behavior, backstabbing and massive risk aversion. It can also lead to or be a result of a toxic work environment. In multi causal bugs it can lead to people downplaying causes which they had something to do with and exaggerating the effect that co-worker thry don't like had something to do with. This often leads to confused attribution and poor rectification of systemic issues - e.g. writing more unit tests even when more unit tests won't really help. "Accountability culture" sounds like it could be the same thing. Or not. I'm not really sure.

notacoward 6y ago

OP mentions three things: staging their work, velocity, and sense of agency/ownership. All three are problematic. Often those who have worked with a component the longest and/or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I've been one myself) it's simply easier to get commits in, not necessarily because you're better at the work but because of the role itself. You never have to re-work your commits to conform to someone else's idea of how things should work. People trust you, so reviews are often cursory. Many maintainers return that courtesy by subjecting others' work to excruciating review, slowing them down. Sometimes it's intentional, sometimes not, but the result's the same. Also, a maintainer often has many commits that started off as someone else's idea but that person didn't have the time or knowledge to complete them, so those are kind of low-hanging fruit that inflate the numbers. A mediocre maintainer will usually still have more commits than even the most talented non-maintainer. Calling them "top performers" because of something that's part of the role seems a bit circular. So much for velocity and ownership. As for the part about staging commits, I'd like to see some evidence. In my experience there's no difference, or sometimes the maintainers are even less likely to break up commits. This can be because maintainers are often charged with making commits with lots of internal dependencies that make them harder to break up, or because it's easy to get a stamp even on a questionable commit from people who are dependent on their goodwill to get their own commits in.

modernlearner 6y ago
It does sound from the article as if incumbents will always have a huge advantage and will be more likely to be labeled top performers.
temac 6y ago
OTOH I'm tired of people who don't "have the time or knowledge to complete [their ideas]". Ideas are cheap. Show me the code. Asking, explicitly or implicitly, for others to "implement/finish" their ideas is easy. I would even call never finishing / polishing anything very disrespectful: I'm not (should not be) here to cleanup after "talented" individuals. This is detrimental to my own "ideas." So at least, if not anything else, I better be recognized for the boring and tedious maintainership work I do and that talented people with their "ideas" refuse to perform...

exabrial 6y ago

The two top performers in my organization definitely don't have a lot of commits. Instead, I would say their strongest skill is written communication; in emails, log messages, code review comments, and chat messages.

AlanSE 6y ago

> If they find an issue along the way, they make a note of it and come back to fix it. Or they might fix in as they go. One consistent tension is that the old-hand developers have a "mental issue queue" that is enormous, but without fail, every time, they just can't be transferred. These can't be made into issues and farmed out to other people. Inconsistencies in the data model, for instance, might exist, but a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better. Once you've contributed enough of the main functions of a code base, you just never lack for something to do. All code is bad, because the business focus is on expansion of responsibilities over refinement of the existing ones. Those ghost issues are best communicated with a code change, at which all observers say WOW WHY DID WE NOT SEE THIS?! But the issue without the code change gets gawking blank stares. EDIT: but fixing unrelated issues as you go is bad, don't do it!

qes 6y ago
> old-hand developers have a "mental issue queue" that is enormous > a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better > Once you've contributed enough of the main functions of a code base, you just never lack for something to do. Hello, friend, I see we know each other well.

mumblemumble 6y ago

I suspect that it's nearly impossible to separate one's definition of a top performing developer from some sense of how often they commit. For better for for worse. I've worked on teams where I had colleagues who were incredibly deliberative. They would spend lots of time working with stakeholders to deeply understand their problems, and then produce elegant solutions that made their jobs drastically easier. Small changes with huge payoff. But management, and even most other team members, didn't recognize this. They just saw a slow programmer. Credit tended to go almost exclusively to other teams, when their members started using those tools to radically improve their own processes. The company's dev org largely didn't care about that effect, because it didn't positively influence their own KPIs.

deleted 6y ago
[deleted]

bumblebritches5 6y ago

...Because they work hard...

trident1000 6y ago

When you have a lot of commits you are working off yourself while everyone else needs to get caught up on what you did and then contribute after. Its essentially twice (or whatever) as much work as a laggard. It becomes 1 persons project and the others are observing. For better or worse because just running with something is often faster than deliberating at every turn. But also can backfire in many ways. Its similar to group projects in college.

pmayrgundter 6y ago

Old maxim: "If you want something done, give it to a busy person"

giantg2 6y ago

I was a top performer on my team in the past for a couple years. It was nice being an expert, but they never promoted me and were always playing games. I think it's better just be a average or below average person and not have to deal with the BS that comes with being a top performer. At this point in my career I doubt I'll ever make it back to that level of skill anyways.

rendall 6y ago
Why not?
- giantg2 6y ago
  Why won't I get back to that level? I have a kid, so I don't have any time to study outside of work or put in tons of extra hours. After years of being screwed over and passed over, I don't really have the drive/hope to get to that level since it wasn't rewarded the first time. Also, the work is very boring now and isn't transferrable to other groups or companies, so I don't have any interest in being an expert just to throw away that knowledge (like I was forced to do in the past).
  - rendall 6y ago
    > "... since it wasn't rewarded the first time" Our industry, unfortunately, doesn't promote from within. We almost always have to leave the company to another that is willing to give you a better title and salary.
    - giantg2 6y ago
      Yeah. My problem is that there aren't very many companies using FileNet or NeoXam.
      - rendall 6y ago
        Hmm. If they are important to the companies that use them, you may be in a good position to move, assuming that is also hard to find people experienced in those technologies

CydeWeys 6y ago

If you look at it from a slightly different viewpoint, there's nothing remotely surprising or controversial about this. You wouldn't be surprised to hear that the best factory workers tend to produce the most widgets per hour, or that the best butchers process the most meat per hour. Productive output is definitely highly correlated with job skill, almost tautologically so. Yes, a code commit isn't exactly the same thing as a widget, but it's similar enough in broad strokes to still be a useful measurement.

corpMaverick 6y ago

For me at least. I am the most productive when I can do many SMALL commits and able to push them to prod. You have to be able to make your change; either a refactoring or a functionality change and get it through the QA, review, deploy process. Now days I spent a lot of time, dealing with multiple branches and deployment environments and my productivity is in the floor. In a previous job I was able to deploy 2 or 3 changes a day in prod. It was very full filling.

corpMaverick 6y ago
Actually that seems to be one of main points of the blog post. Being able to stage their work.

Ozzie_osman 6y ago

There's a pretty subtle pitfall that teams can fall into here. Let's say a team has 2 developers. Josh is 20% "better" than the John, or simply started earlier and has more context on the code base. So initially, Josh is 20% faster, but now John has to spend an extra 20% of his time reviewing Josh's code in a pull request (or understanding Josh's code so he can make a change) instead of making forward progress. So now, actually John is even 20% less effective than he can be, and he has less time to actually code. And since he's even less productive, Josh has __more__ time to code, so he's even faster, which means he writes more code. It kind of compounds, and even an initial slight advantage in speed or context for one developer can amplify itself over time. A good engineering manager or senior engineer can detect when that's happening and try to correct the balance. But often the team kind of settles into a mode where Josh is known to be better and more productive and everything is funneled to him.

specialist 6y ago
Paraphrasing: Josh has the initiative, forcing John to react. -- In my experience, Josh is a firehose of chaos, doesn't test their own work, colors outside the lines. So in addition to John reviewing Josh's torrent of bs, John is always playing catchup, always has to do more rework. Further, it's not a balanced relationship. Josh creates urgency to fast track approval for their own PRs. Then will goal tend John's work. Pedantry over everything. Let PRs get stale, so John has to remerge, reseting the whole process. Insist the commits are "too big", "hard to understand", and therefore need to be broken up. Etc. Individual agility and velocity are evil, rewards dysfunctional behavior. If the whole team isn't committed to getting the whole team across the finish line, it's not a proper team. PS- Additional dysfunction if John is constitutionally incapable of refactoring, removing dead code, and other good citizenry.
datagram 6y ago
I've found myself in this sort of situation a lot, including on 2-person teams. While I'm pointing out all the bugs, maintability issues, etc. on their commit, they're busy writing a new commit full of the same types of issues. And on the flip size: because I self-review my code with the same attention, I rarely have any of those same sorts of issues in code that I make others review. I'm lucky in that my company recognizes and appreciates the quality that provide with my work and encourage from others, but I'm not sure of how to actually address the imbalance. Many times I've thought of just asking engineers to put more effort into self-reviewing their code, but I always feel like it would just be too rude.

jeffreyrogers 6y ago

Top performers do more work (generally, not always). This is contrary to the HN conventional wisdom that lines of code are a bad metric, and I see where those people are coming from. But generally people capable of writing more code faster are also capable of writing the right code.

nrmitchi 6y ago
> Top performers do more work (generally, not always). Yes, that is true by definition. What is not necessarily true is that all of that work involves writing code. > generally people capable of writing more code faster are also capable of writing the right code I disagree here though, and is highly dependent on what you consider to be "the right code". In my experience the people capable of writing more code faster are the people who don't necessarily take the step back and think "should this code even be written at all?".
- jeffreyrogers 6y ago
  Maybe, but I see speed as a proxy for ability. If all I know about someone is they can write code fast then I would bet on them being an above average programmer.

pizza234 6y ago

My theory: simply put, a large number of commits (without considering excess/cheating for the sake of themselves) can indicate lots of qualities of a good software engineer: order, planning, precision and capacity of partitioning a problem in smaller units.

msoad 6y ago

This is inline with my experience as well. I know it is the common wisdom to not measure performance with lines of code or number of commits. But in a large picture it's always the top performers that make the most commits. If I was a manager and asked to lay off X percent of the engineers, I would totally take into account number of commits among other signals.

zimbatm 6y ago

Once you are the top-committer in a project, you have the advantage. You know most of the code, even if it doesn't have tests. It's easy to figure out where reported bugs are, that you have introduced. Meanwhile, the rest of the team is busy reviewing your code and rebasing their PRs. I have seen this pattern so many times. It'a a good strategy to be recognized by management. Also what happens when the top-committer leaves, suddenly the rest of the team can breath and flourish.

seahawks78 6y ago

Could not disagree more. The article's main argument is wrong and dangerous to an extent! A software engineer's productivity depends on the quality of his thinking that goes on between his two ears - not on the number of lines of code (LOC), number of commits and some other meaningless measure. I don't think the author knows/understands what it takes to operate at a Senior/Staff level and beyond. Yeah, may be for someone just out of school productivity can be measured in terms of lines of code. OTOH, if a Principle Engineer in the team comes to me and says that he feels great just because he added 500 commits/30k lines of new code to the code base I will just say one thing: "run for your life"! as soon as possible.

jyriand 6y ago
It's not really constructive to start your comment with a "utter piece of crap".
- seahawks78 6y ago
  Since this comment was downvoted let me elaborate this with a personal experience (of course it is anecdotal). In June of this year, my entire team was struggling after moving to a new Kafka cluster because of low throughout in one of the backend services (about 250k/min with approx 32 instances). This was causing issues for our downstream dependencies as we were not able to reply back within one hour of consuming the record from upstream and our L2 support was daily getting numerous pages which were also escalating to us. Then my manager asked me to take a look at what is going on and if we can improve the throughput somehow. After almost spending one week of banging my head against different theories and tons of experiments in QA I finally figured out that the new Kafka client we were using had a setting where it required acks from all brokers (which has increased to 5 in the new cluster from 3 in previous one) and this caused a huge increase in the blocking time even though we were using an Async framework. The async task just waited too long for completion and once completed could not get the threadpool back due competition with other threads. Solution: simple, I just changed the Kafka producer ack from "ALL" to "ONE" requiring acknowledgement from one broker only. Throughput with same 32 instance jumped from 250k/min to around 700k. I ask the intelligent readers of HN - do you think that based on this I should be penalized since the change was only in one line of config code? Yes, that's all what it took to resolve this outstanding issue - one line of config change/one commit albeit one week of thinking and experimenting time!

dathinab 6y ago

One important point missed: - Top performers tend to be motivated. - Just because someone is a "top performer" in one project/team/company doesn't mean this person will be one in another project/team/company. Reasons can be manifold, motivation can play a big role between someone being a good and someone being a top performer.

ram_rar 6y ago

Top performers are motivated and do more work. But that does not necessarily translate into real progress. If you shit the bed and clean it up, its not real progress. Unfortunately, management doesnt see that way. I wont consider myself a top performer. But I have my moments of glory. Most of my impactful commits were deleting unwanted code and needless libraries in the codebase.

colinrand 6y ago

Another interesting characteristic I've seen over the years from top performers is that they also have deleted the most code.

m3kw9 6y ago

Quality is usually how fast they can complete features with least bugs for a faster release while navigating feature changes they go. That’s where rubber hits the road.

WesolyKubeczek 6y ago

I worked once on a piece of software to track construction projects. The CEO was always grumbling about the pace of development, citing the example of programmers who added Gantt charts to it in two days, and why was I so much slower at “simpler” features. Fast forward a couple of months, and we had a customer complain about the Gantt charts being off. I had a closer look at the thing, and it turned out that the bars on the chart had been drawn using the Math.random() function. They came out different each time you refreshed the page and were in no way related to the real thing.

jl2718 6y ago

I’m trying to understand the DevOps of this concept. Is everybody working in the same repo, or are these personal forks that get hammered until nice merged PRs can be submitted? Do devs complete whole features before submitting, or do they submit partial work that everybody else is trying to contribute to? Are multiple developers working on the same code modules, or have they been split out? Are there tests and interfaces written ahead of time, or do they do tasking by prose? The goal of software management is to keep everybody productive. If you have an imbalance in commits or pull requests in the main repo/branch, that’s a strong sign of a broken process. Tasks should be given according to familiarity and skill so this doesn’t happen. This also says something about software design. Good design is easy to split up. Bad design requires a ‘go to’ person. Therefore, a ‘go to’ person is by definition not a good software engineer, because their design was bad, and/or they never fixed it. And if it worked the first time, you wouldn’t have to ‘go to’ anybody. The skill ladder of software engineering goes something like: watching, practicing, contributing, designing, teaching, leading. Every developer goes through this process from scratch in every project. Getting stuck is a problem (as is skipping steps). Preventing other people from progressing is a bigger problem. Perhaps rethink this.

juancn 6y ago

That's plainly not true. There are top performers that do not produce the largest number of commits and PRs. They produces the most difficult ones to get right. There are mediocre performers that produces an awful lot of commits and PRs, confusing volume with substance.