Back to insights

The Dependencies I Never Upgraded

August 10, 202611 min read

Every technical career is a history of upgraded dependencies — languages, frameworks, platforms. But a handful of intellectual dependencies never got replaced. This is a reflection on the books and poems that quietly shaped how I think — and how they connect to the same discipline I write about in Sidetracked by Sizzle: that curiosity without judgment just becomes noise.

Leadership Philosophy Series — 9 articles
  1. The Power of Lifelong Learning
  2. AI and Critical Thinking in Software Development
  3. Sidetracked by Sizzle: Staying Focused on True Value
  4. The Managed Transition Model: Leadership Promotion as Power Exchange
  5. When the Pressure is On - Late Sprint Hotfix Governance
  6. Accountability and Authority: Walking the Tightrope
  7. Turtling: When a Team Stops Looking for the Door
  8. Every Arm Is Still Searching: The Octopus Model of Agency
  9. The Dependencies I Never Upgraded

Topic cluster

Project Leadership and Delivery

Project Mechanics, leadership judgment, delivery accountability, and team operating models.

"The Dependencies I Never Upgraded" title graphic showing a stack of well-worn books — Rendezvous with Rama, Stranger in a Strange Land, Time Enough for Love, Harrison Bergeron, The Remains of the Day, and Ithaka — beside an open journal, a compass, and a sunset view of an island, evoking the books that shaped a lifelong software career

The Other Reading List

Every Friday, I enjoy reading a friend's roundup of technology trends. New AI models. Emerging frameworks. Leadership articles. Research papers. The kind of reading that helps all of us stay current in an industry that refuses to stand still.

I read those things too. After many years in software, I've learned that staying curious isn't optional. Languages evolve. Platforms change. Entire architectures appear, dominate for a decade, and quietly disappear. If you're not learning, you're falling behind.

But his newsletter recently made me think about a different reading list. Not the one that shaped this week. The one that shaped my life.

As software developers, we spend our careers upgrading dependencies. We replace libraries, retire frameworks, and migrate platforms. Some upgrades are revolutionary, others barely noticeable, but over time almost every dependency changes. Looking back, I realized there are a handful of dependencies I've never upgraded. Not software dependencies. Intellectual ones. They've survived every programming language I've learned, every methodology I've practiced, every technology revolution I've lived through. Not because they predicted the future. Because they were never about technology in the first place.

The Books That Never Got Upgraded

Arthur C. Clarke got to me in high school, and like most teenagers, I came for the spaceships. Rendezvous with Rama was mysterious and imaginative and unlike anything I'd read before, and Tales from the White Hart showed me a completely different side of him — playful, clubby, more interested in the shape of a good idea than in getting the science exactly right. But somewhere along the way I realized I wasn't captivated by the alien spacecraft so much as by Clarke himself — a writer patient enough to let mystery stay mysterious for three hundred pages. He never rushed to explain Rama. He just kept looking at it more carefully. I've had a standing, half-serious wish for years to go to Sri Lanka, where Clarke spent most of his life, and ask him what he was really trying to tell me — not about spaceships, but about the wonder and the intellectual humility underneath them. That combination is the thing I still borrow from him: observe first, explore honestly, and don't pretend to know what you don't. When a legacy system does something inexplicable, or a production issue doesn't match any pattern I recognize, my first instinct used to be to force an explanation onto it fast. Clarke taught me the more useful instinct: sit with the unfamiliar a little longer before you decide you understand it.

Robert Heinlein arrived around the same time, for a completely different reason. I probably read him because he was rebellious — Stranger in a Strange Land felt subversive, Time Enough for Love felt like a dare, and Job: A Comedy of Justice was the first book that showed me an author could be funny and furious about the same subject in the same paragraph. I was maybe seventeen, reading it after everyone else had gone to bed, feeling like I'd gotten away with something. Only much later did I realize the books weren't really about rebellion. They were about refusing to accept an answer just because it was the one everyone already agreed on. Why do we believe what we believe? Why do we do things the way we've always done them? Those turned out to be excellent questions for a lead engineer to keep asking — especially in a room where "that's just how we've always built it" gets treated as an argument instead of a habit. I'll admit, affectionately, that Heinlein — and probably his editors — occasionally seemed to lose track of time somewhere inside those enormous later novels. Even the writers who teach you the most aren't immune to sprawl.

Kurt Vonnegut made me laugh, and he still does. Harrison Bergeron is eight pages long. Eight pages, and it dismantles an entire idea of enforced equality without ever once sounding like it's trying to. That's the whole trick — he never preached. He just told you a story and trusted you to notice what it meant on your own, usually a beat after you'd already laughed at it. I've never fully pulled that off in a design review. I'm still trying.

The Ones I Didn't Understand Until Later

I encountered C. P. Cavafy's Ithaka in college, in a twelve-credit-hour Great Books course that nearly ate my lunch. I appreciated the poem. I admired the language.

I didn't understand it.

Decades later, traveling through Greece with my family, I glanced out the window of our car.

There, across the water, was Ithaka.

And suddenly the poem wasn't literature anymore.

It was life.

The destination had never been the point. The years between college and that moment had filled in everything the younger version of me couldn't yet see — career successes, failures, marriage, raising children, mentoring colleagues, building businesses, losing sleep over projects that eventually worked out fine. The journey had quietly become the lesson. That's the part nobody tells you about judgment: it isn't handed to you at the destination. It accumulates, unglamorously, out of the choices along the way — which is another way of saying the journey doesn't just teach you things, it builds the judgment you'll need for the next one.

For years I knew only a single line from Dylan Thomas: "Rage, rage against the dying of the light." I admired it without understanding it. Only much later did the words start to mean something different. I no longer hear anger in them.

I hear determination — and lately I've started thinking of it less as a line about mortality and more as a line about keeping the fire. Not rage in the sense of anger, but the refusal to let curiosity go quiet just because you've seen enough failed projects to know exactly how hard meaningful work really is. That's what I take from it now: stay curious, stay engaged, and don't let cynicism pass itself off as wisdom just because it's easier to carry.

The book that surprised me most was Kazuo Ishiguro's The Remains of the Day. When I first finished it, I thought it was a tragedy about serving a flawed man. I wasn't wrong.

I also wasn't finished with it.

As the years passed — and especially now that my kids are grown and building lives of their own — the story changed on me. What once read as a tragedy of misplaced loyalty became something richer: a meditation on the dignity of service, on doing work well because the work deserves excellence, on the quiet melancholy that comes with a life devoted to purpose, and the moments that can never be reclaimed along the way. The lesson isn't that Stevens's service was a mistake. It's that service, purpose, relationships, and the courage to exercise your own judgment all have to coexist — leave one out, and the others curdle.

I didn't expect one of the most useful lessons I'd learn about leadership to come from an aging English butler.

Yet here we are.

That pattern — a lesson that only becomes visible once you're old enough to have lived past the surface of it — is worth pausing on, because it isn't limited to a bookshelf. It shows up in how I evaluate technology decisions too.

Curiosity Needs a Compass

There's a reason this reading list keeps circling back to judgment instead of settling for admiration of good writing. I've spent a long career being handed other people's money, time, systems, and people to look after — as an architect, a consultant, a mentor. That's a form of stewardship, and it changes what curiosity is actually for. Curiosity that only serves my own interest in what's technically fascinating isn't the same thing as curiosity in service of the problem actually in front of me.

I wrote about this more directly in Sidetracked by Sizzle, where I described the pull toward whatever looks most advanced instead of what a problem actually requires. That article and this one turned out to be circling the same idea from different directions. Sizzle is what happens when curiosity goes undisciplined — when the newest, most impressive option gets treated as the right one simply because it's new and impressive. The antidote isn't less curiosity. It's judgment: the accumulated, unglamorous sense of which possibilities are worth pursuing and which ones just look worth pursuing.

Innovation provides the possibilities. Judgment decides which of those possibilities deserve the time. That's Ithaka's lesson wearing work clothes — the years of choices, mistakes, and course corrections that build the judgment good technology decisions actually depend on.

Craft as a Form of Service

None of this works, though, without craft. Judgment tells you what's worth pursuing; craft is what lets you actually deliver on it well. I still care, more than I probably need to at this point in my career, about doing the work well regardless of whether anyone notices — documentation that quietly makes the next developer's day easier, an architecture decision that never gets celebrated because it never causes a problem, a mentoring conversation that eventually helps someone become better at this than I am.

That's the same thread Ishiguro's butler was pulling on, translated into a career I actually recognize. Good work, measured this way, often looks quieter than impressive work. It leaves systems clearer, teams stronger, and people a little more capable than it found them — not because it announced itself, but because it did what it was supposed to do and got out of the way. Service and craft aren't separate values sitting next to each other. Craft is what makes the service real instead of just well-intentioned.

What They Taught Me Instead

None of these books taught me software development. They taught me curiosity, humility, craftsmanship, patience with the unfamiliar, respect for the reader — or the teammate — sitting across from me. They taught me that wisdom often arrives years after knowledge does, and that experience has a way of finishing books we thought we'd already read.

That last part is the one I keep coming back to. I didn't understand Ithaka the same way in a twelve-credit-hour Great Books course that I did seeing the actual island from a car window decades later. I didn't understand Dylan Thomas's rage the same way at twenty as I do now. Heinlein's rebellion eventually revealed lessons that had nothing to do with rebellion at all, and The Remains of the Day keeps changing as my own life changes around it. The books haven't changed. I have. Some books, I've come to believe, don't fully reveal themselves until you've lived long enough to understand what they were saying all along.

If there's a single thread under all of it, it's something close to this: curiosity that keeps going, a journey that's allowed to do the teaching, craft practiced well enough to be worth putting in someone else's service, and not letting what's shiny substitute for what's actually worth pursuing. None of that is really a technology philosophy. It just happens to be the one that's shaped how I think about architecture, mentoring, and every dependency — software or otherwise — I've picked up along the way.

Every week I'll keep reading about AI, architecture, and whatever comes next. Those technologies deserve to be upgraded. But these ideas have been quietly shaping how I think for most of my life. They remain the dependencies I never upgraded — and, unlike everything else in this industry, I'm not looking for a replacement.

What book, poem, or story has stayed with you — not because it had all the answers, but because it kept revealing new ones as you grew?

Explore More

Working through a similar architecture decision?

If this article maps to a problem in your system, send a short note with the constraint, the risk, and what decision is blocked.