Writing my FIRST 100,000 lines of code
I’ve recently came across a job post in LinkedIn looking for a developer with just a single requirement:
A programmer who wrote more than a 100,000 lines of code.
This post caught my attention (which I assume was its purpose) - most of the job posts I’ve seen so far have a pretty standard format: the requirements list usually includes some professional hard skills like technology background, programming languages, years of experience and so forth, and some soft skills like being a team player, good communication skills etc.
The post made me wonder how many lines of code (LOC) I’ve written so far during my career. I can probably pull some statistics from Git, but I’ve been around enough time to use other source control tools like CVS and SVN (rest in peace), and worked for Startup companies that unfortunately no longer exists.
Googling the web shows different estimations regarding the number of LOC an average developer writes in a week\month period. This number is subjective and vary form one developer to another, and from project to project depending on the size and the culture of the team. But since we are in the numbering game, I will not avoid and estimate that an average of 100–200 LOC per week over the course of my career sounds about right. Assuming there are 50 working weeks in a year, after writing code for a leaving for the past 15+ years, I’m somewhere in the range of writing 100k LOC as listed in the job requirement.
But what does it really means to be a developer that wrote 100k LOC? Does it necessary means being a better developer from someone who wrote 50k or 10k LOC? The short answer (to my opinion) is no, but stay with me and I’ll explain why.
Writing code — the more the better?
“Quantity has a quality of its own” Joseph Stalin
I’ve spent the vast majority of my career working for Startup companies. And startup companies, by their nature, are very much focus on execution. When you’re a developer in a Startup company, especially in its early days, it usually means that you’re writing and deploying a lot of code (those 100–200 weekly LOC are easily squeezed into a day or two). But does it mean that your delivering a high quality code? I’ll speak only for my self and honestly say that in many cases execute fast was much more important for the Startup company than writing clean and elegant code. It doesn’t means that code quality is not important at all, but it might be prioritized lower.
I do believe that working for Startup companies will make you a better developer, but not because of the amount of LOC you will write but due to the diversity of technologies you need to quickly adopt and the variety of technical issues you will face. Performance issues with your servers? There is no DevOps team to help you resolve that. Bottlenecks in your Database? well, Google is your best new friend cause there’s also no DBA around. In many cases you are the architect, the programmer, the DevOps and the QA of your code. There are other team members who can assist and guide you, but at the end of the day it is up to you to make it work.
How about reading someone else code?
“This the real world, homie, school finished” Kanye West (Gorgeous)
Writing code is fun, but the reality is that developers spend much more time reading code than they do writing code. In an ideal world, the code you’re reading is expressive, well structured, well documented and tested . But in real world there’s legacy code with patches over patches, written by different developers that are not always around. Whether you need to resolve some tedious bug or add new feature, you will first need to read and understand the code your modifying. Anyone who ever spent a week or two reading and debugging hundreds of lines of code just to find out eventually a bug caused by using greater than operator (>) instead of greater than or equal operator (≥), knows what I’m talking about.
You might write very little code during those weeks (or non at all), but it does not means you are not improving your programing skills. Being able to read someone else code is as much, if not more, important for a developer as writing code — since you probably spend much more time doing it.
How about deleting code?
“One of my most productive days was throwing away 1,000 lines of code” Ken Thompson
Writing code is fun, but you know what’s more fun? Deleting code. Developers tend sometimes not to delete code, either since it “might be used in the future” (like there’s no source control) or since we already invested so much work in writing it and now we need to invest work in deleting it. There’s also an emotional aspect attached when you’re deleting your own cod. Adding the fact that time and resources are always limited and there are other higher priority tasks, it is just easier to keep the unnecessary code and not delete it.
Some may argue that there’s no harm with not deleting unused code. I believe there are good reasons for deleting it, but a real life example can demonstrate it best. During data migration process, we’ve added some business logic code to handle both old and new data schemas. After the migration process ends, we didn’t remove this code — not for a good reason but we were lucked resources and there was no real “downside” with keeping the code (it worked, right?). Until a minor code change in a completely different service introduced a serious production bug in our service due to a bug in the code that we’ve originally added just to handle the migration process.
How about NOT writing code?
“Now is better than never.
Although never is often better than right now.” Tim Peters (The Zen of Python)
Writing code is fun, but the question you should be asking is do you really need to write this code? YAGNI (you aren’t gonna need it) is an extreme programing practice, which comes from the observation that you should not write code because you presume you’ll need it in the future. It does not mean that your code should not be flexible, of course, since it will most like need to be expended and modified in the future, it just mean that you write only the code that you need now.
There’s also other reasons not to write code, despite the fact that as developers we’re eager to do so and we spend so much time discussing best practices and architecture and comparing programing languages and implementation. In many cases the best solution is to avoid writing any code. Before rushing into the drawing board, ask yourself if there’s an existing package\tool that already does what you need. And there’s not and you realized you need to write some code to accomplish what ever task you’re assigned to? Great, make sure you understand the requirements and the needs before you’re writing your first line of code — do not code “in the dark” or you might end up rewriting your code over and over.
TL;DR
“If I had more time, I would have written a shorter letter” Blaise Pascal
I hope that by now I was able to explain my general theme — trying to evaluate a developer based on the number of lines he wrote will reveal partial picture of his capabilities. Sure, we write code for a leaving, but writing code has much more to it then just writing code.
