Software people, in my very direct experience, are terrible at hardware... While in jest, I do think most software engineer's understanding of hardware abstractions is pretty poor and does disservice to the hardware they run on.
Generally speaking, I think both are true. Most people seem to have an affinity for either hardware or software, but rarely for both. Those who do are extremely unique. I don't mean that as an insult to anyone, just as an observatin having worked in both (and personally am much better at software than hardware, even though I enjoy both).
Hardware and software have VERY different deployment cost functions and lifecycles. Having "affinity" for one requires a mindset not really suitable for the other and being able to juggle mindsets, especially short vs long term focus is rare in itself.
I agree - at university there were software people and hardware people and a small number who studied mechatronics (hardware and software). But even the mechatronic people were really hardware people who just tolerated software.
I find both interesting but have been working in software for over a decade now.
Honestly, the thing that pushed me into software dev was the fact that hardware tools were absolutely garbage. Verilog felt like a joke of a language designed to torment rather than help the user.
I've worked for 40+ years with a hardware guy and he's great at software, for one reason: attention to detail. In hardware, you have to test, test and test. There's no "fixed it later with a patch" (for the most part).
I don't have a lot of samples, just one. So, YMMV.
Well, and aspect of hardware dev that lacks in software dev is testing. A mistake in hardware is much harder to correct once it leaves the factory vs a mistake in software. A large portion of hardware budget is ultimately spent on QA.
I have to think some of that attitude would be good for apple's software division.
It's not as if ternus will be writing code directly, he's managing managers. Hopefully that means he'll demand and budget more for QA.
In many cases, yes, but it really depends a lot on the person. I have a computer hardware degree but have led both software and UX teams. If you have a hardware background, you’re going to have to acquire a software background before you can lead software teams. What you can’t do is lead a software team like a hardware team (or vice versa).
This is actually one thing I think will be great as AI coding agents get better. Companies whose main expertise is hardware might start producing better software.
There are so many little bugs in consumer-facing apps that hit the ‘sweet’ spot of being incredible little annoyances that just aren’t worth putting an engineer on for a week to fix, but which are totally worth having an engineer throw an agent onto them.
I find that the code AI likes to write actually checks for “errors” too often when often you wouldn’t even want to do that. You don’t need to check every dictionary access and come up with a default value for example
Software people, in my very direct experience, are terrible at hardware... While in jest, I do think most software engineer's understanding of hardware abstractions is pretty poor and does disservice to the hardware they run on.
I know between Moore's Law and Gate's Law which one I would prefer to be the industry standard... https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
Generally speaking, I think both are true. Most people seem to have an affinity for either hardware or software, but rarely for both. Those who do are extremely unique. I don't mean that as an insult to anyone, just as an observatin having worked in both (and personally am much better at software than hardware, even though I enjoy both).
Hardware and software have VERY different deployment cost functions and lifecycles. Having "affinity" for one requires a mindset not really suitable for the other and being able to juggle mindsets, especially short vs long term focus is rare in itself.
I agree - at university there were software people and hardware people and a small number who studied mechatronics (hardware and software). But even the mechatronic people were really hardware people who just tolerated software.
I find both interesting but have been working in software for over a decade now.
Honestly, the thing that pushed me into software dev was the fact that hardware tools were absolutely garbage. Verilog felt like a joke of a language designed to torment rather than help the user.
2 replies →
I am deeply aware of software people being crap at hardware having worked in embedded for much of my career.
I've worked for 40+ years with a hardware guy and he's great at software, for one reason: attention to detail. In hardware, you have to test, test and test. There's no "fixed it later with a patch" (for the most part).
I don't have a lot of samples, just one. So, YMMV.
Bodge wires in shipped products beg to differ!
It's more the hope that he can bring the culture embedded in the hardware division over to software, which hopefully results in better software.
What they need is a culture of UX focus, and I don’t think it’s present in the hardware team either.
They’ve coasted too long on consistent visual identity, and even that’s been slipping. Time to focus on actual user needs.
Well, and aspect of hardware dev that lacks in software dev is testing. A mistake in hardware is much harder to correct once it leaves the factory vs a mistake in software. A large portion of hardware budget is ultimately spent on QA.
I have to think some of that attitude would be good for apple's software division.
It's not as if ternus will be writing code directly, he's managing managers. Hopefully that means he'll demand and budget more for QA.
The whole idea of (good times) Apple was hardware and software made coherently by the same people though.
“People who are really serious about software should make their own hardware" —Alan Kay
In many cases, yes, but it really depends a lot on the person. I have a computer hardware degree but have led both software and UX teams. If you have a hardware background, you’re going to have to acquire a software background before you can lead software teams. What you can’t do is lead a software team like a hardware team (or vice versa).
This is actually one thing I think will be great as AI coding agents get better. Companies whose main expertise is hardware might start producing better software.
There are so many little bugs in consumer-facing apps that hit the ‘sweet’ spot of being incredible little annoyances that just aren’t worth putting an engineer on for a week to fix, but which are totally worth having an engineer throw an agent onto them.
How? Coding agents are trained on every copy of every tutorial that skips error checking and implements the least resistance path.
I find that the code AI likes to write actually checks for “errors” too often when often you wouldn’t even want to do that. You don’t need to check every dictionary access and come up with a default value for example
I mean I would hope at least one person actually reviews the code before it goes out, but yeah we all know what hope does :)
1 reply →
Yeah, like fixing a annoyance while introducing one or two SEV-1 for sure is going to be great progress.