Mixing
Is it a good idea to mention number of git commits in performance review?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
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.
performance-reviews
suggest improvements |Â
up vote
0
down vote
favorite
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.
performance-reviews
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
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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.
performance-reviews
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.
performance-reviews
asked Feb 20 '15 at 8:59
user32773
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
suggest improvements |Â
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
4
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
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
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
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
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
@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
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
suggest improvements |Â
4 Answers
4
active
oldest
votes
up vote
6
down vote
accepted
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.
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
suggest improvements |Â
up vote
7
down vote
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.
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
suggest improvements |Â
up vote
0
down vote
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.
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
suggest improvements |Â
up vote
-1
down vote
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.
answered Feb 22 '15 at 12:55
jgmjgm
23124
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
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.
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
suggest improvements |Â
up vote
6
down vote
accepted
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.
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
suggest improvements |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
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.
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
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.
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
answered Feb 20 '15 at 9:25
Julia Hayward
12k53438
12k53438
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
suggest improvements |Â
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
It also doesn't say much about the amount of work done.
– gnasher729
Dec 23 '15 at 23:04
suggest improvements |Â
up vote
7
down vote
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.
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
suggest improvements |Â
up vote
7
down vote
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.
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
suggest improvements |Â
up vote
7
down vote
up vote
7
down vote
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.
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
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.
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
answered Feb 20 '15 at 10:32
The Wandering Dev Manager
29.8k956107
29.8k956107
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
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.
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
suggest improvements |Â
up vote
0
down vote
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.
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
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.
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
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.
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
answered Feb 20 '15 at 9:24
nvoigt
42.6k18105147
42.6k18105147
suggest improvements |Â
suggest improvements |Â
up vote
-1
down vote
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.
answered Feb 22 '15 at 12:55
jgmjgm
23124
suggest improvements |Â
up vote
-1
down vote
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.
answered Feb 22 '15 at 12:55
jgmjgm
23124
suggest improvements |Â
up vote
-1
down vote
up vote
-1
down vote
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.
answered Feb 22 '15 at 12:55
jgmjgm
23124
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.
answered Feb 22 '15 at 12:55
jgmjgm
23124
answered Feb 22 '15 at 12:55
jgmjgm
23124
answered Feb 22 '15 at 12:55
jgmjgm
23124
answered Feb 22 '15 at 12:55
jgmjgm
23124
23124
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f41692%2fis-it-a-good-idea-to-mention-number-of-git-commits-in-performance-review%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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