My Guiding Principles As An Engineer

• Education
• Career

These are my guiding principles as an embedded systems software engineer, forged over 40 years of experience. They shape the way I work and approach problems, and maintain my attitude in the face of adversity.

You may find them useful as well, whether working as a developer, a manager, or an executive, alone or on a team, when things are going well, and when they aren't.

They're a combination of favorite quotes and my own bits of derivative wisdom I've sprinkled around:

The Golden Rule: Treat others as you would have them treat you.

Sir Francis Bacon: Knowledge is power.

Louis Pasteur: Chance favors the prepared mind.

Benjamin Franklin: Energy and persistence conquer all things.

Field Marshal Helmuth von Moltke: No plan survives contact with the enemy.

Someone around 1880: Correlation does not imply causation.

Thomas Edison: Genius is one percent inspiration and ninety-nine percent perspiration.

Nikola Tesla: Just a little theory and calculation would have saved him ninety percent of his labor.

Dr. William Halsted: See one, do one, teach one.

George Santayana: Those who do not remember the past are condemned to repeat it.

Dwight D. Eisenhower: Plans are worthless, but planning is everything.

Richard Feynman: The first principle is that you must not fool yourself, and you are the easiest person to fool.

Douglas Hofstadter: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Nancy Leveson: Depending on humans not to make mistakes is an almost certain way to guarantee that accidents will happen.

Gary McGraw: Build security in.

Lt. Commander Jocko Willink: Don't give up on it. Own it.

Me: Not knowing is powerlessness.

Me: Knowledge is like peanut butter, it should be spread around.

Me: Untested code is by definition broken code, until proven not.

Me: Trust nothing, and verify.

Me: Evidence is required.

Me: Learn from mistakes, your own and those of others.

Me: Mistakes are learning opportunities. If there's no injury and no damage, there's no harm done. A little blood on the deck isn't an injury.

Me: Instrument things, because like knowledge, data is power, and not having it is powerlessness.

Me: Write stuff down.

Me: We have many ways of tripping ourselves up.

Me: Have plans, backup plans, and backup plans for the backup plans.

Me: Attention to detail.

Me: Success breeds success.

Me: Be a lifelong learner.

Me: Learning new skills is the most important skill you can develop.

Me: Have a hacker mentality.

Me: We are problem solvers.

Me: Don't be stupid.

Me: Be thorough. Be rigorous.

Me: Never underestimate people's ability to use, abuse, misuse, and confuse your system in unexpected ways.

Me: Honesty and integrity over all.

Me: Be nice. Don't let hate be your guiding light.

Interpreting These Principles

There are several themes here, of knowledge, persistence, and discipline.

Study. Prepare. Share what you've learned, the good and the bad.

Have an appropriate level of paranoia, so that you verify and confirm everything. Don't just trust that it will work, no matter who it comes from. Even if it's your own code, even if it worked before.

Evidence is required in all things, whenever someone wants to convince you something is wrong or they've made something work. That includes convincing yourself (since you trust nothing!). Instrumenting things to collect data is one source of evidence. Coincidental correlation is not evidence.

The exercise of writing is a great way to make you organize your thoughts. It's a great way to capture, preserve, and communicate knowledge, information, and evidence. It has a force multiplication effect because then you have something to share with others and across time. It helps maintain the organization bus factor.

Real engineering is hard, because there are many things that can go wrong. Embedded systems combine all the complexities and potential problems of software with all the complexities and potential problems of electronics and mechanics. The combinatorial effect of all those moving parts means there's an infinite number of ways things can break and go wrong, and an infinite number of mistakes you can make. We are human; we make mistakes. Plan for that, and for contingencies.

Planning itself is a valuable activity, because it makes you think things through and consider possibilities. But reality often disrupts plans, so be ready to throw them out or adapt them.

In all that complexity, details matter. You have to pay great attention to detail to understand how things work, how to do things, what's going wrong, and how to fix it. Details can mean the difference between success and failure.

When things feel out of control, start with a small success, anything. Then build from there. Baby steps become big steps, and small sucessess become big successes.

In addition to constantly preparing your mind, every new project or new job will have things that are new to you, so there will always be new things to learn. New technologies, new languages, new software, new hardware, new techniques, new ways of doing things. There will also be new uses of old familiar things. This is a lifelong learning curve in multiple dimensions, what I call the "N-dimensional learning hypercube".

The hacker mentality combines the empirical approach of Edison with the theoretical approach of Tesla, where you keep learning, exploring, adapting, and trying in a continuous feedback loop until you figure it out and get it done. You bring persistence, thought, and effort, with a high tolerance for failure, even as it tests your patience. You don't let anything get in your way, and you don't let frustration get the better of you.

Being a problem solver means you bring whatever it takes to the table. You dig in and learn what you need to learn, put in the time, and keep at it until the problem is solved. Solutions take work. They take time and effort. They're messy to reach. They don't just unfold neatly on the table. That's more of the hacker mentality. For all the stress and frustration along the way, it feels really good when you get there.

Stupid is when people say about your stuff, "Didn't these idiots even try this?" Loss of customer confidence, loss of investor confidence, loss of market share, lawsuits, fines, and jail time may ensue.

Being thorough and rigorous are part of good engineering discipline. We have a duty of care to bring due diligence to our work, because the things we work on affect people's lives. We want those effects to be positive, not make them miserable.

As engineers, we deal in facts and reality. We have to be honest and transparent about information and what we do, the successes and the mistakes, what works and what doesn't, what we know (and how well we know it) and what we don't, if we are to find real solutions. Without integrity, no one will trust us. That trust is hard won, but easily lost.

And be good to others, because that's really the only worthwhile way to live.

Sign in