CS, EE, or BA?
If you can't write it down in English, you can't code it. So does that imply English majors might have a role in development?

When hiring firmware developers I've found little difference between CS, CE, and EEs for doing firmware development. In some industries, though, the degree might be important. One company I know hires mechanical engineers exclusively. 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 a solution.

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?

Too many engineering-trained developers have a 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 four years learning everything there is to know about styles and communication. And they're used to working to a standard, like the Chicago Manual of Style.

Heroes
In a Dilbert cartoon, the pointy-haired boss, apparently frustrated by the company's sub-par products, announces that he'll reward each bug fix with a $10 bill. Wally says: "Hooray! I'm gonna code me a minivan!"

Unfortunately the heroes, those who seem to save the organization in a great flurry of activity, are often reacting dramatically to the problems they created. Like Wally, they're rewarded for the successes while no one notices that furious activity is no substitute for doing things carefully.

Solving problems is a high-visibility process; preventing them is much better, but earns few rewards. This is illustrated by an old parable:

In ancient China, there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, "I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.

"My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors.

"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."

Unfortunately, sometimes the very best developers get the least acknowledgement, even from their own teams.

Jack Ganssle (jack@ganssle.com) is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack click here .

Endnotes:
1. Agile Manifesto, http://agilemanifesto.org/.
Back

2. Circadian. Shiftwork Practices 2005, www.circadian.com (Shiftwork Practices 2007 is now available at here for $250.).
Back

3. Jones, Caper. Program Quality and Programmer Productivity (IBM Technical Report TR 02.764). 2nd edition, IBM Corporation: San Jose, Californiam January 1977; out of print. According to Caper Jones's website. www.spr.com/news/bibliography.shtm some sections have been reprinted separately in Programming Productivity--Issues for the Eighties.
Back

4 Kruger, Justin and David Dunning. "Unskilled and Unaware of it: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,"Journal of Personality and Social Psychology, December 1999, Vol. 77, No. 6, 1121-1134.
Back

5. DeMarco, Tom. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall, 1986.
Back