“The difference between a computer programmer and a user is much less like that between a mechanic and a driver than it is like the difference between a driver and a passenger. If you choose to be a passenger, then you must trust that your driver is taking you where you want to go. Or that he’s even telling you the truth about what’s out there. You’re like Miss Daisy, getting driven from place to place. Only the car has no windows and if the driver tells you there’s only one supermarket in the county, you have to believe him. The more you live like that, the more dependent on the driver you become, and the more tempting it is for the driver to exploit his advantage”
– Douglas Rushkoff
Rushkoff may appear to be making an argument commonly made by those who see the world through the prism of their own particular expertise. The mathematician will argue we should all learn to think more mathematically. The scientist, we should be more scientific in our world view. The artist, philosopher, psychologist, and so on, in turn might argue that in order to make sense of things, you need to be able to understand the world through the tools of their particular craft. But does Rushkoff’s claim have more to it in this particular technological age? Is there a special need to learn programming, in the same way we accept everyone should learn some maths; how to read and write? To answer this question, I consider the core difference in learning to program versus other technical endeavours, examining one way in which this might change our way of comprehending the world.
To begin with, its worth considering what is involved in learning to program. Like learning other forms of science and engineering, there is a blend of formal and experimental approaches available. In the former case, you learn from books and websites about syntax, data structures, algorithms, the mathematical and scientific theories underpinning computing then move on to patterns drawn from examples of prior art. In the latter case, you go ahead and build things using trial and error, familiarising yourself with the machine and the idioms of the problem domain that interest you (for example, how to build a website, game or robot). The balance between these approaches is largely down to individual preference but without pushing in both directions, eventually the practitioner will be unable to justify their methods, collaborate effectively with others or think of novel approaches to solving problems.
So far, there is nothing particularly unique about programming in this regard. This is an extension of the type of practical learning we do as children. We try things out, we learn why things work, we formalise the experience of others and try to generalise them into laws of some causal regularity. If we stop playing and stop reading, our ideas become fossilised and our ability to integrate ourselves within a changing world evaporates.
Where programming is perhaps most distinctive is in the ability to test hypothesis and iterate through different scenarios in rapid succession at negligible cost using virtualisation. The model of reality is the reality in programming. This virtuality is empowering through its immediacy. Immediacy in programming has a distinctive feeling which must be as close to real magic as humanly possible: imagination turns intent into effect with a mild exertion of effort.
In programming, testing new approaches involves changing the instruction set given to the computer, compiling the code down to machine understandable form and executing it (in some cases, compiling and executing is combined into a process of real-time interpretation). Changing assumptions is cheap early on. This allows a programmer to hypothesise freely and rely on looser heuristics in more cases than is typically feasible in other forms of engineering. Programmers routinely construct their worlds without sitting down and doing the necessary maths to see if it will work. The code is the formula, the model and the reality all in one.
This is not always the case, of course. For highly sensitive tasks such as those involving the lives of human beings, efficient and safe solutions require upfront effort, as much thinking ahead for programmers as they do in other technical disciplines. Likewise, for complex systems, typically composed of many sub-systems, teams engage in careful design, sometimes with scientific rigor. However, for exploring the problem (through prototyping) or in any project able to be completed by a solitary individual, the use of high levels of abstraction allows a programmer’s gut feelings to lead on creation. As alluded to earlier, other disciplines benefit to a degree from this cheapness of testing through simulation. So it is not completely exclusive to programming. Simulation was after all an early benefit of universal digital computers.
In any case, today’s programmers are used to trying things out and playing with the facts of their world without worrying quite as much about the consequences. Does this flexibility change their attitude in other areas of life? It certainly appears to at least in business and government which have become the domain of digital natives. The mantra of Agile is to iterate and build upon solutions that meet user needs today without thinking too far ahead as requirements will and do change. The mantra of Silicon Valley is to move fast and break things. Panta Rhei would be an apt motto for the age – everything flows and life is flux.
This ideology of disruption that motivates the digital economy has its roots in the freedom experienced by playing in a sandpit where the cost of rebuilding your castles is merely computing, a commodity that grows cheaper exponentially. The benefits of this mindset is a greater ability to deal with ambiguity and change but at the price of less secure attachments towards, or appreciation of, pre-existing structures. Programmers put down the cost of not looking far enough into the future as “technical debt” and the cost of maintaining ties to the past as working with “legacy systems”. Both require continued activity, a process of redefinition and obsolescence that is pervasive in digital culture. To the outsider, this flux may be rootless and unnerving. One approach to dealing with this anxiety-causing-tumult is to embrace it, to empower yourself to be in some way at the centre of the maelstrom. To learn to be a change maker, rather than a change taker.
Ultimately, this ability to cope with the world created by digital technologies is self-reinforcing and at the heart of Rushkoff’s argument. Whether this is an effective strategy is an open question. I’m not aware of any study saying programmers are better adjusted to the pace of change and the flux caused by the effects of digital technologies than anybody else. Spinning at the centre requires significant outlays of energy: programmers who wish to keep at it must continuously reinvent themselves as well as update their knowledge at a pace familiar to all those involved in science or technology today. The pace only quickens and without support from further technological augmentation, it may be unsustainable.
What seems more of an immediate concern, however, is that since the concept of the Turing Machine was invented, everything that involves calculation of some sort, everything that can be done algorithmically, will eventually be run on digital computers. If being literate and having a certain level of numeracy was essential for flourishing in the 20th Century, programming may well be essential for comprehending the world of the 21st Century. Because more and more of our lives will exist in digital form, to be unable to understand the fundamental composition of it may be as limiting as being innumerate or illiterate.
To see the pervasive digital world as mystifying because you lack the concepts to make sense of it, is in a sense to return to a premodern perspective with technology as magic. Its role in our lives then becomes much like mythic spirits: to be feared or bargained with, their whims completely incomprehensible. There can be little hope of the flourishing of human life under such circumstances.
Rushkoff, D. (2010) Program Or Be Programmed: Ten Commands for a Digital Age, OR Books.