A native app is three codebases: the web app, the iOS app, and the Android app, each reimplementing the same screens and drifting apart. Turbo Native takes a different position — your Rails

Most changelogs are a dump of commit subjects. “Merge pull request #412 from feature/fix-thing”, “wip”, “address review comments”. Nobody reads them, so nobody maintains them, so they get worse — and the one

The # frozen_string_literal: true magic comment sits at the top of nearly every file in a modern Ruby codebase, added by RuboCop, accepted without much thought. It’s a genuine optimization — measurably fewer

Most pull request descriptions say some version of “fixes the bug.” The diff is four hundred lines across eleven files. Your reviewer opens it, has no idea what problem you were solving or

An index page listing fifty posts, each showing a comment count, issues fifty-one queries. The fix is well known — counter_cache — and it’s usually applied incorrectly, either by forgetting the backfill, by

You open a PR at 4pm Kathmandu time. Your reviewer is asleep in Lisbon. They review at 9am theirs, leave four questions, and go into meetings. You answer at 6pm yours. They respond

You can write Ruby for years without knowing what an eigenclass is. Then one day a gem defines a method you can’t find with grep, super calls something you didn’t expect, and define_method

Some data doesn’t deserve a column. User interface preferences, per-account feature toggles, the last three filters someone applied to a report — attributes that are read constantly, queried almost never, and change shape

ENV["STRIPE_KEY"] returns nil in production and the app boots anyway, quietly using no key, until the first payment fails four hours later. Environment variables are the simplest configuration mechanism available and the one

A junior developer sees a stack trace and copies the top line into Google. A senior developer sees the same trace and knows within fifteen seconds which of their own files to open.

@value ||= expensive_call is the first optimization most Ruby developers learn and the one they keep using long after it stops being correct. It works beautifully for a non-nil, non-false result computed from

ChargeCustomerJob.perform_later(order) looks like a function call and behaves like a distributed system. It runs on another machine, at an unknown time, possibly more than once, possibly never. Most job bugs come from writing

“It’s fast enough” is a claim about a single request from one browser on a warm cache. It says nothing about what happens at fifty concurrent users, which is the number that actually

Every Rails team has the same conversation eventually. Someone adds bullet to the Gemfile, fixes the twelve N+1 queries it finds, and six weeks later there are eight new ones. Detection tools tell

Something worked last month. It doesn’t work now. Between then and now there are four hundred commits, three of them yours, and nobody remembers touching that code. The instinct is to start reading