22
deadPix3l
65d

Am I the only one who doesn't judge a programmers contributions by commits or change history?

Frequently I'm always near the bottom of contributors, because I don't make a million commits when it's broken. And I don't commit lines that will likely disappear in later commits. I like to finish a function, test it, check it, rework, and then make a "made function()" commit, as apposed to:

"Wrote function()"
"Wrote unit tests for function()"
"Fixed error"
"Code cleanup"
"Style guide compliance"
"Reworked function()"
etc.

Sorry that I keep my commit history clean and ensure it builds.

Comments
  • 2
    Yeah, thats annoying. But at least it's better than having them write no tests, have no style guide compliance, and no comments.
  • 3
    @gitreflog I agree. I'm glad they do all those things, but they don't see all the hundred of lines that I write, rework and eventually remove to make this beautiful, elegant 5 line function. And then have the audacity to say things like "keep up" or "well if you contributed more, I mean just look at the differences in the graph" like commiting broken, untested code filled with "//TODO:" some how makes them more useful and dedicated.
  • 2
    Same here. I squash my commits when I feel something should be in a single commit
  • 4
    When I was a young developer, I would ask the developers I looked up to, how many lines of code they wrote in a day... A few years later I would ask how many lines of code they eliminated.

    Now I just ask to watch them work.

    You can't use metrics to understand the real value of a developer.
  • 2
    This is a recurring theme where people are asking how to analyse developer performance.

    I am yet to find a suggestion that accurately represents one's contribution to a project.
  • 1
    Dunno, if you're commiting on some short lived feature branch, it shouldn't really matter that much, since it will get merged anyways.

    I think sometimes it's just not possible to to nail everything in the first go. I'd rather commit something roughly made, than delay it until it's finished.

    When I was trying to push only completed stuff, I've noticed I ended up with too much local changes.

    Again, I'm talking about short lived branches.

    This is my current opinion, please correct me if I live in a lie.
  • 0
    Baby steps commits have a reason: track the developer activity and help the team to learn about the workflow style of each dev, IMHO.

    It's obvious that some tasks don't require a profound level of commit details, but it's better than one single commit with multiple tasks/responsabilities.

    Some years from now, other devs that don't even has the actual culture of your team anymore can understand so much by one commits that I can't standing by your side in that mindset.

    Yes, most of the times I think like you, I hate messed histories and stuff, but in the end it's for the best. I expect to improve in that matter soon, because my team will only grow with that.
Your Job Suck?
Get a Better Job
Add Comment