Lines of Code Per Day Performance

There are few arguments with programmers that can elicit such passionate hatred as a debate about measuring a programmer’s performance by tracking the number of lines of code they write per day.

There are far too many variables at play which can affect a programmers ability to type code – how well they understand the problem, the language being used, familiarity with libraries, and distractions in the workplace.  Because of these extra variables it becomes unfair to compare LOC productivity between programmers or between projects.

However I do believe it has merit as a personal metric.

I am a believer in mastery through practice.  You deliberately practice a musical instrument by playing the same song over and over until the performance is good.  You learn your multiplication tables by practicing on 1000’s of example problems in primary school.  You master Jujitsu by repeatedly doing the same throws over and over until they become instinct.

For mastery to occur the practice must be deliberate and focused on improvement.  You wouldn’t get better at playing piano if you just mash keys – no matter how many hours you did it for.

Software programming is a skill like these others which takes experience to become proficient with.  For the vast majority of programmers I’ve met proficiency comes naturally through years of 9-5 coding.  I’m not happy with that level of performance for myself.

Measuring yourself in terms of time to code a solution to a given problem is a valuable metric to have to identify what areas you need to focus on.

For example if you took a standard example such as implement a merge sort algorithm – and tested yourself on that over time and against different languages you would be able to measure a meaningful change in your programming performance.

You might first find that you don’t know the algorithm well enough to type it out off the top of your head and turn to Google for a description of it (a detour that takes valuable time).  If it’s a new language you may find points that the syntax throw you back to a book.  Over time if you continued to learn you could reduce the time it takes to type out a solution.

It’s not that typing out merge sort once per week is going to be code that you would even want to keep.  Just like you don’t record your drum practice and post it up in an album on iTunes.  The point is to identify places in your process for improvement by asking could I have typed out this code better or faster if I was more familiar with the syntax, or knew of some extra libs to use that would cut down on lines of code.

Then once you’ve perfected that song (algorithm) move onto something new.  Practice it until there is no room for improvement in your time to solve or code quality.

I believe that practice like this should improve your personal day to day Lines of Code Per Day metric to be 2x to 5x what it would have been without the deliberate practice.