495: A shortcut to years of experience

What It Covers

Sally Hall and Adji Slater from Thoughtbot examine the Thoughtbot Guides, a public GitHub repository of opinionated software development recommendations covering Ruby, Rails, code review practices, and open source maintenance — framing each concise rule as a distillation of hard-won engineering experience accumulated across decades of professional software development.

Key Questions Answered

• •Thoughtbot Guides language system: The guides use four precise directive words — "avoid" (skip unless justified), "don't" (never acceptable), "prefer" (better of two options), and "use" (positive instruction). This controlled vocabulary eliminates ambiguity and lets developers act immediately without debating intent, making the guides functional as quick decision tools rather than philosophical frameworks.
• •Resource routing in Rails: Defaulting to resource routing over individually generated routes forces developers to model their application around RESTful resources, which frequently surfaces hidden domain concepts. Developers experienced in other stacks often miss this pattern entirely since Rails abstracts route declaration more aggressively than most frameworks, but adopting it consistently produces cleaner, more maintainable route structures.
• •Ternary operators as complexity signals: Avoiding ternary operators and multiple assignments per line serves a diagnostic purpose beyond style. When collapsing logic into a single line feels necessary because the file is already dense, that impulse signals the surrounding code may need structural refactoring rather than syntactic compression — making the guideline a prompt for deeper design review.
• •Code simplicity as a measurable target: Simplicity in code shows up through well-named variables, single-responsibility functions, and minimal indentation depth. Sandy Metz's indentation heuristic applies directly: jagged left-side indentation indicates excessive nesting and complexity. A class exceeding 100 lines in Ruby similarly flags that it likely handles too many responsibilities and warrants decomposition.
• •Don't preemptively build future functionality: Writing code that anticipates unconfirmed future requirements consistently produces the wrong implementation. The correct approach is designing for changeability through good structural hygiene — keeping components loosely coupled and responsibilities narrow — rather than guessing specific future features, which almost never materialize in the form originally imagined.