7 ms·

> At least 1 commit / hour Such a vanity metric for productivity is a red flag, reminds me of the old school horror stories of managers so out of touch with so

by ac2u 11y ago

> At least 1 commit / hour Such a vanity metric for productivity is a red flag, reminds me of the old school horror stories of managers so out of touch with software development that they recorded Lines of Code counts as a means of measuring performance. Curious as to the reasoning.

L8D 11y ago
Do the people who think like seriously imagine that this is something reasonable and expectable, and not totally subjective to the style and habits of individual developers? I'm always baffled by managers or business people who seem to think quantification of productivity is easy. They must be incredibly lazy to not want to invest themselves in understanding what their developers are doing to gauge productivity themselves. Is this a sign of horrible management, or at least, as you say it, management that has become horribly out of touch with their developers?
aheilbut 11y ago
This is a company making a device for Pavlovian conditioning.. Remember, you'll get zapped if you don't make that commit on time!
- ac2u 11y ago
  Ha, would be funny if the internal setup were like that. I wouldn't be too quick to assume bad faith on the companies part though. Sometimes agile companies have these vanity metrics as a proxy to keep their development environments and processes in check. (ie: are things set up well enough with a fast test suite so that developers are comfortable committing/pushing/deploying frequently with confidence?) That's why I phrased it as a query as to the reasoning behind the metric as it could be easily read as the company using a poor performance metric.
  - dvanduzer 11y ago
    For a lot of companies, it's important to signal that they're even thinking about something. Like whether a new hire feels like they've contributed anything during the onboarding period.
- reinhardt 11y ago
  GIT_COMMITTER_DATE='$BOGUS_DATE' GIT_AUTHOR_DATE='$BOGUS_DATE' git commit is your friend ;)
hesdeadjim 11y ago
Also find this hilarious in context with the other line that says "Maintain high output while pairing with junior teammates." I also greatly appreciate knowing when a role will involve pairing so I can steer clear of it. There are way more empowering ways to skill up junior programmers that don't involve wasting both engineers' time. Assign an achievable but not insignificant task, have a code review system set up, and have them frequently post reviews while they build their solution. The senior engineer can then do the whole mentor thing asynchronously and in response to actual issues the junior has, while the junior is then also allowed to make mistakes, struggle, and overcome issues him/herself.
- jacques_chester 11y ago
  My experience is very different from yours. I've been spoilt by pairing, I no longer prefer to work solo. I've also seen organisations trying to substitute asynchronous code reviews for pairing. They aren't really substitutable. Just as pairing has antipatterns, so do code review systems. As an analogy, I've coached olympic-style weightlifting. The difference between coaching in person and coaching online is night and day. And coaching beginners pretty much demands fast feedback to be most effective.
  - p4wnc6 11y ago
    Performing the task of weightlifting is incredibly different than performing the task of programming. Much evidence suggests that programmers perform better solo because they can more easily reach states of psychological flow, and because they are less inhibited by social interactions which modulate certain parts of our thinking and can inhibit creativity, etc. At the very least, this is more highly true of introverted personality styles, and creating mandates for policies like pair programming is extremely insensitive (almost to a point of blatant discrimination) towards people with differing personality and learning styles. For me personally, I can't learn anything from other people saying stuff about it audibly. I have to read documentation or code. I am the weirdo who actually reads my car's maintenance manual to figure out how to change spark plugs or use the jack to lift the car when replacing a tire. Someone can tell me how to change a tire all day long and it just doesn't help at all. I even played quarterback on my high school football team and even at that I had to actually read books and biomechanics papers about the throwing motion before I really improved. I went to football camps and everything and it just did no good. For me, I really only absorb information when I literally tune out all audio (especially the sound of people talking) and read. I suppose I serve as something of a counter-example, then. Just because beginners in weightlifting (or any given activity) benefit most from fast, in-person feedback does not at all mean that beginners in some other activity (like programming) will also benefit from that kind of feedback. I've also worked in high pair-programming environments, in one case with a group of other experienced, extremely talented engineers, and in another case with a larger number of average to mediocre engineers. In both cases, across the board, pairing slowed us down and led to worker dissatisfaction. The few times when pairing came in handy were those cases when a person needed to begin working on a section of code or a subsystem that someone else had explicit experience with. Then, pairing them briefly (for, say, half a day) to force the novice to get up to speed quickly and have an "oracle" nearby was really helpful, but after about the 4 hour mark it just started slowing both people down, caused the novice to learn too slowly, and focused hyper amounts of attention on issues that wouldn't have needed to be brought up if the novice instead focused on solving their own problems and boiling down their issue list into a smaller, asynchronous list of just the most urgent needs. And, truly, the only reason that those first four or so hours of pairing worked at all is that the documentation for the code was poor. If the exact questions and answers that were discussed during pairing had instead been turned into an internal StackOverflow and/or an internal quick start guide, it would have helped far more people get up to speed far more quickly than pairing, while only costing the senior dev a single up front cost. Pairing is the definition of an activity that doesn't scale, and is arguably less beneficial than well written user guides + StackOverflow-like tools that allow for documenting the learning process.
brianmcconnell 11y ago
Agree 100%. Avoid.
maneesh 11y ago
Note the 1 commit per hour is just for the first 14 days. We do that so new devs just know how to use our system and get coordinated in our system. The commits don't always need to have major changes, and often is always branched for the user.
vonmoltke 11y ago
"Old" horror stories? you must not have worked for a large defense contractor lately. :P

by ac2u 11y ago

L8D 11y ago

Do the people who think like seriously imagine that this is something reasonable and expectable, and not totally subjective to the style and habits of individual developers? I'm always baffled by managers or business people who seem to think quantification of productivity is easy. They must be incredibly lazy to not want to invest themselves in understanding what their developers are doing to gauge productivity themselves. Is this a sign of horrible management, or at least, as you say it, management that has become horribly out of touch with their developers?

aheilbut 11y ago

This is a company making a device for Pavlovian conditioning.. Remember, you'll get zapped if you don't make that commit on time!

ac2u 11y ago
Ha, would be funny if the internal setup were like that. I wouldn't be too quick to assume bad faith on the companies part though. Sometimes agile companies have these vanity metrics as a proxy to keep their development environments and processes in check. (ie: are things set up well enough with a fast test suite so that developers are comfortable committing/pushing/deploying frequently with confidence?) That's why I phrased it as a query as to the reasoning behind the metric as it could be easily read as the company using a poor performance metric.
- dvanduzer 11y ago
  For a lot of companies, it's important to signal that they're even thinking about something. Like whether a new hire feels like they've contributed anything during the onboarding period.
reinhardt 11y ago
GIT_COMMITTER_DATE='$BOGUS_DATE' GIT_AUTHOR_DATE='$BOGUS_DATE' git commit is your friend ;)

hesdeadjim 11y ago

Also find this hilarious in context with the other line that says "Maintain high output while pairing with junior teammates." I also greatly appreciate knowing when a role will involve pairing so I can steer clear of it. There are way more empowering ways to skill up junior programmers that don't involve wasting both engineers' time. Assign an achievable but not insignificant task, have a code review system set up, and have them frequently post reviews while they build their solution. The senior engineer can then do the whole mentor thing asynchronously and in response to actual issues the junior has, while the junior is then also allowed to make mistakes, struggle, and overcome issues him/herself.

jacques_chester 11y ago
My experience is very different from yours. I've been spoilt by pairing, I no longer prefer to work solo. I've also seen organisations trying to substitute asynchronous code reviews for pairing. They aren't really substitutable. Just as pairing has antipatterns, so do code review systems. As an analogy, I've coached olympic-style weightlifting. The difference between coaching in person and coaching online is night and day. And coaching beginners pretty much demands fast feedback to be most effective.
- p4wnc6 11y ago
  Performing the task of weightlifting is incredibly different than performing the task of programming. Much evidence suggests that programmers perform better solo because they can more easily reach states of psychological flow, and because they are less inhibited by social interactions which modulate certain parts of our thinking and can inhibit creativity, etc. At the very least, this is more highly true of introverted personality styles, and creating mandates for policies like pair programming is extremely insensitive (almost to a point of blatant discrimination) towards people with differing personality and learning styles. For me personally, I can't learn anything from other people saying stuff about it audibly. I have to read documentation or code. I am the weirdo who actually reads my car's maintenance manual to figure out how to change spark plugs or use the jack to lift the car when replacing a tire. Someone can tell me how to change a tire all day long and it just doesn't help at all. I even played quarterback on my high school football team and even at that I had to actually read books and biomechanics papers about the throwing motion before I really improved. I went to football camps and everything and it just did no good. For me, I really only absorb information when I literally tune out all audio (especially the sound of people talking) and read. I suppose I serve as something of a counter-example, then. Just because beginners in weightlifting (or any given activity) benefit most from fast, in-person feedback does not at all mean that beginners in some other activity (like programming) will also benefit from that kind of feedback. I've also worked in high pair-programming environments, in one case with a group of other experienced, extremely talented engineers, and in another case with a larger number of average to mediocre engineers. In both cases, across the board, pairing slowed us down and led to worker dissatisfaction. The few times when pairing came in handy were those cases when a person needed to begin working on a section of code or a subsystem that someone else had explicit experience with. Then, pairing them briefly (for, say, half a day) to force the novice to get up to speed quickly and have an "oracle" nearby was really helpful, but after about the 4 hour mark it just started slowing both people down, caused the novice to learn too slowly, and focused hyper amounts of attention on issues that wouldn't have needed to be brought up if the novice instead focused on solving their own problems and boiling down their issue list into a smaller, asynchronous list of just the most urgent needs. And, truly, the only reason that those first four or so hours of pairing worked at all is that the documentation for the code was poor. If the exact questions and answers that were discussed during pairing had instead been turned into an internal StackOverflow and/or an internal quick start guide, it would have helped far more people get up to speed far more quickly than pairing, while only costing the senior dev a single up front cost. Pairing is the definition of an activity that doesn't scale, and is arguably less beneficial than well written user guides + StackOverflow-like tools that allow for documenting the learning process.

brianmcconnell 11y ago

Agree 100%. Avoid.

maneesh 11y ago

Note the 1 commit per hour is just for the first 14 days. We do that so new devs just know how to use our system and get coordinated in our system. The commits don't always need to have major changes, and often is always branched for the user.

vonmoltke 11y ago

"Old" horror stories? you must not have worked for a large defense contractor lately. :P