As a computer programmer I enjoy the most:
- to write new code
- to modify existing code
- to read and understand code
This is the question I asked many of my programming friends recently.
After posting a poll on Twitter and asking people directly, I got the shocking (yeah, right :)) revelation:
3 from every 4 programmers I knew loved nothing more than writing new code.
Not surprising, I know đŸ™‚
But how programmers actually spend their time? Writing new code all the time? If only…
Somebody measured that?!
Years ago, people from Microsoft decided to actually watch programmers program and measure how they spend their time. For hours they watched people work. People from different backgrounds and experience. In their lab, they studied them, categorized the types of work and even suggested a few different developers personas.
Why do all this? They were working on Visual Studio, so needed the information to measure what kind of features to put in.
What will be better in an IDE? Features that make writing code easier? Features that make changing code less painful? Or those that help you read and understand code?
What did they find a regular developer does all day?
- Time spent writing new code – 5%
- Time spent modifying existing code – 25%
- Time spent understanding code – 70%
Link to a study here.
This was more than 10 years ago and programming changed since then. The numbers are not 100% correct for sure, but they do not need to be. Experience has thought me that they are not far from the truth.
Not true? Verify this yourself!
No need for a usability lab đŸ™‚
Just answer this question:
What is your ideal programming day?
Most programmers will imagine something like “writing code on this new feature for hours, with minimal interruptions“. Of course, not everyone will answer like this. Specifics are not that important actually and why is that you will see soon đŸ™‚
Suppose you spend a day at work like that – writing a lot of code, good code, on your computer. Running it on your machine. And at the end of the day – you are done. Your code is completed.
Suppose on the next day the product of your ideal day work is gone. Your computer is badly damaged and work cannot be retrieved. You forgot to store it anywhere else. What now?
You just happen to have another computer with IDE and everything set up. You are ready to work again. Now answer this question: How long until you can code the same thing again?
A whole day? No, more like an hour. Or even less. What if you still had all your notes? Or even the sources printed on a sheet of paper? You just need to type them in. 20-30 minutes and you are done.
So the net result of your ideal programming day is less than an hour of writing code.
Even if it was an hour, for an 8 hour day – that’s 12.5 percent.
How many of those ideal days can you get?
And how many of your days are spent chasing a bug for hours before changing one line of code? How long writing that one line take? 1 minute? This is less than 1%.
Now the numbers from the Microsoft team start to make sense. 5% for writing new code may even sound like a lot if you are working with a huge, complex, legacy codebase.
Programming is mostly thinking and understanding.
Not writing, not typing at a keyboard. Understanding.
Even the new code needs to go somewhere, and this may take more time than the actual writing.
All new code is soon old code.
Old code will be changed and you will spend more and more time changing this old code as your project goes.
But what do you need to do before you change code? You need to know what it does. For that, you need to read it, study it and understand it.
Why is that?
Computers need strict instructions for everything they need to do. There is not much room for errors and interpretation and no detail is too small.
The amount of details you need to handle to make even the smallest task on a computer is staggering.
What we, programmers, do is to juggle with this details. We hold this mental model in our minds, grasp it, understand it. Only after that, we can change it.
Now what?
I will finish with a quote from Uncle Bob:
The only way to go fast is to go well.
- Can you write code that future you and your colleagues will understand?
- Will your teammates love your work or grunt in disgust and rewrite it from scratch, because they have no idea how it does what it is supposed to do?
- In 6 months, when you need to change something, how likely it is for you to break something else?
- Do you have a test for your code? Tests are automated understandings.
When you write a program, remember you are writing to a person as well, not to a soulless machine.
If only it was that easy đŸ™‚
Well, that’s it! Please share it if you liked it!
If you would like to receive future post updates, please subscribe below. I do not post frequently and will not spam you.
Thank you for reading.