67
JPRBM
2y

Got together with my old dev team (5) who all left the same company at the same time almost two years ago. (Thats a whole other story).

One of them told us he left and went to a new company that measured performance by the amount of commits a dev would to per day. Of course he didn't know that when he signed on.

Three months into the job he had a week where his first commit wasn't until a wednesday and he got called in by the manager to explain his lack of commits and how he was going to improve.

He quit on the spot. Had a new job in less than a week.

Other devs at the company were fixing typo's and just commiting them one at a time to create a lot of commits.

Comments
  • 10
    Nice
  • 7
  • 28
    maybe make a script that commits one line at a time. Then work 2h per week.
  • 5
    I added a team policy to commit code every day, in case they wrote some.
    Losing a month of work when someone spills coffee on thier laptop is not an option.
  • 13
    I legit have a hard time believing stuff like this.
  • 6
    Read about this similar practice back in the 70s at Xerox or IBM maybe? Coders got their performance rated by how many KLOC (1000 lines of code) they wrote. Manager seemed to grab onto that because it seems easy to measure, says nothing about code quality though
  • 3
    @knuppelsmurf people don't even write for loops they just copy the code hundreds of times
  • 0
    @iSwimInTheC Yep, thats what happens. Optimized for money instead of readability or maintainability
  • 0
    Not having issues with committing regularly. When the part of the work is meaningful, you should commit it.

    That's my take but not applying it everywhere.

    But measuring by how much commits I make is ridiculous! There's script for that that commits to the repo automatically.

    Garbage job has garbage metrics!
  • 0
    I think it'll actually make sense to have something like etherpad built into the IDEs so you don't lose code but don't have to commit just to save something.
Add Comment