Over time, I’ve become a huge fan of what I’ve come to call Point of Pride Engineering Practice. Unlike a lot of what we like to talk about in the technology community, this practice isn’t about efficiency or even writing better software. Instead, it’s about our attitude as individual contributors toward the software we ship to our customers. I’d argue this attitude should apply to software we wrote and software we’ve inherited. Point of Pride Engineering is concerned with owning the ongoing quality and delivery of our software.
In particular, in my head I hold Point of Pride Engineering as consisting of the following guiderails:
- Engineers are hungry for more than the status quo. When you invest a bit of your pride in something you ship, you’re never happy with it being “good enough.” This has to be balanced with a fair dose of pragmatism to guard against perfectionism, but ongoing improvement is the name of the game in all the rules below.
- Engineers make their software tested. Ongoing improvement in test coverage is something that Engineers following this mantra are highly motivated to deliver on.
- Engineers make their software observable. It should be a point of pride for engineers to have a well-observed applicaton. I’d even go so far as to say that engineering leaders should consider doing regular shout outs for the best observability improvements within their organization.
- Engineers are on-call for their code. If I ship something terrible to production, I should expect to be woken up or have my weekend interrupted when it breaks. Accordingly, it should be a point of pride for me as an individual contributor to minimize the occurances of pages for my software by improving the quality of it over time.
- Engineers are “on first” when their software makes trouble for another team or the customer. When something goes wrong with the code, the team responsible for maintaining and owning it should be tripping over themselves to make it right for their customer, be that an internal team or an end-user.
- Engineers take the time to document their code. Information Architecture is a topic I’ve been spending a lot of time thinking about lately. If your organization is anything like mine, you have a lot more “TODO document” comments sitting around your internal wiki than you’d like.
My career has had a theme of promoting this kind of culture so far, and I don’t expect that to change.