The time you spent scrounging for cheaper parts needs to be compared to the opportunity cost and the actual production scale.
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
> Software engineers at startups, are building proofs...
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.
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
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.
It’s not an attitude, it’s how the industry works. You’re an uninformed fool if you think otherwise and fast moving businesses will eat you alive.
>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.
In turn and with respect, I argue your perspective is myopic and completely misses the huge desire/opportunity in today's market for reliable products. (This is why Apple got so far ahead of their competition).
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