If you’ve ever attended a history class where I’m from you will recognise this familiar diagram.
This is known as the “Krzyżanowski sinusoid”, named after Julian Krzyżanowski. The idea behind it is that it shows a progression of historical periods, as seen through the lens of their approach to reason. The epochs above the line are closer to Earth, materialistic, rational and progressive. By contrast, the periods below are more ephemeral, associated with religion, emotions and decadence. It is meant to show how human thought on a civilisational scale is based on contrast, in arts, literature and philosophy.
Unfortunately, how clear and orderly as this sounds, the sinusoid is completely bollocks and has been disproven time and again.
Be that as it may, unlike many things taught to children in schools in this country, it is not completely nonsensical. There is an underlying kernel of truth in the divide between rational and irrational. However, the terms are needlessly loaded. In a society permeated by rampant scientism we have come to, unfortunately, associate the irrational with something negative, and rational with something positive. So we’ll have to redefine those. Also, the application of this in terms of prevalence in historical periods is a classic example of making the facts fit the theory, rather than the opposite.
The fundamental dichotomy of humanity and buying a car
We can find a potential solution to this issue is in Chapter 6 of Zen and the Art of Motorcycle Maintenance. It’s one of the central ideas of Pirsig’s philosophy and also one of the first ones to be presented. It’s a contrast between what he calls “classical” and “romantic” approaches to human understanding.
A classical understanding sees the world primarily as underlying form itself. A romantic understanding sees it primarily in term of immediate appearance.
This dichotomy seems to cut through almost all of human experience, but is most evident and most prevalent when interacting with technology. What is it that you look for in a car that you buy? Some might say that they want a good fuel economy, cheap used parts, low mileage. Others will just go for the car they saw in a movie or a video game when they look to get their first car.
I am in that second group. The first real car I had was a Mitsubishi Eclipse, and I got it only because it looked cool and it seemed fast even though it really was not. When I was looking through the internet for listings, I didn’t really care about the technical details but whether the car featured in one of the Need for Speed games I played as a child.
And, oh my, did it feel good to drive that Eclipse. It’s a few years later now and the car is different hands and I switched to an old Volvo — one of the old Volvos that has the reputation of never breaking down. I love how the Volvo works, it’s quiet and comfortable, the parts are cheap, it’s cheap to drive… But it does not look like the Eclipse and, more importantly, it does not feel like the Eclipse. It’s… boring.
This is the real divide between the classical and romantic mind. The classical is interested with how things work while the romantic is interested with how things feel. This leads to a certain attitude towards technology, too.
The classically minded person is a technophile. He wants to understand the machine, the technical details of how it functions and how all the parts fit together and how to fix it when something breaks. The classical thought gave us logic, mathematics, rationalism and the scientific method. It’s built upon a hierarchy of facts, which themselves are based upon a similar hierarchy, all the way down, until the fundamental axioms of the universe.
On the other hand, the romantically minded person is naturally a technophobe. One of Clarke’s laws states that any sufficiently advanced technology is indistinguishable from magic, and for a romantic understanding that technology is robbing it of its magic, undermining its beauty. What is perceived as strengths by the classically-minded is a weakness for the romantics.
Romantic programmers
Given how tied to technology programming is, one might think that the romantic mindset is entirely incompatible with this vocation. However, it seems to me that with the proliferation of high-abstraction languages and their virtual machines which are agnostic to the kind of hardware they are running on, programming has become much more divorced from technology. It is not art per se, but understood high-level it is definitely not a science either. The software craftsmanship manifesto seems to only confirm this.
It is definitely a difficult field for romantics, though. With the number of classical programmers, romantics are expected to thoroughly embrace classical values, while the inverse is rarely true. We expect that — a classical piece of software is expected to be bulletproof and work without issue, without bugs and without hitches.
With sadness though, I find that amongst my colleagues the value of the software feeling good to use is very often completely secondary. We place far less emphasis on making software that feels good.
This is not an either/or, by the way. Of course, if you were given a choice to have a piece of software that works but is a dread to use, or a piece of software that is delightful but doesn’t work — that’s no choice at all! Both are worth nothing. However, given a piece of software that works really well but is unpleasant to use, one might find more value in focusing on the feel rather than perfecting the work. And achieving a perfect balance between the two is where the quality truly lies.
And what’s important is that we should not seek quality merely in how the software is used but how the software is developed — however in this case I think Agile has practically solved it because resilient, tested and modular codebase that works well is also pleasant to develop in. And we seem to also understand that having too rigid checks is also no good — we notice that if changing one line of production code requires updating a dozen test suites then something has gone wrong.
Ultimately, though, I think that it is important that we keep this dichotomy in mind when deciding team composition. One’s particular affinity should not be an excuse to write bad software, whether it would be software that works poorly or is unpleasant to use, but rather used to perfect existing projects to bring them to the highest levels of quality.
Aside: typing and pleasantness
One would be hard pressed to find a topic more contentious than the debate between static and dynamic typing. Even in the JS community, there is a significant split between those who prefer pure JS and those in favour of TypeScript. There are good cases both for and against widespread adoption of TS and I’m not one to take sides in this.
However I would note that from my perspective, TypeScript seems nightmarish to use and it’s particularly because of that I never really got into it and the claims of its greatness never seemed that impressive. I think, based on that, that one’s particular attitude towards statically or dynamically typed languages might betray one’s position on the classical-romantic axis.
Type safety is a strictly classical value and not having to write types too much is a strictly romantic desire (we really just want things to happen). That’s why the idea behind something like ReasonML, which is a statically typed language with fantastic inference, is really appealing to me. Unfortunately, the Reason ecosystem is not very mature but I hope it might one day achieve more widespread adoption.
