This is day one of our series on how to become a better developer in 30 days. During this series, I will discuss during one month 30 ways for anyone to become a better developer.

Today, I would like to talk about something that few people do voluntarily: reading other peoples code.

Writing good code is the goal of most developers, but what we sometimes forget is that in order to become good writers we also need to be good readers. This is just a reality that has been verified since elementary school, when we first learned to write our language by reading how other writers do their job.

Separating Good and Bad

What makes things a little more complicated for developers is the simple realization that there is huge amount of bad code out there. In fact, without any fear of offending anyone, I can say that most code out there is BAD code. By that, I don’t mean just code that barely works, but also code that was not made for “human consumption”, usually as a result of being written under the time pressure to make a release possible.

While this is sadly the most frequent case (for reasons that have mostly to do with the realities of the software industry), this doesn’t mean that developers cannot find good examples of code to read.

In fact, I believe that just the opposite is the case. For example, many available open source programs are written at a high quality level, and could very well be read just for the leaning experience. The Linux kernel is certainly a case in point. The whole kernel is really large, but the central routines are really well maintained and are in used by many schools as a live example of operating system internals.

Another case in point is software written as literate programs. Literate programming is a term created by Knuth for programs that are written is a style similar to an essay.  In such a style, programming language code is secondary to the description of the algorithm in English. Code enters the picture only as a concrete illustration of the comment section. That code is later on be processed by literate programming tools and transformed into an executable artifact. A classic example of literate program is the source of TeX, the typesetting software used by most mathematicians and computer scientists.

What to Look For

Whatever the style of the program you are reading, it is important to make sure that you are learning new techniques. Thus, it is important to read programs with an objective, such as to understand a new programming paradigm, or to learn how to work well with a new API. In these cases, reading code may be a much more efficient way of learning a topic than reading documentation.

One thing that I wished existed in the software development world is a catalog of software that would be interesting to read. Most APIs come with some sample code, which usually is not enough to teach anything useful. An alternative would be a resource where we could list good software to read if you want to learn a specific technique or concept. For example,  to learn how to write a kernel you can read the Linux kernel, or the MINIX. What would be good sources to learn compilation techniques, or the inner working of a database? Let me know if you ever found a resource answering these questions.

Conclusion

To become good writers it is important to read what really works. Sadly, developers don’t take the time necessary to read what other people are doing. What contributes to this issue is the problem that most code is of low quality. I believe that despite this, it is still possible to find a lot of interesting code to read. In the future, we might have a library of open source code that would be voted as great examples for each major technique and concept in software development. I believe this is a fun and useful way to learn how to write better software.

Further Reading

• The idea of literate programming was promoted by Knuth in his book Literate Programming.
• The Linux kernel is a classic example of code that has been read for its own qualities. Understanding the Linux Kernel is one of the many books that explore this fact.
• Another article with tips on reading code.

Go to the next posts of the series:

• Day 2: Write Shorter Methods
• Day 3: Keep A Programming Diary
• Day 4: Learn a New Programming Language

Similar Posts:

• Tips to Read Other People’s Code
• Literate Programming with Plain C Files
• Adding a bootsplash screen for Linux
• Day 11: Understand the Lower Layers of the System
• When Free Software is Not Free