<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Mega Ari — Notes</title>
    <link>https://megaari.com</link>
    <description>Short essays on software engineering and distance running, and the places where the two overlap.</description>
    <language>en</language>
    <lastBuildDate>Mon, 24 Aug 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://megaari.com/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Shipping small is a training plan</title>
      <link>https://megaari.com/notes/shipping-small</link>
      <guid isPermaLink="true">https://megaari.com/notes/shipping-small</guid>
      <pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
      <category>Engineering</category>
      <description>Big rewrites are the software equivalent of a hero workout: satisfying once, then three weeks of recovery.</description>
      <content:encoded><![CDATA[<p>Every team I've worked on has had the same temptation: pause, rewrite, come back stronger. It almost never pays off, and the reason is the same reason runners blow up in week two of a new plan.</p><p>Progress compounds from repeatable units of work. A pull request you can review in ten minutes is an easy run. A three-week refactor is a max-effort session you didn't earn the base for.</p><p>The practical rule I use: if a change can't be described in one sentence and reverted in one command, it's too big. Split it until both are true.</p><p>This isn't a productivity trick. It's load management. Consistency beats intensity over a quarter, the same way it does over a training block.</p>]]></content:encoded>
    </item>
    <item>
      <title>Pace at heart rate is the only metric I trust</title>
      <link>https://megaari.com/notes/pace-at-heart-rate</link>
      <guid isPermaLink="true">https://megaari.com/notes/pace-at-heart-rate</guid>
      <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
      <category>Running</category>
      <description>Weekly mileage feels like progress. Pace at a fixed aerobic heart rate actually is.</description>
      <content:encoded><![CDATA[<p>Mileage is an input. It tells you what you did, not what changed. If I run 60 km a week for two months and my easy pace hasn't moved, I did volume, not training.</p><p>The number I chart instead is average pace at 145 bpm on flat routes in similar weather. When that line trends down, fitness is real.</p><p>It's noisy. Heat, sleep, and caffeine all shift it by several seconds per kilometer. That's fine — I look at four-week rolling averages, not single runs.</p><p>This is also why I built a log that computes it automatically. Any metric I have to calculate manually is a metric I stop tracking by week three.</p>]]></content:encoded>
    </item>
    <item>
      <title>Design tokens before components</title>
      <link>https://megaari.com/notes/design-tokens-first</link>
      <guid isPermaLink="true">https://megaari.com/notes/design-tokens-first</guid>
      <pubDate>Sun, 19 Jul 2026 00:00:00 GMT</pubDate>
      <category>Engineering</category>
      <description>Most component libraries rot because the colors were decided inside the components.</description>
      <content:encoded><![CDATA[<p>The failure mode is predictable: someone hardcodes a gray in a card, someone else picks a slightly different gray in a table, and six months later there is no theme, only history.</p><p>Tokens first means every color, radius, and shadow lives in one file with a semantic name. Components consume names, never values.</p><p>The payoff shows up the day someone asks for dark mode. With tokens it's a second block of variables. Without them it's an archaeology project.</p>]]></content:encoded>
    </item>
    <item>
      <title>What the long run is actually for</title>
      <link>https://megaari.com/notes/long-run-thinking</link>
      <guid isPermaLink="true">https://megaari.com/notes/long-run-thinking</guid>
      <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
      <category>Running</category>
      <description>Ninety minutes without a screen is the most reliable debugging tool I own.</description>
      <content:encoded><![CDATA[<p>I solve more architecture problems on Sunday mornings than in any meeting. Not because running makes me smarter, but because it removes the option to look something up.</p><p>Without a screen, you're forced to hold the problem in memory. That constraint strips away everything incidental and leaves the actual shape of it.</p><p>I bring one question on every long run. No podcast for the first hour. By kilometer twelve I usually either have an answer or a much better question.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
