97 Things Every Java Programmer Should Know

Chapter 27. From Puzzles to Products

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 ...