My Guiding Principles As An Engineer
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 wisdom I've sprinkled around:
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.
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.
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: 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 to the backup plans.
Me: Attention to detail.
Me: Success breeds success.
Me: Be a lifelong learner.
Me: Have a hacker mentality.
Me: We are problem solvers.
Me: Don't be stupid.
Me: Be thorough. Be rigorous.
Me: Honesty and integrity over all.
Me: Be nice. Treat others as you would have them treat you. Don't let hate be your guiding light.
Interpreting These Principles
There are several themes here, of knowledge, persistence, and discipline.
Study. Prepare. Learn from the mistakes of others. 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.
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. Plan for that, and for contingencies.
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, 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.
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Registering will allow you to participate to the forums on ALL the related sites and give you access to all pdf downloads.