“Writing comes from reading, and reading is the finest teacher of how to write.” —Annie Proulx
Programming is weird. When learning to write code, we tend to focus on memorizing the syntax and features of a programming language. We learn about variables, loops, procedures, etc. We learn the varying parts of the language. We memorize them all. Then we start learning frameworks. Such-and-such framework is great for web. So-and-so framework performs database interactions. Pretty soon we have all the tools we need and it’s time to start writing!
But something is missing here. We call it a programming language, and it’s a wonderfully accurate moniker. Languages are used to express ideas, both concrete and abstract. Within a single language, any idea can be expressed in innumerable ways. Some of which are elegant and poetic, others crude and incoherent.
Code is written with language, but unlike traditional written languages, we don’t focus on learning to read. Imagine writing a novel without ever having read a book. Sure, if you know a language well enough, you can probably express a rudimentary story well enough. To achieve mastery, however, to write a complex epic of interweaving plotlines and twists, a consistent voice, and a cohesive underlying theme, more than a basic understanding of syntax and grammar must be learned.
Master authors have spent thousands upon thousands of hours reading the works of their peers. They have first hand experience immersing themselves in works of different styles. They’ve seen hundreds of different approaches to writing, and they’ve developed a personal preference and style based on an amalgamation of all their favorite aspects. They’ve read good books and they’ve read bad books. They’ve consciously and unconsciously noticed the patterns common to each, and are influenced on an intuitive level by those experiences, such that they emulate the style of their favorite authors while avoiding the styles of the worst.
In programming, however, we do it backwards. We learn to write first. Early in our careers we accept that a lot of code is just over our head. The results are statements like these:
“I know this code is kind of gross and hacky, but that’s because this class I’m using doesn’t support what I’m trying to do, and I didn’t want to make changes to it since I didn’t write it, and therefore might break something if I change what I don’t understand.”
“This open-source framework is awesome! It’s so intuitive that if feels like magic. I wonder how they did it.”
“Ugh. Looks like Bob wrote this. His code is terrible to work with. It’s no use trying to understand it. Let’s just find some other place that uses it and copy/paste how they did it there.”
“That bug’s not my fault. It’s just because I fixed this other bug, but how was I supposed to know the fix would break this section of the code? I didn’t write this section.”
“This code is so gross. I wish we had time to refactor it, but it would take so long just to understand it. I think we better just rewrite the whole thing from scratch.”
“I want to write good code, but to be honest, I don’t really know what that means. What is good code? How am I supposed to get better when I spend most of my time on bug fixes?”
We hear these kinds of statements all the time. We accept them as normal. Code is complicated and difficult to understand. That’s just it’s nature right? Surely, there is nothing we can do about it.
But what if there was another way to think about it? Remember that short story your nephew wrote for his middle school creative writing class? You know, the one where you told him it was great, but then laughed at his rookie mistakes after he left the room. It wasn’t fine literature, but you could still comprehend it. You read English fluently, even poorly written English (assuming you are reading this in English). What if your literacy for code was just as good? How much easier would it be to comprehend a particularly complex or poorly written passage of code if you were just a little more literate?
Remember, you didn’t become literate overnight. It took years of reading books, articles, magazines, etc. If the 1st grade version of you, while struggling to sound out each and every syllable, didn’t already know lots of adults who were highly literate, it would have seemed nearly impossible. The letters, syllables and grammar were just so hard. How could something so abstract and complicated ever begin to feel like second nature? And yet, here you are, reading like a champ.
So next time you’re struggling to sound out the confusing syllables of a particularly difficult passage of code, take solace in knowing that just by trying to understand it, you are improving your coding literacy.
So how do you get better at writing code? There aren’t exactly novels written in Ruby. But worry not, there’s plenty of code out there just waiting to be read.
Perform code reviews of your peers, even if they are more senior than you. You might learn something. Better yet, since everyone is fallible, you might even get brownie points for finding a problem they missed.
That awesome framework you rely on every day to run the bones of your application… how does it work? Dig in. The code is probably open-sourced, and if not, decompilers have come a long way. When your reading list runs dry, ask your peers and role-models what their favorite frameworks are and dig into those next.
The key here is to believe it’s possible to become more literate, and to believe in the benefits.
Next time you run into that really ugly, complicated section of the codebase, take a deep breath and dive in, because you’re lucky enough to have an opportunity to stretch your reading and comprehension skills with a challenging passage.
Next time you’re working in that really awesome, easy to use section of the codebase, take your time. Poke around. See if you can figure out what specific qualities make it so awesome. Soon enough your code will be awesome too.
Read on coding bookworms. Read on.