For much of my career I viewed software development as a craft: a constructive endeavor with fixed standards of excellence. I thought that over a lifetime, I could assiduously refine my skills, inching toward some level of subjective mastery until eventually myself and others would agree that I had become “a real expert.”

Unfortunately it doesn’t work that way with software. The technological context in which software is developed and used changes constantly and dramatically. So most of the stringent guidelines we impose upon ourselves in the name of craftsmanship are at risk of being obsoleted by some new advance in hardware, in programming languages, or in the baseline services of the operating systems we develop for.

Ask yourself, or a software developer of a certain age: what were the guidelines for crafting excellent software 5 years ago? 10 years ago? 20 years ago? The farther back one goes, the less relevant the answers will be to our modern craft. Memory management? Not a significant issue for most programmers today. Multitasking? Obliterated by modern operating systems with efficient context switches. Concurrent programming? Constantly reinvented in the wake of multi-core CPUs, GPUs, and higher-level programming language features.

I have spent a lot of my professional life honing “the skills of programming.” That is, the set of skills that seemed important at the start of my career. But I’ve seen what happens to people who cling to outdated standards of craftsmanship: they become self-righteous, bitter, and delusional. Guided only by the hallowed rules of yesteryear’s geniuses, they and their work become marginalized. Without a foothold in the modern technological context, programmers who should be great are rendered effectively incapable of developing their craft.

I’m sure this problem is not limited to software development, but given the world’s obsession with computers and related technology, the software landscape is changing much faster than many of us can easily keep up with. The world demands that this craft change. The technology for sculpting, firing, and glazing a ceramic bowl has also changed over the years, but not at the same mind-boggling rate as prototyping, programming, and testing a software application has.

What if you happen to enjoy old-school programming? There’s nothing inherently wrong with crafting “retro software.” In fact, I’m sure that dabbling in outdated techniques will serve to round out a modern programmer’s abilities. But while a classics scholar may be intrigued or even obsessed with ancient Greek or Latin, she knows that in order to remain relevant she must publish her papers in modern English. And if Esperanto were to become the lingua franca for her craft, that is the language she would have to use.

In software, the lingua franca is changing all the time, whether by adoption of new programming languages, through nuanced idiomatic changes in the ways that we use languages, or because of evolving operating-system level facilities. We don’t have the luxury of assuming that the tools and techniques of our parents, or even our younger selves, are sufficient to move the profession forward.

As a modern software developer, I derive as much joy from remaining relevant as I do from the thrill of identifying and solving the particular problems in my work. To remain relevant, I have to reject my previous assumption that I would spend a lifetime refining my craft. Instead, I will spend a lifetime adapting the techniques of yesterday’s craft to the sometimes radically different challenges of today. I may never become “a real expert,” as I hoped I might be. But by diligently throwing out the old rules and embracing the new ones, I hope to come close.