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

For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.

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
programs have well documented test protocols, enforced by a formal
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.

Do you need to eliminate bugs in your firmware? Shorten schedules? My one-day Better Firmware Faster seminar will teach your team how to operate at a world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and covers the unique issues faced by embedded developers. Here's information about how this class, taught at your facility, will measurably improve your team's effectiveness.