I recently spent a few days working on rewriting the way that settings get passed into one of our products. This was a slight deviation to my usual work – I can usually be found writing code that requires more time thinking than it does actual code writing, but this task was quite the opposite, and it got me thinking about what the optimum average number of lines of code written per developer per day is.
Is there an optimum number of lines per day? It is well known that number of lines written is a poor measure of productivity, but that doesn’t make thinking about this question any less interesting – there are a huge number of factors to consider.
Firstly, the programming language being used to develop with can have a huge impact. The line count for a developer writing Java is likely to be wildly different to one writing Haskell, or Python, or HTML/CSS/JavaScript. If Developer A writes 100 lines of Haskell and Developer B writes 1000 lines of HTML, it wouldn’t be fair to say that the Developer B is 10 times better than Developer A. (In fact, probably the opposite is more likely to be true!)
So what about if you were to level the playing field and only compare yourself with those writing the same language as you? Even by limiting this factor, your line count is still very much dependent on what it is you’re doing. Writing test code, implementing new features, and bug fixing all have very different code requirements. Some bugs can take many hours to find the source code responsible, and it may only require a single change of a line or two. Similarly, it’s possible when writing a new feature that you discover the need to refactor some code, which could lead to having less lines than when you started.
It’s also dependent on your experience and how concise you are in your code writing. It’s very easy to inflate code, even a simple if/else statement can be very quickly made to occupy twice as many lines as it needs if you have a phobia of curly braces occupying the same line as other code. It’s quite likely that the inexperienced beginner is being less productive, but writing just as many lines as (if not more than) the experienced programmer.
It’s widely accepted that counting lines is a poor measure of productivity, but interestingly there are still some people on the internet who like to boast about how high their average is. Personally, my favourite days are when I leave the repository with less code than when I started. I love coding, but my best days are not those where I have written a huge amount of code.
So how should we measure productivity? Perhaps on a feature oriented, bug-fix oriented basis?
Personally, I would consider my most productive days when I can roll off a list of achievements and give a combination of fixing bug X, implementing feature Y, creating a new test for Z, updating this piece of documentation, updating this website page, and perhaps even working on a new blog article.
It’s not all about writing code, I think it’s equally important to have a range of tasks that you are able to switch to. Doing the same thing all day every day can get boring and result in a drop of productivity. By having other tasks you can switch to, it can help keep you interested in what you are doing, and as a result keep productivity up throughout the day.
So what do your most productive days consist of, and how do you prefer to spend your time?
Our software libraries allow you to
| Convert PDF files to HTML |
| Use PDF Forms in a web browser |
| Convert PDF Documents to an image |
| Work with PDF Documents in Java |
| Read and write HEIC and other Image formats in Java |
I think you get pretty close to the mark when you describe being more productive when you leave with less code than you started. For me the answer to your original question is something along the lines of, “as close as I can get to zero while still having something that’s readable, maintainable and meets my objective in full”. In other words, I won’t purposely go dense just to reduce line count, but I’m always looking for the most elegant way to meet my objective without producing thousands of lines of code in the process. Smaller code is more maintainable, and more bug free by definition. So I see it as an ideal to strive for.
I actually believe this is one of several indicators that denotes the difference between a mature craftsman and an immature one.
I do believe that number of lines of code per se means literally nothing. At least one should consider which type of code we’re talking about. For example writing highly concurrent server-side application especially a distributed one is obviously very different from implementation of the tax calculation or other linear algorithm and it is absolutely pointless to compare productivity of two programmers working in such a different fields. Even if we consider a narrow class of programs the number of lines of code is still a very indirect indicator of whatever you want. For example implementing a completely new functionality which affects only a few places in the code becomes a totally different game if one has to adjust several dozens of places.
Generally speaking I start to think that all (well, almost all) discussions about programing “in general” are mostly absolutely pointless as today there are so many different kinds of programming and some of them are so different that “programming” and “coding” become almost as abstract notions as engineering or art.
I’ve never – ever – counted the number of lines of code I produce each day. Nor have I made an average of these lines – for that matter.
One thing I know for sure, the amount of line of codes is not at all proportional to productivity. It’s completely irrelevant.