Engineering Tenets
Hey!
Welcome back to another week of musings. It's been raining here in the Bay Area lately. I had a few walks in the rain.
I hope you had a restorative weekend! Let's take the week ahead head-on.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- How we evolve code: Notion’s “ratcheting” system using custom ESLint rules a blog post around how Notion keeps cleaning their code base and prevents introducing more of existing outdated patterns.
- Career advice in 2025. by Will Larson, interesting observations on careers now with LLMs and AI everywhere.
I was recently having a few conversations with my peers, and the topic of engineering tenets came up.
More specifically, the tenets from the Amazon Principal Engineering community are publicly listed and generally serve as guidelines for other companies that might not have as formal a staff+ engineering community.
Implicit Tenets
While our organizations might not have the tenets publicly available, or even if we don't discuss them daily, we still have things we believe in that drive our decisions.
As staff engineers, we might not have catchy names like "Technically Fearless" or "Respect What Came Before." Still, we will benefit ourselves and the organization if we understand our implicit tenets. We might not end up publishing them publicly, or even internally, but knowing what beliefs are in our organization are what makes an effective engineer achieve their goals.
We might discover that we favor experimentation over getting it correct from the get-go, or even the opposite, that we prefer big upfront design. The approach to selling and delivering an idea is vastly different in those cases. In other cases, teams might prefer documents over proof-of-concept (poc) demos, or vice versa, and the same idea, they're vastly different approaches.
The problematic part of implicit tenets is that, more generally, they're created and/or imposed by long-tenured folks, leadership, or both.
So, we are more interested in complying with management whims than actual tenets, and I argue that in that case, it would benefit from documenting and discussing it broadly.
Explicit Tenets
Having explicit tenets is good. The best scenario is to follow or write them down after understanding them and the team "living" the tenets.
If they're not written down or your team struggles with analysis paralysis, I recommend you write them down and discuss them with your team. You'll need a few weeks or months of observing how decisions are made and what gets funded. It's hard to determine what a team believes and how that translates to execution.
At the very least, I encourage you to clarify your personal engineering tenets first.
Personal Tenets
Developing personal tenets will allow you to clarify where you're spending your time, or it will let you gauge if you're spending it effectively.
Other times, if you're interviewing for principal-level positions, you might be asked about this, or during an interview, the person might want to understand your leadership style, and tenets are a good way to have that conversation.
Your turn!
Have you ever thought about your personal or team engineering tenets? What's get funded? How are decisions made? What solutions get favored? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others