Computer programs and books share the property of having a dual nature. A book is both something tangible and intangible: a physical object that has to be packed up in a box when you move, and at the same time a story, a biography, a point of view. You can’t judge a book by its cover, but you can judge a book’s cover.
A program, in a similar fashion, is something tangible, visible although not physical, in the form of source code, and at the same time it is the set of computations that the code describes. Even the process that the program becomes when it is run has a physical embodiment in silicon: it takes up space in memory, extends over time and generates heat.
Besides the physical embodiment of the content of a book in paper and ink, there is the embodiment of the author’s ideas in the words, sentences and paragraphs they chose. Similarly, when writing code, a programmer is making choices at every step about how they are going to get the computer to do the thing they want it to do. Like a writer clothing abstract ideas in the concrete form of language, those of use who earn our living by writing code have to know how to translate our ideas into the form of a programming language.
While it is not hard to see how mathematical training and aptitude will help you with this process of translating ideas into bytes, I have a pet theory that good reading comprehension skills contribute more to writing good code than is generally acknowledged. I’m not aware of any studies ever having been done along those lines, but it matches my own experience, as someone more comfortable with words than mathematics, who has nevertheless been able to make a career out of programming computers.
My Code Story
I had almost earned my Bachelor’s degree in English before I discovered programming, and threw myself into learning everything I could about the subject. It did not happen overnight, and I did have to spend a fair amount of time getting caught up with the mathematical concepts that really are important for a programmer to have a facility with, but today I consider myself very lucky that I now get paid to read and write all day, even if it is Python rather than prose.
I chose English as a degree not because I believed that my life’s work would be to write novels. Rather, it was because when I started my higher educational career I did not have a clear vision about what I wanted my life’s work to be, and found that the ideas discussed in my English courses grabbed my interest and wanted to explore them more. I do believe that my experience as an English major contributed to my programming career, at the very least in the indirect sense that the confidence to pick up a whole new area of study, such as software engineering, came only after I had the opportunity to discover that I was good at learning new topics and applying them, and that I actually enjoyed this process.
Code and Prose
One aspect of reading comprehension that seems especially useful for a programmer is the ability to understand something in context. When learning a new code library or programming language, having a reference is indispensable, but equally so is having examples, either code snippets or tutorial examples, as these put the isolated set of facts—class and method names, method parameters and exceptions—into a context and gives them a reason to be. It is one thing to know that a certain class exists, another to know why it exists, and it is often seeing an example of how the class can be used in some actual code that illuminates that why. To put it in journalistic terms, the reference gives you the who and what, while code examples give you the when, where and why.
There are a number of similarities between code and prose when it comes to the process of writing and editing. When proofreading either, you may identify a syntax error, see a typo, or catch a reference that is not matched to what you meant it to be. You start out by dumping all of the ideas in your head and then spend a lot of time pruning what isn’t needed and shaping what remains. You see a sentence that belongs in another paragraph, or a method that belongs in another class. You see a paragraph or class that needs to be broken down into smaller pieces. You see a sentence that could be changed to express the same idea more succinctly or a section of code that could be reduced to fewer operations. You take another look at what you wrote a few days later and see twenty things you want to change. Higher order concepts jump out to you as you put down your thoughts. You never exactly finish a program or essay, you just get close enough to what you envisioned at the beginning to feel alright with it and move on to something else.
When reading over some code you’ve written, you are doing something like “executing” the program in a metaphorical abstract machine in your head, completely implemented by the mental model you’ve developed of how code is executed, however limited that model is. Similarly, reading over some prose you’ve written is something analogous to executing it.
Of course, there are many things you are concerned with on most programming projects that do not have an analogue for the prose writer: performance, security, team coding standards. And while there are feats of programming which can be celebrated, and you can certainly take pride in your work, it is a rare case when code artistry is an end in itself. The code you write today may be rewritten or removed when the language, the platform or the requirements change.
It isn’t anything very controversial to state that there is an art as well as a science to programming. When writing code, you are employing some amount of formal thinking and some amount of informal thinking, and any individual programmer will have their own combination of strengths and weaknesses in both. I won’t try to make any overly-broad statements about the relative merits of the two aspects, and any team will benefit from having members who bring different levels of facility with both to their work, but I will say that in the current world that a professional programmer works in, where any set of functionalities which require deep CS knowledge will likely be available as a library, but where working in a team is an everyday reality, the importance of the informal aspects of programming, the ability to apply compositional skills and to express yourself in a manner understandable to your peers, can’t be overlooked.
Should You Read (Jonathan) Swift to Learn (Apple) Swift?
I don’t want to give the impression that I am advocating for all programmers to start reading Tolstoy in the hope that it will make them better at writing JavaScript, nor that I think that improving one’s reading comprehension skills is the most direct path to better software. Any given problem can be handled in multiple ways, and as I mentioned above, any given development team will benefit from a mixture of abilities. Simply, my experience tells me that the skillset related to reading and writing is more relevant to software development than is generally acknowledged.
Leave a Reply