Having been working in the software industry for quite some time, I would still occasionally miss those days spent working as a hardware engineer – or more specifically, an integrated circuit designer. In case you wonder what is the difference between the two kinds of work, I hereby explain in visualized form how they differ substantially, though in layman’s eyes they are quite similar because both require you to interact with software and both can be categorized as IT industry.
First off, here is the graphic interface of the software you use on a daily basis as circuit designer. Old fashioned if not ugly – because manufacturers of such software don’t give a damn. You got to use it no matter how user hostile it is, because you just don’t have any choice.
You also do programming as a digital circuit designer, but by using a very low level language called Verilog.
You code will get “compiled”, but not compiled in a sense as software engineers understand. Literally, your code is translated into a circuit schematic like the following.
Then comes the real “compilation” – turning your abstract design into something physical. This is an offsite process that can only happen in a factory called Fab. This process is typically hugely expensive and one shot (loosely speaking). Any bugs you let slipped into this phase are engineering catastrophes.
The “compilation” process usually takes quite some time, because there are lots of procedures need to be applied. The products are tiny little black colored chips, as shown in below (note that those chips are mounted on green PCB circuit board already).
Or they could look a little bit fancier if they are large and used in high-end electronics.
It is a great honor if chips designed by you ended up here.
An annoying thing is – though those chips are destined to sold to downstream electronics manufacturers as parts in their products, samples will be returned to you first for testing, making sure that they can work properly and reliably. Testing could be a very daunting process. You will need something like this. No need to say you will be chained in a test room with no windows, assisting test engineer to locate bugs.
What if there is a design flaw or bug? Can you fix it on the physical chip? More often than not that’s not possible – you need to fix it in code and let the factory do a new physical model. So the company loses money and the managerial side gets mad at you.
Now let’s see what I am interacting with as a (internet industry) software engineer on a daily basis.
First, you use very fancy-looking IDE software to write code in fancy-looking programming languages. IDE Softwares need to be fancy-looking, otherwise, they get replaced by competitors very quickly, and so do programming languages.
And then you compile, test and upload your code via networks to “servers”, or physically remote computers. They may sit thousands of miles away in places called data centers like below.
You don’t give a damn to them because most of the time they appear to you like the following – you control them by typing commands.
Then, da-da! your work is recognized. People see it in the following form, and they are like “wow” when you mention you (partially, of course) made it.
As you can imagine, compared to software developing, hardware developing is rather “dirty”. For hardware design, too many physical procedures need to be involved; the feedback loop is long; the cost of mistakes is prohibitively high; people working in hardware industry tend to be extremely conservative – they do not trust any code written by a newbie, no matter how correct it might look like. A semiconductor company needs to widely spread its workforce – sales engineers to boast in front of customers how wonderful your chips are, field application engineers to help customers make the end product in case they do not the expertise (almost a sure thing), in-house circuit designers to design the chip day and night, test engineers to figure out bugs in physical chips – though all of them are labeled “engineers”, they know very very little about the work done by engineers of other types.
With all these being said, I don’t mean I regret being ever a hardware engineer – that work experience has lent me so many unique perspectives in my current work. The two types of job touch the two poles of the IT industry respectively, which kind of makes me proud.