English for Ruby on Rails Developers

Rails leans hard on shared conventions, and the vocabulary that comes with it — “fat model, skinny controller,” “N+1 query,” “convention over configuration” — carries specific meaning that’s easy to misuse if you’re newer to the ecosystem. This guide covers the English used when discussing Rails code with a team.

Key Vocabulary

Convention over configuration — Rails’ guiding philosophy that sensible defaults (naming, file structure, routing) eliminate the need for explicit configuration in most cases. “You don’t need to specify the table name in the model — convention over configuration means Rails infers it from the class name automatically.”

ActiveRecord callback — a hook (before_save, after_commit) that runs code at a specific point in a model’s lifecycle, often a source of hidden, hard-to-trace side effects. “That after_save callback is quietly sending an email on every update — it’s exactly the kind of hidden side effect that makes debugging this model painful.”

N+1 query — a performance bug where an application issues one query to fetch a list, then one additional query per item to fetch related data, instead of eager loading everything up front. “This view is triggering an N+1 — add includes(:author) to the query so the authors get eager loaded in one extra query instead of one per post.”

Fat model, skinny controller — a design convention pushing business logic into models (or service objects) and keeping controllers focused on orchestrating the request/response cycle. “This controller action is forty lines long — let’s follow fat-model-skinny-controller and move that validation logic down into the model.”

Migration — a versioned Ruby file describing an incremental change to the database schema, run in order to bring the schema to a known state. “Don’t edit an already-run migration directly — write a new migration to make the change, or you’ll desync anyone who already ran the old one.”

Concern — a module (ActiveSupport::Concern) used to share reusable behavior across models or controllers, Rails’ pattern for mixing in cross-cutting logic. “Instead of duplicating that soft-delete logic across three models, pull it into a concern and include it where needed.”

Common Phrases

• “Is this callback going to fire in situations we’re not expecting, like bulk imports or seed scripts?”
• “Are we eager loading here, or is this about to trigger an N+1 in production?”
• “Should this validation live in the model, or does it belong in a service object given how much logic there is?”
• “Did we write a new migration for this, or did we edit one that’s already been run?”
• “Is this concern actually shared behavior, or are we forcing two unrelated models to look similar?”

Example Sentences

Reviewing a pull request: “This callback triggers an external API call on save — that’s risky inside a database transaction; can we move it to an after_commit or a background job instead?”

Explaining a design decision: “We extracted the pricing logic into a service object instead of a fat model method, since three different controllers need to call it independently of any specific model instance.”

Describing an incident: “The slowdown came from an N+1 on the dashboard — loading a hundred orders was quietly issuing a hundred and one queries.”

Professional Tips

• Say “eager load” rather than “fetch it all at once” — it’s the precise Rails term reviewers expect when discussing N+1 fixes.
• Flag callback side effects explicitly with “this callback has a side effect on…” — it’s a common Rails code review pattern for surfacing hidden behavior.
• Use “convention over configuration” when explaining why you didn’t add explicit config — it signals you’re leaning on Rails idioms deliberately, not by omission.
• Distinguish “migration” from “schema change” in conversation — a migration is the versioned file; the schema change is the actual database effect it produces.

Practice Exercise

1. Explain in two sentences why an N+1 query happens and how eager loading fixes it.
2. Write a one-sentence code review comment flagging a risky ActiveRecord callback.
3. Describe, in your own words, the difference between putting logic in a fat model versus a service object.