[{"data":1,"prerenderedAt":37},["ShallowReactive",2],{"blog-post-boring-code-is-a-feature-you-ship-to-your-future-self":3},{"slug":4,"title":5,"description":6,"date":7,"updated":8,"tags":9,"pillar":13,"draft":14,"image":15,"imageAlt":16,"html":17,"markdown":18,"faq":19,"readingTimeText":35,"readingTimeMinutes":36},"boring-code-is-a-feature-you-ship-to-your-future-self","Boring code is a feature you ship to your future self","The durable choice in code usually looks unimpressive, and that is the point. Why boring code wins on systems that have to last, how to defend the plain version in review, and the discipline of deleting clever code you were proud of.","2026-06-17T00:00:00.000Z",null,[10,11,12,13],"code-quality","maintainability","code-review","products-that-last",false,"/blog-covers/products-that-last.png","Products that last cover","\u003Cdiv class=\"post-tldr\">\u003Cdiv class=\"post-tldr-label\">TL;DR\u003C/div>\u003Cp>The durable choice in code usually looks unimpressive by design. Boring code optimizes for the incident and the handoff, so defend the plain version from the failure mode, not taste, and delete clever code when a simpler version exists.\u003C/p>\u003C/div>\n\u003Cp>The durable choice in code almost always looks unimpressive, and that is the feature, not a compromise. Boring code (the obvious control flow, the explicit conditional, the named variable instead of the clever chain) is something you ship to the person who has to debug it at 2am, ideally warned by \u003Ca href=\"/blog/why-i-run-uptime-checks-at-the-edge\">monitoring that runs at the edge\u003C/a> before users are, and that person is usually you. Cleverness feels like value while you write it. It reveals its true cost six months later, when someone reads it under pressure and cannot tell what it does.\u003C/p>\n\u003Cp>I build revenue-critical systems: licensing, subscriptions, payments, where the boring choices, like \u003Ca href=\"/blog/store-money-as-integer-cents-never-a-float\">storing money as integer cents rather than a float\u003C/a>, are the ones that keep the numbers honest. In that world an outage is not a slow page, it is customers who cannot pay or cannot use what they paid for. That raises the stakes on readability in a way that reframes the whole “elegant vs boring” argument. When the failure mode is money and trust, the most valuable property of code is that a tired human can understand it correctly on the first read.\u003C/p>\n\u003Ch2 id=\"why-boring-wins\" tabindex=\"-1\">Why boring wins\u003C/h2>\n\u003Cp>Boring code optimizes for the moment that actually matters: the incident, the handoff, the change you make a year after you forgot how it worked. Clever code optimizes for the moment that does not matter much: the fifteen minutes you spent writing it feeling smart.\u003C/p>\n\u003Cp>Concretely, boring means:\u003C/p>\n\u003Cul>\n\u003Cli>One obvious path through a function, not three clever branches folded into a ternary.\u003C/li>\n\u003Cli>Explicit names for the states of a thing, not booleans you have to decode.\u003C/li>\n\u003Cli>Doing the dumb reliable thing (a database unique constraint) instead of the smart fragile thing (a clever in-memory dedupe).\u003C/li>\n\u003Cli>Code that a competent stranger can change without archaeology.\u003C/li>\n\u003C/ul>\n\u003Cp>Here is the shape of it. Same logic, two temperaments:\u003C/p>\n\u003Cpre class=\"shiki shiki-themes github-light github-dark\" style=\"background-color:#fff;--shiki-dark-bg:#24292e;color:#24292e;--shiki-dark:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D;--shiki-dark:#6A737D\">// Clever. Reads like a puzzle, breaks like one.\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">return\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">trial_ends_at\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">?->\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\">isFuture\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">()\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">    ??\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> ($sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">canceled_at \u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">?\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\"> false\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\"> :\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">paid);\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D;--shiki-dark:#6A737D\">// Boring. Reads like a sentence.\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">if\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> ($sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\">onTrial\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">()) {\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">    return\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\"> true\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">}\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">if\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> ($sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\">isCanceled\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">()) {\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">    return\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\"> false\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">}\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">return\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $sub\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">->\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\">isPaid\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">();\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>The second is longer and I will take it every time. When a customer disputes their access at 11pm, I want to read three plain sentences, not reverse engineer a null coalescing operator I was proud of in April.\u003C/p>\n\u003Ch2 id=\"the-cost-clever-code-hides\" tabindex=\"-1\">The cost clever code hides\u003C/h2>\n\u003Cp>Clever code moves cost in time, the same way \u003Ca href=\"/blog/six-payments-edge-cases-that-bite-at-2am\">skipping idempotency does\u003C/a>. It feels free now because the author holds all the context. The context evaporates. What is left is a line that works but nobody wants to touch, so people build around it instead of through it, and the workaround becomes the next person’s clever code. That is how a codebase calcifies: not from bad engineers, but from a hundred small acts of cleverness nobody could safely delete.\u003C/p>\n\u003Cp>The durable version costs a few more keystrokes now and almost nothing later. That trade is the whole game in software that has to last.\u003C/p>\n\u003Ch2 id=\"defending-boring-in-code-review\" tabindex=\"-1\">Defending boring in code review\u003C/h2>\n\u003Cp>The hard part is social, not technical. Boring code gets challenged in review by well-meaning people who mistake terseness for quality. You need a way to defend the plain option that does not sound like you are just less skilled.\u003C/p>\n\u003Cp>What works for me is to argue from the reader, not the writer:\u003C/p>\n\u003Cul>\n\u003Cli>“This is fewer lines, but count the concepts someone has to hold to be sure it is correct. The longer version has fewer.”\u003C/li>\n\u003Cli>“Show me how you would change this under a deadline. If the answer involves rereading it three times, that is the cost.”\u003C/li>\n\u003Cli>“What does this do when the input is null? If we both have to stop and think, the next person will get it wrong.”\u003C/li>\n\u003C/ul>\n\u003Cp>Notice none of that is about taste. It is about the failure mode. Taste arguments are unwinnable. Failure-mode arguments end with someone saying “fair” and merging the boring version.\u003C/p>\n\u003Ch2 id=\"deleting-clever-code-you-were-proud-of\" tabindex=\"-1\">Deleting clever code you were proud of\u003C/h2>\n\u003Cp>The discipline nobody talks about is deletion. Sometimes the clever code is yours, it works, and you are attached to it. Delete it anyway when a plainer version exists. Sunk cost is not a code quality metric. I have replaced my own compact one liners with five boring lines more than once, usually right after watching a teammate misread the compact version in a pull request. If a smart colleague misreads it, it is not clever, it is a trap with good production values.\u003C/p>\n\u003Cp>A useful test before you keep something clever: could you delete it right now without hesitation if a simpler version existed. If the honest answer is “no, I like it”, that attachment is the problem, not a reason to keep it.\u003C/p>\n\u003Ch2 id=\"saying-no-is-part-of-the-job\" tabindex=\"-1\">Saying no is part of the job\u003C/h2>\n\u003Cp>Boring is also a stance you take against your own tools and habits. No to the new abstraction that saves four lines and adds a concept. No to the dependency that does one thing you could write in ten lines you understand. No to the premature generalization for the second case that does not exist yet. Every no keeps the surface area small, and small surface area is what lets a system survive its authors leaving.\u003C/p>\n\u003Cp>This is not an argument for crude code or for never using a good abstraction. A well-chosen abstraction is boring in the best way: it hides complexity behind an obvious name. The line I hold is that the abstraction has to pay for the concept it adds. Most clever code does not pass that test. It adds a concept to save some characters, and characters are free while concepts are expensive.\u003C/p>\n\u003Ch2 id=\"what-you-are-actually-shipping\" tabindex=\"-1\">What you are actually shipping\u003C/h2>\n\u003Cp>When you choose the boring version, you are shipping something to a future person: a faster incident, a cleaner handoff, a change that takes an hour instead of a day. That person cannot thank you, but you can be that person, and you will be, on some night when a customer cannot check out and the fix has to be right the first time.\u003C/p>\n\u003Cp>The engineers I trust with revenue-critical code are not the ones who write the most impressive line. They are the ones whose code I can read while half asleep and change without fear, and it is the same lens I bring when I \u003Ca href=\"/blog/the-refund-path-is-where-i-read-a-codebases-soul\">read an unfamiliar codebase for the first time\u003C/a>. That is the highest compliment I give code, and it is why I spend my review capital defending the plain version and my own time deleting the clever one. Boring is not the absence of skill. On systems that have to last, it is the skill.\u003C/p>\n\u003Cdiv class=\"post-takeaway\">\u003Cdiv class=\"post-takeaway-label\">The takeaway\u003C/div>\u003Cp>Boring code is a gift you ship to whoever debugs the system next, and on software that has to last, that person is usually you. Argue for the plain version from the failure mode rather than taste, spend your review capital defending it, and delete the clever line you were proud of when a simpler one exists. That discipline is not the absence of skill; on systems where the failure mode is money and trust, it is the skill.\u003C/p>\u003C/div>\u003Ch2 id=\"faq\" tabindex=\"-1\">FAQ\u003C/h2>\n\u003Cdiv class=\"post-faq\">\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Isn’t boring code just an excuse for writing less skilled code?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>No. A well-chosen abstraction is boring in the best way, hiding complexity behind an obvious name. The discipline is making every abstraction pay for the concept it adds, which most clever code fails to do.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">How do I defend the plain version when a reviewer calls it verbose?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>Argue from the reader, not the writer. Count the concepts someone must hold to be sure it is correct, and ask how they would change it under a deadline. Failure-mode arguments end in agreement where taste arguments do not.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">When is clever code actually worth keeping?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>When you could delete it without hesitation if a simpler version existed and still choose it on the merits. If your honest answer is “no, I like it”, the attachment is the problem, not a reason to keep it.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Why does this matter more for billing and payments than other code?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>Because the failure mode is money and trust, not a slow page. When a customer cannot check out at 11pm, you want to read three plain sentences, not reverse engineer a null coalescing operator.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Does boring mean I should never add a dependency or abstraction?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>No, it means the abstraction has to earn the concept it introduces. Say no to the one that saves four lines and adds a concept, and yes to the one that hides real complexity behind an obvious name.\u003C/p>\u003C/div>\u003C/div>\u003C/div>","\n## TL;DR\n\nThe durable choice in code usually looks unimpressive by design. Boring code optimizes for the incident and the handoff, so defend the plain version from the failure mode, not taste, and delete clever code when a simpler version exists.\n\nThe durable choice in code almost always looks unimpressive, and that is the feature, not a compromise. Boring code (the obvious control flow, the explicit conditional, the named variable instead of the clever chain) is something you ship to the person who has to debug it at 2am, ideally warned by [monitoring that runs at the edge](/blog/why-i-run-uptime-checks-at-the-edge) before users are, and that person is usually you. Cleverness feels like value while you write it. It reveals its true cost six months later, when someone reads it under pressure and cannot tell what it does.\n\nI build revenue-critical systems: licensing, subscriptions, payments, where the boring choices, like [storing money as integer cents rather than a float](/blog/store-money-as-integer-cents-never-a-float), are the ones that keep the numbers honest. In that world an outage is not a slow page, it is customers who cannot pay or cannot use what they paid for. That raises the stakes on readability in a way that reframes the whole \"elegant vs boring\" argument. When the failure mode is money and trust, the most valuable property of code is that a tired human can understand it correctly on the first read.\n\n## Why boring wins\n\nBoring code optimizes for the moment that actually matters: the incident, the handoff, the change you make a year after you forgot how it worked. Clever code optimizes for the moment that does not matter much: the fifteen minutes you spent writing it feeling smart.\n\nConcretely, boring means:\n\n- One obvious path through a function, not three clever branches folded into a ternary.\n- Explicit names for the states of a thing, not booleans you have to decode.\n- Doing the dumb reliable thing (a database unique constraint) instead of the smart fragile thing (a clever in-memory dedupe).\n- Code that a competent stranger can change without archaeology.\n\nHere is the shape of it. Same logic, two temperaments:\n\n```php\n// Clever. Reads like a puzzle, breaks like one.\nreturn $sub->trial_ends_at?->isFuture()\n    ?? ($sub->canceled_at ? false : $sub->paid);\n\n// Boring. Reads like a sentence.\nif ($sub->onTrial()) {\n    return true;\n}\nif ($sub->isCanceled()) {\n    return false;\n}\nreturn $sub->isPaid();\n```\n\nThe second is longer and I will take it every time. When a customer disputes their access at 11pm, I want to read three plain sentences, not reverse engineer a null coalescing operator I was proud of in April.\n\n## The cost clever code hides\n\nClever code moves cost in time, the same way [skipping idempotency does](/blog/six-payments-edge-cases-that-bite-at-2am). It feels free now because the author holds all the context. The context evaporates. What is left is a line that works but nobody wants to touch, so people build around it instead of through it, and the workaround becomes the next person's clever code. That is how a codebase calcifies: not from bad engineers, but from a hundred small acts of cleverness nobody could safely delete.\n\nThe durable version costs a few more keystrokes now and almost nothing later. That trade is the whole game in software that has to last.\n\n## Defending boring in code review\n\nThe hard part is social, not technical. Boring code gets challenged in review by well-meaning people who mistake terseness for quality. You need a way to defend the plain option that does not sound like you are just less skilled.\n\nWhat works for me is to argue from the reader, not the writer:\n\n- \"This is fewer lines, but count the concepts someone has to hold to be sure it is correct. The longer version has fewer.\"\n- \"Show me how you would change this under a deadline. If the answer involves rereading it three times, that is the cost.\"\n- \"What does this do when the input is null? If we both have to stop and think, the next person will get it wrong.\"\n\nNotice none of that is about taste. It is about the failure mode. Taste arguments are unwinnable. Failure-mode arguments end with someone saying \"fair\" and merging the boring version.\n\n## Deleting clever code you were proud of\n\nThe discipline nobody talks about is deletion. Sometimes the clever code is yours, it works, and you are attached to it. Delete it anyway when a plainer version exists. Sunk cost is not a code quality metric. I have replaced my own compact one liners with five boring lines more than once, usually right after watching a teammate misread the compact version in a pull request. If a smart colleague misreads it, it is not clever, it is a trap with good production values.\n\nA useful test before you keep something clever: could you delete it right now without hesitation if a simpler version existed. If the honest answer is \"no, I like it\", that attachment is the problem, not a reason to keep it.\n\n## Saying no is part of the job\n\nBoring is also a stance you take against your own tools and habits. No to the new abstraction that saves four lines and adds a concept. No to the dependency that does one thing you could write in ten lines you understand. No to the premature generalization for the second case that does not exist yet. Every no keeps the surface area small, and small surface area is what lets a system survive its authors leaving.\n\nThis is not an argument for crude code or for never using a good abstraction. A well-chosen abstraction is boring in the best way: it hides complexity behind an obvious name. The line I hold is that the abstraction has to pay for the concept it adds. Most clever code does not pass that test. It adds a concept to save some characters, and characters are free while concepts are expensive.\n\n## What you are actually shipping\n\nWhen you choose the boring version, you are shipping something to a future person: a faster incident, a cleaner handoff, a change that takes an hour instead of a day. That person cannot thank you, but you can be that person, and you will be, on some night when a customer cannot check out and the fix has to be right the first time.\n\nThe engineers I trust with revenue-critical code are not the ones who write the most impressive line. They are the ones whose code I can read while half asleep and change without fear, and it is the same lens I bring when I [read an unfamiliar codebase for the first time](/blog/the-refund-path-is-where-i-read-a-codebases-soul). That is the highest compliment I give code, and it is why I spend my review capital defending the plain version and my own time deleting the clever one. Boring is not the absence of skill. On systems that have to last, it is the skill.\n\n## The takeaway\n\nBoring code is a gift you ship to whoever debugs the system next, and on software that has to last, that person is usually you. Argue for the plain version from the failure mode rather than taste, spend your review capital defending it, and delete the clever line you were proud of when a simpler one exists. That discipline is not the absence of skill; on systems where the failure mode is money and trust, it is the skill.\n\n## FAQ\n\n**Isn't boring code just an excuse for writing less skilled code?**\nNo. A well-chosen abstraction is boring in the best way, hiding complexity behind an obvious name. The discipline is making every abstraction pay for the concept it adds, which most clever code fails to do.\n\n**How do I defend the plain version when a reviewer calls it verbose?**\nArgue from the reader, not the writer. Count the concepts someone must hold to be sure it is correct, and ask how they would change it under a deadline. Failure-mode arguments end in agreement where taste arguments do not.\n\n**When is clever code actually worth keeping?**\nWhen you could delete it without hesitation if a simpler version existed and still choose it on the merits. If your honest answer is \"no, I like it\", the attachment is the problem, not a reason to keep it.\n\n**Why does this matter more for billing and payments than other code?**\nBecause the failure mode is money and trust, not a slow page. When a customer cannot check out at 11pm, you want to read three plain sentences, not reverse engineer a null coalescing operator.\n\n**Does boring mean I should never add a dependency or abstraction?**\nNo, it means the abstraction has to earn the concept it introduces. Say no to the one that saves four lines and adds a concept, and yes to the one that hides real complexity behind an obvious name.\n",[20,23,26,29,32],{"q":21,"a":22},"Isn't boring code just an excuse for writing less skilled code?","No. A well-chosen abstraction is boring in the best way, hiding complexity behind an obvious name. The discipline is making every abstraction pay for the concept it adds, which most clever code fails to do.",{"q":24,"a":25},"How do I defend the plain version when a reviewer calls it verbose?","Argue from the reader, not the writer. Count the concepts someone must hold to be sure it is correct, and ask how they would change it under a deadline. Failure-mode arguments end in agreement where taste arguments do not.",{"q":27,"a":28},"When is clever code actually worth keeping?","When you could delete it without hesitation if a simpler version existed and still choose it on the merits. If your honest answer is \"no, I like it\", the attachment is the problem, not a reason to keep it.",{"q":30,"a":31},"Why does this matter more for billing and payments than other code?","Because the failure mode is money and trust, not a slow page. When a customer cannot check out at 11pm, you want to read three plain sentences, not reverse engineer a null coalescing operator.",{"q":33,"a":34},"Does boring mean I should never add a dependency or abstraction?","No, it means the abstraction has to earn the concept it introduces. Say no to the one that saves four lines and adds a concept, and yes to the one that hides real complexity behind an obvious name.","8 min read",8,1785070532920]