Why Performance Improvements Compound
Mature systems rarely waste time inside algorithms. They waste time moving data between algorithms—and that's why performance improvements compound.
Long-form writing on software engineering, systems design, and building things.
Mature systems rarely waste time inside algorithms. They waste time moving data between algorithms—and that's why performance improvements compound.
Every embedding API sends vectors as JSON. That's convenient. It's also one of the most expensive ways to move numerical data between services. Here's how switching to binary Base64 float buffers cut our payload size by 75% and reduced serialization latency by 98%.
When you need more throughput from your Rails background job workers, adding more threads seems like the obvious answer. But under the wrong conditions, increasing concurrency can actually grind your system to a halt. Here is how to recognize when your AI server is fighting the scheduler instead of scaling with it.
Every senior engineer has lived through a migration that got 80% finished, stalled for a year, and left the team maintaining two versions of the same system forever. Migrations rarely fail because the new architecture is bad; they fail because of incorrect system boundaries, lack of dual-writing strategy, and ignoring human momentum.
When the database CPU spikes to 99% or your background job queue has a backlog of 200,000 tasks, your engineering skills are only half the battle. Leadership during an incident is about command, communication, and systematic triage. Here is what I've learned from managing production fires.
Deleting code is easy; convincing other developers, product managers, and business stakeholders to let you delete it is the real challenge. Here is how to build a case for deletion, treat code removal as a product feature, and safely execute large-scale cleanups.
Most engineers write CLAUDE.md like a README. They put their stack, a few preferences, maybe a note about testing. The agent reads it and proceeds to write code shaped by its training data rather than their codebase. The file exists. It doesn't do much. The problem is category. A README describes a project. A specification constrains behavior. This post covers three dimensions of getting it right: how to structure the file across a real directory hierarchy, how to write rules the agent actually follows instead of weighs, and how to keep the file current as the codebase evolves.
The engineers who stand the test of time aren't the ones who chased every new thing, they're the ones who knew what was worth chasing. Every field has a surface and a foundation. The ones who only ever work the surface stay busy but never quite arrive anywhere. The ones who go deep find that the fundamentals they learned ten years ago are still paying interest today. That's not nostalgia. That's how engineering actually compounds ... not by accumulating tools, but by developing the judgment to know which problems are new and which ones just look that way.
You don't need new mental models to start a business. You need to recognize the ones your codebase already gave you, and the one place where they'll betray you.
Stop writing N+1 update loops. Learn how `update_all`, `update_columns`, and safe, batched SQL can drastically improve your Rails app's performance.