I love this article. I’m a firm believer in the strengths of well-written code, even in the age of “move fast and break things.” One of the points this touches

I love this article. I’m a firm believer in the strengths of well-written code, even in the age of “move fast and break things.” One of the points this touches on is idiomatic code. In front-end development, there are lots of resources for organizing and styling components for cohesion across a website. For some reason, there’s rarely a consideration to do this for the back-end, at least in the dozens of applications I’ve worked on and contributed to over the past few years. The last few larger teams I’ve been on (15-50 developers), I’ve had the responsibility for putting together best practices (or at least better practices) and style guides for the back-end. While I love doing it, I wish they were a forethought rather than an afterthought; only done when shit has already started hitting the fan because of situations that look like this article alludes to. Developers at these organizations have regularly reached out to me periods of time later showing appreciation for putting them together - so I must have done something right. Even developers that were hired after I no longer was with the organization. You could argue that the back-end is more complex; it is. But for the majority of operations in your very typical application (glorified CRUD on some flavor of an MVC framework), there’s always a dozen ways to get the same result. Asking your framework to do things that it doesn’t explicitly address is where the hairiness comes in. Things like how to build this complex query based on four different contexts? How to represent a form from an object that isn’t backed by a row in the table? How to handle business logic in a way that doesn’t just involve copying a controller method into an object and invoking it, and then copying that object into another object when I need to do the same thing in a slightly different context somewhere else? How to format this string in a way that won’t require me to make changes to the seventy-two different places we currently have it when it’s not always in the view-layer? How to architect a feature that lives by itself in the monolith? Answers to these questions may be easier to find here on HN, but my typical colleague isn’t on HN (for better or for worse :)). Just like the typical web application is mostly CRUD. “Best” or even “optimal” solutions to these questions is often a matter of opinion, but in regards to extensibility, maintainability, and legibility, there’s usually some symbiosis. Such agreement is something I keep front-of-mind now. Does that mean I’ll forego putting together these guides? No, I enjoy writing them because I enjoy having them. I love Breath of the Wild’s choose-your-own-adventure format, but less so when I’m pumping out code.