That said, even I like to get some numbers on code, especially unfamiliar code, to help me figure out a few things. For example, I’ve been using CLOC (Count Lines of Code) for years to find out quickly how big a project is and what languages are used in what proportion.

The first metric that’s started to be tracked at work is lines of code added and deleted per release, per author. I’ve occasionally glanced at these kinds of numbers in the past too, and even wrote a little script (git-rank) to get the same kind of info when I was on a code deletion spree. I’ve found these numbers to be useful for getting a general idea of who is most knowledgeable about a project or some files within the project.

However, the numbers can easily be misleading. For example, if someone is committing a lot of style reformats, vendoring code from other projects, or autogenerating documentation, their numbers will be very high but they may know very little about the codebase. For example, for a release to a Rails project I’ve worked on the metrics gathered showed that I had added 248,475 lines and deleted 458,020 lines. That’s obviously suspicious, although it does make me look very active. These are the kinds of numbers that you should dig a little to figure out what’s happening, which is why I wrote my little git-rank script makes it easy to break those line totals down by file, and then exclude files for the next count.

$ git rank v1.1.1..v1.1.9 --all-authors-breakdown --author "Matt Robinson"
Matt Robinson 603061
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail14.json
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail12.json
1 vendor/rails/railties/test/vendor/gems/dummy-gem-a-0.4.0/lib/dummy-gem-a.rb
........
21418 vendor/gems/haml-3.0.13/lib/haml/precompiler.rbc
24953 vendor/gems/haml-3.0.13/test/sass/engine_test.rbc
30038 vendor/gems/haml-3.0.13/test/haml/engine_test.rbc
Matt Robinson 603061

It’s pretty obvious that most of what I did was update vendored gems. If you’re trying to figure out who did the most work between the releases I specified, you probably want to ignore the vendor directory when count lines of code.

% git rank v1.1.1..v1.1.9 --exclude-file vendor
Josh Cooper 4
Nigel Kersten 8
Andreas Zuber 11
Michael Stahnke 11
Jacob Helwig 15
nfagerlund 37
Daniel Pittman 283
Max Martin 418
Nick Lewis 543
Randall Hansen 901
Pieter van de Bruggen 1018
Matt Robinson 1661

Now we’re starting to get a more realistic picture. From here we could dig deeper by listing all the files again for all the authors, and then maybe start excluding lines based on a regex if there were automated changes, and then maybe look at additions vs deletions in the count (I’m summing them together for these numbers).

However, I hope people *never* think they can get the whole picture, or even most of the picture, of a code base and who is contributing the most from something as arbitrary as lines of code counts. I feel like that’s almost too obvious to say, but I’ve heard horror stories of managers who tie reviews to metrics like this. I hope I never personally experience such a thing.

P.S. If anyone tries using the ‘git-rank’ project I mentioned above, please keep in mind it’s a hacky little sick project that is probably got some bugs and you should take the numbers is spits out with a grain of salt. What a weird phrase that is.

How do you avoid this slowdown and prevent loss of all those great hacks and configurations you’ve built up? Version control all the files that enable your productive environment. Here’s my repo for all those files.

https://github.com/mmrobins/config-files

I’ve got bash, zsh, vim, screen, tmux, irb, tmux, irssi, ruby scripts, puppet scripts and more in this git repository. I spend a lot time working remotely via ssh or on virtual machines on my development box, so it’s important not only that I have these files available, but I also have a fast way to get all these files in place quickly. I also want changes that I make to these files to be easy to commit back to my repository. To accomplish this, I make all these files symlinks to the files in my repository so that if I edit ~/.bashrc with my great new alias that saves all sorts of typing, it’s actually editing the .bashrc in my git respository. Then I have a little perl script that when run puts all these symlinks in place for my automatically and backup up any files I’m moving out of the way to create the links, just in case.

https://github.com/mmrobins/config-files/blob/master/create_symlinks

Now whenever I end up in a new environment on the terminal, I can get all my productivity in place with a few simple commands from the home directory.

git clone git://github.com/mmrobins/config-files.git
./config-files/create_symlinks
source .bashrc


Now vim has my plugins and configuration, bash has my prompt, if GNU Screen or tmux are available they’re how I like them, my aliases work, etc. There’s always going to be tweaks necessary for this to work cross platform and on different machines with different privileges, but since committing those changes back to the git repo is so easy, it become a natural part of my workflow to have these incremental improvements to my work environment available everywhere I work.

The way I’ve done it is to use GitHub to store my config files, so anyone else is free to take a look if they want to see how I’ve got vim, bash, screen, readline, ruby’s irb or other things configured. However, the biggest benefit is that I can quickly get a new machine customized with all my favorite settings just by doing a checkout (clone in git) into my home directory on the new machine. From there I’ve got a little script I run called ‘create_symlinks’ that backs up the old config files before overwriting them with symlinks that point to the files in my checkout. That way, whenever I update my repository, the files are automatically current.

This has been immensely helpful in taking the tricks I learn at work and easily incorporating them at home or on any remote server I have to do work. If I add something new and cool to my vimrc at work, I just have to remember to commit it and push the changes to GitHub before I head home, and then I can continue working from home without having to remember whatever command I just automated.

I’ve even heard of people who go so far as to put their whole home directories under version control as a way of not only moving files around, but as a way of doing backups. That seems overkill to me, but it’s worth thinking about what sorts of files we move around a lot might be easily moved and backed up using a source control system like git or SVN.