Survival of the Fittest

Do you work hard? How about smart? This article might make you mad, but hopefully it's start some ideas flowing. Feel free to send flames to use via email!

Published in Embedded Systems Programming, January 1992

By Jack Ganssle

I've never really understood how big companies operate. Walking through the halls you'll see hundreds or thousands of individuals scurrying about, each presumably working frantically to increase the profitability of the business. It is pretty clear how these operations behave during a downturn, though. An order from the top demands some across the board cut in payroll; as we've seen far too often lately, lots of poor souls then lose their jobs. Shortsighted companies pick these from the most recent hires. Others, those willing to make the tough (but fairer) decisions, will keep the cream of the crop and get rid of non-performers.

Smaller companies are more often than not uniformly rational in firing decisions. When business problems demand some sort of layoff, they'll usually divest the "dead weight".

All of us want very much to not be dead weight. Furthermore, I for one very much wish to see my salary steadily increase over the years. It's unrealistic to expect that increasing age or time on the job is all it takes to make either of these goals.

January is a good time to reflect on our accomplishments over the last year and to plan ahead for the next 12 months. So many New Year's resolutions are slightly narcissistic goals like losing weight or quitting smoking. You spend months planning and implementing projects for your company; once a year plan how you can make yourself a more valuable member of the development team. Job security (if there is such a thing anymore) and continued raises will depend on it.

I know of a mechanical engineer who spent most of the space race designing wheels for moon buggies, thereby becoming so focussed on such a narrow area that I imagine he is now unemployable. If he had planned ahead, he certainly would have changed jobs before getting so specialized. Strategically plan your career to maximize your employability: be technically broad and competent, and learn about other areas (such as business) that effect technical decision-making.

The painful truth is that we're all commodities that companies hire and fire to satisfy internal profitability needs. This is neither good nor bad, but it is a fact of capitalism. A company resembles the food chain: those at the bottom are perhaps more replaceable than those at the top, but even CEOs are bought and sold in the stockholders' relentless quest for equity. We can move up the chain via politicking (distasteful as that is), or by constantly honing our skills to become more useful to the company.

Merit Raises

Cost of living raises theoretically are just to compensate for inflation. Few of us are happy with that minimum, and expect, no, demand, additional increases as well.

Let's face it: merit raises are for merit. What have you done this year that makes you more valuable to the company? Don't answer that you designed product X; you are paid for doing product design. Why are you now a better employee?

A lot of companies give merit raises as a matter of course, but in these troubled times we can expect some rethinking of this policy.

If your job as firmware engineer is implementing products, then presumably a merit raise is earned by being able to build systems faster, more accurately, and more economically. Merit raises most definitely should not come from the nebulous phrase of "having more experience". Are you better this year at your job than last? Can you measure, or even better, document this performance improvement? This isn't a rhetorical question to be casually and quickly answered in the affirmative. Wrestle with the perhaps uncomfortable truth. How can you do better in the coming year? If you decide you've done everything correctly and need no changes, you probably haven't been honest with yourself.

Managers curse engineering activities because they are so hard to measure. There's always a thousand unforeseen problems, some technical, some specification related, and others due to events far beyond the control of the engineering group. It's hard to compare this year's project with last year's, since no two are of equal complexity.

It might seem impossible to assess engineering productivity, but there is one sure fire way to improve. Re-use code. With or without object oriented techniques, build libraries, document them, and re-use them constantly. You can be very sure your boss is grading you, comparing you to associates and others in related fields.If you re-invent the wheel with every program, your rating will surely suffer in comparison to someone using a clean code library.

A second surefire way to speed code generation is to have a library of algorithms to draw from. Few of us are smart enough to invent a Fast Fourier Transform from scratch. If you collect algorithms, when the need arises for some strange routine you will likely already have all of the information needed to start work.

This is easier said than done. It takes determination and constant work to build these libraries. It takes patience and thought just to plan how you want to organize and document them. Spend some time planning the libraries. Do you need your own written software standards manual to define the libraries' framework? Then by all means work one up. Leave nothing to chance.

Technical Skills

A firmware designer is paid primarily for his or her expertise at developing embedded code. Are you good at this? Can you be better? A number of years of experience does not imply any expertise - is your code a house of cards waiting to crumble?

Technical skills run the gamut from knowledge of your company's technologies to good coding and design abilities. Most of these are obvious. Think about each and look for ways to improve.

One that few consider is the issue of bug management. Very large QA team. However, most embedded systems are developed by one, or perhaps a few, engineers. In these shops software quality assurance is generally informal. It can be awfully easy to make a quick fix and ship the product with only the most cursory of checks.

Do you let your boss find the bugs? Take responsibility for testing. Keep your reputation clean by releasing only that code you are sure of.

Do you study new methodologies and new changes in the field? It amazes me that three years ago virtually all 8 and 16 bit embedded code was written in assembly language. Now, something like 80% is in C. What's next? Certainly C++ looms immediately ahead. We should all be studying it now.

What do you know about object oriented programming? There's a world of difference between reading a book on the subject and actually writing code. OOP will have a profound effect on most of our lives. Start playing with it now, so you aren't forced to play catch-up later.

Avoid being too specialized. Though increasing specialization is a trait of our times, it creates a balancing need for increasing diversity. Although the traditional sciences still follow a course of Descartian reductionism, a new sort of generalism is evolving. Whole new fields that attempt to tie together vastly different subjects have been born. We will be called upon to build systems based on these ideas. Consider chaos theory: though discovered by mathematicians it seems to underlie much of the nature of the universe. Already it shows promise of revolutionizing data compression and image analysis.

I do believe that the vast breadth and intricately interwoven structure of modern technology demands that we become Renaissance Men (people?) - those who understand the science and technology that will be called upon to solve society's largest problems, yet who see the whole picture including social, political, and human issues. Study broadly.

Communication

Every week some editorial expounds on this, the communications age. Though there is no doubt we have unprecedented telecom technology, it sometimes seems we really have very little to say. Or, worse, too many just cannot use communications channels effectively.

Frequently our purely technical careers are frighteningly short. After only a few years most engineers become managers of one sort or another, even if that means managing the company's technology. Once your job is more than sitting in front of a tube pounding out code, then communications becomes ever more important.

Sure, it's easy to pick up a phone and talk to someone. But do you really unambiguously get your message across? In this world market you could be speaking to France one day and Japan the next. Do you make yourself clear to native English speakers as well as with those whose comprehension may be a little weak? As the old saying goes, eschew obfuscation. Be precise and clear.

Hone or develop writing skills. Users manuals, technical briefs, and other documentation are all so much garbage if poorly written. Sadly, many engineers have trouble conveying ideas on paper.

The comments in your code should be clear, expressive, and complete. This is a good place to start refining writing skills. Your software will immediately benefit, and you can take an extra measure of pride in the quality of your work.

The other side to communications, one that is perhaps more important than getting your own message across, is the lost art of listening. Usually it's just a matter of simple respect to pay attention to a speaker. Occasionally your job could be on the line.

Attitudes

I suspect more people are canned due to attitude problems than to any other reason - especially in technology businesses. Face it: we still have the reputation of being a culture of pencil necked geeks, which is unfortunately reinforced by the occasional person true to this type. Over the years I've worked with an embarrassing number of engineers who had no people skills, and who almost seemed to cultivate anti-organizational neuroses.

Be a can-do sort of person with a zest for life (Jeez - sounds like a beer commercial!). Negative attitudes quickly contaminate a group. Don't be a whisperer or rumor monger. If things are so bad at your company, quit now!

Fact: the boss has power to hire and fire. Common sense suggests your role is, in part, to keep her happy. Fight with the boss, passionately if necessary, when you feel the wrong decision is being made. But, support the final verdict. If the boss is so unreasonable that she never listens, get out of that job.

Technical managers have a hard time keeping up with technology advances, and so must depend on the engineers in the trenches to supply advice. Try to give the boss succinct yet complete pictures of what various tradeoffs entail. A quick way to find the door booting your backside is to wait until a project is underway, and then reveal limitations or problems that should have been discussed up front.

Remember, it never hurts to CYA with paper. Use your writing skills to give the boss synopses of anticipated tradeoffs and problems in a permanent form.

Learning

Peter Ustinov commented "I am convinced that it is of primordial importance to learn more every year than the year before". Surely this must be true of an industry changing as fast as ours, yet DeMarco and Lister lament that it seems few programmers read much.

Set time aside every day to learn. Blow up the TV. Read constantly. There's a lot of stuff going on in the world, and we as techies will have to synthesize much of it into our projects. Draw your reading from a wide range of sources - don't stay trapped in programming-only material.

We're already seeing profound shifds in our jobs from highly niched ICs, yet few recognize these trends. Alvin Toffler's latest book (Powershift), and George Gilder's Microcosm both describe the direction the embedded market is likely to head, yet neither of these works are technical books. Rappaport and Halevi, in their August 1991 article in Harvard Business Review, redefine the entire nature of computer companies. Again, this source is far outside the normal reach of technical journals.

Firmware designers must get a good grounding in hardware.

Learn more about your tools. Try not to just limp along with the ten most commonly used commands (because you haven't gotten around to reading the manuals). Allocate a few minutes per week to learning their nuances.

Finally, cultivate the bizarre. Tom Peters, the business guru, suggests making odd friends (boring folks, boring ideas), spending half your time with "wacko" outsiders, and spreading chaos in your wake.  

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: