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.
As a software dev that started at a hardware focused company... I don't think it need be in jest, nor need be offensive? Hardware and software are different disciplines, even when they do overlap in embedded. It just seems to me - having been at a hardware company that failed to pivot to software, and went out of business (while a new competitor, software first, became Zoom), that the mindset is too different. Hardware requires far more planning; software far faster iteration. In software too much planning is a death sentence. In hardware insufficient planning is a death sentence. I think a single person absolutely could do both well but in my relatively basic estimation, I don't see it being a common trait. Hardware is cool and impressive, but I could never do it. And in my experience, many of the hardware folks I know don't seem to like how software development works either.
I don't think it means anything for this particular move; good leaders know what they know and what they don't know; they know how to motivate and select the right people, they know what to delegate and what to control. Having a track record of success of any kind is IMHO always the best start. I'm excited to see what kind of changes the transition from an operations person to a more technical leader may bring. Especially given how awesome Apple's hardware has consistently been.
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).
And then there is IC versus leadership. They're opposites. Lead times and supply chains are a headache in hardware, but tangible deadlines are great for keeping the project grounded. In software you have to invent your own discipline to keep the team on pace and bend over backwards to explain to physical-minded stakeholders why you can't build something with no lead times overnight.
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.
My experience studying 'Computing and Electronics' - a combined degree - was that we could get practically any extensions or leniency we wanted by blaming the other specialism. To each the other was mistrusted and magic.
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.
Verilog is not the best and that’s not even the worst part - tools like ISE/Vivado and Quartus are even worse!
It’s really amazing that at least there are some fully open flows for FPGAs these days, unfortunately they don’t support system Verilog. (I think this is still the case?)
Yeah at university we had to do some hardware stuff in our software course. I know there were better debug tools available as some students purchased them but playing with microprocessors was no fun.
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).
Ternus is foremost a manager though. Maybe he is also a hardware guy and that's the secret behind the success he had with Apple's hardware team, but I hope it's transferable to getting the most out of the software teams too.
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
This is actually one thing I think will be great as AI coding agents get better. Companies whose main expertise is code reviewing might start producing better software.
