Working With Your Hands
This week I had the pleasure of setting up a flat-panel TV for my mother-in-law. I had to mount it, too. This was particularly challenging because she has a 2-3 foot deep cabinet built into the wall, where her old CRT TV was installed. The new LCD TV would be mounted on the wall at the back of the cabinet, while the TV itself rests just outside the cabinet, flush with the front edge. This way the biggest possible screen could be accommodated, whereas a TV that fit entirely inside the cabinet, on its stand, would have to be several inches smaller. The mount I used was horizontally adjustable, but not vertically. So I had to get the height exactly right or it was going to look funny.
Now to any serious craftsman, this would have been a trivial task. Only one of three dimensions had to be Just Right, for crying out loud. Let’s just say I struggled a bit. I’m pleased to say it turned out pretty well, if I do say so myself. But more importantly, I realized it’s my years of work on software that keeps me from becoming a proficient hacker of physical objects. The word hacker is only awkwardly applied to the manipulation of physical objects. (Unless you’re, you know, literally hacking away at something.) The fact that I’d even think to do it reveals the problem: I’ve been approaching smallish handyman tasks the same way I approach smallish software tasks: do the first thing that occurs to you. If it works well, improve it. If it still works well, improve it further. At any iteration, if it stops working or you discover a better approach, start over. Repeat until satisfied. This is a terrible way to, say, mount an LCD TV.
One of the things that appealed to me about SourceGear, even before I came to work here, was Eric’s deliberate fence-sitting in the craftsman vs. engineer debate. As far as I know, his business card still reads “Software Craftsman.” Are the creators of software more like carpenters, or scientists? The predictable reality is that there are all kinds, and there’s work to be done by all kinds. I read Matthew Crawford’s brilliant essay a while back, in which he explores the dichotomy between the intellectually challenging professions valued by white collar, middle class America and the work done by tradesmen. He resigned from a prestigious Washington think tank to fix motorcycles, and never looked back. Working on real, physical things, he argues, is not only intellectually stimulating, but you get to see the results of the work you’ve done. I couldn’t ignore the similarities between working on the intricate machinery of an internal combustion engine and that of software:
Some diagnostic situations contain a lot of variables. Any given symptom may have several possible causes, and further, these causes may interact with one another and therefore be difficult to isolate. In deciding how to proceed, there often comes a point where you have to step back and get a larger gestalt. Have a cigarette and walk around the lift. The gap between theory and practice stretches out in front of you, and this is where it gets interesting. What you need now is the kind of judgment that arises only from experience; hunches rather than rules. For me, at least, there is more real thinking going on in the bike shop than there was in the think tank.
The slap of worn-out pistons hitting their cylinders can sound a lot like loose valve tappets, so to be a good mechanic you have to be constantly open to the possibility that you may be mistaken. This is a virtue that is at once cognitive and moral. It seems to develop because the mechanic, if he is the sort who goes on to become good at it, internalizes the healthy functioning of the motorcycle as an object of passionate concern. How else can you explain the elation he gets when he identifies the root cause of some problem?
I realized, or perhaps remembered, what it is I love about creating software. Nobody says it better than Frederick Brooks:
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder "for Daddy’s office."
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (…)
Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
I’m not particularly good at craftsmanship with physical objects, and doubt I ever will be. It’s not just my lack of patience. I’ve been spoiled by “such a tractable medium” for too long. There’s nothing more frustrating than when the last bolt just won’t go in because the holes aren’t drilled quite right. Or when, hypothetically, there are apparently NO STUDS in the wall! Seriously, where the [redacted] are the [redacted] STUDS! Three dimensional space is so confining! Last winter I was absurdly pleased with myself for correctly diagnosing the problem and subsequently replacing my own car battery. Only my coworkers understood: “doesn’t that void the warranty?” somebody asked.
It would be awfully nice to create things that normal people notice. I spent many, many hours improving our home media server software, but my wife definitely would have preferred I spent those hours on tangible things around the house. For every change she noticed on her own, there were ten times I forced her to stop what she was doing so I could demonstrate and prod for token enthusiasm. When I first read The Mythical Man Month ten years ago, I emailed that passage to my non-programmer friends and family, in hopes that they would understand why I derive such pleasure in pecking away at the keys of a machine all day. Nobody responded. This is the drawback to working on machinery that operates outside three dimensional space: hardly anybody lives there.
Physical and metaphysical craftsmen share the thrill of creation. The hum of a well-oiled machine has no substitute, even if the machine is virtual. But I love working on software because it yields two wildly different forms of satisfaction. I can take pride in the specialized intellectual challenge of fixing an O(n2) algorithm to be O(log n). And I get the more visceral craftsman’s satisfaction when my wife notices that the music stopped skipping when the screensaver comes on. Occasionally.