Comments on: A Non-Uniform Work Distribution Yeah, my feeling is that commit frequency is mostly a matter of work style than anything else (see my comment above). I'm planning to take svn revision 65536 now. Just hope we won't switch to hg before that... there getting big round SHA1 hashes (which are revision identifiers) is much harder! Yeah, my feeling is that commit frequency is mostly a matter of work style than anything else (see my comment above).

I’m planning to take svn revision 65536 now. Just hope we won’t switch to hg before that… there getting big round SHA1 hashes (which are revision identifiers) is much harder!

]]>
By: Aras Pranckevičius/2011/02/16/a-non-uniform-work-distribution/#comment-889 Aras Pranckevičius Sun, 20 Feb 2011 13:33:20 +0000 About source control commits count: it all depends on your project and programming team type of work. Are you building technology for off-team clients with who you have reduced communication? I'm not, and I believe that one form of successful games are built from shared code ownership, iterating smoothly and organically, and using continuous integration methodologies. Those naturally lead to high-commit count. I am one of those people committing a lot. I'm not suggesting my work is better, etc.(and I have my share of being involved in bad breakage) but if you see software as a rapidly and continuously evolving thing there is no harm committing a lot. I would even go as far as hinting that the side-effect of breaking things for others helps sharing knowledge and responsibility about a code-base. But this has to be agreed on with the team else you would just appear as a wreck-less beast. Now I understand that if you are doing research or implementing feature X into a widely-used tech you are likely to have weeks or month-spaced commits. @aras_p: As it happens last week I committed r32768 into our code-base with a useless change and log entry saying "2^15". #pointlessmilestone About source control commits count: it all depends on your project and programming team type of work.
Are you building technology for off-team clients with who you have reduced communication?

I’m not, and I believe that one form of successful games are built from shared code ownership, iterating smoothly and organically, and using continuous integration methodologies. Those naturally lead to high-commit count.

I am one of those people committing a lot. I’m not suggesting my work is better, etc.(and I have my share of being involved in bad breakage) but if you see software as a rapidly and continuously evolving thing there is no harm committing a lot. I would even go as far as hinting that the side-effect of breaking things for others helps sharing knowledge and responsibility about a code-base. But this has to be agreed on with the team else you would just appear as a wreck-less beast.

Now I understand that if you are doing research or implementing feature X into a widely-used tech you are likely to have weeks or month-spaced commits.

@aras_p: As it happens last week I committed r32768 into our code-base with a useless change and log entry saying “2^15″. #pointlessmilestone

]]>
By: James Podesta/2011/02/16/a-non-uniform-work-distribution/#comment-848 James Podesta Fri, 18 Feb 2011 01:45:36 +0000 I love the idea of programmer productivity metrics. I don't have any easy rules of thumb. Source control submits and bug fixes are two metrics which really show the difference between a naive interpretation of the data and a more in depth one. For example, having a high number of source control submits may look good at first glance. But if they're all submits to the same file, or fixes for compile breakages, they mean just the opposite. Generally I'll say that people who submit less frequently are less productive, and those at the edges of the bell curve may both submit more frequently but the quality of each change is way, way different. Naively, I can say bug re-opens are a strong negative indicator of programmer productivity. I love the idea of programmer productivity metrics. I don’t have any easy rules of thumb. Source control submits and bug fixes are two metrics which really show the difference between a naive interpretation of the data and a more in depth one.

For example, having a high number of source control submits may look good at first glance. But if they’re all submits to the same file, or fixes for compile breakages, they mean just the opposite. Generally I’ll say that people who submit less frequently are less productive, and those at the edges of the bell curve may both submit more frequently but the quality of each change is way, way different.

Naively, I can say bug re-opens are a strong negative indicator of programmer productivity.

]]>
By: Rytis/2011/02/16/a-non-uniform-work-distribution/#comment-833 Rytis Wed, 16 Feb 2011 17:04:58 +0000 You are not alone in this :) I've had a very good friend tell me, a long time ago, that working with me was intimidating in terms of speed and even though he felt he hadn't beeen doing anything wrong he'd been feeling he couldnt keep up and was very unhappy. I've also had people tell me - "why should I struggle with this for hours when you can do it in 10 minutes" - of course the answer here is "so you can learn" but the bottom line is people get upset on both sides.While you think you are working fast and doing most of the work which you may think is unfair at the same time people who can't keep up get demotivated by that. We are assuming here everyone want's to do well :) Then awhile back I had started allocating certain type and scope of tasks according to people's speed of work and their skill. But then I got pulled by one of my better programmers who asked me why person X was getting all the easy work and when I explained he asked to be paid a lot more more or get equal ammount of "easy work" - which is fair, right? But I guess I was looking for easy way out to keep everyone happy then. The main problem here stems from the fact that as a lead I want to deliver good product, good code, etc... and I allocate the tasks in a manner that will produce the best possible product. This will yeild best result short term but wont show me who can't cope and I wont encounter many "you are late on your work" or "your work is below par let's see how it can be improved" conversations but the people who end up doing most of the work are probably quietly unhappy that they are carrying the weight. On other hand if everyone got equal share of the work but some people can't cope then I end up with occasional bad results (which reflects bad on me as a lead) and more "conversations" as culprits of bad results are addressed - not a nice experience but arguably that's the more fair way to handle it, right? I feel like I've added more questions than asnwers too. You are not alone in this :)

I’ve had a very good friend tell me, a long time ago, that working with me was intimidating in terms of speed and even though he felt he hadn’t beeen doing anything wrong he’d been feeling he couldnt keep up and was very unhappy. I’ve also had people tell me – “why should I struggle with this for hours when you can do it in 10 minutes” – of course the answer here is “so you can learn” but the bottom line is people get upset on both sides.While you think you are working fast and doing most of the work which you may think is unfair at the same time people who can’t keep up get demotivated by that. We are assuming here everyone want’s to do well :)

Then awhile back I had started allocating certain type and scope of tasks according to people’s speed of work and their skill. But then I got pulled by one of my better programmers who asked me why person X was getting all the easy work and when I explained he asked to be paid a lot more more or get equal ammount of “easy work” – which is fair, right? But I guess I was looking for easy way out to keep everyone happy then.

The main problem here stems from the fact that as a lead I want to deliver good product, good code, etc… and I allocate the tasks in a manner that will produce the best possible product. This will yeild best result short term but wont show me who can’t cope and I wont encounter many “you are late on your work” or “your work is below par let’s see how it can be improved” conversations but the people who end up doing most of the work are probably quietly unhappy that they are carrying the weight. On other hand if everyone got equal share of the work but some people can’t cope then I end up with occasional bad results (which reflects bad on me as a lead) and more “conversations” as culprits of bad results are addressed – not a nice experience but arguably that’s the more fair way to handle it, right?

I feel like I’ve added more questions than asnwers too.

]]>