Senior Track
Spot the Tax
Twenty short Rails lessons. Each one shows a snippet of code that works today and walks you through what it'll cost in six months — under load, after a deploy, when the table grows. Look at the code, try to spot the tax yourself, then reveal the answer.
How to use this page. Pick any lesson and start there — the lessons don't depend on each other. Each one takes about 5 minutes: look at the code, take a moment to think about the fix, then reveal the solution and the underlying principle. The principles are the part worth remembering.
Section 1 of 4
Universal taxes
No principles, no jargon. Five pieces of code that work for the first user and bite later.
Card 1
Uniqueness lives in the database, not in valid?
Database constraints
Card 2
External I/O belongs outside the transaction
Transaction scope
Card 3
:destroy runs in Ruby, :delete_all runs in SQL
Bulk operations in SQL
Card 4
JSON-as-text blocks the queries you'll need later
Indexable storage
Card 5
Authorization belongs in the query, not after
Scoped queries
Section 2 of 4
SOLID, one card per letter
Each principle in SOLID, demonstrated through one tax that real teams have paid in production.
Card 6
One class, one reason to change
Single responsibility
Card 7
Adding a variant shouldn't mean editing every file
Open/closed
Card 8
A subclass that breaks the parent's promises isn't really a subclass
Liskov substitution
Card 9
Depend on the smallest interface that does the job
Interface segregation
Card 10
Business logic shouldn't know which payment provider you use
Dependency inversion
Section 3 of 4
Senior gotchas
Concurrency, retries, scaling, error handling, schema escape hatches. The taxes that don't fit cleanly into a SOLID slot.
Card 11
Read-modify-write isn't atomic
Atomic operations
Card 12
Rescue only what you can recover from
Targeted error handling
Card 13
Background jobs must be safe to run twice
Idempotency
Card 14
User.all.each will eventually run out of memory
Bounded memory iteration
Card 15
update_all is a SQL escape hatch
Performance shortcuts skip the framework
Section 4 of 4
DDD in Rails
Domain-driven design ideas applied in a Rails codebase. Anemic models, primitive obsession, leaky boundaries, missing events, and broken aggregates.
Card 16
Models that don't know their own rules
Models own their own rules
Card 17
A phone number is more than a string
Value objects
Card 18
One model class serving four teams
Bounded contexts
Card 19
When the controller knows about every downstream concern
Domain events
Card 20
Mutating a child without going through the parent breaks invariants
Aggregate roots
These lessons aren't a curriculum, they're a collection. The same five "I do that every week" recognitions, twenty times. Working through the deck once teaches you the principles. Coming back to the deck a few months later, when the same patterns show up in a code review, is when the senior reflex actually starts to form.