The ontology of the lambs

There is a lot of buzz being generated on Twitter right now as a result of some ignoramuses, led by the inimitable Zed Shaw, taking to launching multiple-tweet angry tirades (filled to the brim with as much profanity as 140 characters will permit) against advocates of strong static typing in programming languages. In addition to the profane personal attacks, there is a strong tendency to use straw man fallacies to the point that you’d be forgiven if you’d thought you’d wound up somewhere in Bizarro Earth where up is down, black is white and the Republican Party is the bedrock of tolerance and diversity.

What is astonishing to me about all this is the raw anger these people demonstrate. The raw hatred they spew for those who favour and use strongly and statically typed languages. Or, rather, it would astonish me if I didn’t already know the why. For the rage of Zed (and others like him) is the “rage of Caliban, seeing his own face in a glass”.

The ontology itself

Now keep in mind here that I do not mean the following three terms in their literal meaning. I’m invoking Forms of sorts, albeit fairly vaguely-defined and ephemeral ones. I’m using the three terms, in short, for a form of symbolic meaning, not literal truth.

The terms are:

• Technician
• Engineer
• Scientist

These three forms will be capitalized to distinguish them from their prosaic, better-defined real-world terms. I submit, however, in brief, that programmers fall into one of these three Forms (predominantly, I mean, there is overlap) and that accepting and working within these Forms will improve the world of software in measurable and important ways.

The Technician

In one of my earliest jobs in tech, I worked for a (very) small hardware manufacturing firm. How small was it? In the firm proper there were three people: the owner/boss, a technician and me as the software dogsbody. The technician was a nice, gentle Polish guy who was very good with his hands. His job was to populate our trial boards with components (assembly, in a word), to diagnose flaws and errors in the boards, and to, within limits, perform repairs on the prototypes to get them into functioning order for the next revision of the actual PCB.

At no point did this nice man, however, ever do anything creative. He was remarkably well-trained in his field, had a broad knowledge base, but he had no actual education. It was all training; a sophisticated intellectual toolbox and a sophisticated set of tools to use, but in the end still pre-formatted, pre-arranged, work using pre-formatted, pre-arranged components and tools.

In any engineering discipline, you’ll find technicians outnumbering engineers by anywhere from 2:1 to 10:1 and beyond. I submit that this is the same in software, but that we haven’t (yet) reached the stage of actually distinguishing between Technicians and Engineers in any formal fashion.

(And nor have I yet actually talked about what I mean by Engineers. I’ll correct that now.)

The Engineer

Again, going back to that job, my boss in this tiny firm was an engineer. He didn’t (often) assemble or repair things. He designed them. He saw a capability need of some form, figured out how to meet that need, designed the boards for it, selected the required components to go into them, etc. He created in short, building things that had not yet been built before. He may have used predefined concepts and components, and he may have rigidly applied some well-known conventions in the process, but in the end he created new things. His skills, knowledge and education were a step above our technician’s in that he solved problems using new, as yet uncreated technology.

Now before the straw goes flying fast and hard, please note that I’m not saying that this engineer was in some way a better person than the technician. I’m not even saying that he was more valuable to the company! The fact is that our technician was probably the most valuable to the company in the short term because his hard, boring drudge work was what allowed the boss to get on with his own work and gave him the time needed to create things. If my boss had to do all the assembly, debugging and repair work himself we’d never have made it to market.

Again, as in this electronics field, I submit that there is a distinction between the Technicians of coding and the Engineers of software development. I also submit that, depending on context, as with my former employer, both are actually necessary. The Engineer is not a better person than the Technician, nor is the Engineer necessarily more valuable to a company. It is, however, important to note that there is a difference and that this difference necessitates different handling of each’s working life, supervision, etc.

The Scientist

In the context of electronics, the technician, you recall, assembled the boards, and the engineer designed the boards. So what then is the role of the scientist? Well in this context the scientist is the person who invented the transistor (or whatever other ground-breaking piece of technology you choose to use—it’s not as if there’s a paucity of examples here!).

The Scientist’s main area is inquiring in nature. Where the Technician and the Engineer are concerned with making things that work, the Scientist is more concerned with pushing back the boundaries of human knowledge, even if it doesn’t necessarily have immediate practical benefits.

Again, as before, I submit that the realm of software has its Scientists. These are the people who invent the new techniques the Engineers use to design software systems and the Technicians use to implement them. They invent the algorithms, the “esoteric” languages, the paradigms and put them on a firm theoretical foundation to build up from. And again I submit that these people are not intrinsically better or more valuable. It’s just a different focus of interest and intent.

Examples

Examples of the Scientist Form in computing would be people like Knuth or Dijkstra or McCarthy for the big names. It would involve, too, the lesser-known names like Parr or Peyton-Jones or Bone or their ilk. All of these people have, to one degree or another, pushed back the boundaries of human knowledge and added tools, techniques and even simply thinking patterns to the field of software.

Examples of the Engineer Form in computing would be people like Ritchie or Moore. Ritchie, for example, together with Thompson and others of that team, created Unix. Unix was not groundbreaking in any of its features. Most of the “firsts” that are cited for it by its unthinking fans (and, thankfully, not by any of the principles involved) are not firsts. Unix was a product of taking the best known practices of the time and putting them together into a new and unique whole. This is the Engineer in a nutshell.

Moore, similarly, in inventing Forth, was not inventing anything new at a conceptual level. Stacks were known. Dictionaries were known. Modular programming was known. Even implicit operands or rapidly building abstractions upon earlier abstractions were all known techniques. (APL, for example, predated Forth by about four years.) All the techniques were old hat (relatively speaking), but Moore put them together and created something new with them.

By their very nature, Technicians are not going to be well-known, so it is hard to name examples. Instead I’ll point to the kinds of people who are the technicians in software. Think of the body shoppers in big consulting firms like Accenture/Andersen or EDS or their ilk. I’m not talking their “designers” or “architects” or that kind of person but rather their coding drones who are given a function/window/table/whatever specification who then type out the code that implements said function/window/table/whatever specification. This is the Technician of software development.

The problem

The problem is one of communication and identity. Explaining the communication problem is simple. For a Technician to be useful, they have to understand enough of the vocabulary (and thus thinking) of the Engineer to follow explanations and instructions; to discern intent from vague pronouncements and to build up their work from that. A Technician that can’t understand Engineers is useless and, likely, in the very near future, out of a job.

Similarly, for an Engineer to make new things, they have to understand what the Scientists are talking about sufficiently to turn the academics’ ideas into something practical and useful. An Engineer who can’t understand what a Scientist communicates cannot make new ideas into practical, useful or even beautiful things.

The problem, I think, is that people like Zed Shaw (and those who lionize his angry person/a) are at their core Technicians. They may be very good technicians. They may have a large tool belt with a lot of specialized tools. They may have a great deal of in-depth training. In the end, however, they’re Technicians. They assemble things based upon the specifications and instructions given by others. Just like the technician in the small hardware firm I worked for they may occasionally dabble in making things of their own (I did mention that the categories don’t have hard boundaries above, after all), but overall they remain Technicians: the assembly line workers of software.

The thing is that they don’t perceive themselves to be Technicians. They are emotionally invested in being Engineers and/or Scientists. And yet they cannot actually understand the output of software’s Scientists (this link alone should be ample evidence of this!) and this holds up a glass to their face that reflects something they don’t want to know: that they are not truly the Engineers they believe themselves to be. They rage at the looking glass because it doesn’t show them what they believe it should; they rage at it because it shows them what is, not what they desire to be.

The solution

For people like Shaw and company there is no solution. Reality faces one way, they face another. Their rage is real and exists because it strikes at the heart of their perceived identity.

But why is that their perceived identity and why are they so invested in it?

I think it’s because we, in software, don’t value our Technicians enough so nobody wants to be one. In that small hardware firm the technician was a highly valued member of the team; without his work there would have been no company at all. He was not looked down upon. He was not sneered at. He was not derided. In software, however, the Technician is given all sorts of epithets: code monkey, keyboard jockey, remote keyboard, technical stenographer. Their work is described as “a simple matter of typing” or even worse.

Even worse, I think in software by not recognizing these three Forms, we do egregious harm to the whole software development process. Because even on something as simple as supervision and assignment of work you should be treating your Technicians differently from your Engineers and your Scientists differently from both.

I’ve seen a company that almost got this right. They definitely recognized their Scientists at Entrust in that the cryptographers on staff, some of whom were heavy movers and shakers in the field, were treated with the deference and the care you should be treating those whose job is primarily thinking and expanding human knowledge. Sadly it all fell apart with the Engineers and Technicians. There were people who were obviously Technicians (the clue lay in their proclivity toward cut-and-paste programming and the utter disasters that were their unfactorable, unmaintainable, unalterable code) given roles of Engineers while obvious Engineers were treated like they were Technicians who needed close personal supervision of detailed, closely-specified drudge work.

It doesn’t help that educational institutions blur the lines too. You can get degrees in “Computer Science” that show no hint of academic rigour at all. (When you graduate from a “Computer Science” program without exposure to at least five entirely different ways of thinking about problems, including at least one purely abstract way, you’re not a Scientist!) Indeed some trade colleges give better theoretical grounding than some universities. There has to be better stratification of education so that those suited by temperament or preference to Technician-grade work go to trade colleges, those suited to thinking of new ways to piece things together to solve problems can go to engineering schools and those suited to pushing back the foundations of abstract thought enter computer science programs.

But just recognizing the differences (and acting accordingly) is a good start.