.png)
4 days ago
2
The form keeps changing, but the craft remains the same. What do I mean? We keep rebranding old problems—wrapping them in new tools, frameworks, and slogans—and then act surprised when the problems are not solved. The craft of building software—too often goes untouched.
Naoto Kan said, "If you are unable to understand the cause of a problem, it is impossible to solve it." Albert Einstein famously said, "We cannot solve our problems with the same thinking we used when we created them." This leaves the question—where are we today?
Do we understand the problem and
Are we ready for the next level of thinking to solve them?
The truth is that even with all our technological progress, the deeper patterns remain unchanged. Teams still struggle, architectures are overly complex, projects still collapse under the weight of ambiguity, not infrastructure, and we focus more on the process than the outcome we are striving to achieve.
"Those that fail to learn from history are doomed to repeat it!”
— Winston Churchill
The domain of Information Technology stretches back as far as the written word. The term "information technology" first appeared in the Harvard Business Review in 1958. Since then, it has evolved rapidly, with new tools, techniques, and products. We've seen innovations and remarkable achievements, like the latest AI advancements.
However, I am not looking at the latest innovation; I am looking at a more specific observation of our craft. The fact that a search for “The craft of information technology” falls short helps add validity to my frustration.
One constant throughout my career has been that each client I speak with is fighting the same problems. The problems might have new names, but they are the same problems we tried to fix through the last iteration of tools, techniques, and methodologies. I find myself repeating the same conversation decades apart!
Thus, the forms change, and the craft remains unresolved.
"We are being drowned in information, while starving for wisdom."
— E.O. Wilson
We obsess over new forms—frameworks, languages, architectures—while neglecting the deep craft that animates them all. Like a photographer fixated on camera bodies rather than composition and light, we mistake the tools, techniques, and methodologies for the art itself. Orlando Jones observed,
"Photography is photography, it doesn't matter what you're taking photos of, it's just important that you practice and master the craft of shooting a photo. That will always be in season, and there will always be a use for it."
This pattern persists not because we lack information but because we lack the space for attentive craftsmanship. Our industry suffers from a fundamental contradiction,
We are expected to create art while being managed like assembly line workers.
Companies demand innovation, quality, and resilient systems, yet structure teams for maximum throughput, as if code were widgets to be manufactured rather than complex systems to be designed.
The fundamental tensions in software development—between elegant abstraction and operational resilience, between delivery velocity and architectural integrity—don't change with technology stacks or methodologies. These trade-offs exist in every system we build, from monoliths to microservices, from waterfall to agile. A CTO might swap Kubernetes for VMs or React for Angular, but they cannot escape the inherent tension between immediate business demands and long-term technical sustainability.
The technical debt we accrue from expedient solutions, the complexity that emerges from prioritizing features over foundations, the brittleness that develops when we optimize for speed over maintainability—these challenges have followed us from mainframes to the cloud.
They are not technology problems; they are human and organizational problems manifesting in our technology. Organizations celebrate the virtues of programming craftsmanship while simultaneously eliminating the conditions necessary for it to flourish: time for reflection, space for learning from failure, and continuity of attention.
In this environment, tools become mere accelerants of shallow thinking. No sophisticated tool can redeem the outcome when our practice is rushed, fragmented, and driven by artificial urgency.
"The day you finally start dealing with your past is the day you stop dragging it into the present." — Diane Guerrero
We are not just repeating old problems. We are accelerating them—abstracting, scaling, and deploying them to production under new names.
In twenty years of building systems, I've watched the same fundamental problems reappear wearing different clothes. I've seen teams celebrate new approaches that repackage old limitations. And I've seen rare moments when practitioners transcended the limitations of their tools through deep craft. These moments have convinced me that our profession needs fewer evangelists of form and more masters of craft.
Understanding light, composition, and the decisive moment transcends whatever camera sits in a photographer's hand. Similarly, in technology, understanding system coherence, state management, and domain modeling transcends whatever technology stack you've deployed. Mastering observability, error handling, and graceful degradation outlasts any framework or cloud provider. Skilled data modeling, concurrency control, and caching strategies remain relevant whether you're using REST, GraphQL, or the next API paradigm.
The forms will constantly change—Kubernetes may replace VMs, just as serverless may supersede containers, and whatever comes next will eventually replace serverless. But the underlying craft—how we manage complexity, design for resilience, create observable systems, and translate business requirements into maintainable code—this remains eternally relevant.
The technical leaders who consistently deliver value aren't those who chase every trend, but those who recognize the enduring patterns beneath them.
"In our rush to do everything faster, we tend to stop doing certain things altogether, like taking time to get the problem statement right." — Fred Brooks
This publication began with a recognition that perhaps we do not need more novelty but more clarity, attention, and a return to the foundational wisdom that built our field. I created this space to share my journey back to the books, papers, and thought leaders who evangelize our craft, to remind myself and you all that it is the mastery of craft—not the particular form in which we express it—that ultimately makes us successful as technical leaders.
Here, I write about the core practices of software and systems—the ones that still matter and the ones we seem most eager to forget. Each essay begins with a piece of writing—a book, a paper, a blog post—and uses it as a lens to reflect on the deeper tensions of our industry. Not as a nostalgia exercise, not to be contrarian, but to return to the original questions that built our field in the first place.
They say to pick a niche. I decline. I am a generalist by design and a synthesist by practice. The value, for me, has never been in narrowing my view, but in tracing the relationships between things we've been taught to see as separate.
You will not find trend forecasts here. No tips. Nor frameworks. This is not a place for AI-created advice. It is a place for orientation. For language. For remembering our craft through the writing of others and our conversations.
I hope you find something useful here—or at least something familiar.
We are still broken. But we are still building.
I look forward to figuring out my journey with it and to building a community of like-minded professionals who believe in our craft.
— Dan
