Published: 2021/07/10
Last updated: 2021/08/23
When non-programmers speak of the discipline of programming, they almost always imply that programming is something akin to a branch of raw mathematics – that it’s purely about logic, that everything has a purpose, that computing as an industry is a mystical set of well-oiled machines composed of raw knowing made manifest.
That’s how you know they’re not programmers.
Calling programming “logical” is true to a certain extent – the computer does what you tell it, no more and no less – and it doesn’t care one bit about who you are or what you look like or any of your beliefs or delusions. However, it isn’t straight mathematical “logic” in the sense many people seem to believe, where there’s always a straightforward, canonical method to solve problems. Rather, there is always more than one way to do things, and a measure of “best” is essentially impossible to quantify in any meaningful way.
In this respect, programming is a lot more an act of creative composition, utilising many of the same skills and thought processes of, say, writing an article on a Web site. You start with formulating a goal and an outline of the steps necessary (the logic), but then each writer is free to do things their own way within the constraints of the language in order to reach that goal.
There is no “best way” to instruct someone on say, the benefits of hygiene or the dangers of untested vaccines. One can start from the top, the bottom, in medias res, whatever that writer feels would be most effective. Similarly, when programming, one is allowed a lot of freedom in how they dictate to the computer what to do.
For instance, they might decide that a simple CSV text file is sufficient for their dataset instead of a database after weighing the trade-offs, or that a problem should be solved by two distinct subroutines instead of one larger one for the purpose of later reusability; they might even decide that the traditional approaches to a problem could be improved upon and seek to create a new alternative.
These things are not acts of pure logic, but involve raw sparks of creativity. In other words, programming can reasonably be called an art as much as a science.
As an art, programming naturally has many different schools of thought, some of which compete with each other and some of which run parallel, often intersecting in unexpected ways. One example of such an intersection is the tongue-in-cheek “holy wars” surrounding text editors, the most common being Emacs (GNU or otherwise) vs Vim (the leading “vi” implementation); Emacs users tend to have a philosophy of monolithic programs that encompass a wide variety of tightly integrated features, while Vim users tend towards the more UNIX-like philosophy of having (relatively) small programs focusing on one particular task that can be chained together in various combinations arbitrarily, without a reliance on one another.
It should be noted that neither approach is inherently wrong – both have appreciable pros and cons, as this is a matter of how the art is approached, not the final results of the application of the art.
Another consequence of having multiple schools of thought and multiple approaches to problems available is that this throws huge wrenches into the idea of attempting to measure “productivity”. As a program and its programmer grow and change, this naturally calls for refactoring the program to meet new understandings or philosophies. Such growth and introspection also takes time. As such, a surprising amount of a programmer’s time is not spent typing lines into his favourite text editor or IDE, but seeking to plan and understand.
Paradoxically, this can even lead to a situation where a programmer’s most productive day can involve not adding lines to a project, but actually removing them due to the lessons learned. Being able to do so puts one in pretty good company, in fact: Ken Thompson, the father of UNIX, once said “one of my most productive days was throwing away 1000 lines of code”.
That’s a little hard to explain to managerial types, but so is any artistic endeavour. However, as with any art, the mechanics are for the medium, but the art itself is for people, both enjoyers and other artists alike, and artists always seek to perfect their art.
Said another way, “programs are for computers; programming is for humans.”
This sentiment was also echoed by Dennis Ritchie, the creator of the C programming language and another father of UNIX, when he said “what we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form”.
The existence of Free Software, IRC, and other electronic communities are extensions of this notion. Programming can bring very diverse groups of people together as they discuss and attempt to improve upon their arts, and it’s this sort of communal spirit, this care of each other and their fellow men, that drove the creators of Free Software to do what they did, creating a social movement valuing freedom for the user and cooperation above ruthless competition. Someone pursuing only logical/practical problem-solving and chasing after money wouldn’t be able to create something like that.
This truth is what makes so much of this art click into place. Keeping the human element in mind during the design process is what allows us to make sustainable technology. Things such as appropriate use of comments, elegant self-documenting design, and the way we approach and phrase our individual lines all flow from this idea. The computer doesn’t care if we approach a problem in a highly compact, abstracted way or a simpler but lengthier way, but your fellow programmer benefits dramatically when you choose the latter, and this helps your program to have a long lifetime.
Perhaps the strongest demonstration of the humanistic element of programming as a field is in how illogical it can be.
People seem to think that the programmers have a reason for doing everything they do, that elements are put together in well thought-out ways from the top down. Really, that is a shiny, mystical illusion. It’s certainly what is aimed for, but the human element, our politics and beliefs, can really hamper that.
Consider, for instance, the situation of systemd on GNU/Linux systems. It, while attempting to address a real concern (traditional shell script-based init systems have certain limitations and annoyances), vastly overstepped its bounds, absorbing tons of sub-systems, betraying the traditional UNIX Philosophy and creating massive security flaws in the process. This is not a logical series of decisions to make, nor is it logical for the distributions to blindly adopt it. Many did so because the company behind it, Red Hat, holds a disproportionate amount of political and financial power. Either they directly bowed because “Red Hat surely knows what they’re doing”, or because of the tyranny of the majority – “everyone else is doing it, so I guess we have to too”. Naturally, others, such as the author of tmux, rejected the call to homogenise and blur the lines, as did many GNU/Linux distributions, very notably Devuan, which forked the entire Debian project.
It is often surprising how the history of computing was shaped by circumstances just like this. The development of the World Wide Web, which people better-qualified than myself have gone into at length elsewhere, makes for an excellent case study.
All told, programming and the people surrounding it are both more and less complicated than appearances suggest. There’s a lot of creativity amidst the logic, and a lot of chaos amongst the order. Like anything people touch, it’s never perfect and orderly, and that’s part of what makes it such a fascinating discipline.