These are some engineering principles and values that are important to me, personally. My hope is to find these in -- or, sometimes, introduce these into -- the engineering and engineering leadership communities in which I participate. Probably more importantly, these principles, like me, are a Work-In-Progress, and I will continue to refine and adapt these based on those same communities, and beyond, in perpetuity. I’m always curious and willing to learn, and for that same reason I’m more than willing to publicly publish and share these, and hope for feedback.
I won't claim any of these are really truly original - I picked ALL of them up, at least in concept, from listening to and observing folks much more capable than myself, and it's plausible there are one or more of these that I've indeed inadvertently plagerized. Any such plagerization is purely unintentional, and I am more than happy to provide attribution where I can.
A principle is a framework for exercising judgement, and provides useful constraint while still supporting a high degree of empowerment. In contrast, a rule is typically an explicit dogmatic constraint that removes the need for judgment, and is often disempowering. Sometimes the only difference is subtle framing, or voice. For example, this value principle COULD have been stated as a rule, in the active voice: “Always use principles instead of rules”. That, however, wouldn’t allow for the reality that rules DO exist, and are often clearer or more efficient than the underlying principle. Rules exist, but principles are generally better.
In communication, and especially in code, despite some overlap, the nuanced differences between simple and clever are critical. Outwardly, they often appear the same, but they can also frequently work against each other, and the difference is often in the eye of the beholder. Opt for simple.
One powerful effect of this principle is to help manage WIP (Work In Progress), where it applies to the state of concrete deliverables, like features and stories. WIP is not inherently 'bad', but choosing to be intentional by seeking ways to minimize WIP in aggregate brings focus and clarity. The uncertainty embodied by a Work In Progress "rolls up", and inversely, the certainty represented by "done" also rolls up -- it's much easier to visualize the overall state of a product or a service when the constituent components are either done or not, than when they are "in progress".
You can use any new tools, techniques, and technology that you want. As long as you have a plan to bring the rest of the team along with you.
The People that create the systems are uniquely prepared to understand how they operate. And vice-versa.
"What came before" got us where we are today. You don’t have to like it and you don’t have to keep it, but if it exists before this very moment, it's legacy, and by definition it captures past thinking. It's really easy to see the terrible parts, because those stand out and still cause pain, and truly great parts have almost certainly slipped seamlessly and silently from memory into obscurity, the moment the pain that they resolved went away. By the same token, understanding that what you build now is going to live for a very long time gives you an opportunity to demonstrate some positive intent to your future self, coworkers, and customers.
In lieu of either begging for forgiveness or asking for permission, state what you intend to do to potentially interested parties, solicit for and listen to any input, and then take the action or make your decision. The opportunity to react will be greatly appreciated by those with a genuine vested interest, but without the downside and friction of deferring your decisions to others’ judgment or authority.
Building in public builds trust. Closely related to signaling intent, building in public provides an opportunity for a broad range of stakeholders and other interested parties to provide feedback. While you don’t have to incorporate or even respond to the feedback, listening and making a good-faith effort to understand will almost always have an outsized payoff - we all have something to learn, whether that’s from a customer, a co-worker, someone elsewhere in the organization, or even a competitor. This principle applies broadly beyond software, and includes documentation, culture, and even personal and professional development.
Often the very best time to address deficiencies is the moment you discover them. This applies well beyond code, and also includes docs, access permissions, configuration, and communication. The best way to “Address” an error is usually to take the pause to fix it right then, but where that’s not practical, it’s still crucial to immediately share the discovery, and create a plan to address it.
Stated as a much more familiar rule: Don’t Fight the Framework. The nuance here is that frameworks aren’t static, and our objectives are important. Sometimes - if we have cause to believe the framework will, eventually, bend to our will, it MAY be worth it to “fight” it, where the costs are well understood and clearly worth it, AND the expected outcome of the fight is validated learning that informs our future success. The best example of something like this is Open Banking, as a “fledgling juggernaut” - currently the banking industry’s “frameworks” don’t align cleanly with Open Banking, and won’t for a while, but are clearly crucial to the future. On the other hand, if it looks more like we’re just trying to shave corners off of a square peg so that we can fit it into a round hole: Stop. Don’t fight that framework.
The difference between executing like a well-oiled machine with a strong bias for action versus taking reckless action with no regard for the future is often a brief pause to signal intent, listen to others, consider the broader and future impacts through the lens of our people, practices, priorities, and values – and then taking deliberate action. Take the pause.
Where outcomes are not critical or are well-understood, it’s very efficient to rely on process, as well as rote, habit, and muscle memory. Where outcomes ARE critical or out-of-process - you can get most of the efficiency benefit without the risk, just by bringing the action under consideration to the forefront of your conscious mind by doing a buddy-check, saying it out loud, writing it down, or at least pausing, thinking, and taking a breath. Do that, and then take the action, deliberately and mindfully with your full attention. A typical example is live-editing a production configuration, or responding to a hostile emails. A handy corollary to this concept is to write a checklist for any such action with more than one or two steps, and then the ‘deliberate action’ is partially pre-empted by the creation of the checklist itself, as well as efficiently executed by applying any additional ‘deliberate action checks’ to each step in a cookie-cutter fashion.