I fixed that one for you. Software engineers not at startups are usually not building proofs-of-concept. They are usually building production systems. And at the early stages of development of production systems, it can save a lot of headache down the road to think ahead. Yes, you will be slower in the moment, but the number of times I have heard a startup say "we did great with our first version, but then realized we needed to completely rewrite the thing to scale" (when the rewrite takes literally a week longer than the first version) has been too high.
This is completely false. Most startups go through massive pivots. I’ve been through 6 of them (2 successful exits) and literally everyone made drastic changes to every code base to target completely different markets and features.
I’m telling you from experience, if you can’t recognize providing business value as an engineer recognizing opportunity cost, you will stagnate as a junior engineer or even destroy the company as a senior one.
This attitude is one vendors have leaned into way too hard, and it's why there are so many consumer products out there which shipped with half-baked, buggy firmware.
>which shipped with half-baked, buggy firmware.
Because consumers pay for this shit. It’s the world we live in. The people working on the bug free version ship a year later after the buggy competitor ate the whole market. They’ve also taken the recognized revenue to take a higher valuation and hire more engineers to rewrite their buggy system than won the market.
Bugs don’t matter unless it’s a competitive market where they can change a sale. A startup operating in that kind of market is already fucked.
Software engineers, especially at startups, are building proofs of concept that they need to iterate on very quickly. Spending significant thought on reducing opex is an absolutely terrible call in the early stages of dev.
If you have a profitable product, or one that would be if you can squeeze costs, then you play the optimization game.
The difference between electrical engineering and software engineering is that software can be updated after it’s deployed. The ability to get all of those gains later changes the strategy completely