[{"data":1,"prerenderedAt":135},["ShallowReactive",2],{"blog-boring":3},{"id":4,"title":5,"article":6,"body":7,"date":122,"description":123,"extension":124,"meta":125,"navigation":126,"path":127,"readingTime":128,"seo":129,"stem":130,"tags":131,"__hash__":134},"content\u002Fblog\u002Fboring.md","Boring software",2,{"type":8,"value":9,"toc":114},"minimark",[10,14,17,22,25,33,36,40,47,54,57,60,64,67,70,73,80,84,95,98,102,105,108,111],[11,12,13],"p",{},"The highest compliment I can give a system is that it is boring. Not boring as in unambitious. Boring as in: nothing unexpected happens. Deploys go out on Tuesday and nobody holds their breath. The on-call phone doesn't ring. Customers don't notice, because there is nothing to notice. Everything just works.",[11,15,16],{},"This is extraordinarily hard to achieve.",[18,19,21],"h2",{"id":20},"the-glamour-problem","The glamour problem",[11,23,24],{},"Our industry has a glamour problem. We celebrate the heroic fix, the all-night debugging session, the engineer who saved production at 3 AM. We write blog posts about surviving scale, war stories about incidents, post-mortems that read like thrillers. These make for great conference talks. They make for terrible engineering cultures.",[11,26,27,28,32],{},"If your team regularly needs heroes, your system is telling you something. It's telling you that the work that ",[29,30,31],"em",{},"should"," have been done — the planning, the testing, the documentation, the careful thinking about failure modes — was skipped in favor of speed.",[11,34,35],{},"Speed is not velocity. Shipping fast and fixing later is just borrowing time from your future self at a brutal interest rate.",[18,37,39],{"id":38},"what-boring-looks-like","What boring looks like",[11,41,42,43,46],{},"Boring software is written clearly. Not cleverly — clearly. Every function does what its name says. The code reads like prose, not puzzles. A new engineer can open any file and understand what it does and why. Not because the code is simple, but because someone took the time to make it ",[29,44,45],{},"legible",".",[11,48,49,50,53],{},"Boring software is documented. Not as an afterthought, not as a ticket that never leaves the backlog — documented as a first-class part of the work. The architecture decisions are recorded. The runbooks exist ",[29,51,52],{},"before"," the incident. The README actually tells you how to run the project.",[11,55,56],{},"Boring software is tested. Not with a handful of optimistic happy-path tests, but with the kind of testing that comes from genuinely asking: what could go wrong? Edge cases are not surprises — they were anticipated, discussed, and handled. The test suite is a living document of every assumption the system makes.",[11,58,59],{},"Boring software is deployed predictably. There is a pipeline. It runs the same way every time. Rollbacks are a button, not a prayer. Feature flags gate new behavior. Migrations are backward-compatible. Nobody is SSHing into production.",[18,61,63],{"id":62},"the-cost-of-excitement","The cost of excitement",[11,65,66],{},"I've worked on exciting systems. Systems where every deploy was an event, where monitoring dashboards were watched like live sports, where Slack channels lit up at odd hours. It felt important. It felt like we were doing real work.",[11,68,69],{},"We were. But most of that work was a loan we didn't remember taking out.",[11,71,72],{},"A heroic fix is not a one-time cost. It's a loan whose collateral is the next hero hour. The artifacts of last night's save — the untested patch, the undocumented workaround, the deploy nobody quite understands — become the substrate of next month's incident. This is why exciting teams stay exciting. Each rescue makes the system slightly less legible, which makes the next failure slightly harder to diagnose, which requires a slightly bigger hero. Boring is not the absence of heroism. It is the refusal to take out the loan in the first place.",[11,74,75,76,79],{},"There's a way to tell whether your team has stopped paying interest. Count your last ten incidents. Not by severity — by root cause. If most of them are variations of a cause you've already seen, the team isn't encountering the frontier of its system. It's failing to learn from it. A boring team is not the team with the fewest incidents. It's the team whose incidents are all ",[29,77,78],{},"new"," — each one a genuinely novel discovery, never the same race condition twice.",[18,81,83],{"id":82},"the-visibility-problem","The visibility problem",[11,85,86,87,90,91,94],{},"Boring has a visibility problem. You cannot demo a thing that didn't happen. You cannot put \"prevented fourteen outages\" on a performance review, because the counterfactual doesn't exist — there is no parallel universe to compare against. Organizations can only see what ",[29,88,89],{},"fails",", never what was ",[29,92,93],{},"prevented",", which means the incentive gradient inside almost every company points away from boring and toward visible heroism.",[11,96,97],{},"This is not a culture problem you fix with a values poster. It is a measurement problem. The teams that stay boring are the ones whose managers have learned to read negative space — to ask \"what didn't happen this quarter that should have?\" instead of only \"what did you ship?\" Until someone is rewarded for the absence of incidents, the system will keep paying its best engineers to create them.",[18,99,101],{"id":100},"the-quiet-pride","The quiet pride",[11,103,104],{},"There's a particular kind of satisfaction that comes from running a system that just works. No war stories. No heroics. No dramatic saves. Just steady, reliable, unremarkable service — day after day.",[11,106,107],{},"It won't get you on stage at a conference. Nobody writes threads about the deploy that went exactly as planned. But your team sleeps well. Your users trust you without thinking about it. And when you do need to change something, you change it calmly, because the system was built to be changed.",[11,109,110],{},"That is not the absence of craft. That is craft at its highest form.",[11,112,113],{},"The best software is boring. I intend to keep it that way.",{"title":115,"searchDepth":6,"depth":6,"links":116},"",[117,118,119,120,121],{"id":20,"depth":6,"text":21},{"id":38,"depth":6,"text":39},{"id":62,"depth":6,"text":63},{"id":82,"depth":6,"text":83},{"id":100,"depth":6,"text":101},"2026-04-05","The best software is the kind where nothing happens. Everything was planned, written, tested, and deployed — and it just works.","md",{},true,"\u002Fblog\u002Fboring","5 min read",{"title":5,"description":123},"blog\u002Fboring",[132,133],"engineering","philosophy","g1ig7OdmyrBEC6_T9J6DhgAZ7Kuto5AGAqR1DxQU_MA",1776423304193]