I believe it is important for those that I work with to understand my principles. These inform the decisions I make in my work life. I was inspired to write these down and continue to iterate on them after reading Principles by Ray Dalio
Take what you envision and make it real, don’t just talk about it. Write it down, build it, and share it.
Albeit cliché by now, this one is true to my heart. Everything great started from something that failed many times and has only become great by applying the learnings of those failures. If you have an idea, just start doing.
If you work with me, you have my trust from day one and it is yours to lose. If you break that trust, you can gain it back, but it will take time.
Avoid what I refer to as “heat loss through friction”. Be open, honest, and collaborative up, down, and across the organization. We should spend more energy moving value through the system than arguing on how that system should work. Furthermore, we should focus on improving the flow through that system, always looking for the next constraint (friction point) and alleviating it.
I always think back to this question when deep in discussion or problem solving mode. Often times the problem is misunderstood or not agreed upon by all participants in the discussion. A lot of times, it doesn't exist at all!
Own your product. Whatever that product may be, e.g., a consumer facing app, a web service, an internal service, a wiki page… whatever it may be, own it through and through. Make sure that you always protect your customer. Dogfood your product, and if it sucks for you, don’t get discouraged, get excited and take the opportunity to make it better.
Being able to Google an error, use development tools such as cURL, Postman, Proxies, Debuggers, Tracing etc… should be a core competency of engineers. These abilities are not outsourced to other individuals or groups.
Take the time to make well thought-out decisions. The time spent doing this will oft be much shorter than the time it takes to correct corners cut to enable instant gratification. There is a time and place to make quick decisions (perhaps to stop bleeding) but the default behavior should be thought out decisions. Do not race to be the hero the moment wants, have the patience to be the hero the organization needs.
Know when good enough is good enough and make sure this is known within your team. Particularly when you’re guiding others, make sure expectations are set both ways. Striving for perfection sounds great on paper, but hardly works in practice and can lead to teams feeling like they’ll never be good enough. Understand your drivers for optimization and only engineer it when necessary.
Don’t build because you can, build because you must. Understand your customer to an exhaustive degree and build what they need. This is often harder than the engineering part itself. When you find yourself doing the same thing a third time for a new customer, it’s time to automate/build a feature.