5 ms·

In the late aughts, I became lead developer of a team that had never done any sort of version control. Just nightly backups of a shared SMB server. I wanted to

by donatj 2y ago

In the late aughts, I became lead developer of a team that had never done any sort of version control. Just nightly backups of a shared SMB server. I wanted to get everyone using git, but getting people to actually bother committing their work was like pulling teeth. I built a "git leaderboard" showing how many commits each developer had made that week. It didn't really help and it sure didn't make them resent me any less.

gardenhedge 2y ago
Some things need management to run and say "do this, or else". If you don't have that weight behind your words good luck getting any big changes done.
- donatj 2y ago
  I was ill suited to be manager in hindsight. I am a good developer, I am not great with people. I wanted it because it seemed like the next logical step in career progression but I was not good at managing people. I am very glad I left. I have spoken on here before about how it gave me stress induced health issues.
  - gardenhedge 2y ago
    Were you a lead or a manager? Did you take a salary cut?
    - donatj 2y ago
      Both? I was in charge of our codebase as well as managing our developers. Is that not how it always is? Everywhere I have worked "Lead Developer" has been a management position, such that your team reports to you. No, it was actually a pretty significant pay increase. I went from a very small company to a larger one.
eesmith 2y ago
About the same time, I looked to see if there was any research on the effectiveness of a version control system like git vs. other methods of versioning (like VMS-style numbered versions, or backup/snapshotted file systems with a temporal browser). I found nothing. FWIW, "git leaderboard" is trivially gamed. Not only with pointless auto-commits, but some people commit every few lines while others commit only when things are in a good shape. What you ended up doing was introducing the same sort of resentment as factory workers under Taylorism and observations from the time-and-motion man. Had our schools taught more about the history of labor rights and struggles, and perhaps less of the success of industrial oligarchs, then perhaps you would have been more likely to expect that resentment and not tried it in the first place.
- donatj 2y ago
  > trivially gamed Eh, there were no rewards, so no real incentive to win. The idea was just more to get the act of committing their code into their minds. Like "oh hey, everyone can see I'm at zero, maybe I should commit my work". This was something I tried after months of poking people to commit their work. I'd put together a whole training on what git is and why we should be using it. It came up every weekly meeting. I was grasping at straws.
  - eesmith 2y ago
    Then no real inventive to lose, so no real incentive to switch, so no real incentive to care about a scoreboard, while making those who might test the waters subject to possible public ridicule. What do you think the advantage is to 1) using a version control system, and 2) using git, in the aughts? Version control systems have been around since at least the 1970s (dating from SCCS), so 30 years before your experience. My group was using RCS in 1993. Which means the people you were trying to convince almost certainly know about the concept and possibility before you tried to persuade them. Frequent backups of a shared file system is a form of versioning. VMS-file filenames.txt;001 is a form of versioning. Moving projects into new directories is a form of versioning. None of them require any special training to get started, and the latter two let you use any normal tools to view and compare different versions of the file. Some places had conventions about who was allowed to modify a file, while the git model is that anyone can modify anything. Which means there are clear negatives to switching to git, especially for an organization which has been using another means of versioning. What did you do to minimize those negatives? What did you do to provide transition system so some people could use the old system and others the new? Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?

by donatj 2y ago

gardenhedge 2y ago

Some things need management to run and say "do this, or else". If you don't have that weight behind your words good luck getting any big changes done.

donatj 2y ago
I was ill suited to be manager in hindsight. I am a good developer, I am not great with people. I wanted it because it seemed like the next logical step in career progression but I was not good at managing people. I am very glad I left. I have spoken on here before about how it gave me stress induced health issues.
- gardenhedge 2y ago
  Were you a lead or a manager? Did you take a salary cut?
  - donatj 2y ago
    Both? I was in charge of our codebase as well as managing our developers. Is that not how it always is? Everywhere I have worked "Lead Developer" has been a management position, such that your team reports to you. No, it was actually a pretty significant pay increase. I went from a very small company to a larger one.

eesmith 2y ago

About the same time, I looked to see if there was any research on the effectiveness of a version control system like git vs. other methods of versioning (like VMS-style numbered versions, or backup/snapshotted file systems with a temporal browser). I found nothing. FWIW, "git leaderboard" is trivially gamed. Not only with pointless auto-commits, but some people commit every few lines while others commit only when things are in a good shape. What you ended up doing was introducing the same sort of resentment as factory workers under Taylorism and observations from the time-and-motion man. Had our schools taught more about the history of labor rights and struggles, and perhaps less of the success of industrial oligarchs, then perhaps you would have been more likely to expect that resentment and not tried it in the first place.

donatj 2y ago
> trivially gamed Eh, there were no rewards, so no real incentive to win. The idea was just more to get the act of committing their code into their minds. Like "oh hey, everyone can see I'm at zero, maybe I should commit my work". This was something I tried after months of poking people to commit their work. I'd put together a whole training on what git is and why we should be using it. It came up every weekly meeting. I was grasping at straws.
- eesmith 2y ago
  Then no real inventive to lose, so no real incentive to switch, so no real incentive to care about a scoreboard, while making those who might test the waters subject to possible public ridicule. What do you think the advantage is to 1) using a version control system, and 2) using git, in the aughts? Version control systems have been around since at least the 1970s (dating from SCCS), so 30 years before your experience. My group was using RCS in 1993. Which means the people you were trying to convince almost certainly know about the concept and possibility before you tried to persuade them. Frequent backups of a shared file system is a form of versioning. VMS-file filenames.txt;001 is a form of versioning. Moving projects into new directories is a form of versioning. None of them require any special training to get started, and the latter two let you use any normal tools to view and compare different versions of the file. Some places had conventions about who was allowed to modify a file, while the git model is that anyone can modify anything. Which means there are clear negatives to switching to git, especially for an organization which has been using another means of versioning. What did you do to minimize those negatives? What did you do to provide transition system so some people could use the old system and others the new? Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?