DAVE'S LIFE ON HOLD

Learn how to read programs

There's this topic du jour in which everyone and their brother is touting that everyone should learn to program. And it is one of the most wrong headed ideas to grace the technoliteratti sphere of influence. Sure if you need to hire a bunch of grade-A brilliant ├╝ber programmers, you want as many potential candidates to display incredible brilliance. And if you're looking at your current stable of talent, how can you turn that awesome sales guy in your cube into sales bot. Surely if your sales team can code programs, they can do their own analysis and create empirical projections on which leads are better than others. If only they knew how to code, they could automate their jobs and spam the fuck out of your potential customer base, and track their conversion statistics themselves. Obviously, every kid should learn Java or C# so that they can build their own Facebooks and IPO.

The reality is that rather than have everyone learn to program, we should first have every existing programmer learn to read programs. If the existing programmers learned to read other people's code, they'd discover 95% of everything they think they need to write is already written, the remaining 5% can usually knocked out in a week or two. If programmer learned to read programs and studied the work of other programmers, they would also learn both humility and develop a sense of style and taste. The endless flamewars of language versus language, idiom vs idiom, ideology vs ideology, quickly fall apart when you read enough code. You'll quickly realize that more bugs are a result of poor choice of words than are due to typing, fragile base classes, exception handling, convoluted flow control, lack of test coverage, or in appropriate data structures combined. Most bugs are a result of a programmer getting themselves in a muddle, and banging on it until their test case works. They bang on the code, because they don't know how to read it. They learned to program, not to read programs.

This bias carries into how managers often judge work output. Once, many years ago, I was working on a project where in the project manager (accustomed to working on large outsourced code bases) was counting SLOCs as the basis of productivity. He didn't bother reading the code, or looking at the comments, or even trying to run it. He ran it through wc -l and called it a day. Imagine his glee as the project over the course of months grew by a steady 500 SLOC per week (about 100 lines a day) for a single programmer. And then imagine his horror when, that programmer's total SLOC went from 15k to 12k one week, 9k the next, 6k the following, and finally 3k when that programmer claimed it was done! I remember sitting in a meeting with my business partners, the PM, and explaining that the final work output was only 3k SLOC for 6 months work, and the PM insisted it could not be done because I had less code than I started with a month ago. Had he read any of the code? Of course not! Had he read it, he would have seen the 15k SLOC consisted of about 9k SLOC of "failed" experiments with various AI models (this was a poker app), 3k was cruft removed when I finally refactored out the shared bits of the "winning" experiements. The remaining 3k, was the code that would run the entire backend for the business. The design as a small statemachine engine of about 300 SLOC, and 2700 lines of plugins that provided business logic to the statemachine. When the PM then brought in an off shore team to maintain the code, the response the Indian programmer in charge was "you can't do that in Python!" He had never read the guts of the CPython implementation, had never read code anything close to what I wrote, and didn't understand the language in anything more than most superficial layer. He couldn't read my 3k SLOC (which had about 3k lines of comments) because he never learned to read programs.

When I write programs, I use a series of tools I've created for myself to judge the effectiveness of my work. I aim for concise functions, which describe a singular behavior. Each of these functions are then combined in higher order functions which perform some additional aggregate level of behavior. These are combined at higher levels, and so on, until the program describes the solution on multiple levels. My goal is for the audience to be able to read the top level description and understand in broad strokes what it does. For example, here's a virtual device driver base class for a JavaScript framework I wrote:


An.object().
named('Device').plural('Devices').
does('dispatch', function(M,E)  <br>		Widget.widgets().every(function(W,J) { <br>			try { if (W.can(M)) W[M](Event.init(E))
catch(X)  console.error(X)
})
return this
})

What this code does is declare an object with a name Device that will dispatch events to every widget registered with the base Widgets class. If a widget can respond to the message associated with the event, it is passed a new event object and invoked. Any exceptions are caught and logged. There are a few conventions in this code that one might find unusual. An is an alias for the A global, which acts as a framework specific global object, into which all of my objects are registered by the named and plural methods. The object() method is a constructor for a generic JavaScript object, but has applied a number of extensions such as the methods invoked in the sample. The does(method,function) method not only hides an assignment, but allows us to protect against unintended overrides on a per-object basis (as it can be overridden too). By learning to read this example, we can learn how the structure of the language is being used to drive home the meaning of the code. This influences how we will read future programs. We will look for more elegant structures in other's code.

Learning to read programs is more important than learning to program. If you learn to read other people's programs, you will eventually develop the critical faculties to design programs of your own. Personally, I learned programming at a young age by reading programs. Only after years of reading other people's programs did I ever feel confident enough in my own ability to try my hand at writing them professionally for other people. By the time I entered college, I had already written my own compilers, operating system, BBS software, device drivers, and a handful of games. Before I had to register for college courses, I had a body of work that would have covered the requirements for all of the 300 and 400 level college courses. Over the prior decade, I had read more code than many of the professors who would have been failing to teaching me. I enjoy reading programs, and read the source to every module I download. I read far more than I write, and can tell when someone writes more than they read. And basic computer literacy begins with learning to read programs critically. Until we make that the primary focus for programmers, we will continue to want everyone to learn to program. And trust me, you don't want to read what most people write.