On Being an Engineer

This page last updated on 06/07/2022.

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:

What field of engineering do you specialize in?

Well, I’m kind of weird when it comes to engineering. Most of my colleagues specialize in just one field of engineering. I am fluent is several, but I do have a primary: Software Engineering. Specifically, a sub-field known as “Embedded Firmware.” It requires knowledge of programming and a good grasp of electrical engineering.
What is your current job title?

Hardware Architect Senior Staff Engineer
What jobs and duties come with your field of engineering?
Here is what I am responsible for when I embark on an embedded firmware coding job. These are just the things I have to do related to coding. There are other duties too, but they are kind of tangent to the core tasks:

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.

Thermodynamic 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.

Inorganic 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.

Electrical and electronic design; microprocessor controlled devices, power electronics design, high power load balancing algorithms, yadda-yadda...lots of different stuff.

Basic 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.

Requirements analysis and development for complex systems.

Mathematical 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?”

Overall 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 minutes)
- Discuss 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 enough.

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 engineering:
- 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, over-work, etc.

What do you enjoy most about your field of engineering?

Bottom line: 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 Apollo 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 6. Holy cow.

Do you personally feel like the college you went to has had an effect on your career?

Yes, but 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 formative:

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 National 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 march-of-progress.

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.