Don’t Just Read Other People’s Code: Understand It!
Becoming a Better Programmer
The Internet’s software development stratosphere is forever spewing forth lists of N steps to becoming a better programmer. Among those touting their personal take on the road to code nirvana, I’ve noticed a single step that seems to be almost ubiquitous: read other people’s code. Since reading the perfectly distilled common sense of Steve McConnell’s Code Complete a few years back, I’ve always considered this to be a stylistic thing: when you read other people’s code, you do so to improve your own aesthetic.
McConnell’s book encouraged readers to (and I’m paraphrasing here) take what they found in the code of others and evaluate it. I took that at face value at the time (and I have ever since), and used others’ code as a judge of good style. If somebody’s code was easy to read, I’d integrate elements of their style into my own. If the code was … uh … labyrinthine … well, I’d tend to lean away from the styles in play. Easy.
The Goal is to Grok
Some time ago it struck me that maybe, after all this time, I’ve been quite wrong about what I should be focusing on when looking at others’ code. I think the one thing I’ve dearly undervalued in all my years of programming is this: reading code is just a step on the long path to understanding it. That is, don’t strive to merely “read” the individual statements in a source file. Develop a general understanding of how the system fits together as a whole and at multiple levels of granularity. My narrow-minded approach was never going to be nearly as effective as truly understanding more complex code bases.
Style is doubtlessly important, but there’s more to be gained from reading code than merely what works stylistically. There is really so, so much more to take from the nitty gritty of the implementation details of even the most poorly constructed software systems. By all means, discard the stylistic abortions of programmers who don’t care for aesthetics or code of a language which doesn’t necessarily lend itself to the problem at hand. But damn it, play with it. Become familiar with how all the little ugly parts of a system fit together. Step through the interesting bits in a debugger, watch the data move around, watch the state changes. Read the documentation back to front. Know the libraries, know the subsystems. Come to know the code, the software and the domain at a level you never thought possible when you first started playing with it. Understand it! Again, I guarantee you’ll learn as much from all the bad code you encounter as you do from the good - but only if you take the time to fit the pieces together.
Finding direction
Having said that, slogging through code for software you find mundane or boring is going to both test your patience and limit your potential for learning something new. Pick an open-source project (or two) that interests you and spend a few weeks or months tinkering with it. For example, you might be interested to learn how Pidgin/Gaim protocols and plugins are handled internally, or how JEdit’s editor component is rendered. How does Glade work? Delve into the source code behind your favourite libraries like wxWidgets, GTK+ and Qt/KDE and see how user interface libraries are built. How do Mono’s C# compiler and Python’s internals tick? How do you implement a robust HTTP server like Apache?
There’s a lot of code out there, so much to learn and a lot of smart people. Don’t be afraid to get your hands dirty with non-trivial projects, even when it’s initially frustrating to understand the basics of an unfamiliar domain. Understanding complex software systems will make you a better programmer and help you grow as a professional.