Engineering-Practices on rjrowland

The 6 Principles: How I Try to Work as an Engineer

Fri, 07 Aug 2026 09:00:00 -0500

I don’t meet this bar every day. I wrote it down because writing it down is how I hold myself to it. This series lays out the practices I try to work by as an engineer: patterns and anti-patterns across data modeling, delivery, code quality, code structure, architecture, and performance.

1. Make impossible states unrepresentable — and parse, don’t validate

This is the single highest-leverage type-level habit. Every time you reach for boolean, number, or string to represent a domain concept, ask: can this type contain values that are invalid in the domain?

The Highest-Leverage Work Is Never Feature Work

Thu, 06 Aug 2026 09:00:00 -0500

Senior engineers amplify through team success, not individual output. The leverage formula applies directly to career development: the highest-return activities multiply team effectiveness, they don’t just add to your own.

The key insight: the most visible, most impactful technical contributions at a company level are almost never feature work. They’re the infrastructure improvements that make feature work easier, safer, or faster for everyone else.

Finding the opportunity

Diagnose before you propose. Ask:

Stuck Designing or Stuck Building?

Tue, 04 Aug 2026 09:00:00 -0500

This tension runs underneath most of the practices in this series. Making it explicit helps you pick the right mode at each stage of the work.

Top-down starts from the highest-level model, requirements, domain, architecture, and works toward implementation. It asks: what are we building? What does success look like? What structure should this system have?

Bottom-up starts from concrete, working pieces and builds upward. It asks: what actually works? What do the real constraints look like? What can I demonstrate right now?

Code Review Is Wasted on Style Comments

Fri, 31 Jul 2026 09:00:00 -0500

Code review has its highest leverage at the design level, not the style level. The questions that matter most are structural.

Are invariants maintained?

What does the system depend on being true, and does this change preserve that? This question catches whole classes of bugs a line-by-line read misses entirely.

// The invariant: a settled transfer always has a SettledAt timestamp.
// This PR adds a new status without touching that guarantee.
func markSettled(ctx context.Context, transferID TransferID, network string) error {
 return db.Transfers.Update(ctx, transferID, TransferUpdate{Status: "settled", Network: network})
 // SettledAt never gets set — nothing enforces it, nothing warns you
}

Line by line, this reads fine: it updates a status, it takes a network, it compiles. The bug only shows up when you ask the invariant question directly — “settled transfers always have a SettledAt” was true before this PR and isn’t after it. A line-by-line read has no way to know that invariant exists unless someone states it and checks the diff against it.

How to Learn a Codebase With No Docs

Wed, 29 Jul 2026 09:00:00 -0500

The hardest case: no tests, no architecture decision records, no diagrams. The tactics shift from consuming documentation to producing it as a byproduct of exploring.

Here’s what that actually looks like, walked through on one example: you’ve just joined a team maintaining Ledger, an internal core-banking service written in Go. Nobody’s written a README beyond make dev. You have a week before you’re expected to ship anything.

Start outside the code

Use the product as a user before you read a line of source. Check the error monitoring dashboards, Sentry, Datadog, early: they show where the system actually breaks, which tells you more than reading happy-path code ever will. The production error log is an honest account of what the system struggles with. The codebase only shows you what the engineers thought would happen.

If Running Tests Takes Willpower, They're Too Slow

Tue, 28 Jul 2026 09:00:00 -0500

The layers of feedback

The practices in this series keep circling back to feedback, for a reason: the speed of your feedback loop sets the speed of your learning, and the speed of your learning sets almost everything else about how effective you are.

Feedback loops come in layers, and the right fix is different at each one.

Editor feedback. Compiler errors, go vet, staticcheck, inline warnings. Zero latency, the tightest loop that exists. Investing in it, stricter linting, more complete type coverage, pays back with compounding interest.
Unit tests in watch mode. Sub-second, on the file you just changed. If your unit tests don’t run automatically on save (gotestsum --watch, or your editor’s built-in runner), you’re leaving real developer experience on the table.
Local rebuild-and-run. A change reflected without a full redeploy. Trivial to script with air or reflex, and often just left off.
Integration tests. Should run in seconds, not minutes. A slow test doesn’t get run. That’s not a discipline problem, it’s an incentives problem: a four-minute suite gives engineers a reason to skip it before pushing.
CI. Parallelize aggressively. A twenty-minute pipeline is a morale tax paid on every single PR, and the cost isn’t just the twenty minutes, it’s the context switch of sitting there waiting.

The heuristic: if running tests takes willpower, the tests are too slow. Running them should be the path of least resistance, not a deliberate act you have to talk yourself into.

Profile First, Optimize Second

Mon, 27 Jul 2026 09:00:00 -0500

Measure first, know your bottlenecks

Performance intuition is wrong more often than it’s right. The thing you’re certain is the bottleneck almost never turns out to be. Profile first and let the data decide where effort goes. There’s no reliable shortcut around this.

Most web application code spends its time waiting, not computing. A request handler calls the database, waits, calls another service, waits, maybe hits a cache, waits again — and the CPU sits idle through nearly all of it. That’s why the common bottleneck categories skew so heavily toward I/O, roughly in this order of frequency:

Design for the System You Have, Not the One You Imagine

Sat, 25 Jul 2026 09:00:00 -0500

Strangler fig, not the big bang rewrite

The big bang rewrite has a seductive pitch: the existing system is a mess, the new one will be clean, we’ll migrate users when it’s ready. What actually happens: the rewrite starts with “just the core functionality” and spends years discovering that the old system’s quirks were load-bearing. Edge cases nobody documented, accumulated over years. Integrations with external systems nobody wrote down. Data migration complexity nobody scoped. Behavioral requirements nobody stated because everyone assumed they were obvious.

Don't Touch Code You Don't Understand Yet

Fri, 24 Jul 2026 09:00:00 -0500

Characterization tests, one dimension at a time

The term “characterization tests” comes from Michael Feathers’ Working Effectively with Legacy Code.

Refactoring without tests isn’t refactoring. It’s rewriting with optimism. “Looks equivalent” is not “is equivalent.” The subtle behavioral change hiding in an untested path finds its way to production six months later, git blame points at a commit that moved some files around, and nobody can tell what the intended behavior even was.

Ship Small, Ship Boring, Know When You're Done

Thu, 23 Jul 2026 09:00:00 -0500

Vertical slices, not horizontal layers

Here’s a failure mode I’ve watched play out on almost every large feature: the team builds all of one layer before starting the next. Every database table first, then every endpoint, then every screen. Progress looks real — the database layer is “done,” the API is 70% there — right up until week six, when integration starts. The data model was built on assumptions that turned out wrong. The API contract doesn’t match what the UI actually needs. Two weeks of rework follows.

Get the Data Model Right, Get Everything Else for Free

Wed, 22 Jul 2026 09:00:00 -0500

The data model is the most consequential decision in a system, and teams make it too casually. Code gets rewritten constantly. Schemas outlast teams. A wrong column name costs you a migration. A missing foreign key costs you a redesign. A misunderstood entity relationship can invalidate months of work. Get the model right before any code exists, because that’s the cheapest point at which you’ll ever get to fix it.

Push Complexity to the Edges

Tue, 21 Jul 2026 09:00:00 -0500

Push ifs up and fors down

Alex Kladov named this precisely in “Push Ifs Up and Fors Down”: two structural habits most engineers apply by instinct sometimes, without ever generalizing them.

Push ifs up: conditional logic belongs as high in the call stack as it can go. Instead of a function checking a condition internally and doing nothing when it doesn’t apply, let the caller decide whether to call it. The function becomes unconditional, simpler, more composable. Its signature stops lying: it does X, full stop, instead of “maybe does X depending on internal state.”