Coffee and the Programmer

What if programming became as commonplace as working in a café?

I sometimes imagine a world where programming is far more widespread than it is today—something anyone can learn and use with ease. Think about a barista. Given a fixed workflow, a calibrated machine, and a set of beans, the act of making coffee can be learned fairly quickly. To a newcomer, it may feel like repetitive work: follow the steps and make the drink. Running a café, however, is more complicated. The difference lies less in the ingredients than in how they are used.

You can glimpse that difference in coffee competitions. In some, competitors choose their own beans; in others, everyone receives the same beans. In the first kind, bean selection and experience with those beans matter. In the second, everyone starts with the same material, so skill is measured by how well each competitor can express it within the given conditions. These two formats resemble the different ways we look at software development today. No matter how far AI advances, I do not think our view of development will converge on a single answer. It may continue to branch in directions like these.

That is why today’s AI ecosystem also resembles a coffee competition. More than the model itself, data and platforms build moats, and the gaps they create become competitive advantages. Logging and analysis used to be major undertakings; now they are incomparably easier. Access to data—the equivalent of good beans—and the basic infrastructure are increasingly becoming part of the given conditions. Programming, the moat that followed, is becoming a simple action too.

If programming really becomes as common as café work, where will developers converge? I imagine two groups. The first can make a good cup from whatever beans arrive. Even when the data is inconsistent, these developers stabilize pipelines, narrow down problems through observation and experimentation, and create repeatable quality. The other group knows what to choose and how to make the case for it. These developers set product direction, explain the reasoning behind their choices clearly to teams and stakeholders, and present the result in a way that fits the situation. The first resembles a data engineer; the second, a product engineer.

Working directly with individual machines and beans is becoming less important. Workflow, space, and context matter more. We are moving toward a role in which we decide what context gives an outcome meaning, then persuade others of that choice. More slowly than I first imagined, but still quickly enough.