A recent email from a longtime friend landed in my inbox as a response to a column I’d written about opaque coding domains. His message was half joke, half provocation, suggesting that if Kubernetes still feels mysterious, perhaps my evolution from “coder” to “developer” is questionable. The comment was familiar in tone and spirit, the kind of ribbing that only comes from someone who’s watched your career unfold over years.
It immediately reminded me of an old book review I once wrote for Coder to Developer by Mike Gunderloy. The book argued that being a professional in software involves far more than writing code—it’s about communication, systems thinking, maintenance, and understanding the broader context in which software lives. For a long time, that distinction felt sharp and useful, a clear line between someone who types code and someone who builds software responsibly.
But the industry has changed, especially in the age of AI, automation, and sprawling infrastructure. Titles that once felt meaningful now blur together. Is a “coder” someone who only writes code? Is a “developer” defined by ownership and design? And where do “engineer” or “programmer” fit when tools increasingly handle the mechanics for us? The words haven’t disappeared, but their meanings have become more fluid.
That fluidity is what makes these labels interesting. The terms we use to describe ourselves aren’t just shorthand for job functions; they signal values, priorities, and how we see our place in the software ecosystem. Whether we call ourselves coders, developers, programmers, or engineers, each choice carries assumptions about skill, responsibility, and identity—and together, they tell a story about how the software profession understands itself.