Do Yourself a Favor — Read More Code

In order to learn how to write, you first need to learn how to read. One of the best ways to improve your writing is to read more content from a variety of authors.

Why should it be different in coding?

Have you ever seen a coding course that actually teaches you how to read code before you write it?

The answer is no. Maybe because it’s quite hard to do well, or just because engineers focus more on making things work and force the computer to do what they want it to do without thinking about anything else.

This focus on short term execution is what makes it so hard to find good developers. At the end of the day — many of the so-called developers around focus on writing code and running it. Not understanding it. Not thinking about it. Not learning about it.

The Benefit of Learning to Read Code

There are several ways to learn how to code better. We can read books, such as Clean Code, The Pragmatic Programmer and Clean Architecture, those will teach you theory. We can read software engineering blogs that will guide us in specific cases.

Reading code, on the other other hand, will make you effective.

It Makes You Faster

As software engineers, we tend to work a lot with other people’s code. This is mostly correct in large codebases. Being able to read other people’s code fast and understand it well — is a key to integrating with it effectively. Most of the time (especially if the code in stake is internal), you cannot assume documentation is correct. The code, on the other hand, is always correct.

It Builds Intuition Towards How Good Code Looks Like

It is hard to implement what is written in books. It is very theoretical, and almost always irrelevant to what we do in our day-to-day lives. It isn’t until you see the concepts you read about in real life, that things start to make sense.

Reading a lot of code will actually make you familiar with more concepts and will enable you to develop critical thinking. It would make you not only better code writers, but also better influencers to the environment that surrounds you.

At least I’m not asking you to read this (Source: xkcd)

Where to Start

Navigating through code is not a simple task, and probably worth a post by itself. I’ll try to give a short overview though, on the methods I found most effective.

Eventually, you need the right mindset and the right tools.

The Right Mindset

• Don’t try to understand everything — It’s impossible to understand all the code that you read, so please don’t try to read and comprehend every line. Focus on specific areas. The best way to do this is to ask yourself a specific question that you want to answer. Something like “Does this data fetching library support data caching? What’s the API for that?”. Focus on answering this question, and do not try to overload yourself with too much information. You won’t be able to handle everything, and it will take too much time.
• Put yourself in the author’s shoes — Doing this will help you understand why they chose to write the code they did, and not only what is being done there. It can help you answer those questions mentioned above. Ask yourself “if I was to write this feature now, what would I do?”. This will also help you check your own intuition.
• Be in Growth Mode — Focus on your own growth during this process. Think about what you can gain from this code while you read it. Think critically about patterns, about good and bad things the author implemented there. Think about opportunities for you and for the developers themselves.

The Right Tools

• “Grepping” — grepping stands for all the possible ways to navigate through the code fast. It comes from “grep”, which is the command line tool that enables searching for specific strings in a big input. I find “grep” great for most purposes, but more sophisticated tools such as symbolications in IDEs, reference searches, hierarchies etc are very very useful in doing this. Doing it fast is key, so find the best tools for you (honestly I usually use just grep).
• Debugger — It will be hard to understand complex flows without an active debugger. Setup the environment, be able to connect a debugger, and work with it while you try to understand why certain things behave the way they do. Using a debugger you can see the call stack in certain areas of the execution, you can see variable values, and in general this helps you better understand and control the flow.
• Logs — Logs give you very good indication on why things are happening and what the flow of execution looks like. Use “grepping” to locate the specific place where the log occurs. Start from there.

Start from a specific point in the code, debug/read your way out — This is not always true, but as a general rule of thumb this is quite useful, and it uses all above tools.

Find a specific point you want to start with. Look at the logs, find the code pointer to start and read. Don’t be afraid of debugging the code. Be focused on specific questions and find your way out to understand the bigger picture.

Do it often, the opportunities are there. I promise you’ll become better engineers as a result.