These days, it seems that almost everybody wants to learn to code — and if you believe all the boot camps and book titles that have surfaced over the past two decades, you might think it's also easy to do.
It seems to me that the latest generation of programmers is learning to code quite differently from how I learned. Perhaps that’s progress, but on the other hand, I meet many junior programmers who achieve a certain competency with code, but then hit a ceiling.
They recognize and respect the productivity of their most senior peers, but they don’t see themselves moving any closer to that goal.
I think I know why, and I’d like to help. It boils down to this:
You won’t be able to write well before you learn to read well.
Down below, I include three reasons why. But in order to really understand where I'm coming from, you need to know a bit about the cultural environment in which I learned to code, which shaped these opinions.
I Promise This Isn't an "Uphill Both Ways" Tale...
When I was young, I learned that if I kept quiet, and paid attention, I could learn a lot. Even though I thought I knew plenty, I also realized that the world wasn’t exactly waiting eagerly for my youthful wisdom. This was the season of life when I was expected to listen, to read, and to learn. So, I was never driven by a burning desire to “express myself.”
This understanding governed how I learned to program. I wasn’t attracted by some prospect of expressing myself with code. I just thought it would be fun, and possibly useful, to learn how to make a computer do stuff. I approached learning to code in the same way I had learned to write and the same way I had learned to speak: long periods of observation, followed by terse, mimicked expression.
An average baby listens to speech all day, every day, for 18 months before being able to speak 10-20 words. I learned to read early but didn’t write more than the letters in my name until school forced me, years later.
My introduction to programming was reading the programs published in magazines, or in books like Basic Fun: Computer Games, Puzzles, and Problems Children Can Write.
This was the age of type-ins. Before anybody had modems and when floppy disks were way too expensive for mass distribution, the best way for a kid with a library card and no money to get software was to type it in from the back of a library book.
In case it’s not extremely obvious, typing a full program from a book is fairly tedious, even if it’s in BASIC and not in C64 assembly. It’s not something you do without being fairly confident that you really want a digital copy of your own to play with.
It sure wasn’t the occasional screenshot of an ascii-punctuation adventurer navigating a dungeon with walls made of ‘-’ and ‘|’ characters that provided the motivation to overcome that tedium.
It was reading the code. Lots of it.
Read First, Write Second
Like reading a cookbook, when picking a recipe is going to involve a multi-hour (or multi-day) commitment, you read more than just one or two programs before picking a winner.
Here’s the thing: It wasn’t until I was fairly practiced at reading code, and meticulously transcribing other people’s programs that I ventured into writing code — first by trivially modifying those existing programs and later by extending and creating my own programs.
Notice how completely different this is from the typical way many people are learning to code today!
I can jump right in to learning JavaScript at the famously well-polished CodeAcademy. How does it start? Write some very simple code. How does it continue? Write some incrementally less simple code. I can get well on my way to writing loads of JavaScript without ever having read a line of JavaScript in my entire life.
Does this make any sense at all?
Not really.
It turns out that knowing how to speak and how to write isn’t nearly as useful as knowing what to say and what to write. So it is with code.
Knowing how to write code without the experience of reading code is like being able to pronounce all the phonemes used in Swahili without ever having heard a word of spoken Swahili.
Thus I concluded: It’s only by reading code that I can understand the patterns of thought that people express in code and only by understanding those patterns can I have any thought of my own worth expressing in code.
But Isn't Reading Code the Easy Part?
You might argue that it’s impossible to learn to write code without becoming proficient at reading code.
You’d be tragically wrong.
I have personally worked with (brilliant, by the way) people who were completely capable of programming, and yet completely incapable of looking at a program (even their own program!) and understanding what it did.
If it didn’t behave as desired, they were forced to simply rewrite random parts, or finally just write another program. I’m sure that this is a terribly frustrating place to be, and it’s got to be even worse if you’re a professional coder.
If you write code professionally, or aspire to, don’t be a write-only programmer.
Here's why the ability to read and understand code is more important than the ability to write code.
Reason 1: You Will Read More Than You Write
A programmer will be required to read a lot more code than he or she will write. Many new professional programmers believe that they were hired to primarily write code. Modern programming involves SDKs, third-party libraries, virtual machines, interpreters, compilers, transpilers, browsers, clients, servers, operating systems, etc., all built with code, some of which you may have to actually read one day in order to make stuff work.
Since 97% of statistics are made up on the spot, I can tell you immediately that the most effective programmers I know spend less than 5% of their time writing code.
If you program professionally, it’s likely that you’ll eventually need to read code in many more languages than you can write. And it will be fine that you don’t know how to write in them because you’ll have no need to. But you’ll still have to read some unfamiliar language in order to understand how to avoid some undocumented behavior you’re seeing from some dependency that’s randomly crashing your program.
The world’s a big place, and it’s full of code you didn’t write. Understanding what some of it does will be a vastly larger part of your job than adding your small contribution.
Reason 2: Reading Is Faster Than Writing
As a professional, you desire to increase your productivity, and the best way to do that is to get better at reading code.
You already know that the gap between the effectiveness of the exceptional programmer and the average programmer is an order of magnitude.
The exceptional programmer must be faster at something than the average programmer, but what is it? Does the exceptional programmer spend an order of magnitude more time actually writing code than average? Or, does the exceptional programmer simply type out lines of code much faster than average?
No, the most effective programmers spend an approximately average amount of time writing code at an approximately average speed.
What accounts for the difference in efficiency, then?
While writing is limited by the speed of the fingers, the reading is only limited by the speed of the eye and the mind. An exceptional programmer reads the same complex code and understands it in seconds, while an average programmer takes days to reach the same understanding of it.
Furthermore, when the time comes to write, the more code you’ve read, the more likely you are to know what code has already been written and, therefore, be able to reuse it, rather than write it.
So, the more widely-read programmer writes less code to accomplish the same task in less time, which makes them more productive. That’s right: the key to becoming a more productive programmer is to write less (and read more) code!
Reason 3: Reading Makes Better Writing
The more code you’ve read, the better code you'll eventually write.
Programming is often more akin to editing than to writing from scratch. Whatever code you write will exist in some context — the surrounding code, the APIs you interact with, the interfaces you implement. Every codebase has idioms, conventions, patterns, and customs that define its character.
The better you know that context, the better your new code will fit in. If you don’t absorb that knowledge by reading code, your new code will stick out like a sore thumb.
Unless you miraculously write perfect code the first time, writing code will also require you to debug it. If your task is to fix some bug in the code, then the ability to read and understand code is absolutely fundamental to being able to reason about the correctness of that code or even its suitability for any particular purpose. It’s fundamental to the evaluation of any proposed changes to code.
Therefore, especially as you edit existing code, the better you can read that code, the more correct and appropriate your changes to that code will be.
Conclusion
In short, for the professional programmer, code comprehension is more important than code construction because 1) you’ll be reading far more frequently than writing, 2) faster comprehension is the key to exceptional efficiency, and 3) the better reader writes the more appropriate and more correct code.
If you're interested in learning more about Engineering at MojoTech hop on over to our dedicated page.