DHH is both a curse and a blessing

David Heinemeier Hansson is one of those figures you can’t quietly admire. You either reckon with him fully or not at all. I’ve been doing the former for a while, and I’ve landed somewhere honest enough to write down: he’s more right than wrong, and the people most annoyed by him are usually the ones he’s calling out correctly.

The enterprise complexity theater DHH will not shut up about

DHH has made a career of being the most annoying person in the room for anyone whose job title exists because of organizational bloat. Not in a troll way — in an actually correct way, which is worse.

The specific disease he’s diagnosing: process worship. Not process that serves product — process that serves the people running it. Standups that exist so someone can feel in control. Roadmap theater where quarterly planning decks get shuffled while nothing ships. Premature microservices where a team of eight splits a CRUD app into twelve services and calls it “scale-ready architecture.” Rewrite ego projects where a senior engineer convinces leadership that the whole codebase needs to be rebuilt from scratch — in Go, or Rust, or whatever — conveniently creating two years of job security and no accountability when it ships late and broken.

The most insidious part of this ecosystem is the accountability blur. When you have enough layers — product, engineering, platform, infra, SRE, data — nobody is actually responsible when something doesn’t ship. Every failure has a handoff point to blame. DHH has been calling this out for years. Basecamp runs a product used by millions with a team in the dozens. That’s not a fluke. It’s what happens when you refuse to hire your way into dysfunction.

FAANG cargo-culting without FAANG constraints

The most damaging thing enterprise software culture did in the 2010s was convince mid-sized companies that they should operate like Google. Not the part where Google hires world-class engineers and pays them obscenely well — the part where they adopted the organizational rituals: OKRs, DORA metrics, platform teams, internal developer portals, SLO ceremonies.

The problem: Google’s complexity overhead exists because Google has a thousand engineers touching the same codebase. Your forty-person company does not have that problem. You have a different problem — shipping fast enough to stay alive — and you’ve now imported a solution optimized for a constraint you don’t have.

DHH is one of the few people with a platform who says this directly. The industry pattern isn’t engineering excellence — it’s cargo-culting the aesthetics of big tech without the underlying constraints that made those choices rational. Kubernetes for your startup with three services. Microservices before you’ve found product-market fit. Event-driven architecture before you even have events worth caring about. All of it signals sophistication to investors and hiring candidates while actively making the product worse to build.

Getting Real, Rework, Shape Up: the boring truth that actually works

Getting Real, Rework, Shape Up — these aren’t motivational fluff. They’re operational manuals written by people who shipped software profitably for decades without burning through investor money.

Getting Real in particular is the one I keep returning to. It’s blunt about reducing scope, shipping faster, and cutting vanity work before it metastasizes into process theater. Getting Real is the core mindset correction: build less, ship sooner, and stay close to what customers actually pay for.

The philosophy underneath all of it is simple: build a profitable product. Don’t raise capital you don’t need. Keep the team small. Own your stack. This is not a new idea — it’s a very old idea that got drowned out by the VC-funded growth-at-all-costs decade. DHH kept saying it anyway, loudly, when it was the least fashionable position possible. He was right then and the post-2022 reckoning with mass layoffs proved it.

Rails coherence vs. the rest of the ecosystem

Framework choice is not a trivial decision if you’re building alone or close to it. It’s a five-to-ten-year bet on ecosystem stability, documentation quality, upgrade path discipline, and whether the core team will throw out their conventions every two years for something shiny.

Rails has been remarkably coherent for over twenty years. The conventions are the same conventions. DHH has been steering the framework’s direction as one person — with input, but with clear final-say — and the result is a stack that doesn’t fragment. Compare this with Laravel: genuinely excellent, but its ecosystem has a different incentive structure. More noise around paid courses, paid tooling, churn-driven content. The core is solid, but the surrounding ecosystem rewards keeping you buying things.

DHH has been explicit that Rails is increasingly a one-person framework — the bet that a single developer with Rails can now build and operate something that previously needed a team. Hotwire, Solid Queue, Solid Cache, Kamal — every recent move collapses operational surface area for the solo builder. That’s a deliberate design philosophy, not an accident. For a solopreneur in 2026, that coherence is worth real money in saved mental overhead and hiring optionality.

I don’t use Rails day-to-day, but I still watch every Rails World opening because the signal is obvious — this guy genuinely cares about building software that lasts. You can fake hype for a release cycle, not for 20+ years. His energy around simplicity, coherence, and shipping feels like conviction, not branding. That mindset is contagious and always drags me back to fundamentals: own your stack, cut complexity, and ship products that make money.

Where I have to be honest about discomfort

Here’s the part that’s complicated for me personally.

DHH’s political positioning — anti-DEI framing, skepticism of institutional progressivism, occasionally platforming figures that read as inflammatory — lands differently depending on where you’re standing. I’m from a Vietnamese background, living as a permanent resident in Japan, operating from lower soft-power positioning in most rooms I walk into. Political signaling from high-platform tech figures isn’t purely abstract when you’re in a minority context. Some of what he says shapes professional cultures in ways that make people like me feel slightly less welcome. That’s real.

I’m not going to accuse him of bad faith. Cheap smears help nobody and I don’t know his heart. But this is a fair note: the practical content is excellent and the political vibe is sometimes uncomfortable. You can hold both without contradiction.

The quotes that stuck anyway

Two things DHH has said became personal north stars despite the discomfort:

“Competence, not compliment, builds confidence.” In environments where you’re always slightly outside the in-group — foreigner, minority, from somewhere that doesn’t carry cultural weight — the pull toward seeking external validation is real and corrosive. This is the right correction.

“Privilege is wonderful — you should earn more of it.” Controversial framing. But strip the political charge: the underlying point is that privilege worth having is worth acquiring through competence and output. That’s a more useful mental model than resentment.

If forced to choose

DHH makes me uncomfortable in specific ways, and I’m not minimizing that. But if you make me choose between his abrasive, high-conviction practical truth-telling and the polite frauds who run complexity theater, ship nothing, and make everyone feel included while the product dies — I’m choosing DHH.

The people most offended by him are usually selling something he’s debunking. That’s not a coincidence. Pick the person who’s right over the person who’s comfortable. Use what works. Stay clear-eyed about the rest.