Partly because everyone was an “optimization freak”, and partly because it was a cool way to show that only you could speak directly to the machine.
Machines did not always have plenty of RAM.
Servers were not always easy to upgrade.
Browsers did not have the same power.
Mobile devices could not handle everything.
And “just add more” was not always an option.
So there was a stronger sense of responsibility.
If the program was heavy, it showed.
If the page was slow, it showed.
If a loop was badly written, it showed.
If the application consumed too much memory, sooner or later the machine would remind you.
And the end client would definitely remind you too.
Today, things have changed quite a lot.
Computers are much more powerful.
Browsers can handle much more complex applications.
Servers can be upgraded more easily.
Cloud made scaling more accessible.
Frameworks do a big part of the work for us.
And users have become used to “heavier” experiences.
This has many positives.
We can build richer interfaces.
Faster interactive applications, dashboards full of statistics, and one-export applications where, with something like Expo, you can have Android, iOS, and a web app.
We no longer need to think about every line of code as if we are writing for a machine with minimal resources that run out after every wrong move.
And that is progress.
For technology, not necessarily for devs :P
But as often happens in technology, every convenience creates a new weakness.
Now, because machines can handle more, bad or heavy code is often simply hidden better.
It does not appear immediately.
It does not always show clear signs.
It just loads a little slower. The render is hidden behind a well-designed loader. Nobody checks how much memory it consumes, let alone why. Images may not even be compressed, making the response slightly slower.
And because this “slightly” is not immediately visible, it is easy to ignore.
Until it piles up.
Because the problem with unoptimized software is not always that it fails dramatically.
Many times, it just becomes slowly, quietly, and gradually heavier.
And somewhere there, the modern logic appears:
“It’s fine, we’ll just get a bigger server.”
“Who even still has that phone model?”
Which is actually destructive.
Because from the beginning, you are limiting your audience.
Every phone, within reasonable limits, should be able to run what you create. Because the biggest satisfaction comes from people continuously and widely using your creation.
This wrong mindset around unoptimized code has become quite common.
But we also need to be fair.
Premature optimization is also a problem.
If you try to optimize something before you even understand whether it needs optimization, you may lose time, make the code more complicated, and create technical debt for no real reason.
But avoiding premature optimization is one thing.
Writing code with no thought for performance because “the machine will somehow handle it” is another.
That is the difference.
We do not need to optimize everything.
But we do need to stop being indifferent.
Because performance is not only a technical issue.
It is user experience.
A user who waits too long for a page to load does not think, “the developer probably did not implement lazy loading.”
They simply think the application is slow.
A user who clicks a button and waits too long for a response does not care whether the issue is frontend state, a backend query, or API latency.
They simply feel that something is wrong.
A user with an older phone does not care if we have a MacBook, fast internet, and a local environment that runs perfectly.
If the application freezes for them, then for them the application freezes.
And this is something we easily forget: the huge range of devices that have internet access and processing power.
Because on our own machine, everything looks fast.
Until someone else opens it and asks whether the page is loading or simply meditating.
Today’s comfort with resources has made us more productive.
But maybe it has also made us a bit more careless.
In the past, when something was heavy, you were forced to look at it. You did not always have the luxury of hiding it. Today, we have more ways to cover a slow experience.
And this is very visible on the web.
A site may load huge JavaScript bundles to create animations and data tracking, constantly making requests to improve cookies and convince you to buy something.
But at what cost?
Apart from destroying your card, of course :D
And despite all that, at the beginning it may look “fine”.
Until it grows.
Until more users come in.
Until more features are added.
The same thing happens on the backend.
A bad query may not be visible with 10 records.
With 10,000, it starts to show.
With 1,000,000, it becomes a problem.
An API endpoint may be acceptable when one developer hits it locally.
But not when many users hit it at the same time.
A service may look simple.
Until it starts eating RAM, CPU, and money.
And this is where the other side of upgrading appears.
Yes, you can get a bigger server.
But that does not mean you solved the problem.
Sometimes you simply bought time.
Or worse, you bought the illusion that the problem does not exist.
Because if the code is wasteful, scaling simply makes the waste more expensive.
And this is very important today, especially in cloud environments.
In the past, heavy software mainly cost user experience and hardware.
Today, it also costs money to server providers.
All of this eventually turns into cost.
Maybe not from day one.
But the bigger a project becomes, the more visible it gets.
And here we return to the basic question.
Should we always write the most optimized code possible?
No.
But we should write code with awareness.
We should know when something is “good enough”.
But also when “good enough” is simply an excuse.
We should understand when an animation improves the experience.
And when it simply hides a slow interface.
We should know when scaling is the right solution.
And when it simply covers bad architecture.
We should know when optimization is worth it.
And when we are just chasing micro-improvements that do not really matter.
For me, that is the right balance.
Not obsession with performance.
But respect for performance.
Not writing code as if we are still working on machines from 20 years ago.
But also not writing code as if resources are infinite.
Because they are not.
They just look more infinite now.
A good developer is not the one who optimizes everything from the first line.
Nor the one who completely ignores optimization because “computers are fast”.
A good developer is the one who understands the context.
They know when to prioritize development speed.
And they know when they are simply trying to perfect something that does not need to be perfected.
Optimization should not be fear.
It should be awareness.
Because in the end, the user does not see the code.
They see the experience.
And if the experience is slow, heavy, or tiring, they do not care if behind it there is a beautiful framework, a modern stack, or a nice animation.
They will feel that something is not working properly.
And maybe that is the point we need to keep.
Technology gave us more powerful machines, easier scaling, and faster tools.
But that should not make us forget the basic idea.
Code should not simply work.
It should respect the machine that runs it.
And most importantly, the human who uses it.