Programming

Programmer time is more expensive than computer time.

That might excuse inefficiency if all of these things were true:

• The programmers (or their employers) were buying new computers for all their users
• The new computers were fast enough to keep slow software from wasting users' time
• The electricity to run them was free and without pollution
• The resources consumed and waste produced by that upgrade cycle had no impact on the environment

What's really happening here is that producers of software are making things cheaper and easier for themselves by shifting and multiplying costs onto the users and the environment.

The amount of waste is staggering. It's part of why I haven't enjoyed professional software development in years.

Good article that I think does a pretty good job of outlining the problems of "Computer time is less expensive than programmer time."

I was "raised" on the idea that end-user time is more valuable than programmer time and nobody really talked about computer time except in the case of unattended-by-design systems like batch processing. Even those were developed to save end-user time by, for example, preparing standard reports overnight so that they would be ready for use in the morning.

I think that one place we went off the rails was the discovery that one way to manage efficiency was by creating different classes of end-user: internal and external. Why would management care about efficiency when the cost of inefficiency is paid by someone else?

So much software is created explicitly for the purpose of getting someone else to do the work. That means the quicker you get something out there, the quicker you start benefiting, almost without regard to how bad the system is. And why bother improving it if it's not chasing customers away?

It only got worse, and now that enshittification is in full effect for most big name consumer software, the speed at which things are falling is rising exponentially.

I only expect even worse now that AI has become mainstream and companies are half baking it into every notepad they find.

IMO, it's more relevant today than it was when written. None of the problems called out in the post have been addressed, and many have gotten worse.

I was just thinking about something similar in regards to gamedev.

For the past few years since college, we've been working on a 2D game in our spare time, running on Unity. And for the past few months I've been mostly working on performace, and it's still mind-boggling to me how is it possible that we're having troubles with performance. It's a 2D game, and we're not even doing that much with it. That said, I know it's mostly my fault, being the lead programmer, and since most of the core system were written when I wasn't really an experienced programmer, it shows, but still. It shouldn't be that hard.

Is the engine overkill for what we need? Probably. Especially since it's 2D, writing our own would probably be better - we don't use most of the features anyway. The only problem would be tooling for scene building, but that's also something that shouldn't be that hard.

The blog post is inspiring, just yesterday I was looking into what would I need to get a basic rendering done in Rust, I may actually give it a try and see if I can make a basic 2D engine from scratch, it would definitely be an amazing learning experience. And I don't really need that many features, right? Rendering, audio, sprite animation, collisions and scene editor should be sufficient, and I have a vague idea about how would I write each of those features in 2D.

Hmm. I wonder what would be the performance difference if I got an MVP working.