One should try to learn from those that have more experience than you, and are wiser than you.  Maybe some day down the road, you will be the one passing on experience and wisdom.

I had the opportunity to ask an engineer, that I really look up to and admire, what are the two or three principles that helped in their career.

It doesn’t have to be this way

When I first started out in engineering, I quickly learned that not all engineering work starts with a clean slate.  For various reasons, many projects can be described as sustaining efforts, incremental improvements, maintenance cycles, or evolution of legacy designs or code bases.   I have also been lucky to have had those opportunities of clean slate design work, where you as the designer are free to choose your own adventure.  What my friend was trying to convey though, in thinking through the design problem you’re trying to solve, your default position doesn’t necessarily have to be to repeat the past.  One should always strive to think of ways to improve the present condition, where it makes sense.   And that desire for improvement is the tricky nuance of this principle.  Thinking it doesn’t have to be this way isn’t a license to treat every project as an opportunity for a clean slate, but rather I believe it’s an invitation to not assume that the way things have been done is the right way going forward.

Programmers make it work, engineers make it work for the right reasons

This principle speaks to taking pride in your work and understanding your craft.  How many stories have you heard of something not working, and the solution is change a couple of lines of code and it magically works, but no one can explain why.  I believe this is what this principle tries to avoid.  Sure there may be times where your own expertise limits your understanding of the solution, but an educated guess is still better than wild conjecture.  In order to make things work for the right reasons, the next principle offers a solution.

Try to understand low-level, dig down through the abstractions 

Thinking in abstractions is a huge part of life, not just engineering, but in order to keep this short, let’s focus on the context of engineering.   In my career I’ve focused on robotics, and embedded systems, but even those two areas are just a couple of nodes of a much deeper tree.  I don’t claim or expect to know everything, but the pursuit of knowledge, through levels of abstractions, allows me to gain insights into the complexities of these fields that would otherwise remain obfuscated.  And what’s more, you start to see patterns emerge that help you understand other abstractions in a completely new way.

Thanks for stopping by.  I hope you found these principles helpful.  What are some of your favorite principles?