One Sure-Fire Way to Improve Your Coding
The most obvious way to improve your coding is to write more code. Everybody knows that. However, another activity which I guarantee will improve your coding is the complete opposite of writing. I will state this as plainly as I possibly can:
If you want to dramatically increase your programming skills you need to be reading other people’s code.
Maybe you believe that, maybe you don’t. You should. And if you’re willing to give it a shot, I believe you will be rewarded greatly for your time.
In this article I will help you choose what to read and give you practical advice on how to go about reading it. If you’re already a code reader you may find a few ways to get more from your efforts. If you aren’t, you absolutely must read on.
What to Read
This is a big decision, and one that is difficult to advise on. I won’t simply point you toward code I think you should read, because it really comes down to what you’re in to. However, I will provide some guidelines which you can follow to help you choose what to read.
» Read Code That You Rely On
A great place to start is with any plugins or libraries that you are already using.
- A WordPress plugin that you really like
- A Ruby gem that you’ve found useful
- A jQuery plugin that you keep going back to
These are all great candidates for learning. You are already familiar with their public APIs so the barrier to understanding their inner workings is lower. Also, as a user of the code you have an opportunity to add documentation, implement a new feature, or generally give back to the project in some way.
» Read Code That Impresses You
I remember the first time I saw 280 Slides and I thought to myself, “Now that is impressive.” I quickly learned that the code driving that site was the open-source Cappuccino project. I tucked that knowledge into the far recesses of my brain and when I eventually came across another impressive app running on Cappuccino I knew I had a project that I could learn a lot from. What have you been impressed by lately? Is it open-source? If so, it’s a great choice for reading since the code is likely to impress you as much as the resulting application.
» Read Code Written By Somebody You Respect
If you’ve been coding with open-source software for more than a little while, there are probably other programmers who have earned your respect. I can think of a few developers off the top of my head whose code is downright enviable.

If you don’t have a respected developer in mind, it’s easy to find one. He or she has probably authored some code in one of the previous two sections (code you rely upon, or that impresses you).
» Read Code That You Can Actually Grok
If you’re the adventurous type you may be considering diving into a large project like Ruby on Rails, Drupal, or jQuery. I suggest avoiding projects like these for now unless you are an experienced code reader.
Large projects have a lot more moving pieces, and you may end up struggling too much with the concepts to learn anything of immediate value. Confusion leads to discouragement, and larger projects more likely to confuse and discourage you in your reading. The advantage of picking a small project to read is that you can hold the entire program logic in your head at once. This leaves you with just the details to discover and learn from.
How to Read
Now that you’ve chosen some code to read, what is the best way to go about reading it? I’ve read a lot of code in my days, and I can suggest a few ways to maximize your ROI.
» See the Big Picture
I’m going to assume that you at least know at a macro level what the code you’re reading accomplishes. If not, I suggest reading the project’s website, tutorials, documentation, and anything else you can get your hands on except the code.
Okay, with that cleared I suggest your first step is to wrap your head around the project’s structure. This is a variable amount of work depending on the size of the codebase you’ve chosen, but anything larger than one file will require a little bit of time.
First, note the file structure. This step is aided by an editor that has a folder hierarchy view like TextMate. For example, here is a nice overview of the Twitter Ruby gem:

The goal with this step is to just get familiar with the source. Find out which files include/require/load other files, where the bulk of the code is, the namespaces used if any, and things of this nature. Once you’ve got the big picture you’ll be ready to dig into the details.
» Document Your Findings
Reading code should not be a passive activity. I encourage you to add comments as you go, documenting your assumptions and your conclusions as you begin to understand the program flow. When you first get started your comments will probably look something like:
# I think this function is called after 'initialize'
# What does this equation even do?
# Pretty sure this variable loses scope after line 17
As your understanding progresses you can remove the little breadcrumb comments you left yourself and perhaps write more meaningful and authoritative comments that could possibly be committed back to the project.
» Use the Tests, Luke
Hopefully the project you’ve chosen has a test suite. If not, you can skip this section altogether (or find one that does).
Tests are a great place to start whenever you read somebody else’s code because they document what the code is supposed to accomplish. Some tests are more informative than others, but no matter how well written, you’ll often find the programmer’s intent in the tests much more easily than you’ll find it in the implementation. While you’re reading, try to get the test suite to run successfully. This will make sure your development environment is configured properly and will make you more confident when making changes.
» Execute, Change Stuff, Execute
Who said reading code had to be hands off? You’ll really start to understand things once you’ve broken everything and put it back together again. Remember those tests you got passing? Make them fail, add some more, or try changing the implementation without breaking them. Try adding a small feature that you think is cool, or setup project-wide logging so you can print output at various stages of the code. Is this still reading? Absolutely, but at this point its more of a choose your own adventure than a mystery novel. And that’s a good thing!
» Rinse and Repeat
Once you finish reading one codebase, pick another one and start the process over again. The more code you read, the better you get at reading it and the more you get out of it in less time. I think you’ll find that the ROI increases quite quickly and that it’s actually a very enjoyable way to learn.
Where To Start
The single most influential factor in my code reading is GitHub. The site makes it so easy to find new projects and great coders that you’re doing yourself a disservice if you’re not leveraging it. I suggest starting on GitHub and reading code right on the site until you find a project you know you can learn from. Then git clone that baby and get to reading!
How about you? Do you read code as a learning tool? Which projects would you recommend to others? Read any good code lately?
Jerod Santo is an Editor at Fuel Your Coding and a contract software developer at RSDi where he works daily with Ruby, JavaScript, and related technologies. He loves shiny toys, powerful tools, and open-source software. Learn more about Jerod by visiting his homepage or following him on Twitter.


Use the source, Luke!
That was an awesome play on words. I have to remember that :)
Absolutely! I read code on GitHub daily. Mainly the inner workings of Rails. Besides making you a better developer, you will can an insight into the code you use that is unparalleled.
That’s awesome, Scott!
Ah! That should read “you will gain an insight…”
I never though about “Document Your Findings” before, but it’s really spot on. I underline and scribble all over all books I read, no reason I shouldn’t do that for code too.
Yes, exactly! It also can act as a bookmark; helping you pick up where you left off reading last time.
Wow – quite true. I love dissecting the code of others to discover new tricks, especially stretching myself in areas in which I’m not proficient.
FWIW, there’s an excellent book on this very topic by Diomidis Spinellis:
http://www.spinellis.gr/codereading/
Don’t be dismayed by the publication date, it’s still very relevant.
Excellent post. Thanks a lot :-)
One other type of code to read: code that you want to change. Once you try it, you’ll find that it’s not that difficult. When you come up with a possible improvement in an open source project you’re using, go read the code and try to implement it.
Excellent point Diomidis, I can’t believe I missed that one.
I’m sure you have a lot of input about reading code, seeing that you wrote a book on the topic :)
Code reading skills are seriously underrated, especially among lone wolf web developers. One of my favorite interview questions is to ask if someone likes to read code. It really tells you what level of experience a person has dealing with other people’s code, and sets them apart from people who simply copy / paste snippets without understanding them.
Well said.
Another good question to ask a developer is how they optimize their code. Cleverness? Brevity? Readability?
I’m a firm believer in optimizing for readability (which sometimes means brevity, sometimes not) since code is written once and read many times.
I agree. While this is a bit dated (2004) I still try to read other good quality code bases when I can http://jcooney.net/post/2004/04/03/Good-Programmers-Read-Good-Code-What-code-should-be-essential-reading-for-NET-Developers.aspx
Learning code is a building process. You start off just getting the simple concepts like variable declarations, then move on to functions, then classes, then you start to get really anal about memory management, and latency. You become obsessed with reducing response times to your application, and eventually Colocate your own server. If you see a code snippet and don’t immediately start pondering how you could make this run faster, then you have no right to call yourself a programmer.
Whatever you do, don’t read GPL code! It’s dangerous to do so. They might try to claim everything from then on. Think about it. If you learn some trick, you got it from GPL code, so you can’t use it at a real company.
If you learn a trick from GPL code, you can rewrite it yourself using the same idea. GPL doesn’t work like patents; it affects code, not ideas. You can reimplement the same idea yourself and license it as you wish.
I think Terry was being a bit facetious, but you are right, Nicolas.
Thanks for sharing your thoughts and tips. I’ve just added a link to for my readers here…
http://muneebbaig.blogspot.com/2010/05/one-sure-fire-way-to-improve-your.html
Amazing post! I didn’t know GitHub and I’m sure that it will be a good way to improve my coding!
In the past, the best tool that allowed me to improve my code was FxCop, an application that analyses .NET assemblies and proposes modifications to improve it. I don’t know if there are also the same type of tools for other languages but it’s a great way to follow good programming practices and learn how to optimize coding.
Also reading MSDN sample code was pretty interesting.
As you begin to understand a code base, it’s important to try to evaluate the effectiveness of the techniques used, the way the code is organized, and other factors that indicate its quality. You can learn from reading both good code and bad code, but in different ways: good code can show you things to try, while bad code can show you pitfalls to avoid.
Bear in mind that even a popular, well-established, useful project may not be so great under the hood, or at least may have a few messy parts. Don’t blindly emulate code without thinking about the benefits (if any) of doing things that way.
Well said. Thanks, John.
Great Points!
I am contiually amazed, when searching for a solution, that I typically find the resolution in many forms.
There is usually one piece of succinct piece of code using 4 or 5 lines. And, invariably another solution, acheiving the same result in over 100 lines!
As developers, our paradigm needs to be the beauty and effectiveness of the result, not the expressing how much knowledge we have in code.
Code is never a case of more is better.
Wow! You’ve really opened my eyes. I’ve been an avid reader for pretty much my whole life and I’ve even taught college classes on how to read (textbooks, philosophy books, whatever). Thank you for showing me how to translate those skills over to my programming activities (I’m a hobbyist really).
Seriously, most OS projects are the best source to learn how NOT to do it. Few of the projects out there in the wild are even worth looking at if you want to learn how to do it right.
So far the best source for quality code I’ve found is codeproject.com, just stay with articles rated 4.3 or higher. They are rarely whole projects so they wont help you get a grip on project design or architecture, but there are excellent methodologies, techniques, classes and objects to learn from and with.
Another source to learn from is your own code: reread your code you’ve written last year. This will be a sure mark of your progress (or lack thereof).
Beware: reading your code from a year ago may lead to tears and terrible bouts of depression ; )
I’ve been cutting code for 36 years now, but that’s how I learned programming back in the day – reading code that worked. I still have a few libraries full of snippets I’ve gleaned from the code of others. (Note to self: write one library that I can keep all of them in [probably on the day between Tuesday and Wednesday].)
Learn functional programming. Even if you are not coding in a functional style, it will help you look at problems from a broader perspective. Additionally, functional skills may become increasingly relevant in the workplace.
Good point Tim, I couldn’t agree with this more. I have been dabbling with Erlang for this very reason.
Know yourself. (your skills and flaws as a programmer).
Know your enemy. (the problem you intent to solve)
Know the terrain. (API, language, OS, libraries)
Become invinsible. (eliminate your flaws by learning)
Act. (program, debug, betatest, etc)
and you will win the battle. (finish the program and ship it)
Epic war-drum background music, anyone? :)
Well said, Master Sun Tzu, well said.
I’ve been working as a software engineer for 3 years. All of those years, reading sample codes or at times small open source projects codes have been my bestfriend in software development. I believe in the significance code reading skills. It makes the developer more independent. What’s more fun is debugging source code of others. Fixing a bug from a code without asking any questions from the code author himself / herself gives such level of fulfillment.
Great blog! Good to see more people have thoughts around this. I wrote about this in the book “97 things every programmer should know”.
One of the problems I regularly run into with code reading is the “this really needs fixing” infinite time sink. (This particularly applies to older code in PHP, Java or any other language that’s undergone significant change since the code in question was written; nobody in their right mind writes PHP 5.3 code the way they’d write the same code for PHP 4 when it was new and shiny.)
One helpful thing I’ve started doing when reading Other People’s Code that doesn’t have “properly complete” testing support is to add that using PHPUnit/JUnit/NUnit/LSMFT/your tool of choice. Benefits include:
– being able to prove that you have at least some understanding of the entire codebase (using coverage testing);
– being able to prove that any changes you make (whether refactoring or new features) have exactly and only the effects you intended; and most significantly
– being able to give something back to the community within which the code was found.
That last item is a beautiful Trojan Horse; I’ve helped a fair number of talented but under-disciplined hackers become test-infected and move on to being more deliberate craftsfolk of high-quality code that their community can be proud of. And that’s a fantastic feeling.
A brilliant read, Jerod. I’ve never thought about it before, but I now realise that my biggest leaps in code-learning were when I had to work with an open-source script or a plugin that either didn’t do exactly what I wanted, or was broken and the support behind the plugin/code wasn’t enough. I had to go in and dissect it and find out what made it tick so that I could make it work the way I wanted it to. I’ve never thought to ACTIVELY try this.
I am SO bookmarking this.
Thanks for this information.. :).. I enjoyed reading this, very informative article.. cheers!!!
That’s pretty well how I learn. I read online tutorials, read other people’s code, and then dive in and try to hack something up.
Of course, I’m pretty well a hobbyist, never went to school for this stuff.
My first language was tcl/tk, and the http://wiki.tcl.tk was the best teacher, making it very easy to learn that language.
Excellent post, thanks for sharing it :).
I’ve been reading uncountable line of code because reading code is my hobby and also an intrinsic part of my job. Unfortunately although I could choose what code to read as a hobby, in my job I have almost no chance since I read code from other developers in my team and it’s often not so good, if (people think) it’s well-done it doesn’t need me as a code reviewer :).