This page last updated on
Copyright © 2001-2019 by Russ Meyer
Back in October 2016, Cole Howell had a school assignment to interview someone
about his job and asked if I would answer some questions. Cole asked some
really good questions that I think struck to the heart of life as an engineer.
Here are the results:
- Work with System
Engineering to understand the firmware requirements.
When I say “requirements” I mean it in an engineering sense.
The requirements are a carefully structured sequence of independent,
written statements that together describe, in unambiguous detail,
WHAT the proposed system is supposed to do. There’s a whole
field of study there. Anyway, Systems Engineering develops the
requirements then Mechanical, Electrical, and Firmware Engineering
turns them into operational stuff. Mechanical builds housings,
gear boxes, radiators, etc.; Electrical builds wiring harnesses,
printed circuit boards, etc.; Firmware writes programmed logic
(code) which runs on a CPU to control the whole mess.
So...before you start coding, you have to know just exactly WHAT
this new system is supposed to do. Gotta get intimate with the
requirements; they’re your Bible.
- Get with Electrical
Engineering to help develop and review the schematic diagram.
We have to get the electronics ironed out before code can be
written. To this end, I help electrical engineering select the
processor, memory, and peripherals (mostly sensors) needed to get
the job done. Electrical then takes that input and develops
the schematic diagram for the circuit. Once they think they
have something pretty close to the real deal, we get together and
review the whole schematic: resistors, inductors, diodes,
integrated circuits, etc. After much hashing and wrangling,
when everyone finally gets to the point of nodding their head up and
down, Electrical goes and builds a few prototype circuit boards.
- Write Code.
Now you are ready to write code, so get with it buster! The
boss says you’ve got 1/2 the time you requested, so you better work
late and not get sick man! After all, we’re in this to make
money...and time is money! Think Mr. Crabs. Dude, he’s
based on real-life characters. No joke. Oh, and your
code better not have too many errors in it or your career as a
programmer is going to be pretty short.
- Review Code.
When your code compiles OK and appears to mostly work, it’s time to
schedule a code review with your fellow programmers. We get
together in a conference room for a few hours with your code
projected on a screen. You explain the overall theory of
operation of your code (in general how it works) then all your other
coder friends bust some kung-fu moves on your code, trying to see
what’s wrong, how it could be done better, where you have violated
company coding standards, where your code doesn’t meet requirements,
etc. After the review, you wheel your brutalized code back to
your cube on a gurney and go to work, trying to address each
reviewer’s comments. The objective is to weed as many problems
out of the code as possible BEFORE it goes to formal testing.
You’re trying to turn your Frankenstein into Tom Cruz before the
beauty pageant starts.
- Formal Test.
OK, this is the acid test. While you’ve been busy for weeks
writing your Magnum Opus of code, the test engineers have been
furiously writing test procedures design to ferret out anything and
everything wrong with your code. It’s a diabolical
relationship between you and the test team, the but end objective is
good. The objective is release your code to the world
virtually bug-free, and that is much harder than it sounds.
The test team should be your BFFs actually, though they cause you a
lot more work and are uncouth in their rejoicing when they find
something you did wrong in your code. The kind of testing they
do is called Requirements Verification Test. It’s where they
take each requirement and write a test for just that specific
requirement. They then execute that test on your code,
expecting a certain outcome. If your code does anything but
that one expected outcome, they write you up...like a speeding
ticket. You must then take each of these tickets and fix the
problem. It is a big challenge to keep up with the torrent of
tickets that usually spew out of the test group. Lots of late
nights and frustration. When you think you have the problems
fixed, the test team re-executes the test procedure against your new
revision of code. They will only give you a PASS, if your code
runs flawlessly. The truth is, no matter how hard you work,
you will never be able to eliminate all bugs. Even if the test
team doesn’t find anything wrong, history has proven that there WILL
be hidden defects in any chunk of code. Good code design takes
this into account; there are a number of coding tricks that can make
your code more robust. Even if an unexpected bug causes your
code to malfunction, it will gracefully recover from the error and
keep running. These kinds of measures are really important for
things like flight control software, nuclear reactor safety systems,
medical devices, telephony switches that handle 911 calls, etc.
Because I am fluent in
a number of disciplines, I am often assigned to do things besides embedded
firmware. Each of these things has a set of tasks by which they get
done, but I won’t go into detail unless you need it.
analysis. For example, trying to figure out how a big a
radiator needs to be in order to reject excess heat from a system.
The radiator is liquid-to-liquid mediated by graphite plates between
two salt solutions of different composition. There are other
thermo problems like this. They come up a lot. Another
one: Will the electronics in this new gizmo work OK, even
after heat-soaking on a car dash at the equator for 2 hours?
No kidding man...you don’t understand stuff like this, the product
might flop. After investing a few million dollars to get it
into production, the last thing you want to find out is that the
housing melts if you leave it in the sun. Batteries...oh
sheezh, don’t get me started on batteries! Our battery
technology (when I say “our,” I mean mankind’s) is highly lame-o.
- Many types of
mechanical engineering problems; gearing, hydraulics, pneumatics,
temperatures, pressures, etc.
chemistry and chemical problems. For example, the effects of
hot acids on tantalum coatings, selecting the best plastic for an
application, electron migration using the oxidation states of
vanadium pentoxide, etc.
and electronic design; microprocessor controlled devices, power
electronics design, high power load balancing algorithms,
yadda-yadda...lots of different stuff.
research: inventing sensors, investigating how physical
principles dictate/constrain the architecture of a new design.
This is my personal favorite thing to do. I’m really a
scientist who can only find a living wage doing engineering.
analysis and development for complex systems.
analysis of system bounds and parameters; that is, trying to answer
the question, “What are the limits of behavior and performance for a
certain system configuration?”
system architecture. In other words, what is the right/best
mix of sciences and technologies and in what configuration to best
achieve the goals of the system. This is actually a field
called System Engineering, and I was once a System Engineer.
Knowing lots of things across lots of fields REALLY helps you be a
good System Engineer.
- What does an average
day look like in your field?
- Get to work and
slam a diet Coke to prime my slothful body to do something. (10 minutes)
- Read and answer
E-mail. (Easing my balky body into doing actual work.) (40
engineering and architectural problems of various projects with my
fellow engineers; some are my projects, some are the projects of others.
(Transitioning from sloth mode to work mode.) (1 hour)
- Examine the
schematic for the project I’m working on. (Getting this-close to
doing actual work.) (20 minutes)
- Write the code
for a small part of the system I’m developing; typically ~30 lines.
(Working finally.) (1 hour)
- Compile and test
the code segment I just wrote (20 minutes)
- Correct problems
I found while testing (1 hour)
- Lunch (1 hour)
- Prepare to review
the code one of my peers is developing for another project; review his
requirements, schematic, and source code (1 hour)
- Attend my buddy’s
code review and make comments; try not to be too vicious, coders are
people too. (2 hours)
- Prepare to write
another segment of code (to be written tomorrow). Understand
requirements, understand portion of schematic impacted, develop an
algorithm (not code, just the code design) that might work. (2 hours)
Go home. Whew, that’s enough for today.
- Would you be willing
to describe your educational background?
I went to Washington
State University (WSU). Got a BS in general science, minor in math,
minor in software engineering, minor in electrical engineering. I was
only 3 credit hours away from a second major in math, but I just couldn’t
take it. I couldn’t stand to spend another semester in school; I’d had
- If you had a clean
slate, related to your education or career, what would you do differently?
I would definitely NOT
have gone to WSU. WSU is kind of a second-string university that is
better suited to agriculture and veterinary medicine. I didn’t really
appreciate that until after I had been at WSU a few years. The
engineering, math, and science professors there are kind of second-string
too. This leads to many frustrations and missed educational
opportunities. It has an impact on how well you know stuff coming out
of college. I noticed that it took me about 5 years to catch up with
the knowledge and mastery of some of my colleagues that had gone to schools
like MIT and Perdue. If I had to do it again, I would go to Perdue.
Their science, math, and engineering courses are solid. Even better,
their engineering classes are hands-on and oriented toward developing
practical solutions. That was something WSU was strongly criticized
for; engineering graduates could work problems on paper, but were not able
to actually solve real-life problems. They had spent all their time in
college doing book problems. For example, they could do Fourier
analysis all day, but could not recognize a situation in real-life where it
was needed to solve a problem. So, you’ve got this crop of WSU
engineers with straight A’s but they can’t design a sheet metal box or
analyze data from a sensor. It was so bad that the year after I
graduated, Boeing announced it would no longer interview WSU graduates for
engineering positions. That was a super-killer criticism. Boeing
was one of the leading employers in Washington state. If THEY think
WSU graduates suck, then WE SUCK BIG TIME. Even worse, lots of other
Washington industries followed suit and it became a big crisis at WSU.
I say they deserved to get kicked in the head. The problems were
obvious, but the staff sat around in their chairs for years and did nothing.
I only regret wasting so much time and money there. Can’t say I’d
recommend WSU to anyone except vet majors.
One other thing I would do differently: I should have seriously
considered starting my own business right out of college. That is the
optimal time to do it. Your family obligations are few to none (no
other distractions/obligations). You can survive on pizza and coke and
sleep on the floor of your office (your overhead is low). You have
youthful vigor and energy. You are bursting with funky, novel ideas
(you’ll be able to make a mark). You’ll be your own boss and can work
on the things that inspire you. You will make many, important contacts
with people all over the industry. This menagerie of contacts will
continue to serve you well for years. If the business flops, no sweat,
you can get a job at a big company later. Anyone in a hiring position
at a big company will almost certainly appreciate the gumption it takes to
start your own business. You earn their respect in an important way
before you even arrive for the job interview. There’s almost no
downside to doing this right out of college, except that you remain somewhat
financially insecure for a few years. But, even if the business washes
out, the impact of the financial fallout is not as bad as you probably
imagine. Besides, you still have your whole career ahead of you to dig
out of the hole. One thing is for sure: No one gets ahead just
pulling down a wage. If you look at wealthy people, most own their own
business. So, if you want to be well off in life, start your own
business. You’re just playing the percentages. It doesn’t
guarantee success, but you are at least positioned for it should it occur.
- What advice would you
give to someone pursuing a similar field of engineering?
Make sure you are OK with the following things, before committing to
- Are you OK with
the pay? The pay is generally decent, but if you want to become
well-off or a millionaire, engineering is NOT the way. Got to have
your own business to really accomplish that.
- Are you OK with
the hours and commitment you’ll have to make when you take an
engineering job? It can be demanding and relentless. I have
to pull an engineering rabbit out of my hat about every month to stay
employed. Sometimes the rabbit appears because I got lucky.
Sometimes it took enormous work. It can get stressful; you’re
always on stage man. Employers are constantly evaluating whether
you are worth the money they’re paying you to keep you around.
It’s tough to stay on the positive side of that value curve every month,
every year, every decade, etc. Relentless.
- Do you have a
passion for the work? To be a good engineer, something
irresistible inside you has to drive an insatiable fascination with
mechanical, electrical, or computer gizmos. You have to be a
little obsessed. It’s like being a professional football player,
you don’t get a steady job playing pro ball unless you are psycho about
football. Same thing for engineering. It’s a passion and
you’re always thinking about it. For example, when I interview
people for something like a mechanical engineering job, one of the first
things I ask them is if they work on their car. A solid ME
candidate will have been working on his car since he could turn a
wrench, probably starting with helping his Dad on the family car.
If he doesn’t do much on his car, he doesn’t have the engineering
spirit...a passion for the job. For example, with programmers,
after 5 years, 70% of the people that entered the field have quit, never
to return. Programming didn’t measure up to their expectations.
They couldn’t keep doing it. The ones that remain are the ones
whose passion for the field carry them over the disappointments,
- What do you enjoy
most about your field of engineering?
I like to see machines do things for themselves. I squeal with
delight, internally of course, when I see a machine detect a condition,
choose a course of action, then deftly implement that action. My
favorite example is the
Saturn V guidance system. It was embodied in a 13 term
differential equation and implemented on a hybrid analog/digital
computer made my IBM. It was absolutely bullet-proof. Even
when Apollo 12 was struck by lightning twice during the boost phase, the
guidance computer shrugged off the torrent of glitches and kept that
whole 6.5 million pound rocket, being propelled by 7.9 million pounds of
thrust right on the guidance line. Makes me shiver just to think
of it. Just think, a couple of pounds of hardware and a few lines
of code delicately and subtly balancing 6.5 million pounds on a narrow
7.9 million pound thrust vector at Mach 2. Holy cow.
- Do you personally
feel like the college you went to has had an effect on your career?
negatively in many ways. From the standpoint of my actual
engineering skills, it took me years to catch up with my peers. On
a personal level, I was devastated intellectually, emotionally, and
spiritually when I departed WSU. It took me about 12 years to
recover and begin to feel like my old self again. I should have
quit WSU, but didn’t know any better at the time. I just assumed I
wasn’t working hard enough and opened the throttle even more, ultimately
burning myself out HARD. I tell new students now that if they
aren’t having fun and it seems like excessive work, they’re in the wrong
field or at the wrong school.
- What made you
interested in your field of engineering?
Four things were
- The emphasis
on science and technology during the cold war – Starting in the late
50s and on through the 70s, the federal government poured money into
science and technology education. For example, the
Defense Education Act. There was a perception that the Soviets
were kicking our butts in science and technology; and they WERE for
many years. By the time the late 70s rolled around, we clearly
had the lead over them. There was a feeling pervading all of
America that we were in the throws of a death match with the
Soviets. Our way of life and our very lives were right on or
very close to the line all the time. There is just not that
feeling in society today, thank goodness. It was a feeling of
desperation that hovered over everything you did. There were
many incredible developments in this time too; nothing like it in
scale going on today: nuclear power, nuclear powered
submarines and ships, the growth in digital computers, artificial
intelligence, RADAR development, supersonic aircraft, the space
program, laser and particle beam weapons development, advances in
cosmology, tectonics, oceanography, medicine, electronics, etc.
Everything was blitzing forward simultaneously. There was
enormous optimism that all these developments and more would make
life better and better. Engineers were the drum majors of this
- The manned
space program – The space program and especially the moon-shots were
almost unbelievably exciting. There is almost no analog for
this today. They riveted the attention of the nation and were
a source of great pride in America and our accomplishments. It
really rubbed the Soviets nose in the mud too, which was immensely
satisfying. Kind of like Tony Stark and his crack team of
super-heros beats bitter cross-town rivals at a massively hyped
football game. Watching the astronauts step onto the moon was
like seeing Columbus discover America. We were making history
man, and it would never be like this again. I was so thankful
to be alive to see the moon landings actually happen in real-life.
- Star Trek (TOS)
– Maybe it sounds goofy, but Star Trek was a watershed television
show for budding engineers. I hear this all the time from my
engineering buddies. They (and I) were greatly inspired by the
vision of man, spreading out through the stars, using his mind and
fabulous new advances in science and technology. Engineers
leading the race of man to it’s manifest destiny. And, Star
Trek made a sort of technical sense. It was internally
consistent with its view of technology and how their systems worked.
Someone, somewhere had thought it through enough to make it hang
together. Interesting and inspiring.
- The TRS-80,
model I – I worked all summer and saved my money. In 1979 I
blew my whole wad of cash to buy a TRS-80. I taught myself how
to program it. I was already bananas about electronics, now
this showed me what programmed logic could do. It essentially
launched me down the road to my career.