Published 5/25/2001

I'm always astonished at how many EEs write firmware full-time. All of those years in college studying electronics, transistor circuits, Kirchoff's Law, and Electromagnetics, only to be doing essentially the work of a computer science major. Of course, in the embedded world so much of what we do is deep inside the hardware, so an EE background doesn't hurt.

In fact many colleges now recognize the mixed skills needed in our industry with the Computer Engineering degree program, a sort of watered down EE with serious software emphasis. It takes a lot more code than hardware to build an embedded system, so a software focus just makes sense.

When hiring firmware developers I've found little difference between each of these majors as long as the candidates have practical experience. In some particular industries, though, the degree might be important. One company I know almost exclusively hires mechanical engineers. They, too, get quite a bit of programming experience in college. Their sound understanding of machine control is what's important to this company that makes material handling equipment.

ME, EE, CS, CE - all are engineering or engineering-like programs that stress practical problem-solving abilities. We're taught to build things, to decompose big problems into solvable chunks. That in a large sense differentiates us from our friends studying the liberal arts.

Yet, in my career, I've found that some of the best developers of all are English majors! They'll often graduate with no programming experience at all, and certainly without a clue about the difference between DRAM and EPROM.

They can write. That's the art of conveying information concisely and clearly. Software development and writing are both the art of knowing what you're going to do, and then lucidly expressing your ideas.

The worst developers, regardless of background, fail due to their inability to be clear. Their thoughts and code tend to ramble rather than zero-in on the goal.

It's easier to train someone in a new language than to teach them to think clearly. C really isn't that hard to learn; it has but a handful of constructs. Most folks can learn the fundamentals in a week. Debugging takes longer, but all new programmers find themselves at sea when first faced with bugs. What do I do now? Should I single step through the entire program? How do I decide where to set breakpoints?

The worst thing about engineering-trained developers is their (usual) total disregard for stylistic issues in programming. Anything goes. Firmware is the most expensive thing in the universe, so it makes sense to craft it carefully and in accordance with a standard style guide. That is: make sure it clearly communicates its intent. This is where the English majors shine; they've spent 4 years learning everything there is to know about styles and communication.

In fact, the best programming book ever written was first published in 1914 and never mentions computers. It's "The Elements of Style", by William Strunk and E. B. White (Allyn & Bacon; ISBN: 020530902X). It's a slender volume of 105 pages that tells us how to write well. Just five bucks from Amazon.com. My observation is that most programmers are in dire need of such help. Unless a program's comments are in well-formed English, that unambiguously express the developer's intent, the code is junk. Just as we've got to conform to C's syntax to make a useful routine, our comments must be in solid English to aid future maintenance. And maintenance, as we all know, usually costs much more than the initial development.

A more recent, shorter and less pedantic style guide is "The Technical Writer's Checklist", by unspecified people at iTrain.org (http://itrain.org/ttwc/). Its 15 pages list 38 rules essential to effective writing.

So, mentor an English major and get a new team member. Listen to him, though, and learn to express your ideas more clearly.