When the Ground Shifts Beneath Your Code
Technology doesn't change overnight. It shifts gradually—a new pattern emerges, a language migrates to a different domain, a library's adoption curve suddenly steepens. But for developers caught in the middle of their own work, these shifts can feel abrupt. The ReadME Project's Mike Melanson spoke with three engineers about recognizing these moments, deciding what to adopt, and knowing when to let a wave pass.
Nyah Macklin is a Developer Evangelist at Couchbase, teaches at the G{Code} non-profit, and was an early engineer at Suborbital Software Systems. 
Damien Katz, creator of Apache CouchDB and founder of the JSON query system Noise, most recently worked on Amazon Aurora for MySQL. 
Justin Searls is co-founder of the consulting agency Test Double, where he studies why software apps fail and how teams can build reliable systems.
Defining Moments
A paradigm shift often announces itself through a single memorable experience. For Searls, it was 2003 and an article on Slashdot about Ajax as a design pattern enabled by Internet Explorer's XMLHTTPRequest API. The proof of concept changed his understanding of the web overnight.
"The web was just documents before. I could suddenly see my entire career unfold in front of me," Searls says. He built his first single-page Ajax application within three hours. After four years of traditional computer science working in C and Java, the shift redefined his entire developer ideology. "It was dreadfully obvious, in exciting and terrifying ways, that this document model would be abused into becoming an application runtime."
For Macklin, the most significant shift wasn't a technical one, but an economic one: the expectation that software should be free or inexpensive. Coming from a low-income background, she didn't have access to a laptop growing up or a computer science education. A paid boot camp called Resilient Coders changed her path.
"Many developers will not touch a piece of software unless it has a perpetually free tier," she says. That expectation opened the door for herself and others who couldn't afford hosting fees or paid tools to build software and advance their careers. Free and open source software played a central role in that democratization.
Katz's moment came early, in an "Intro to C++" course in college that was so engaging he changed his major. He embraced object-oriented programming (OOP), then spent years overcomplicating code in an attempt to adhere to it. "Being dogmatic about programming styles, paradigms, or processes is very limiting," he says. "Looking back, I cringe at some of the code I wrote."
What the First Shift Taught Them
Katz went from OOP to functional programming, driven by a concrete need: concurrency. He kept hearing about Erlang's ability to handle concurrent workloads safely. After two weeks of playing with it, he threw away all of his existing C++ code and rewrote his entire project in Erlang.
"I was ridiculously productive," he says. He came to see functional programming as a simplification of the OOP model. "With functional programming, you get very simple types, and a rich library of functions that can operate on them."
For Macklin, the constant churn of hot technologies—React roles, then crypto roles, now AI and ML—taught her that the ground is never stable. The lesson: remain flexible. "If you stay grounded in your abilities and skills, and you take up the willingness to be flexible as things shift, you will come out a stronger engineer."
Searls learned to view technologies not as isolated moments in the zeitgeist, but as waves at different stages of their lifecycles. In 2011, working with a Java-only client that rejected every new dependency, he asked to use sammy.js for a tight deadline. Their response: "Oh, nobody cares about JavaScript." It was so early in JavaScript's lifecycle that the client didn't perceive a threat. Searls built an application that bypassed the client's Java architecture entirely—and by the time IT caught on, the customer was already in love with the product.
Staying Current Without Chasing Everything
Different engineers adopt different strategies to keep up. Macklin, whose developer relations role demands her finger on the pulse of the community, evaluates potential adoptions through a personal lens. "Does it increase my developer productivity? Does it improve my life at all? Who built this product, and what do I believe is the future for such a product?" She also asks harder questions: whether a product can be used for good, whether its data was gathered equitably, and who could it negatively impact.
Katz browses tech sites constantly—it's part of how he stays informed. The interest focuses on frameworks and languages that make you think differently. But he's clear about limits. "You can't learn them all, otherwise you'll just have a smattering of information about a bunch of things and an expertise in none." Expertise, he argues, comes from focused time with a technology until it becomes second nature.
Searls takes the opposite approach: he avoids tech news, podcasts, and videos entirely. Instead, he invents projects—"something new or cool or useful"—and starts his technology search only when he needs a better tool to make something happen. "If you only search for tools for tools' sake, or only track what's trending, it can be a case of the tail wagging the dog." He ensures his curiosity is driven by a concrete problem he actually wants to solve.
The Ones That Got Away
Everyone has a regret—a technology they passed on that cost them, or one they adopted that turned out to be a poor fit.
Searls deliberately skipped React. "I just knew that that impedance mismatch was going to result in more bloated apps and buggier user experiences than anything we did in jQuery." He feels his technical judgment was right, but the decision had a professional cost: he faded out of relevance in the JavaScript community. He wonders, briefly, if staying with the zeitgeist might have let him contribute to the conversation. But he's honestly at peace with the trade-off.
Macklin similarly avoided React—especially React Hooks—because she didn't understand it at first. The punishment was delayed growth: while she avoided it, she watched new engineering patterns reshape how sites were built. The lesson eventually landed: "Flexibility is a muscle that I think is extremely important for engineers." Her eventual shift toward React showed her that you can learn something new without either destroying yourself or missing out on the important current of a discipline.
Katz second-guesses his choice of Erlang for CouchDB. It made him personally absurdly productive, but mainstream languages brought their competitors better tools, larger communities, and bigger hiring pools for engineers. He couldn't easily onboard developers into Erlang. "Its syntax is bizarre," he acknowledges. "It's way too different from what they know." And yet the alternative might have meant spending his focus on concurrency rather than shipping. He's genuinely unsure if the trade was right—hindsight, he reminds us, is not necessarily 20/20.
Bringing the Team Along
When a technology has the developer's buy-in, the question becomes: when do you evangelize it?
Macklin is deliberate about not pushing. Before suggesting any dependency to a team, she wants answers on the product's trajectory: How many engineers use it? How long has it been supported? How actively do maintainers close issues? How is the software funded?
Katz rarely argues for technology changes. "As engineers, we tend to believe ourselves to be these hyper-rational, logical people. We believe that our desire to use a certain technology isn't an emotional thing... and then we get into these arguments about different paradigms that end up being more about keeping our ego intact." He points out that the productivity gains from a technology switch are rarely dramatic. He prefers to "bring in aspects when appropriate" rather than trying to convert a settled team.
Searls holds his strongest standard for endorsement. Before adopting something, he attacks it with a "hard-charging approach": he picks a genuinely difficult problem and uses the technology from an angle it doesn't expect. "Every tool certainly is going to do a Hello World demo really nicely, but if that's why you adopt it, you don't actually know whether or not it'll stand up to scrutiny." Only when a technology survives his aggression does he feel ready to recommend it—and, accordingly, his endorsements are rare.
Advice for Newer Developers
For a rank-and-file engineer, Shapiro's advice is to be deliberate about where you spend attention: "If you spend your entire career picking up and moving on to the next thing, you'll never actually spend sufficient time in the present moment digging in and solving hard problems." There will always be another green field over the next hill.
When faced with a wave you don't yet understand anywhere, remember that you've successfully integrated many such waves before. "Remain in your knowledge and know that you are capable and brilliant," Macklin says. "Don't be afraid of the ever changing waves of this field because that flexibility allows you to become a much stronger technologist."
