Most lay people and programmers early in their career begin with the assumption that we write code to communicate to the computer what we’d like it to do, and how. While this is partly true, it misses a much more important audience; people. And for much greater reason than humans must be able to maintain it.
Early in the days of computing, code was indeed written solely for the purposes of getting a computer to perform some calculation or task. People wrote code in binary, hand toggled it into a machine, and hand translated the outputs back into a form to be understood by humans. But it did not take long before we devised more convenient forms and tools to make the code and the machine’s outputs more easily understood by humans. After the decades of research that followed in computer science and programming language design, I contend that software can now be much more powerfully thought of as a formal specification for knowledge documentation and use.
As an example, large volumes of text have been written on every subject imaginable, as ways of transferring knowledge from human being to human being. Particularly in fields of science, text books are written to describe observations and assumptions made, deductions that can be followed, conclusions drawn and their implications, all supported with models, mathematical equations and logical reasoning. As an example of where we’re headed mathematics was developed as way of providing concise notations and methods of reasoning about numerical concepts. It was then adopted by science as a way of precisely documenting the knowledge arrived at about how the universe behaves.
In the same vein, computer science and programming language design have been developed as ways of making the intentions of the programmer (i.e. the knowledge they wish to document) easier to describe more precisely and formally, in ways that are clearer to human readers. In this light, software can be seen as the precise, formal notation for documenting any human knowledge and/or desire in the same way that math can be seen as the precise, formal notation for documenting the nature of the universe. Strangely it seems this even managed to occur without it ever having been clear that that was the actual goal. The goal was more about making programers more productive. But of course programmers are more productive when they can more easily understand the knowledge (code) their colleges have documented (developed).
But that’s not all. Looking at software this way, we can surmise why it has so quickly “eaten” the world and become so ubiquitous. Because it is so formal and precise that it can be executed by a machine, it allows other human beings to put that knowledge to work without having to first understand it themselves! I can take a piece of software written by someone else, and knowing only a bare minimum about how to interact with it, let alone its inner workings, use it to accomplish some goal. For instance, I know next to nothing about how my web browser works, the java script it’s running to allow me to write this blog post, the networking software used to transmit it back to some server, the database engine used to store that data, or whatever allowed you to find it, but I have still managed to communicate this message to more people than I’ll probably ever know. I can’t do that with an engineering text book.
Now don’t get me wrong, I’m not simply going to tell every developer I know about this and magically we’ll all have better software. Unfortunately it’s not that simple. Learning to write software this way is a bit like relearning how to write an essay. You probably weren’t very good at composing a sentence when you were 6, you probably still weren’t great at composing paragraphs by 8, and probably just starting to improve at writing essays by the time you were 10. It takes years of study to get good at writing clear, coherent prose. And it takes years of study to get good at writing clear, coherent software. I’ve been at it for nearly a decade now and still come back to code I wrote 6 months ago thinking “this could be so much better.” So practice. It might be a year or two before you’re really good at writing clear and concise functions, another couple years still to compose coherent modules, and more years still before you’ll be writing whole systems you and your colleagues will be proud of. And even then you’ll still come back 6 months later and go “eh, this could be better.”
But don’t stop, because you’re at the forefront of documenting human knowledge, and making it a powerful tool for people who won’t even have to understand it.