I'm having a performance review soon with my manager. Would it be a good idea to mention the number of commits I've made since started working here?

I know that the number usually doesn't say much because it doesn't say much about the quality and some people might make a lot of small commits while others make few big ones. But the reason I'm wondering is that I've started working on a really old project (more than 10 years old) and during about a half year I've made about as many as some developers who have been working on the projects for a couple of years.

Of course, I'm only mean to mention it casually and not as a main point.

  • 4
    The number of git commits, or lines of code, is not in any way a good indicator of your performance. You could mention how few bugs you've produced and had to fix as a result of your commits. – James Feb 20 '15 at 9:46
  • I hate it when a cmm guy or some other standard guy comes and tries to tie GIT to a specific parameter ...there should be one push or only x number of commit...tomorrow they will also ask that your IDE should have following setting...we are programmer not a assembly line – amar Feb 20 '15 at 10:36
  • 1
    If you think # of git commits is important, you could start doing a commit every time you make any small change, just to try and get a high commit count. But then, that would be a waste of time unless you already like doing lots of commits. If I'm working in a project with a Git repo I tend to commit a lot more often compared with an SVN repo for example, but that's just because it's faster to do it in Git. But obviously it's what's in the commits that counts, not the number of them. – Brandin Feb 20 '15 at 16:22
  • @Brandin why wait for small changes. Commit some garbage and then you need another commit to remove the garbage. Rinse and repeat. Every other commit also counts as a bug fix. – emory Feb 21 '15 at 19:09
  • I can easily double or triple the number of git commits without any increase of productivity (actually, a tiny decrease). So why would that number give any information for a performance review? – gnasher729 Feb 22 '15 at 13:16

No, it wouldn't be a good idea. And you give the reason: "the number usually doesn't say much because it doesn't say much about the quality".

Reading between the lines, you feel you need to convince your manager you're doing a better job than your colleagues. From his point of view, that correlates to the value of what you produce for the team and the business as a whole. So you need to show the ways in which you create value, not quote metrics that could be gamed.

| improve this answer | |
  • It also doesn't say much about the amount of work done. – gnasher729 Dec 23 '15 at 23:04

No the number of commits is irrelevant AND dangerous. If it counted, Ted over there would start doing 20 commits a day (for every line of code he writes in a day) and would be the superstar by that metric.

Commits/velocity DON'T count to how useful you are (I had to bring up a teams velocity once, we just multiplied all the estimate points by 10, we were instantly 10x as productive), it's about what you have improved.

So if you mention something it should be:

  • Details of the actual improvements to the 10 yr old code and why they are better (resiliency/performance/maintainability/re-usability)
  • Details of improvements you made to the performance of yourself and the others in the team (processes/ideas/better ways of working)
  • Details of where you've brought something new into the company/team or done something that's saved the company money/increased revenue
  • Where you've gone the extra mile for customers/brought in new business by being great/kept the customer happy

Mention these things and you'll deserve to get more money/responsibility/opportunities etc, if the best you can say is "I made more commits than anyone else", I'd say you're struggling to justify your role.

| improve this answer | |

It depends. Does the Git commits say anything about the value you are generating for the company? In other words, is it better for the company to have 100 small commits instead of 10 large ones? Is that measurable or just a gut feeling? I think you could sit in a cubicle and commit the same line of comment for days without generating value, so the plain number of commits says nothing.

Personally, I think you should come up with something more aligned to the business. Did you close tickets? Work on open issues? Satisfied customers by fixing bugs? Did you help other people with their code? How many problems did you solve for the company? That's what is interesting.

| improve this answer | |

Sometimes it can be a valid figure and sometimes not. It depend on the circumstances. However even if it is in this situation you want to be careful not to set any precedent. A precedent of measuring by commits or LOC can create a lot of spam that will harm the codebase.

Performance comparisons need to be multi-factor and if it's appropriate to include git commits in that then I would say go ahead but if that is your sole measure it wont work out for the best. Measuring LOC per commit would be more useful and comparing average cases for code quality would be fairer. However LOC is not brilliant either because of library inclusions and bloat code (I have seen people commit 100 lines of code for something that could be 10 lines of code).

If you do want to use it, make sure it's valid to do so but the primary focus should be the points raise above. I think in this case the hardest thing to measure is code quality. For example is your code more maintainable, stable, bug free, fast and does it potentially cater to more future business requirements. For that the only thing you can do is have another expert (objective) take a look and back you up because managers are not technical. You may need a technical jury.

| improve this answer | |

You must log in to answer this question.