Gabriel Busto

engineering excellence

engineering excellence: something that every engineering team wants to embody. but it’s a pretty nebulous concept. the general idea is just “do engineering things well”. if you asked me to describe it, i’d probably say things about best practices like ci/cd and being able to deploy easily multiple times per day if necessary, minimal incidents, good observability, solid unit test coverage…

so you can try to just measure those things, but i think if that’s all you’re doing, it’s a bit too far downstream and not something that’s woven into the fabric of your team. it’s more reactive than proactive.

i’m of the opinion that you need to be able to translate or operationalize principles of engineering excellence into easy-to-explain and easy-to-perform actions so it’s clear what actions to take, and they can turn into habits. so i started thinking about this this week and i came up with the first principle to propose to my team: “sweat the small stuff”.

the reason is that if you can’t do the little things right, you’re probably not going to be able to do the big things right. and our eng team i believe has mostly switched to having AI write most, if not all, code. so it’s easy to just skip reviewing the PR. but even if you wrote your own code, if you focus your attention on looking for details to improve, chances are you’ll be able to find something. to translate this principle into an action that anyone can perform, i proposed the following action (not verbatim, but close enough):

when you create a PR, spend 3-5 minutes reviewing it. you can either look over the code or run a test to examine the UI/UX and behavior of the app with this new change. look for one small detail (a log line, an error path, an obscure function, premature optimization, unnecessary abstractions, overly defensive programming, improving a process document, etc) and find a way to improve it. the general idea is that you apply some of your own judgement and reasoning to improve something small.

that’s more or less what i wrote out in an internal document i shared with the team. it’s not perfect, but it’s something.

for the document itself, i also proposed some rules (summarized):

the reason i think this will work well is because is because it pushes us each to change at a fundamental level. we each adopt a new, aligned mindset and new behaviors, and this hopefully translates (or flows downstream) into improved metrics or outcomes of things that are generally considered engineering excellence. and those improvements happen as a byproduct of how we operate daily as opposed to being a metric we try to fix and keep from drifting.

in general, i think if you want your team to embody any principles or values, you need to translate them into simple actions that they can perform, or a definition that makes it clear how to express that value. otherwise they’re just words with loose meanings that people say a lot but have no shared understanding of what they mean.

the ultimate goal i think is if your downstream metrics (that help measure the quality of your engineering) remain optimal or improve naturally as a result of adopting these new behaviors and turning them into habits. then you know excellence has been woven into the fabric of your team. and when new members join, you can point them to this doc as a guide for how to operate within the team to maintain and increase the level of excellence.

just my $0.02. we’ll see how well this goes.