The Corpse of Content

It is I again– Nat Bennett! Newsletterer! Writer of words, and, occasionally, of software! I bring to you another edition of Simpler Machines, a look inside the mind of that scribe of the modern age, that new cavalier, both monk and man-of-arms, the software engineer.

Yes, I've also just started reading the Silmarillion. You've been warned.

A lot of people who work with software engineers model us as easily distractible mad scientists, always wandering away from the path of business value to build excessively complex things. This isn't wrong, exactly, but it's incomplete, and it leads to mistakes in managing engineers. Managers come to believe that their job is to wrangle engineers away from shiny complexity, and back towards productive and useful work, and narrow their eyes whenever the engineers get too excited about something. Or they try to motivate engineers with complexity for its own sake, and let their systems accumulate excessive complexity for the sake of "retaining top talent."

These are all mistakes. Engineers do not want to build complex things for their own sake. Engineers want many things, but they most love these three:

• Building beautiful and useful things
• Increasing their knowledge of their art, and the tools of their art
• Winning respect in the eyes of their peers

This leads to a love of complexity mostly when the first love is thwarted, and engineers must turn to the second and third loves: Knowledge and respect. Building and mastery complex systems is a good enough path to both in many places. Build something complex and you learn how to build it, and how not to build it. It's hard, so it feels like learning. Build something complex and you become, "The engineer who did this hard thing." Other engineers come to you with questions and they listen when you provide answers, and that feels like respect.

I'm also a photographer, and a student of photography. I watch Alec Soth's "long, rambling talks" about photobooks, and one of my favorites features Tim Davis's I'm Looking Through You, and one of the essays in it, "The Corpse of Content." Soth is interested in the relationship between the text and the pictures, the abstract structure linking the two, and how similar structures could link other text, and other pictures. I'm interested in the content– the phenomenon Davis Calls "the Corpse of Content."

You should watch the whole video, buy and read the whole essay, but I've pulled some quotes so you can get the general gist. Davis writes:

I'm not one of the handful of photographers with an obviously palpable visual style. Lee Friedlander can make one of his pictures anywhere. He visually warps and wonks and crosshatches and unkilters and ajumbles it, and it's a Friedlander.

The rest of us have to have something to say. We need content, and it's not always not always forthcoming. On these days, I fantasize about dead bodies.

It's happened enough times that I gave the phenomenon a name: "The Corpse of Content." It stands for the photographer's yearning for content so potent that it's taboo– that Fijian or Tongon or Malagasy word that means both forbidden and sacred.

The first time I read that, I thought of myself as a photographer, and I thought it was a lesson on the public's disinterest in photographs-for-their-own-sake. The necessity, for most photographers, of content, to get anyone to pay attention to their carefully arranged rectangles.

The second time I read it, I remembered I was a software engineer, and had a shock of recognition at the word yearning.

Some programmers are like Friedlander. They can make beautiful code, powerful and arresting code, out of anything. I don't have an example I'm as confident in as Friedlander, but I think maybe programming language authors are this way– I'm thinking of Matz, and his reputation for beautiful C code.

There's something sorcerous about writing a programming language. The requirement space is so vast. (Could you design a programming language by user story? Would the individual stories be programs?) The sheer volume of code required, the sheer volume of vision. I don't know how I would begin to construct such a project, and I feel a kind of envy– a deep and indecent yearning– against the people who do know.

The rest of us have to have content.

Most companies that employ programmers are miserably bad at giving them useful things to do.

You can't get content from a ticket. "Implement this endpoint." "Solve this timing bug."

User stories are a little better, at least they name an actual human, but too often they are thin, whispy things, drawn from a product manager's imagination or longing. I've worked at places where we were forbidden, by the ancient magic of contract law, from speaking to the real users of the code we wrote for them. Even when a shop does do researcher, has some empirical basis for the decisions the engineers are asked to implement, engineers are rarely included. Our time is too valuable to waste any of it understanding the problems we're meant to solve.

I came to programmer relatively late, in my twenties, on the job. I tried a few times in my teens, but always abandoned it. Too hard– and I didn't want to make calculator games, anyway. I hadn't found a problem to fall in love with yet. I hadn't found content.

When I did finally learn to code, I was working as a software tester, my desk next to the folks running the data entry and management side of the software I was working on. And I noticed that a couple of the programmers were always coming over and asking the data entry folks questions. "Would it help if we did this?" they would ask. "We could build you something that would... would that help?" They saw humans doing a repetitive task, and they wanted to make a machine that would help.

So here's my hypothesis.

If you want to tame the beast of complexity in your systems, you can't do it by wrangling. You can't specify and nail down, you can't incentivize, you can't review, you can't shame or yell. You can't feedback your way out of an engineer's– thwarted and poorly understood– but inescapable– yearning for content, content so powerful it changes the world. For work that matters.

If you want to tame the beast of complexity in your systems, you have to help your engineers find real problems that matter to real human beings, that they can solve with machines.

We have to have content.