In order to cover "everything" there are a couple of "primary" articles and a larger set of standalone essays on specific details - some of these started as footnotes, others were triggered by hearing a colleague run into the same problem again without a good online reference to wield. These are generally positive - even the admonishments are about how you could do better rather than telling you something to avoid; most developers and team leads are already doing things they think are good and just need justifications for leaning in and doing more good.

Primary Material on Developer Process

These essays collect a number of "Pretty Good Practices", aimed at development teams that would like to improve their craft, and thus improve their results. This is not aimed at the solo coder (other than to point out what you're missing by not having a team); it is generally biased towards addressing members of a team, which includes team leaders - basically if you can say "your team" and mean a handful individual developers (at most a dozen), you should find this useful. (Not that large teams are bad! But none of these practices directly address the distinct issues a manager of managers has.)

• Code Review - which often feels like distrust and bureaucracy, when it should be one of your better productivity tools, if you're doing it right.
• Testing - which deserves more attention than you're probably giving it (here are some ideas to help you correct that.)
• Release Engineering - which isn't the fringe obsessive corner it often comes across as, but is a necessary foundation for other aspects of software engineering.
• Security - which isn't mysterious, so much as boring and principled - but you do need to understand when you should be considering it in the first place.

The idea is to have a framework for consensus - high level principles that your team finds convincing - and a set of practical approaches that are consistent with these principles. Support for any given policy or chore is easier to sustain, and simply more palatable, if there's a shared rationale behind it - even in cases where the choice is arbitrary, it's easier to accept one choice over another when everyone sees the value of having made the choice.

This structure also helps support institutional change - as long as you can show a change in what principles apply, that gives you a basis for changing the approaches in a consistent way. Note that the examples here may already not fit your industry or environment as written - for example, medical software requires different transparency versus privacy tradeoffs than social media services or robotics - and knowing where your lines are should help your team agree to approaches that support those principles.

Singular details

Many of these are referenced in the primary practice articles, but they're in enough depth that they needed to be more than a footnote (or I wanted to be able to refer to them directly.)

• The Bug Funnel - a structured way of justifying spending effort on quality, and where to put the effort.
• Provenance - a term from the art world, but in software it's more specifically "where did this thing come from" - for credit, licensing, or security reasons.
• Archaeology - figuring out where problems came from also involves a lot of digging, in the software world. Sometimes "how we do software" supports that, sometimes we just need the shovels...
• There Are No Mysteries - computers are entirely knowable, and it pays off to choose to look deeper than most people do. (This also covers the idea that "The Good Stuff is the Next Level Down".)
• Traceability - the simple idea that you can trace everything you ship back to where it actually came from; this covers supply chains, change control, release engineering, and many other sorts of detail.
• Debugging Tales - the principles and processes are the actionable parts of this collection, but sometimes a good old fashioned "from the trenches" story clarifies some of the points, without being directly applicable.
• Code Retirement - explicit code retirement is a way to encourage deleting code while defending against feelings of it being wasted effort.
• Code Audit - how audit is distinct from review, even though they show up in the same places.
• Firefighting - firefighting is rewarding and visible, but addictive and not sustainable.

These essays include "bits of (tech) culture" - narratives that are helpful for talking about (and thinking about) the mechanics of doing better software development in a startup context, where resources are constrained, but mistakes are also expensive, so putting some of those limited resources towards accuracy and efficiency pays off.

Rather than insisting on them as "Best Practices" - which just invites argument and can come across as a bit too authoritarian for a creative development team - describing them as "Pretty Good" is meant to imply that if you're not doing them, you should consider it, and adapt them, but if you're not doing them (yet) that's ok - maybe now is a good time to start thinking about the benefits.

"Rule 3" itself

Rule 3 itself explains the details of the rule that named this collection; it's not the most important idea here, it just ended up with the best name.