Who this is for: nothing new here for senior devs. This one's for folks 2-3 years into the field who are feeling the "is it even worth it anymore" doubt. Keep studying. It's worth it.
Note: the ideas are mine; I used AI to format and organize my thoughts
Everyone keeps saying programming is over. That AI writes the code, that the profession will disappear, that it's not worth learning anymore.
I feel differently. To me, this conversation confuses two things: typing code and doing engineering. They're not the same, and only the first one is becoming a commodity.
And looking back, this has always happened. We used to write SQL by hand until the ORM came along and abstracted most of it. We used to build everything from scratch until frameworks standardized the heavy lifting. Each of these jumps felt, at the time, like it would "make things too easy" and strip away the programmer's value. It didn't. The value just moved. It freed us from the mechanical part so we could think about the genuinely hard part.
We're in one more of these shifts. And the skill that defines a developer in this phase isn't remembering the syntax of a for loop. It's engineering and decision-making: understanding how the pieces connect, knowing what consumes more and what consumes less resource to reach the same goal, and making those choices meet at a point where the business owner gets the best balance of quality, cost, and profit.
This isn't over. It's barely begun. And honestly, it's still fun.
Every technical decision is a cost decision
This is the heart of it.
Writing the code that solves the problem is only half the work. The other half is choosing how to solve it in a way the business can actually sustain. Cost of money, of time, of maintenance, of risk. And this is where a good engineer earns their keep, in very different ways depending on the company's pocket.
In a company with few resources, the right decision can be the difference between surviving and burning through the cash. When money is tight, every infrastructure choice matters. Paying for a fixed server every month to run a task that takes thirty seconds a day is pure waste: you pay for the other 99.9% of the time the machine sits idle. Swapping that for something that charges per use can turn a bill of tens of dollars a month into a few cents. Multiply that across several small services and the startup buys itself months of runway, just by deciding well. Here, a good engineer isn't a luxury, it's a survival factor: they stretch the little that exists.
In a company with resources to spare, the game changes, but the logic is the same, only at scale. The savings don't show up in cents, they show up in thousands or millions. That same "use the right resource for the right goal" decision, repeated across hundreds of services, becomes a fat line in the budget. A good engineer sees money leaking where everyone else just sees "the system working": paid idle capacity, inefficient queries, infrastructure oversized "just in case". That waste is silent, it doesn't break anything, it just drains margin month after month. A good team gives that margin back, and reduces risk on top of it.
But pay attention, because this is the most important point: there is no one-size-fits-all recipe. The same choice that's brilliant for a thirty-second daily task can be terrible for a high-volume service running all the time. Everything is studied, everything is relative, everything depends on context. The skill isn't "knowing the right answer", it's knowing how to ask the right question and measure the trade-off case by case.
In the end, that's what the business owner buys from a good engineer: not lines of code, but decisions that bring quality, cost, and profit together at the point that makes sense for that company, at that moment. AI helps you write code. That judgment, it does not.
A small case to ground it
I recently built a silly little project to play with: a crawler that generates a stock JSON for a store, every day, on its own. Sounds trivial, but there was a hidden decision at every step.
First, a bug that made no sense. I had two versions of the same crawler, same logic. One kept getting HTTP 429 (Too Many Requests) on the very first request; the other went through the whole store without complaining. The lazy hypothesis was the usual one: "I must have blown past some request quota". But the evidence killed that instantly: the version that worked ran in between the other one's failures, same IP, seconds apart. If it were a quota, both would fail together.
The real cause was a single line of configuration: the User-Agent. One version announced itself as a bot, the other looked like a browser, and the server treated them in opposite ways. It had nothing to do with the language or with which one was "better". It had to do with investigating with method instead of guessing. In this new phase, debugging with evidence is worth more than memorizing an API.
Then, where to run it. The job runs about thirty seconds a day. A fixed server would sit idle 99.9% of the time, and paid. So I built it on an approach that only runs when it's called, stores the result, and fires itself every day at the right time (in my case, AWS Lambda + S3 + a scheduler). The result: the project runs for ~$0/month, basically cents, versus the fixed cost of a server running all month to do the exact same thing.
And here comes the honest part, calmly: having a server matters too. In this same project I have a Ruby on Rails API running on a server, because for that it makes sense. And nothing would have stopped me from just dropping a cronjob on my own local server for this crawler. It would work. It has its pros and cons, a topic for a future post. But at that moment, with the structure I had in mind, serverless was the simplest, most practical, and cheapest option for me. Serverless isn't "better", it's "better for this case". Every case is its own case.
And that's exactly the kind of reasoning we need to have: the question isn't "what's the coolest solution", it's "what fits best here, right now".
Simple, done well
If there's one thing this project reminded me of, it's this: it doesn't look like it, but simple done well is harder than it seems. Choosing the simple, right solution for the context takes more thinking than going off and building the complex one. The complex is often just us running away from the decision.
Programming isn't over. It became less about "how do I write this" and more about "what's the best way to solve this for this business". It's more demanding, more strategic, and, for anyone who likes solving problems, more fun. It's not the end. It's the next phase.
Top comments (0)