Jessica Kerr

I went into programming because it was easy. I solved puzzles all day, then went home at five thirty and hung out with my friends. Twenty years later, I stay in software because it is hard.

It is hard because I moved from solving puzzles to growing products, from obsessing over correctness to optimizing for change.

Early in my career, I focused on one area of the system. My team leader gave me requirements for new features. This defined “correct,” and when the code achieved it, my task was done.

The available means were restricted: we worked in C, with the standard library plus Oracle. For bonus points, we made the code look like everyone else’s.

Within a few years, my perspective broadened: I met with customers; I participated in the negotiation between design and implementation. If a particular new feature took the code in an awkward direction, then we went back to the customer with other suggestions to solve the same problem. I now help define the puzzles, as well as solve them.

Puzzle solving is a prerequisite, not the essence of my work. The essence of my work is to provide a capability to the rest of the organization (or to the world); I do this by operating a useful product.

Puzzles have an end state as a goal—like a game of baseball, there is a fixed end. With products, the goal is to continue being useful—like a career in baseball, we want to keep playing.

Puzzles have defined means, like a board game. Growing products, we have the world of libraries and services, a plethora of puzzles solved for us. It is more like a game of pretend, open to what we can find.

Later in my career, my perspective broadened.

When I push satisfactory code, this is only the beginning of my work. I want more than code change: I aim for system change. A new feature in my app must work with the current systems that depend on mine. I work with the people who own those systems to help them start using the new feature.

Now I see my job as designing change, not code. Code is a detail. 

Designing change means feature flags, backward compatibility, data migrations, and progressive deployment. It means documentation, helpful error messages, and social contact with adjacent teams.

A plus: all those if statements for feature flags, deprecated methods, and backward compatibility handling? These are no longer ugly. They express change—and change is the point, not some particular state of the code.

Designing change means building in observability so I can tell who is still using the deprecated feature, and who is getting value from the new one. In puzzle solving, I didn’t have to care whether people liked the feature, or even whether it was in production. Growing a product, I care very much. From experience in production, we learn how to make our products more useful.

Products don’t have one definition of “correct.” Many things are definitely not correct, so we can be careful about “not broken.” Beyond that, we aim for “better.”

Growing a product is hard in different ways than solving puzzles. Instead of hard work followed by a feeling of accomplishment, there is a slog of mushy work, through ambiguity and politics and context. The reward is more than a feeling, though: it can have a real impact on your company and thereby the world. That is more satisfying than ordinary fun.