Constraints
Thursday, January 13, 2022
categories: work
Read: 5 minutes
This morning I wrote an email to a friend in response to some images he shared with me of an old computer he's restoring.
I'm not talking about a 2000 Hewlett-Packard, I mean a really old computer, the kind where the name is like a CIA code name of letters and numbers and just saying it
makes you feel a little bit dorkier.
I think it's really cool that he restores old computers. I like to "restore" old hand tools, and
think that if you can breath new life into old equipment then you're doing a really beautiful thing (I'm less inclined toward "museum" type restoration, if
an item has out lived it's value then allowing it to die is not a bad thing.)
What struck me immediately about the photos of his restoration was the complexity of the machine and the picture he took of the thick binder titled "Maintenance Manual". It instantly told me one thing about old computer restoration. I would really struggle to do it.
The reason?
Constraints.
Constraints are a very important part of any work you do. When you chop down a tree: the lean of the tree, the strength and direction of the wind, the species, the age, the degree of rot, the sharpness and bit profile of your axe, these are all constraints on that work.
When you write (or more commonly edit) a computer program you have constraints as well. The tech stack, the quality/organization/cleanliness of the code base, the complexity of the problem your edits aim to resolve, the urgency of the task, the importance of the task (note that these are separate things), the design choices of your predecessors, and on and on; all these are common constraints of programming.
There is at least one (and probably more) fundamental difference in these 2 types of work and to my eye that difference is in the constraints. In chopping down a tree the constraints are all set by God. In programming the constraints are nearly all set by peers and/or predecessors.
When you consider a constraint like "Species of tree" the constraint is really the behavior and properties of the wood. For example, cedar is a soft wood, and of the softwoods it's a lot more prone to splitting and splintering (in my experience). And so when you cut one down or do any sort of wood working with cedar you must bear that in mind in your approach to cutting it. Compare that with a hardwood like maple or oak and your approach will greatly differ because those woods are much less given to splintering (again, in my experience). All the constraints I can think of in chopping down a tree (unless you're a professional following some set of OSHA guide lines) are given by nature.
Now consider the constrains for programming. Unless you're Dijkstra sitting around in Holland thinking up algorithms then you're almost always working with constraints from other people. The software used to build, run, debug the code constrains you. The design of the software you're editing constrains you. The priorities of your company's leaders constrain you. Your peers adherence to the coding standard (assuming you have one... you should...) constrains you. And whether you notice it or not the cumulative decisions of programmers from Dennis Ritchie to Bjarne Stroustroup to Linus Torvolds to Guido van Rossum, to the countless non-famous programmers and engineers that have ever worked on a programming language, software development tool, operating system or processor architecture constrains you. They all solved their problems to varying degrees of completeness and success. These solutions of theirs where good enough to be co-opted by others and built upon.
It makes sense that a good solution should be expanded upon, it's the way we humans have been driving innovation all throughout history. Newton famously stated "If I have seen farther than other it is merely because I stood on the shoulders of giants" or something like that. But Newton was observing natural laws and contributing to the expansion of our understanding of mathematics (the perfect platonic language of the gods). He and scientist like him work(ed) in fundamental constraints provided by God (not unlike a lumberjack chopping a tree).
But the poor programmer of today is less fortunate. See the building up of the software milieu is predicated on the false assumption that the software we build from is any good or better yet, fundamentally correct (which mathematicians are lucky to be able to independently verify about the work of their progenitors). But as my good friend and mentor Alex Quick once taught me: "The first problem with every piece of software is that it was written in the first place". Or if you like xkcd he's got a pretty good take on it. And so the fundamental problem I have with programming and antique computer restoration both, is that the constraints of that work come from man. Flawed, myopic, untrustworthy, unintuitive, bad-at-reasoning mankind calls the shots with computers. When we get to set the rules, the constraints become arbitrary ("It was just easier if we did X") and endless ("We can worry about Y later, right now we need to get an MVP", or my favorite "Move fast and break things"). So solving a problem in that space quickly and frustratingly becomes totally impossible. Most of the time the best you can hope for is a diversion, or band aide rather than an actual solution (because the problem often is fundamental to the system).
I'm not sure what my point is here, perhaps I'm just trying to say "I like wood more than computers" and that's definitely true. But working with constraints is part of all work. And although the constraints of nature are some how easier for me to stomach, it's true that if you can keep from pulling your hair out, computers, even computers running on fossil fuel and the flawed choices of our computational forebears, can be made to do remarkable, useful and even beautiful things. And if you are patient enough and abuse your body by sitting in a chair and shooting high intensity blue light down your retinas even you can write some software that will do a thing just well enough for you and maybe even a few peers to get some use or even better enjoyment out of it. And then you too, like Dennis, Bjarne, Linus, and Guido before you, will become another sinner willing evil code into our fragile universe. Shame on us all.