Modern software is easy to scale, hard to fix, and increasingly built on things we barely understand.
Modern software is easy to scale, hard to fix, and increasingly built on things we barely understand.
•
May 7, 2025
•
Read time
Modern software is faster, easier, more scalable than ever. You can ship a global product in a weekend. Spin up entire architectures with YAML or just conversationally.
But here's the uncomfortable truth: in our pursuit of speed and convenience, we’ve created a generation of engineers who’ve forgotten how things actually work.
Cloud platforms have mastered the art of selling convenience as innovation. And it’s worked. Developers don’t need to know how consensus protocols work, or how networks behave under load, or what happens when a disk starts to fail. The platform handles it. Until it doesn’t.
We’ve traded understanding for speed. Mastery for momentum. And when things break, because they always do, the cost is real.
Engineers stare at dashboards without intuition. Incidents drag on longer than they should. The team scales horizontally when they should be debugging vertically. There's more guesswork than diagnosis.
This isn’t just about outages. It’s about erosion of curiosity, of craftsmanship, of critical thinking.
If every performance problem is solved by adding nodes instead of improving code, what happens to the skill of writing efficient systems? If every architecture problem is solved by “just using a managed service” how often do we stop to ask why something works the way it does?
We’re building castles on foundations we no longer inspect. We’ve made it possible to deploy without understanding. And so we do.
None of this is an argument against cloud platforms. They’re incredible. Managed services exist for a reason. But the issue isn’t the tool; it’s how we relate to it.
We confuse using something with knowing it. We mistake shipping velocity for engineering depth. And we rarely ask: What is this abstraction hiding from me?
The best engineers I know aren’t the ones who can write the fastest code. They’re the ones who know where the dragons lie, the ones who can drop into the kernel when needed, or trace a network issue across zones, or just calmly say, “I think I know what’s going on here.”
Not because they’ve memorized everything, but because they haven’t stopped learning.
We need to bring back discomfort. Not for its own sake, but because real understanding is often inconvenient. It means asking questions we don’t know the answers to. It means tracing past the interface. It means poking around in systems that mostly “just work” until they don’t.
Engineering leaders have a responsibility here. To hire for fundamentals, not just framework fluency. To create time and space for digging deeper. To value people who build, but also people who ask hard, annoying, necessary questions.
The future of engineering is about mastering abstraction, not rejecting it. The teams that win won't be the ones who abstract everything away. They’ll be the ones who know how far down they can go and aren’t afraid to go there when it matters.
Because when your system breaks at 2am, it won’t be your cloud provider that saves you. It’ll be the engineer who knows how the thing actually works.
Convenience is good. But it’s not the same as competence.
Your tools should make you faster, not duller.
Use the abstraction. But never stop reaching beneath it.
Why human-machine collaboration is the future of enterprise AI.
Why emotional design is the next frontier in user experience.
