<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Rough Edges</title><link>https://roughedges.dev/posts/</link><description>Recent content in Posts on Rough Edges</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 15 Apr 2026 00:00:00 -0400</lastBuildDate><atom:link href="https://roughedges.dev/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Your Test Strategy Should Match Your Reality</title><link>https://roughedges.dev/posts/rethinking-your-test-strategy/</link><pubDate>Wed, 15 Apr 2026 00:00:00 -0400</pubDate><guid>https://roughedges.dev/posts/rethinking-your-test-strategy/</guid><description>&lt;p&gt;The critique of over-mocking in unit tests is worth taking seriously. It&amp;rsquo;s a real problem, and it&amp;rsquo;s more widespread than the industry generally acknowledges.&lt;/p&gt;
&lt;p&gt;When you mock every dependency in a unit test, you&amp;rsquo;re no longer testing whether your code works – you&amp;rsquo;re testing whether your code does what you told your mocks to pretend the dependencies do. If the mocks don&amp;rsquo;t reflect production behavior, your tests pass and your production system still breaks. Worse, those tests make your codebase rigid. Every internal refactor requires updating a web of mock expectations, which creates friction, which leads to tests being deleted rather than maintained, which defeats the purpose entirely.&lt;/p&gt;</description></item><item><title>Your Infrastructure Costs Are Telling You Something – But Maybe Not What You Think</title><link>https://roughedges.dev/posts/infrastructure-costs-and-complexity/</link><pubDate>Thu, 09 Apr 2026 00:00:00 -0400</pubDate><guid>https://roughedges.dev/posts/infrastructure-costs-and-complexity/</guid><description>&lt;p&gt;High infrastructure costs are worth paying attention to. Teams that never look at their cloud bills tend to accumulate waste quietly – redundant logging pipelines, forgotten container registries, storage that nobody owns. Getting engineers to care about the cost of what they build is a legitimate goal, and one that&amp;rsquo;s harder than it sounds.&lt;/p&gt;
&lt;p&gt;But the diagnosis matters as much as the observation.&lt;/p&gt;
&lt;p&gt;The claim that elevated infrastructure costs primarily signal expertise gaps is too simple. Sometimes high costs reflect poor decisions. Sometimes they reflect genuine scale, regulatory requirements, or deliberate tradeoffs made during rapid growth. Sometimes they&amp;rsquo;re a combination. The work is figuring out which you&amp;rsquo;re dealing with before reaching for a solution.&lt;/p&gt;</description></item><item><title>Measuring Engineering Performance: Activity Is Not Output</title><link>https://roughedges.dev/posts/measuring-engineering-performance/</link><pubDate>Mon, 06 Apr 2026 00:00:00 -0400</pubDate><guid>https://roughedges.dev/posts/measuring-engineering-performance/</guid><description>&lt;p&gt;The case for making engineering performance visible is legitimate. Hidden underperformance is a real organizational problem, and managers who avoid measuring their teams are often just avoiding difficult conversations. That much is fair.&lt;/p&gt;
&lt;p&gt;The problem is the tool, not the intent.&lt;/p&gt;
&lt;p&gt;GitHub activity metrics – PR counts, commit frequency, lines of code – are proxies. They measure inputs, not outcomes. And once any metric becomes a target, it stops being a reliable signal. This is Goodhart&amp;rsquo;s Law, first articulated in economics but applicable almost anywhere humans are being measured. Engineers are rational people. Tell them their PR count matters and you&amp;rsquo;ll get more PRs – smaller, more frequent, shallower in scope. Tell them reviews are tracked and you&amp;rsquo;ll get more reviews that say &amp;ldquo;LGTM.&amp;rdquo; You haven&amp;rsquo;t improved performance. You&amp;rsquo;ve changed what people optimize for.&lt;/p&gt;</description></item><item><title>Rough Edges</title><link>https://roughedges.dev/posts/hello-world/</link><pubDate>Sat, 04 Apr 2026 09:20:00 -0400</pubDate><guid>https://roughedges.dev/posts/hello-world/</guid><description>&lt;p&gt;I'm an engineering manager. I've spent years building teams, shipping software, and keeping infrastructure from catching fire – sometimes successfully.&lt;/p&gt;

&lt;p&gt;The name is deliberate. Rough edges aren't a failure of craft. They're what you get when you make real decisions under real constraints. Every system has them. Every team has them. Anyone who tells you otherwise is either lying or hasn't shipped anything lately.&lt;/p&gt;

&lt;h2&gt;The philosophy&lt;/h2&gt;

&lt;p&gt;I'm pragmatic by nature. I believe, genuinely and without irony, that perfect is the enemy of the good.&lt;/p&gt;</description></item></channel></rss>