I’m retired. I should be relaxed. I’ve got Pop!_OS 24.04 running with the new Cosmic desktop beta—which, by the way, is genuinely impressive work from System76. I dual boot with CachyOS for gaming, another beautifully crafted distro. I’m tinkering, exploring, enjoying my Linux playground.
Then I open a weather app.
It wants me to enter longitude and latitude. Manually. No city lookup. No zip code. No “use my location.” Just raw coordinates like I’m programming a GPS satellite from 1987.
How hard is it to add a lookup? There are free APIs. It’s a solved problem. But no—someone shipped it anyway. Good enough, right?
And that’s when I realized: I can’t stop caring. Even in retirement, I physically cannot look at lazy code and just… let it go.
The Pattern Is Everywhere
It’s not just one weather app. It’s a pattern I keep seeing in the FOSS world, particularly in desktop Linux extensions and utilities.
Power management extension that displays the wrong status and crashes randomly? Shipped it anyway.
Window tiling extension that’s jerky on hardware that should handle it fine? Eh, works on my machine.
I’m not naming names—I don’t want to throw individual developers under the bus. But the pattern is clear: good enough to compile is good enough to ship.
And I can’t unsee it. Because 44 years ago, constraints taught me that “good enough” wasn’t actually good enough.
Where This Started
1981, I was 25 years old, working in my father’s carpet warehouse, maintaining his inventory with paper ledgers. By hand. Every day.
I got frustrated watching the inefficiency, so I bought a TI-99/4A—one of the first personal computers available to regular people—and taught myself BASIC. Three months later, I’d built a complete billing and inventory system that replaced those paper ledgers entirely.
That machine was brutally constrained. You had to care about every byte, every cycle, every design decision. There was no room for “I’ll just throw more RAM at it” or “the CPU can handle the inefficiency.” You either wrote tight, thoughtful code, or your program didn’t work.
Those constraints didn’t just teach me to optimize performance. They taught me to care about craft. To think through problems. To not ship garbage just because it technically runs.
What Cheap Hardware Killed
Here’s what I think happened: hardware got so fast and so cheap that caring stopped being necessary.
You can write a weather app that makes a dozen unnecessary API calls because network latency doesn’t matter anymore. You can skip implementing a city lookup because users have browsers they can use to find their coordinates. You can ship an extension that leaks memory because most systems have 16GB of RAM anyway.
None of it breaks anymore. It just… works poorly. And because it works at all, it ships.
I’m not saying every developer should have learned to code on a TI-99/4A with 16K of RAM. But I am saying something was lost when constraints disappeared. When hardware got good enough that lazy code still functioned, we stopped teaching people to care about the difference between “runs” and “runs well.”
What I Still Respect
Don’t get me wrong—I’m not just shaking my fist at clouds here. There’s incredible work happening in FOSS.
Cosmic desktop itself is proof that people still care about quality. System76 didn’t just slap together a desktop environment and ship it. They’re building something genuinely impressive—modern, fast, thoughtful. Yes, it’s still in beta and has issues (windows staying on top, I’m looking at you), but I can see the craftsmanship in the work. They’re doing it right.
Pop!_OS and CachyOS—the two distros I dual boot—are works of art. Both are carefully crafted, thoughtfully designed, and built by people who clearly care about quality. These projects prove that craft still exists in FOSS.
MangoHud, when built from source, is another example. Tight code, good performance monitoring, actually solves the problem it set out to solve.
The tools are there. The talent is there. What’s missing is the expectation that things should be done right, not just done.
I Can’t Stop
Even in retirement, I’m still optimizing things nobody asked me to optimize.
My main game is Elite Dangerous. On Windows, it used 13+ GB of RAM. On Pop!_OS? 6-7 GB.
I have 64GB of RAM. I don’t need to care about that difference. But I noticed it. And I spent time tweaking configs, monitoring performance, making sure everything ran as efficiently as possible.
Why? Because I can’t help it.
I learned to code in an era where you had to care, and that wiring never went away. When I see a weather app that can’t be bothered to implement a city lookup, or an extension that crashes because nobody tested edge cases, or a UI that’s jerky because nobody profiled the render loop—I see laziness. And it drives me insane.
Maybe that makes me the weirdo. Maybe I’m the grumpy old dev who can’t accept that “good enough” actually is good enough in 2025.
But I don’t think I’m wrong.
Hardware Never Gets Good Enough
Here’s my thesis: Hardware will never get good enough that we should stop caring about quality.
Yes, we have fast CPUs and cheap RAM and SSDs that make everything instant. But that’s not an excuse to write lazy code. That’s an opportunity to write great code that runs even better.
Those early constraints didn’t just teach me to optimize performance. They taught me that craft matters. That the difference between “works” and “works well” is worth caring about. That users deserve better than “I shipped it and it didn’t crash.”
I’m grateful I learned to code when I did. When constraints forced quality. When you couldn’t just throw hardware at a problem and hope it went away.
And I’m defiant about it. I’m going to keep caring about tight code, thoughtful UX, and software that’s actually finished—even if that makes me the weird old guy who can’t let things go.
Because hardware never gets good enough. There’s always room to do better. And someone should.
Might as well be me.
