I don't recommend reading code for an exercise (at least not by itself). I do recommend modifying code as an exercise though. There are lots of pieces of code that are deceptively complex: they look simple, but come to a grinding halt when you make the slightest change. Thus, it's important to know that there's a difference between what code is doing and what it looks like it's doing.
This teaches a few things:
1. How to read code
2. How to write code
3. How not to write code. When you encounter the grinding halt effect I mentioned above, there's a good chance that's how not to write code (but maybe not, some code is naturally tricky).
Good point. In the article I also point out that you should not be reading code passively. You should be running the tests, executing the code, breaking stuff, and trying to fix it.
I noticed that. Perhaps my point is more of a semantic one. It still seems to me that the article seems to focus more on the reading than the modifying though.
This is also a great exercise to improve your writing of prose, if anybody is interested. Take a well-written couple of paragraphs (Hemingway, etc.), and try to write it better. It's a short exercise that teaches you the importance of the subtleties of style.
Someone should make a site where user's share pieces of code and explain why it's awesome. Allow people to comment etc. I want to read more code, but don't have to time to go find it.
I started work on it straight after I read your comment... With some luck I should have a minimal version finished by this afternoon. I'll post a link here as a response!
I've never got into thinking what features the site should or should not have, for example: comments? forum-like interface? code-wiki so people can improve the submission? user submitted code? editor reviewed, crowd votting? tags to classify code? tales of adoption in production?
Two of my friends are working on a "am I hot or not" for code that (AFAIK) has features like this. The url is http://codesmackdown.com/ but there is nothing there yet. Hopefully me posting this on-line will get them to get off their ass and release something.
Yeh, myself and another guy are writing a 'codesmackdown' site (source code here: http://bitbucket.org/OJ/codesmackdown ) as a side-project, not as a money-maker, entirely for fun. Life keeps getting in the way though.
So far the only good thing to come out of this project is that I wrote a cheatsheet for mercurial, as I'm a noob and keen to help other noobs ;-)
http://www.secretgeek.net/mercurial_flow.asp
Completely agree. In fact one of the biggest problems our office has with new hires fresh out of college, many of which are really bright kids, is that they haven't read enough BIG pieces of code.
When working alone it might not matter but when working in a team of 50 coders on a million line code base that goes across 5 continents and 10 different hardware platforms... Being able to consume and understand large chunks of code and how they fit together is essential. Personally, for any young programmers I'd suggest you practice reading and understanding large software modules... example: some big, active, corner of the linux kernel. (I'm a C / C++ systems developer so I'm biased).
These types of productivity articles have been an excuse for me to keep spending too much time on HN. The thing is, I already know most of what's in the articles, but I'm not doing such a great job of executing them. Freeing up time by spending less time on HN could help. So, perhaps finding these articles the way I do is a net productivity loss.
Of the articles I've read on the topic, though, I think this is a really good one. I like the point about seeing how something you really like is built. I think this must be how people get started with Cappuccino. It's weird, but it does some really neat things. The same could be said of Cassandra.
Edit: I just realized this comment reads like a Yelp review. It starts completely off topic, and gradually gets on topic. Please forgive me. :)
For a mind boggling good time (If you can have that in C) take a look aftr.c. This is Comcast's open source ipv4 -> ipv6 routing code. I'm not saying it's pretty... but if your interest lay in C and systems level bit twiddling it's 13000 lines of good times.
I learned programming on the Apple ][+ by typing in programs and then modifying them. Nothing forces you to read the code better than being forced to type it in!
Reading code on a computer can be tedious, and only a few relics like TeX are available in print. Fortunately, two recent innovations make reading recent code much more pleasant: Github and the iPad. Try it some time.
This teaches a few things:
1. How to read code
2. How to write code
3. How not to write code. When you encounter the grinding halt effect I mentioned above, there's a good chance that's how not to write code (but maybe not, some code is naturally tricky).