Notes from my Eight-Year-Old Laptop

*The views expressed in this post are my personal reflections in today’s software engineering industry and do not reflect the views of any past or current employers.

I’ve been in software engineering for six years, and for half of that time I’ve worked as a Tech Lead and Solution Architect. Lately though, I’ve felt like a novice again. Not because I lost my way, but because I’m struggling to recognize the industry I once fell in love with.

These days I do most of my coding on an eight-year-old laptop. It’s served me well, but it demands patience. Try running a modern IDE, a bloated Markdown editor, and a stack of Docker containers on it, and the machine groans. It can’t keep up with the weight of modern software. That limitation forced me to stop and reconsider how I build things.

So I built my own tool: a lightweight Markdown editor in plain HTML, CSS, and vanilla JavaScript. Fast, local, sips RAM instead of gorging on it. Building it gave me a kind of peace I haven’t felt in years.

It also left me a little melancholy. It made me realize how far we’ve drifted from the foundations that used to define this craft.

The Evolving Resume-Driven Development Culture

A few years back, people talked about Resume-Driven Development (RDD): picking technologies not because they solve the user’s problem best, but because they look good on a portfolio. FOMO did a lot of the driving. If you weren’t using the newest, most complex framework, you were falling behind.

Now it feels like RDD has evolved into something worse: Hype-Driven Development (HDD). Social feeds are full of “AI agents” left running overnight, burning through tokens like they’re free. People call it “token-maxxing”, a performative race to generate the most complex, bloated codebase possible, with little regard for whether any of it was needed. It seems we forgot that good engineering starts with understanding the problem, and choosing the trendiest solution is not always the right approach.

It’s not just an individual habit either. It’s systemic. Companies chase the shiny stack over the sensible one, hoping it’ll attract talent or investors by riding the newest buzzword. Performance, sustainability, and the user’s actual hardware get sacrificed so the company can look “cutting edge.”

The “Full-Department” Mirage

Why is the industry drifting toward HDD? Why do we adopt frameworks so fast, or let agents run loose overnight? It’s not laziness. It’s that we’re buckling under unreasonable expectations.

The line between “Software Engineer” and “one-person IT department” has all but disappeared. From what I’ve seen and heard, companies aren’t looking for craftsmen anymore, instead they want a full-stack unicorn who also does DevOps, security, cloud architecture, and product management, under the convenient assumption that AI will cover whatever bandwidth is left over.

This is where HDD becomes a dangerous escape hatch.

When a company expects five people’s worth of output from one person in a single sprint, AI stops being a tool and becomes a way to mask the impossible. I’ve watched people let their agents run loose to hit absurd deadlines, adopt trendy libraries just to look state-of-the-art to stakeholders, and burn resources, all to keep up the illusion of moving at lightning speed.

People think it is “productivity” while actually it’s more of a managed despair.

And it’s a loop: companies demand instant results, we respond with machine-generated complexity to keep pace, and the systems that come out the other end are bloated, unmaintainable, and full of complexity debt nobody actually understands.

We try to meet the “expert in everything” bar with tools that strip us of our own agency. We stop being architects designing something elegant and become curators of machine-generated bloat, chasing targets that were never realistic to begin with.

The Cost of Chasing Speed

We’ve reached a point where the machine’s activity matters more than the quality of what it produces. We let agents run loose, piling on abstractions nobody asked for, simply because we can. At what cost, though? We’re burning resources, inflating complexity debt, and losing the one skill that actually matters: knowing when a problem has been solved well enough, and when it’s time to stop.

AI coding agents lowers the barrier to complexity. We can generate thousands of lines of code in seconds now. Instead of using that to build things cleaner or leaner, we use it to automate bloat. We let AI fill projects with unnecessary abstraction layers because it’s the trendy way to build, and because the machine makes the cost so easy to ignore.

We’re trading craftsmanship for the illusion of speed, building software as sluggish as an aging hard drive while being told we’re moving forward.

I’m not against AI. I’m against the erosion of our role as thinkers and decision-makers. We’re becoming editors of machine-generated complexity instead of architects of elegant solutions. It’s unsettling how many of us treat these agents like autonomous architects: give it a prompt, it spits out something bloated, and we accept it because it “works.” In doing that, we hand off our responsibility as engineers. We’re not designing systems anymore. We’re curating complexity we don’t fully understand.

AI is an incredible tool. AI is able to help us explore ideas faster, validate assumptions, or automate repetitive work, but the responsibility for deciding what to build, how to build and why, it still belongs to us. Let’s not lose the judgment that makes that tool valuable.

Closing Thoughts

It’s a strange thing, watching a field built on math and logic get pulled this hard by emotion and status. And I include myself in that, some of my own choices have been driven by the same pressure.

Building that little side project was a quiet act of rebellion. A reminder that simplicity isn’t a sign of incompetence, but sometimes it is a well-thought-out choice. That we still value the user’s experience over the developer’s ego.

I don’t want to go back to over-engineering. I want to build things that solve the problem, run efficiently, and go easy on the machines they live on. There’s a real joy in something that just works, without the noise or the pressure to perform.

I don’t have a fix for the industry. But I’m trying, in my own small way, to get back to the math and logic that got me into this field in the first place.

*The views expressed in this post are my personal reflections in today’s software engineering industry and do not reflect the views of any past or current employers.