How does it not make sense? As a software person you are completely relying on the hardware to do its job. You are putting your blind faith into the work of semiconductor engineers in order for you to get your paycheck
More often in startup land, you are relying on the investors for your paycheck.
The place where the value is is not at all related to where the difficulties are or the bottlenecks are. The universe does not have that kind of sense of distributive justice.
It makes no sense because if the semiconductor industry only hires the absolute best student of the cohort, that's a way higher barrier of entry than software where 90% of the students in my coding class is now working in MANGA. That should guarantee an insanely high pay for the semiconductor engineer. Instead he's currently making less than what fresh grad MANGA hires are paid.
But you said they hired 1 person out of a class of 20? Obviously the few who get in can't ask for a high salary with that many candidates per position.
>But you said they hired 1 person out of a class of 20? Obviously the few who get in can't ask for a high salary with that many candidates per position.
Obviosly they can, assuming that these companies hire "only the best". That means that in the demand/supply calculations, the demand is not for "graduates of semiconducting programs" but "only top top graduates of semiconducating programs, ignore the rest".
That's in much shorter supply, and means that 95% of the "class of 20" aren't even considered worthy as candidates, and aren't competition for those top semicon jobs. They'll need to find work in another field (like switching to software), or low level semicon jobs.
You could write the same thing about the concrete slab the office or data centre is on. The barrier to being a concreter is very close to "applied for a job as a concreter".
It does not make sense because software could be written using the same quality standards that CPUs use, which would involve a lot of formal reasoning and proofs.
This work style, however, is not valued at all and is actively suppressed by "flat", non-expert hierarchies that reward people for being popular and sloppy.
It works for web companies because errors have no consequences for them and the web has turned into a gigantic tabloid anyway.
Abstraction layers become simpler, more rigid and more robust as you peel them.
A painter uses rules of thumb all of the time, yet his work is entirely dependent on chemical engineers getting their science and formulas right. Artistic painting is just one of many uses of paint (and probably its most approximate), but both the painter and the industrial product engineer need the same quality assurances regarding their colors.
Hardware needs to be solid to allow all kinds of software the freedom to be built.
I think you also overestimate the formality in CPU design. Yes they do a lot of testing, but it's not lik an airtight mathematical document for the whole chip.
In my experience what trade-off is the correct one depends on your ability to iterate and where your risk comes from. Can you ship infrequently, but you know with high confidence what product/market-fit looks like (extreme example Mars mission)? In that case you want all the planning and verification you can get. Can you ship often, but have little confidence in what your users/customers want and what will grow your business (extreme example social media app)? In this case you probably want to prioritize speed of iteration and rework technical aspects once you know it's what's needed.
I've had a very angry product manager because a feature took almost a second to load. I told him that we could make it load much faster but it would be almost a week of work and he should validate the feature with customers before we invest in that. "Of course we need this feature! It's core to the product!". So we spent a week. It worked realty nicely and scaled pretty well. In the next 12 months the feature changed completely twice because customers didn't find it useful. Then it was removed entirely and then we had to bring it back because the sales team liked it for demos. All that iteration was required to find what the market needed, not fit technical reasons, except for the performance work which was entirely wasted because it all got redone after the first user feedback.
