* Chip design pays better than software in many cases and many places (US and UK included; but excluding comparisons to Finance/FinTech software, unless you happen to be in hardware for those two sectors)

* Software engineers make great digital logic verification engineers. They can also gradually be trained to do design too. There are significant and valuable skill and knowledge crossovers.

* Software engineers lack the knowledge to learn analogue design / verification, and there’s little to no knowledge-crossover.

* We have a shortage of engineers in the chip industry, particularly in chip design and verification, but also architecture, modelling/simulation, and low-level software. Unfortunately, the decline in hardware courses in academia is very long standing, and AI Software is just the latest fuel on the fire. AI Hardware has inspired some new people to join the industry but nothing like the tidal wave of new software engineers.

* The lack of open source hardware tools, workflows, high-quality examples, relative to the gross abundance of open source software, doesn’t help the situation, but I think it is more a symptom than it is a cause.

The vagaries of analog electronics, RF, noise, and the rest is another matter. While it's possible that a CS graduate might have a hint of how much they don't know, it's unreasonable to expect them to cover that territory as well.

Simple example, did you know that it's possible for 2 otherwise identical resistors to have more than 20db differences in their noise generation?[1] I've been messing with electronics and ham radio for 50+ years, and it was news to me. I'm not sure even a EE graduate would be aware of that.

[1] https://www.youtube.com/watch?v=omn_Lh0MLA4&t=445s

RF design, radars, etc... are more an art than a science, in many aspects.

I would expect a Physics-trained student to be more adaptable to that type of EE work than a CS student...

The article is more in the area of chip design and verification than PCB hardware, so I kinda understand where it's coming from.

Learning KiCad took me a few evenings with YT videos (greetings to Phil!).

Soldering needs much more exercise. Soldering QFN with a stencil, paste and oven (or only pre-heater) can only be learned by failing many times.

Having a huge stock of good components (sorted nicely with PartsDB!) lowers the barrier for starting projects dramatically.

But as always: the better your gear gets - the more fun it becomes.

My biggest gripe with the semiconductor industry as a career, compared to software, is twofold.

First, it is very concentrated. If you want to make good money there are only a handful of potential employers, and this only a handful of cities/neighborhoods where you will have to live; remote work is theoretically possible but not all employers make it effective. I found this the most frustrating. The upside is that people know this and this tend to stay at the same employer for a long time, so you get to learn from people with a deep understanding of the product, and people are mindful to keep a pleasant work environment.

Second, the pay isn't as good at the top end. If you have FAANG-level skills, you will typically do much better financially there than in the semiconductor industry —with the notable exception of NVidia for the past decade or so.

The reason for the "talent shortage" (aka "talent more expensive than we'd like") is really just because hardware design is a niche field that most people a) don't need to do, b) can't access because almost all the tools are proprietary and c) can't afford, outside of tiny FPGAs.

If Intel or AMD ever release a CPU range that comes with an eFPGA as standard that's fully documented with free tooling then you'll suddenly see a lot more talent appear as if by magic.

I'm guessing this isn't part of most curricula anymore?

Here's an example of my implementation of the original Tamagotchi: https://news.ycombinator.com/item?id=45737872 (https://github.com/agg23/fpga-tamagotchi)

I understand that it makes sense for a blog called Semiconductor Engineering to be focused on semiconductor engineering, but I was caught off guard because I have been working on the reasonable assumption that "hardware designer" could be someone who... designs hardware, as in devices containing PCBs.

In the same way that not all software developers want to build libraries and/or compilers, surely not all hardware designers want to get hired at [big chip company] to design chips.

Of my graduating class, very few are designing hardware. Most are writing code in one form or another. There were very few jobs available in EE that didn't underpay and lock you into an antiquated skillset, whether in renewables/MRI/nuclear/control etc.

We had enough exposure to emerging growth areas (computer vision, reinforcement learning, GPUs) to learn useful skills, and those all had free and open source systems to study after graduation, unlike chip design.

The company sponsoring this article is a contributor to that status quo. The complete lack of grassroots support for custom chips in North America, including a dearth of open source design tools or a community around them, has made it a complete non-starter for upskilling. Nobody graduates from an EE undergrad with real capability in the chip design field, so unless you did graduate studies, you probably just ended up learning more and more software skills.

But the relentless off-shoring of hardware manufacturing is likely the ultimate cause. These days, most interesting EE roles I see require fluency in Mandarin.

I would bet that a CS guy would have similar problems switching to hardware engineering.

I learned Ada sometime around 1991. Counting assembly for various platforms, I had already learned about a dozen other languages by then, and would later learn many more.

Sometime around 2000 I learned VHDL. In all of the material (two textbooks and numerous handouts) there was no mention of the obvious similarities to Ada. I wish somebody had just produced a textbook describing the additional features and nomenclatures that VHDL added to Ada -- That would have made learning it even easier. The obvious reason that nobody had done that is that I was among a very small minority of hardware people who already knew Ada, and it just wouldn't be useful to most people.

In all of my work, but especially in systems integration work, I've found that my knowledge of multiple domains has really helped me outperform my peers. Having an understanding of what the computer is doing at the machine level, as well as what the software is doing (or trying to do) can make the integration work easy.

More on-topic: I think it would be a great improvement to add some basic hardware elements to CS software courses, and to add some basic CS elements to EE courses. It would benefit everyone.

The former (CS -> EE) is very unlikely to happen at a large scale than the latter (EE -> CS). It is much easier to teach EEs to become (albeit, often bad) software engineers, than teaching CS student to be good engineers.

Also, the former (CS -> EE) will not happen in academia because of (1) turf wars, and (2) CS faculty not having any understanding, nor interest in electronics/hardware/engineering.

I once proposed to teach an IoT class in the CS department of a major university in US, the proposal basically fell on deaf ears.

Most people that land a successful long career, also refuse to solve some clown firms ephemeral problems at a loss. The trend of externalizing costs onto perspective employees starts to fail in difficult fields requiring actual domain talent with $3.7m per seat equipment. Regulatory capture also fails in advanced areas, as large firms regress into state sponsored thievery instead.

Advice to students that is funny and accurate =3

"Mike Monteiro: F*ck You, Pay Me"

https://www.youtube.com/watch?v=jVkLVRt6c1U

Hardware people go to software because it is lower-stress and can pay better (well, at least you have a higher chance of getting rich, start-ups and all that).

(But I am not saying either task is easy.)

I used Vivado (from Xilinx) a bit during my undergrad in computer engineering and was constantly surprised at how much of a complete disaster the tooling chain was. Crashes that would erase all your work. Strange errors.

I briefed worked at a few hardware companies and I was always taken aback by the poor state of the tooling which was highly correlated with the license terms dicated by EDA tools. Software dev seemed much more interesting and portable. Working in hardware meant you would almost always be searching between Intel, Arm, AMD and maybe Nvidia if you were a rockstar.

Software by comparison offered plentiful opportunities and a skill set that could be used at an insurance firm or any of the fortune 100s. I've always loved hardware but the opaque datasheets and IP rules kills my interest everytime.

Also, I would argue software devs make better hardware engineers. Look at Oxide computer. They have fixed bugs in AMD's hardware datasets because of their insane attention to detail. Software has eaten the world and EEs should not be writing the software that brings up UEFI. We would have much more powerful hardware systems if we were able to shine a light on the inner workings of most hardware.

Mostly B. Even if you work in company that does both you'll rarely get a chance to touch the hardware as a software developer because all the EDA tools are seat-licensed, making it an expensive gamble to let someone who doesn't have domain experience take a crack at it. If you work at a verilog shop you can sneak in verilator, but the digital designers tend to push back in favor of vendor tools.

The notable exceptions are:

* Formal verification, which is very widely used in hardware and barely used in software (not software's fault really - there are good reasons for it).

* What the software guys now call "deterministic system testing", which is just called "testing" in the hardware world because that's how it has always been done.

I don't know your background, but this feels like from someone who hasn't worked on both the aspects for a non-trivial industry project. The thing is software spans a huge range - web FE/BE, GUI, Database, networking, os, compiler, hpc, embedded etc. Not all of them have the same background to be a good HW designer. Sure you can design HW as if you are writing software, but it won't be production worthy - not when you are pushing the boundaries.

My work straddles both HW architecture and SW. I design processors, custom ISA optimized for SW application algorithms, and ensuring optimized micro-architecture implementation on the HW side to meet the PPA. I sit at the intersection of HW, SW and verification. People like me are rare, not just in my company but in the industry. Things fall through the gap, if you don't have someone to bridge it and then you have a sub-optimal design.

I don't deny that SW people cannot learn HW design, there is nothing magical after all; just hardwork and practice. But to say that the venn diagram is two identical circle is plain wrong. The cognitive load to shuttle up and down the two HW/SW stacks is a lot more than either of them.

Which doesn't pay as well as jobs in software do, unfortunately.

But, I seem to recall there were ways to bypass most hardware background knowledge for a CS degree. You had to do intro math and physics that did classical mechanics, but you could stop short of most of the electromagnetic stuff or multivariate calculus. You could get your breadth credits in other areas like statistics, philosophy, and biology. I think you could also bypass digital design with mix of other CS intro courses like algorithms, operating systems, compilers, graphics, database systems, and maybe AI?

My sibling is a CS@UIUC grad and they as well as CS+X were still required to do that.

In other universities such as Cal it's a different story. Systems programming and computer architecture course requirements have either been significantly reduced or eliminated entirely in CS programs over the past decade.

I've documented this change before on HN [0][1][2]. The CS major has been increasingly deskilled in the US.

[0] - https://news.ycombinator.com/item?id=45413516

[1] - https://news.ycombinator.com/item?id=45404647

[2] - https://news.ycombinator.com/item?id=45397327

Definitely no ALU design on the curriculum, no interfacing or busses, very little physics. They don't even put a multimeter in your hand.

Informatics is considered a branch of logic. If you want to know how to design a computer, you should have studied EE, is their thinking.