If I were to teach a course at the University level, I would teach programology. Not the study of programming, but the study of existing computer programs. In the entire course, we would only read source code. Not small snippets of algorithms, and not trivialized polished examples of code created just for class. I’m talking about the industrial gritty always evolving code that actually runs a good part of the industrialized world now. Just as in cultural anthropology you study tribes from New Guinea to understand the various ways in which human society has evolved, we would study old programs, new programs, large programs, and small programs. We would study programs developed under a variety of different paradigms.

It would be a weeder class. Writing code is hard; reading code is harder. But that is the point, being able to take an existing code base and quickly conceptualize the architecture and its design elements is what separates the software developer who can make the trivial one line fix to a problem and the one who bolts on three hundred lines of monstrous code because they didn’t quite get it.

It will also help us not repeat the same mistakes that the majority of software developers have made before us. Most new software developers start out writing spaghetti code, code without known structure, features organically tacked on and general anarchy. Most developers eventually learn from their mistake, but when given the chance to rewrite their original software they swing too far the other way. They create a huge over-designed Frankenstein creation that is fully table driven, has an intricate inheritance tree and incorporates god knows how many design patterns. If we are lucky, the developer spends enough time in the field to eventually learn from this mistake as well and finds a happy medium.

Fred Brooks described this problem as the second system effect in his book the Mythical Man-Month, published in 1975, before most software developers today were even born. Yet, the vast majority of software developers today still follow the same evolution because we don’t study source code and what factors led that source code to arise why it did. We are like building architects who have never actually studied the design of any other building  besides those we personally took part in creating. Or a writer of novels who has never read any novels besides his own. To progress as a field, we must study those who came before us.

I probably will never teach this class, despite the desperate need for it. In the end though, I say to anyone that wishes to be a great software developer, the surest way is to write lots and lots of code, and to read even more.