Reading code is a skill nobody teaches
October 18, 2026
Tunde Okafor
Think about your first week in a new codebase, or the first time you opened an open-source project to fix a small bug. You probably did not spend that week writing much. You spent it reading and trying to work out what was connected to what.
That is the normal shape of programming work. Most of the job is reading code that already exists. Writing a new function is the small part at the end. Yet almost every beginner course is organised around writing, because writing is easier to demonstrate and easier to grade.
Reading code is a skill you can practise deliberately, and it does not require a course.
Start with something small and complete. A single file is ideal: a utility script, a small component, a function you already use but have never opened. Read it once without worrying about the details. What is it for? What goes in? What comes out? You should be able to answer those three questions before you look at any specific line.
Then read it again and trace one path. Pick one input and follow it through the file, writing down each value as it changes. This is slow and slightly boring, and it is exactly how the pieces start to connect. When you reach the end, you should know why the output is what it is.
Next, ask what could break. What happens if the input is empty? If a number is negative? If a file is missing? You do not have to run anything. Just look for assumptions the original author made. Every piece of code has them, and finding them is how you learn to write code with fewer of your own.
A useful habit is to summarise a file in three sentences, as if you were explaining it to a friend. If you cannot, you do not understand it well enough yet. Reread the part that does not fit. This is also how you prepare for code reviews later, except the stakes are lower and no one is waiting on you.
Another exercise is to rewrite a small function in your own words. Not improve it, just restate it. Rename the variables to something clearer, or split one long expression into three short ones. You will quickly discover which parts you only understood at a glance and which parts you actually understood.
Reading other people's code also teaches you what you dislike. You will find functions that do five things, names that mean nothing, and comments that describe the code instead of the reason for it. Those notes are useful. They become the rules you apply to your own work, and they are much more memorable than a list of best practices in a style guide.
One warning: do not start with a huge repository. Opening a framework you have never used and trying to read it end to end is not a practice session, it is a maze. Start with the code you can finish understanding in one sitting, then move outward.
We include complete worked examples in every programming lesson for this reason. You are meant to read them before you write anything, and to change one line and predict what will happen before you run it. That small loop, read, predict, run, compare, is the closest thing to a shortcut this skill has.
Writing code gets the attention. Reading it gets the results.
That is the normal shape of programming work. Most of the job is reading code that already exists. Writing a new function is the small part at the end. Yet almost every beginner course is organised around writing, because writing is easier to demonstrate and easier to grade.
Reading code is a skill you can practise deliberately, and it does not require a course.
Start with something small and complete. A single file is ideal: a utility script, a small component, a function you already use but have never opened. Read it once without worrying about the details. What is it for? What goes in? What comes out? You should be able to answer those three questions before you look at any specific line.
Then read it again and trace one path. Pick one input and follow it through the file, writing down each value as it changes. This is slow and slightly boring, and it is exactly how the pieces start to connect. When you reach the end, you should know why the output is what it is.
Next, ask what could break. What happens if the input is empty? If a number is negative? If a file is missing? You do not have to run anything. Just look for assumptions the original author made. Every piece of code has them, and finding them is how you learn to write code with fewer of your own.
A useful habit is to summarise a file in three sentences, as if you were explaining it to a friend. If you cannot, you do not understand it well enough yet. Reread the part that does not fit. This is also how you prepare for code reviews later, except the stakes are lower and no one is waiting on you.
Another exercise is to rewrite a small function in your own words. Not improve it, just restate it. Rename the variables to something clearer, or split one long expression into three short ones. You will quickly discover which parts you only understood at a glance and which parts you actually understood.
Reading other people's code also teaches you what you dislike. You will find functions that do five things, names that mean nothing, and comments that describe the code instead of the reason for it. Those notes are useful. They become the rules you apply to your own work, and they are much more memorable than a list of best practices in a style guide.
One warning: do not start with a huge repository. Opening a framework you have never used and trying to read it end to end is not a practice session, it is a maze. Start with the code you can finish understanding in one sitting, then move outward.
We include complete worked examples in every programming lesson for this reason. You are meant to read them before you write anything, and to change one line and predict what will happen before you run it. That small loop, read, predict, run, compare, is the closest thing to a shortcut this skill has.
Writing code gets the attention. Reading it gets the results.