You Should Love Reading Code
If you are a developer, you should love reading code. If you love writing code, but hate reading it, you aren’t going to become a very good developer.
It’s like writing a book. Have you ever met a writer who hates reading? I haven’t and I have high confidence you haven’t either.
It’s the same for any artform (and yes, coding is part art). Dancers like to watch dancers dance; musicians love listening to music or seeing their favorite band; chiefs love to eat. Anyone who creates needs to look at great examples of already created things to learn and grow.
So coders should all love to read code too.
Sadly, many of us don’t.
It’s not for lack of resources though. We have literally millions of lines of browseable code in GitHub; we have IDEs that can let you browse public APIs of libraries and bounce around with a key command to go to source; and we have people writing about and sharing great code via blogs and books.
But we still don’t all love it.
So why don’t most developers don’t love reading code? Below are some reasons you likely have and my humble rebuttals.
Most Code Doesn’t Live Very Long
I’d bet that in most code bases, the average life expectancy of any line of code is a year. Maybe two or three for really important ones. I unfortunately don’t have an empirical study on this — if you know of one let me know! — but from personal experience code doesn’t tend to stay the same for very long.
With that in mind, why read it? After-all, most things we read or study are things that last for a long time right? They have timeless qualities about them and knowing them deeply will likely be helpful in the future. It would seem that reading and understanding things that change quickly might not be the best use of our time. Why not treat code like a trendy-book? We might glance at it, get a general overview, and move along without really reading it.
Here is where I might encourage you to think of code as a compilation of short-stories rather than a novel or lengthy book. Within a compilation, each short-story is usually related to the others and they share some theme. However, you will find yourself having to start over at the beginning with each one. But a good short-story is worth reading! And often the core ideas of a compilation require you to read most of the stories therein.
If you treat your code as a set of short-stories, you don’t have to read it all or memorize something that might change soon. You simply read for understanding the theme and goal of the code.
Most Code is Kinda-Bad
A nicer way to say it is that most code isn’t very good. Mine included. We all wish we were great developers never making a mistake, but we do. Even with code reviews, code is hard to get right all the time.
This is where writing code is different than writing a book or a blog. With code, you usually have a specific feature or fix that you didn’t necessarily come up with. Normally you have a timeline. Better yet, there is always risk that your changes today might be invalidated by a change tomorrow. When it comes to viewing or editing your changes, you usually get just enough of someone’s time in code review to say “your code isn’t awful”, but not much else.
Like reading a book, though, when you read a poorly written code, its painful. I usually put down almost all of the books that suffer from simply bad-writing a few chapters in. If the story doesn’t make sense, the character descriptions are cloudy, and the plot is lacking I put it down. In code, if your methods don’t make sense, if your variables are poorly named, and there isn’t a clear direction your code is taking, readers will check-out.
How do you find motivation to read bad-code?
My best advice is this: read with the intent of understanding rather than critique. Try as hard as you can to put the story together, and as you do, think of how the story could be told better. What changes would you make to make it better? Why? If you can be active in attempting to align what you are reading with your mental model, you will understand what you are reading faster (and in the process already have the next version in your head).
Most Code is Kinda-Boring
Have you read Lord of the Rings? Or read anything from Tolstoy? There are sections of those stories that are mundane; character descriptions that are tedious; lulls in plot that are flat out boring.
Likewise, in code there is often a lot of repetitive, mundane, tedious, boring sections. Configuration classes in Spring; boilerplate code for a React app; the init main methods in python.
You can feel your eyes drying up and cracking can’t you?
No one wants to read a boring story and no one wants to read boring code. But, in a great novel, the mundane, tedious, boring sections can tell us a lot. They give us insights into a character’s mind or how they act. We might learn about a nuanced detail that illuminates some other part of the story. These sections help us learn how to read the rest of the story.
Boring code is the same way. Take the time to learn how your code is structured. Read all of the logging lines to see if they make sense. Make sure the simple configuration is actually simple. Having these details will make reading the rest of your code so much easier.
At the end of the day, being a great coder requires reading great code. Sometimes it’s a chore, but that is when you really get good. Seeing bad code for bad code is just as important as seeing good code for good code. After a while, you’ll be able to have an immediate reaction to whether some function, class, or even design is just “off”. Once you get that intuition, you’ll be writing better and better code each day.
Happy coding!
