As developers, programmers, software builders, solution creators, we tend to focus on the output of our work. It’s the code we write. It’s also the outcomes that we create for ourselves, our clients and/or our work.
How do we get better at it though? That’s what we care about in the end. The obvious answer is to write more code (duh!). What I’ve learned goes against that common logic.
Here’s what you need to do. You need to read more code. Yup, you heard that right. This is what’ll give you the largest skill gains. That’s the secret sauce.
I can hear your disbelief all the way through the internet! Of course, writing code is necessary. After all, you have to practice what you learn… from reading code.
What are you doing when you’re writing code?
You’re solving a problem. Writing code is just a process that you use to do it. So let’s say you hit a problem you’ve never seen before. What’s your first instinct? You google it, right?
You don’t sit down and write code out of nowhere. That’s because you know there’s a solution out there. You can just use it and move on. It’s just human behaviour.
Why is reading code more useful?
To understand that, we have to take a look at how we (humans) learn. In particular, we want to look at how we learn from observing others. That’s because the internet acts as your personal observation laboratory.
As a developer, you learn a lot from observing the behaviour of other developers. You might observe them by:
- Reading their questions and discussions on Stack Overflow.
- Following them on social media.
- Subscribing to their blog.
The reality is that you can observe anything that someone shares in public. This gives you countless opportunities to learn from the behaviour of others. That’s why the topic is important.
So let’s dive further into it. We’re going to take a look at two ways that we learn through observation. This will explain where the need to read code comes from.
Learning through imitation
This is where you learn by mimicking someone’s actions. You repeat the same set of actions to replicate the result. Our previous situation fits this behaviour.
1) You stumble on a problem that you can’t solve.
2) You google it.
3) You copy (often as-is) the solution that you just found.
What did you learn from doing this? You learned that you can just google a solution to your programming problems. It’s a strong self-reinforcing behaviour because it works.
Now let’s go back to this idea of improving yourself by writing more code. How does this happen? Most of us, just don’t sit down and start writing out of the blue. We find a problem that we want to solve and then start coding.
This brings us back to our googling behaviour. If you solve problems by googling solutions, you won’t gain much from writing code. You’re just practising your google-fu and your ability to assemble pieces of code.
Now, this isn’t to say that googling a solution is bad. That couldn’t be further from the truth. It’s an amazing (and required) tool in your toolbox. You just have to understand that the behaviour can also be a liability.
Learning through emulation
Emulation learning focuses on the environmental result of a set of actions. You’re looking to replicate a result like you would with imitation. The key difference is that you don’t have to follow the same steps. Rather you create your own strategy.
So let’s go back to our situation again. You’ve hit a problem that you can’t solve. How would you devise your own strategy to solve it? You still have to write code, but what do you write?
This is where the reading more code comes in. When you read code, you’re viewing a solution from someone else’s perspective. You’re increasing your exposure to new ideas and new ways to solve problems.
You’re not thinking about code the same way. You’re asking questions like:
- Does this code fit my situation?
- Can I make it fit my situation?
- What changes do I need to make so that it does?
You’ll notice the dynamic changed as well. Writing more code does a lot more for you now. You’re transposing solutions to your environment. We call this sharing of ideas cross-pollination.
It might seem like a subtle difference, but it’s significant. Emulation requires so much more out of your coding skills. You’re not just copying and pasting code anymore.
How do you increase your exposure?
You should start small. Let’s say you work with WordPress. Have you ever read anything in WordPress core? No? You should start there. You’ll see that there’s plenty to learn about.
Once you’re comfortable with WordPress, you can move on to the rest of PHP. You can look at PHP libraries and frameworks. After that, you can do the same, but in another programming language.
In fact, the order that you do any of this isn’t important.
It’s about getting out of your comfort zone
It’s about overcoming your fears. The fear you won’t be able to understand the code you read. The fear that you won’t be smart enough to use it. The fear that you’ll waste your time. Fear is always there in the back of your mind.
But behind that fear also lies discovery (and even wonder). You’re discovering new ideas. You’re discovering new problems that you didn’t know existed. You’re discovering new ways to solve new and existing problems.
You’re no longer just a developer. You’re also an explorer (a coding Indiana Jones!) with a big world to explore. Each time you go out and read code, you’re going on an adventure.
It’s what you bring back from those adventures that counts the most. It’s an idol of knowledge, a nugget of insight or maybe just a bruised ego (hey, it happens!). At the end of the day, they’re all learning experiences.
And it’s those experiences that’ll make you a better developer.