Month: January 2017

Programming, as I guess, is just like many other craftmanship work, needs abundant guidance and tutoring. In today’s world there is an enormous amount of excellent open source projects out there and you could download them in just a few clicks. Theoretically, there are no hidden secret recipes and you can learn everything by studying the code, but very people become experts in this way, probably just like no one becomes a surgeon by doing post mortems on his/her own, no matter how many corpses are available to him/her.

Programming, given its engineering nature, is finding the quickest, simplest and most efficient way to solve your problem. It is difficult to master some techniques if you don’t make mistakes and learn from failures, but more often than not, you would want somebody to tell you what is the correct way to do things, simply because life’s too short to repeat mistakes. It’s so much better when some engineering catastrophe happens, you are able to recall instantly that somebody ever told you a possible cause that can lead to it, than to guess and troubleshoot without any clue for days. This is why people are always emphasizing on “platform”, “team” and “projects” when advising for software engineering career selection. Work hours do not translate into work experience equally in different environments. In a reputable corporation, you see projects that prove themselves by sustaining market pressure, so you know the architecture and implementation, especially after years of iterative development, is well thought and well designed. You see systems that handle millions of queries per second and what special treatment and care such a system needs. When you are asked to improve it, you need to first figure out all the internal wiring, how components interact with one another, and what functionality that snippet of fancy-looking code brings. Achieving this level of proficiency is impossible by sitting at home and studying alone. If you don’t have smart and expert level team members answer your questions, you would be stuck forever – for real practical problems, chances are very slim that you could find answers on Stackoverflow.

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.