I have been in this industry long enough to have watched it change its mind — completely, repeatedly, and with great conviction — about nearly everything. How to write software. How to organise teams around writing it. How to deploy it, host it, scale it, monitor it. The version of me who started in the early 2000s would not recognise the day-to-day work of the person writing this sentence. And yet I have stayed in the same field the entire time. That tension is what I want to explore here.
Because here is what I have come to believe after twenty years of watching: each transformation was not simply an industry finding a better tool. Each one was a correction. A slow, collective admission that the previous way of thinking about software had been built on a misunderstanding — not a technical misunderstanding, but a deeper one. A misunderstanding about what software is.
The Shifts I Lived Through
When I started, Waterfall was not just a methodology — it was a worldview. The assumption was that software could be designed completely before it was built, the way an architect draws blueprints before construction begins. You gathered requirements, you wrote a specification document the size of a small novel, you designed the system, you built it, you tested it, you delivered it. Six months to two years later. The plan was everything. Deviation from the plan was failure.
Agile did not replace Waterfall by being a better process. It replaced it by exposing the misunderstanding at the core of Waterfall's worldview. Software is not a bridge. A bridge, once designed and built, does not need to understand what crossing it feels like from the pedestrian's perspective. Software does. A bridge does not get replaced by a different bridge in eighteen months because the city changed its mind about where it wanted to go. Software does. Waterfall assumed software was a construction problem. Agile said: no — it is closer to writing a novel. You draft, you revise, you respond to readers, you let the work teach you what it wants to be. The plan is not the destination. It is the first guess.
I watched the same correction happen with architecture. The monolith — a single codebase, a single deployable unit — made perfect sense when teams were small, deployments were infrequent, and the definition of “the system” was stable for years at a time. The misunderstanding it contained was subtler: it assumed that co-location was the same as cohesion. That putting things in the same place was the same as making them belong together. Microservices did not invalidate the monolith. They said: belonging together and living together are different things. A domain boundary is real whether or not you enforce it in the code.
Then the infrastructure underneath everything moved. On-premises data centres, owned hardware, manually provisioned servers — this model assumed that the safest place for your system was a building you controlled. The cloud corrected a different misunderstanding: that ownership and reliability are the same thing. You do not need to own the machine to depend on it. You do not need to manage the hardware to trust it. Infrastructure, it turned out, could be rented the way you rent electricity — consumed on demand, billed by use, managed by someone whose entire business is managing it well.
User experience underwent its own series of corrections — from desktop applications built for power users who learned a tool once and used it for years, to web applications that assumed the browser as a universal runtime, to mobile applications that assumed the device was always present, always personal, always connected. Each shift corrected an assumption about where users were, what they were doing, and how much patience they had.
I am not cataloguing these shifts to prove the industry’s inconsistency. I am cataloguing them because of what they have in common. In every case, the previous approach had been treating software as something it was not. And in every case, the correction arrived not from a committee or a standards body, but from practitioners who were close enough to the actual work — and honest enough about its nature — to name the misunderstanding out loud.
Computer Science Is Like Poetry. Most People Just Don’t Know It Yet.
I have said this to engineers, to managers, to students. The reaction is always the same: a slight pause, a polite nod, and then a pivot to something more comfortable. Nobody argues with it. Nobody agrees with it. It makes people uneasy in the way that most honest observations make people uneasy.
Here is what I mean by it. Poetry has formal rules — meter, rhyme, line structure. You can learn those rules. You can apply them correctly. You can write verse that satisfies every technical requirement and moves no one. The rules are necessary but not sufficient. What separates a technically correct poem from one that stays with you is something the rules cannot produce: the judgment of where to break the line, the instinct for which word carries the weight, the sense of what the poem actually needs to say versus what the poet had planned for it to say.
Code is the same. Syntax is grammar. Algorithms are meter. Architecture is form. And you can write code that compiles without error, passes every test, fulfils every requirement, and is nonetheless unreadable, unmaintainable, thoughtless — code that communicates nothing about what it was meant to do, that offers no handhold to the engineer who will work on it next. Correct code and good code are not the same thing. The distance between them is not measurable by any tool in the build pipeline.
That distance is where the art lives.
"Writing code is not less than an art. We have good and bad artists — more than in most creative fields."
The ratio of good to bad artists in software is, I believe, worse than in most creative disciplines. Not because the people are worse. Because the barrier to entry has always been lower than the barrier to excellence, and the demand has always outpaced the supply of genuine aptitude. In music, a bad musician plays to small rooms. In literature, a bad writer sells few books. In software, a bad engineer ships to production systems that affect millions of people, handles financial transactions, stores medical records, controls infrastructure. The stakes of bad art in this field are higher than in most others. The visibility of the gap between correct and good is often much lower.
I want to be clear: this is not elitism. The aptitude required for excellent software is learnable. It is not a gift present at birth and absent in everyone else. But it requires something that most technical education does not teach and most technical organisations do not cultivate: the development of taste. The ability to look at working code and feel that something is wrong before you can articulate why. The instinct that a design is carrying weight it shouldn’t, that a boundary is in the wrong place, that this solution solves today’s problem by creating three problems next year. These instincts can be developed. They develop slowly, through exposure to good work and bad work, through reading code written by people better than you, through having your own code read by people who will tell you honestly what they see.
The Aptitude Needs Reform. Not Replacement.
Here is the uncomfortable thing about aptitude: it is context-dependent. The instincts that make someone an excellent engineer in one era can become liabilities in the next. The engineer who developed excellent taste in the Waterfall world — who became skilled at thinking completely before building, who could hold a large system in their head and design it end to end before writing a line — carried instincts that were genuinely liabilities when Agile arrived. Not because they were wrong. Because the context had changed, and the instincts were calibrated for a world that no longer existed.
I have watched this play out in three distinct generations of excellent engineers becoming confused engineers: the transition from Waterfall to Agile, the transition from monolith to distributed systems, and the transition from on-premises to cloud-native architecture. In each case, the people who struggled most were not the mediocre ones. They were the ones who had been genuinely excellent in the previous paradigm. Their excellence was, in a specific way, working against them. They had more to unlearn.
Reform is not the same as replacement. The engineer who understood large systems deeply in the monolith world does not need to forget what they know. They need to recalibrate their instincts: the sense of where a boundary belongs, the feel of a design that will scale under pressure, the judgment of when to optimise and when to leave well alone. These capabilities do not expire. They require translation — from one context to another, from one set of constraints to another, from one definition of “excellent” to the next.
What the reform demands, concretely, is this: practices need updating as the tools and methods available change. Knowledge needs refreshing as the landscape shifts beneath it. Mindset needs loosening — the willingness to hold your current best understanding with enough humility that a better understanding can replace it. Reasoning needs expanding to accommodate systems too large and too distributed for any single mind to hold completely. And skills need honest auditing — not the comfortable list of what you are good at, but the harder inventory of what the next ten years will require that you cannot yet supply.
They Will Need to Reform Faster. The Canvas Changes More Quickly.
The transformation I have watched over twenty years will happen in four or five for the engineers coming after us. AI-assisted development, data engineering at scale, automation of processes that required human judgment for generations — these are not distant futures. They are present realities that will compound. The engineers who thrive in that world will not be the ones who accumulated the most skills. They will be the ones who developed the capacity to reform — to recalibrate their aptitude as the context demands it, again and again, without losing the artistic sense that made them good in the first place.
The most important thing we can teach the next generation is not Python syntax or cloud architecture or any specific tool that will be outdated in five years. It is the instinct that drove every shift I have witnessed: the willingness to look at how things are done, feel that something is wrong before you can articulate why, and stay in that discomfort long enough to find the misunderstanding underneath. That instinct is the constant. The canvas keeps changing. The poet stays.