Learning to Read Code

Usually when I write spontaneously here, it's because a topic or idea has been percolating in my mind for a while, and I will stumble across a reference or blog post that provides the necessary activation energy to jot the thoughts down in a more cohesive form. In this case, I want to grab at something that has been bothering me lately, when I observe certain habits and traits of developers: read your code! It seems simple, but the more I think about it, the more I wonder how many developers actually do this in reality. Time and time again, I run into the same situations with messy conceptual models (or lack thereof), and ugly hacks that I have to fix and tidy up. I am starting to come to the conclusion that there is a basic structural reason why reasonably skilled programmers bog themselves down. Too many developers are used to writing code and not reading it. It's usually quicker and easier to just hack extra code into a project to solve a special case or fix a bug, rather than rewriting or changing existing code which means taking on the burden of understanding what the existing code actually does.

So my suggestion is straightforward, to anyone out there who want to learn how to write kick ass software (though not necessarily easy): learn to read code. It'd not just what the code does, you have to read between the lines. Ask yourself questions about the code. What is the intent? What conceptual model is it trying to wrap around? Does it succeed? Is there a nascent pattern or obvious direction? Does the formatting reflect its structure and identity? Is it rigid or flexible? Symmetry? Choice and style of naming? Train your eyes to see through the syntax, understanding the ebbs and flows, or the 'grain' of the code, to use a woodworking metaphor. Learn to approach code purposefully and understand how refactoring can be used to tell a story,

If you're using a framework, take some time out read its underlying source code. If you're using a language, read the source code of its underlying implementation too. Out of context, a lot of this code will surely be over your head. But that's not the point - you're scanning for intent, style, understanding. Not all your high level thinking should take place in UML. Once you develop the vision for spotting regularities in syntax and structure, you'll learn how to read the general shape within a large application with much less effort than you might have otherwise thought. Being able to write good software is not just about being able to understand architecture and the bigger picture models, it's also about the fractal picture of how the tiny parts relate to the larger parts. The worst possible thing for producing good quality websites and software is to be mired in the psychological state of fear and disarray that occurs when people on a team continually try to avoid dealing with particularly messy or gnarly bits of problem code.

Maintenance programming is very much underrated in the industry, yet it is the skills involved in maintaining software that separate masters of the craft from the average mediocre developer. Good maintenance programmers have deeply refined code reading skills to the point where they are able to step into a mature software project - sometimes even regardless of language - and very rapidly absorb information and assimilate the key aspects of the system in a practical way that enables them to fix bugs and make changes with confidence in an environment that is oftentimes completely hostile to progress. It's a great skill to have, and learning to read code is a stepping stone towards being extremely good at it.