Do the Smallest Amount of Good Work

Article Purpose

The purpose of this article is to attempt to codify rules for software engineers to habitualize the "do the smallest amount of good work" principle. First of all, what is this principle? You can learn about it in F's ~3min post unsurprisingly titled do the smallest amount of good work, but in summary:

TL;DR - err on submitting PRs early and often even if they aren't a "feature" or provide immediate user-facing value

So the core goal of this article is to develop a ruleset for software engineers to easily adopt the "do the smallest amount of good work" principle way of thinking via actionable steps.

Background

F's post is great as it provides some concrete examples and arguments for adopting the principle. I came to understand the idea via my experience working at GitLab. The CEO Sid Sijbrandij did a great job being the broken record that's needed when trying to encourage behavior adoption for a large and fast-growing org and team. Of the many things I learned working there, a few nuggets (paraphrased below) stand out in the context of F's principle:

1. Take your issue and cut it in half, then cut it in half again
2. If the user can do something they couldn't do before, ship it

These are ideas or mantras one can internalize and I've intentionally internalized both—though still improving in practice. In reading F's post it made me realize these can be expanded upon and made more concrete. Hence this article.

Ruleset

Details and context surrounding each rule follows this ruleset list:

1. Rule 1 - If you refactor to aid WIP, submit the refactor as a distinct commit, PR it
2. Rule 2 - If code changes would positively impact engineers or users right now, PR it

Rule 1 - If you refactor to aid WIP, submit the refactor as a distinct commit, PR it

The context for the below reasons was directly informed by the okay but in practice section of F's post.

Reasons:

1. Empower teammates earlier
• others may be working on the same old system part—they don't know it's old yet
• if one is out sick or OOO the realized value is delayed and potentially lost
2. Simplify code review
• easier to grok and spot bugs
• less painful and lighter cognitive load
3. Reduce conflicting changes
• an antidote to pain, frustration, and lost time
4. Prevent stale code
• combat the inevitable context switch (shit happens, fires happen)

Rule 2 - If code changes would positively impact engineers or users right now, PR it

This rule plays off Sid's "if the user can do something they couldn't do before, ship it", but broadens the user definition to include engineers (DX and UX)

Reasons:

1. Empower teammates earlier—same as rule 1
2. Provide value faster (regardless if it's DX or UX value)
3. Develop the "good enough" muscle

Conclusion

The ruleset is incomplete, but it's a start. If you have any thoughts, ideas, or rule suggestions, don't hesitate to contact me on Twitter @derekknox.