You spend much more time reading code than writing code.
I like my code to be in order. I like my code to be easy to read and easy to understand. And I’m willing to go the extra mile to make my code adhere to those standards. But is it worth it? Is writing clean code a good investment?
When discussing this with colleagues I usually get one of two reactions: Either they care a lot about writing readable code, or the readability of code is not important to them at all. But what’s far more interesting is that usually, they have a really hard time explaining why they feel one way or another.
Especially on new teams or after major personnel changes on existing teams I’ve seen this topic being discussed more often. But I’ve also seen that this discussion oftentimes lacks objective arguments and metrics. My primary argument in those discussions is usually quoting Bob Martin.
On the one hand, I love the idea of simply comparing time spent reading and time spent writing code. On the other hand, I grew more and more curious, because I felt this ratio for me is way higher than 10 to 1. Besides if we could make this metric more objective — potentially even let individual engineers compute this metric for themselves — it would be much easier to argue for or against spending time to make code more readable.
Time spent writing code
That being said we’d first need to compute the time spent writing code per day. Pay attention here: it’s purely about the time spent writing code rather than time spent “coding”, because if we talk about “coding” it oftentimes involves reading other code and to figure out how or where to apply a change.
This could leave us with the following formula:
Lines of Code: For good reasons it’s really hard to find good sources for how many lines of code a developer writes. There are two sources that have collected contributed lines of code per developer over multiple projects reporting an average between 325–750 and 209–470 per month. This leaves us between 10–37 lines of code per working day — if you calculate with 20 working days per month.
Characters per Line: If you look at successful open source projects this could give us an indicator on this metric. AngularJS for example has an average of 39 characters per line on all Typescript files. A similar value can be found on GCC where lines have an average of 29 characters. Both include whitespaces.
Typing Speed: Based on this survey most programmers can type between 30 and 70 words per minute. With an average word length of 4.8 chars per word, this means most developers should be able to type between 144 and 336 chars per minute.
On average, an engineer would spend between 1 minute and 10 minutes writing code per day
Time spent reading code:
We could try to reverse engineer this metric. If we would know how much time an engineer spends time on “coding” we could subtract the time he spends writing code as well as the time he spends thinking about the problem without reading other code
Coding Time: Based on the following two surveys we can assume that engineers spend between 3–5 hours per day or around 19.5 hours per week “coding”
Writing Code: As computed above this is around 1 to 10 minutes per day.
Thinking time: This value relates to time spent where you would think about the problem within the time you would classify as “coding time”, but without reading existing code. I have to admit, this is the vaguest value of all. I assumed this could somehow be related to the time required to write the code — although I’m not super happy with this metric I think it could give us a ballpark figure. So I assume it’s around 5 to 10 times the time required to write the code.
On average, an engineer would spend between 70 and 294 minutes reading code per day
Given the calculations above it would mean that you spend significantly more time reading code than writing code. If you put those two metrics in relation the ratio of time spent reading versus time spent writing is between 7 to 1 and 200+ to 1.
The ratio of time spent reading versus writing is between 7 to 1 and 200+ to 1
To answer our initial question — is writing readable code a good investment? Hypothetically: Given an engineer has a ratio of reading versus writing time of about 50 to 1. If this engineer would spend twice as much time writing code including thinking about it) as before and in the process make the code ten percent more readable it would even out.
And those numbers also raise an interesting question. Could this have an impact on personal learning goals? Would it make sense to focus on getting better at reading and understanding code? Could it make sense to rather learn a new shortcut to navigate within your IDE or highlight usages of functions or variables instead of a new shortcut to make writing code easier?
I don’t claim that those numbers are hard facts. But I’ve tried to be transparent about how they are computed — which should give you the chance to decide for yourself how relevant they are for you. So please treat this as food for thought — best case those numbers are in the back of your head next time you need to decide whether to spend time on making code more readable or not.
