I wanted to discuss something pretty giant topic that I’ve come across time and time again while teaching myself good coding practices. I’ll introduce it with a basic question: Do you know how to read code?

Oh, you do? Are you sure? Because I’m not talking about your own code. I’m talking about other people’s code.

Maybe you’re sitting here thinking to yourself, “why would I need to know how to read other people’s code?”… or perhaps you are nodding your head sagely, having been in a situation where you needed to call upon this invaluable skill at some point in the past.

I’m personally still not very good at really figuring out what other people’s code is supposed to do unless I have an abstract telling me, so I’ve been honing in on code-reading as a skill alongside problem-solving.

But knowing how to read other people’s code is incredibly important, and I’m going to tell you why.

Programming is Literature

The importance of knowing how to read code has been an oft-discussed topic, alongside learning to write code. In Peter Norvig’s Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, he approaches the topic of coding from an angle that programming is literature.

What does that mean, exactly? Well, for example, no serious writer would try to write without first having many of the Great Works. In order to write a masterpiece, you need to know what a masterpiece looks like, and whatexactly makes it a masterpiece. To draw another parallel, Cunningham & Cunningham OOP development agency says on the topic of reading others’ code:

Great creative musicians don’t create in a vacuum. No matter how great they get, they still constantly absorb inspiration from what other musicians are doing. Programming might be different, but it’s not as if one day you will read your nth program and then have ‘finally learned to program.

Now, this is not to say that every website or program you will come across will be a masterpiece. Often times, you may be looking over a fellow newbie’s HTML, some scrapped-together JavaScript, or a sloppy Ruby file. That’s okay.

However, as time goes on, you’ll want to gradually increase the complexity of the code you are reading to match your knowledge and skill sets, as well as the quality of the code you are reading to see the most efficient ways of solving a problem.

There are a couple of different types of scenarios you will encounter as a web developer, in which you need to translate someone’s code in order to understand what is going on, and even possibly debug the code:

1. A web page’s source code, or the HTML/CSS/JavaScript rendered by your own browser
2. A web application or program on the back end (could be any language supported by a server)

Navigating a Web Page’s Source Code

Have you ever checked the source code of a website you were visiting? If you have, you were probably either hunting for some type of hint as to the basis of some behavior on the site, or you clicked something accidentally and thought you broke your computer. Whichever it was, you were likely met with lines and lines of code that your brain may or may not have been able to comprehend.

If you haven’t had a chance to look into any websites’ source code yet, go ahead and take a gander. Don’t worry if it’s overwhelming — the fact that you’re even looking sets you apart from most other denizens of the interwebs.

PC

• Firefox — CTRL + U (Meaning press the CTRL key on your keyboard and hold it down. While holding down the CTRL key, press the “U” key.) Alternatively, you can go to the “Firefox” menu and then click on “Web Developer,” and then “Page Source.”
• Internet Explorer — CTRL + U. Or right click and select “View Source.”
• Chrome — CTRL + U. Or you can click on the “Menu” icon in the upper right hand corner of your Chrome window. Then, click on “Tools” and select “View Source.”
• Opera — CTRL + U. You also can right click on the webpage and select “View Page Source.”

Mac

• Safari — The keyboard shortcut is Option + ⌘ + U. You also can right click on the webpage and select “Show Page Source.”
• Firefox — You can right click and select “Page Source” or you can navigate to your “Tools” menu, select “Web Developer,” and click on “Page Source.” The keyboard shortcut is ⌘ + U.
• Chrome — Navigate to “View” and then click on “Developer” and then “View Source.” You also can right click and select “View Page Source.” The keyboard shortcut is Option + ⌘ +U.

There! Now we’re cooking. With the source code open, let’s take a look at some of the different characteristics of website source code, which will probably contain predominantly HTML, and perhaps some inline CSS or JavaScript (though hopefully not, because that’s not ideal).

The <head> tag — This is the first section of the web page’s code that you will likely encounter. With the exception of the page title, everything between the <head> and </head> tags is not visually rendered on the webpage itself — it stays hidden inside the source code, dictating things that you can’t actually see. Generally, this is also where you will find references to other files that the HTML file you are viewing uses to make things appear the way they do, such as CSS stylesheets, and the occasional JavaScript file.

The <body> tag — The body section makes up the vast majority of the source code you’ll be looking at, and all of the webpage’s visible components are contained within the <body> and </body> tags. Here you can see all of the coding that goes into making components appear the way they do, from headers, to paragraphs of text, to images, and beyond. In other words, the actual content of the site goes inside the body tags.

<div> tags — You will likely see a lot of <div> tags within the body section. Divs (or divided sections) create divisions in the content of a page, using an ID specified within its tag. Generally, this will appear as <div class=”…”> or <div id=”…”>. This ID references CSS code that tells that division where to be placed, how big it should be, how it should be behave, and other styling properties including colors, border, and margins. A well-designed, modern website uses mostly <div> tags to place content.

Alongside being able to identify different sections of content within the <body> and important linked stylesheets/JavaScript files in the <head>, another invaluable tool is stored inside your browser: the Developer tools. Knowing how to use the developer tools correctly and effectively can help you quickly locate the source of problems with styling these sections.

In addition to using Developer Tools for style and Document Object Model (DOM)-related tasks, they also offer a localized JavaScript console, where you can test out code separately from your programs. Google has put out an excellent repository of information on its Developer Tools, and Treehouse has also covered “Mastering the Developer Tools Console” on its blog.

Navigating a Program (In Any Coding Language)

While there are a plethora (and growing!) number of different languages out there to code in, the basics of coding are still the same. Every program that you encounter has been written to accomplish a certain set of tasks, and may include many smaller programs inside of it. As a result, reading other people’s program code can be a complex ordeal, as you weren’t in their head at the time they wrote it.

There are a few things you can do to make things easier on yourself when you approach another person’s program.

1. Read the comments

Comments aren’t just a superfluous line of text to be overlooked in favor of code that actually does something — they serve an important purpose. Since we weren’t there when the author wrote their code, they provide important direction and instruction on how the code works, and what it’s trying to accomplish.

If there are no comments… well, take it as a lesson, and perhaps contact the author to bring this to their attention, especially if it’s an open-source project you are peeping.

Commenting your code is incredibly important, for yourself and for your peers reviewing your code. Without comments, the overall purpose of your code may become lost in translation, or at the very least, frustrate your fellow programmer as they spend way more time than they have to figure out what you were trying to do.

When writing your own code, writing the actions of your program out without using actual code (or “pseudo-coding”) uses comments, and there’s often no reason to delete them entirely after you flesh out your program.

Once you know that your program works, it’s a great habit to go back through your comments and make sure that they all align closely with the code you ended up writing. This way, as you learn more, it makes it easier to go back and improve on code that you could write more effectively or memory-resourcefully.

In addition to comments, GitHub repositories should have a readme.md file that will explain what the program does. This isn’t always the case, but again, take it as a personal lesson as well — include these important files in your repositories so others can follow your objectives!

2. Start with what you do know

Alex Coleman of Self-Taught Coders wrote an excellent piece, “How to Quickly and Effectively Read Other People’s Code“, in which he responds to the common question. Alex advises to find one thing you know the code does, and trace those actions backward, starting at the end.

For instance, if you are reading a program that you know generates a file, find the exact line where that file is generated, and work backwards to see how it arrives to that action.

When navigating the unknown, start one step backwards from that final action: the program places the information in the file. Prior to that, you know that the information must be retrieved from somewhere, and you can likely figure out where it came from. And so on, and so forth!

3. Believe that you know what you’re looking at

This isn’t a “pep talk” so much as an affirmation — all code can be translated to “pseudo-code”. After working backwards as in the previous step, you will almost certainly have at least a cursory understanding of what is happening here.

So don’t get overwhelmed if you have to refer to a codex or other documentation/resources to work out the details. Perhaps you don’t know what a certain function is doing. Highlight it and move on if you are able to at least see its output, or take a moment to Google it.

For ultimately effective searching, you’ll want to use something like “language_name function_name” in your Google search, rather than just the function name, as they can be repetitive across multiple coding languages.

4. In the long run, expose yourself to high-quality code

In other words, don’t read my code. Ever. (Just kidding. Sort of.)

I did not use the term “great works” at the beginning of this article facetiously. By exposing yourself to well-written code made by experienced programmers, you are subconsciously taking in the methodology they follow, as well as their best practices.

If you read poorly-written, non-semantic code, you will likely emulate the same when writing your own. And yes, although we all start writing garbage code, our ultimate goal is to move on from that point as quickly as possible!

5. Try watching live-streamed programming (or pair programming with a peer)

Free Code Camp announced in its most recent Medium blog update that they would be pushing to increase the number of hours of live-streamed programming on Twitch.tv. You may be thinking, “Watching people program? That sounds incredibly droll” — trust me, it is.

However, it’s one of the best ways to watch the coding process from start to finish in real time, and ask questions as you encounter them. Watching other people program in real time also gives you insight into other people’s coding processes, and helps you develop good habits, regardless of whether or not they are a master themselves.

Please Don’t Shy Away From Others’ Code!

“Know that the longer you’re programming — and thus the more code samples you see, of all different kinds — the easier it gets to understand other people’s code. And the faster you’re able to do it.”

— Alex Coleman of Self-Taught Coders

Hopefully, you’ll go forth and be more courageous in your code-reading. If you’re uncomfortable with what you’re reading, note what parts make you especially confused, and try to find something a bit easier.

For an excellent resource on the front end (HTML, CSS, JavaScript), try perusing Codepen. Free, and very user-friendly, many front-end developers use this site as a sandbox. With input and output side-by-side in your browser window, you can even fork (or copy locally) someone’s project and fiddle with the code yourself in Codepen to ensure you understand what is happening. There are also some really fun projects up there that may inspire your next one!

On the back end, I recommend you sign up for GitHub and start digging into some of the most popular repositories. You can view a file from right within your browser, and if you wish to improve on the code, you can edit it in your own forked version and create a “pull request”. If the author likes your improvements, they may choose to implement them into their programs!

(FYI, what I just described is open-source programming by definition — more on that soon! 🙂