<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: lgrthmsprs</title><link>https://news.ycombinator.com/user?id=lgrthmsprs</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 09 Aug 2026 07:00:54 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=lgrthmsprs" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by lgrthmsprs in "When Feature Flags Do and Don't Make Sense"]]></title><description><![CDATA[
<p>That's a good point about not using feature flags to mitigate risk, and how rollbacks are a better alternative. Teams need to be in the habit of performing a rollback though. Sometimes, the rollback process can be black magic if the engineer handling an incident isn't familiar with that process. Having a bunch of flags in a system is a great way to end up with nondeterministic errors.<p>And that brings us to another great point, which is too many flags is problematic. So often there's an excuse made in the nature of, "we'll go back and remove this later," but later never comes.<p>At the end of the day, it's rigor that separates good teams from bad teams. Good teams will rigorously review old code and remove it; it's all too easy to do the opposite.</p>
]]></description><pubDate>Sun, 09 Aug 2026 02:47:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=49227959</link><dc:creator>lgrthmsprs</dc:creator><comments>https://news.ycombinator.com/item?id=49227959</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49227959</guid></item></channel></rss>