Markov Chains Are the Original Language Models

<h1>Code Ages Like Milk</h1>
<img src="/images/front_range.webp" alt="The Front Range in the summer is hard to beat">
<p>A bold title, no? But it’s true, and it’s something that I (and most other maintainers) have to deal with on a regular basis. Failing to account for this reality can slow down development and dissuade contributors from sticking around.</p>
<p>As the chief maintainer of Harper, one of my main jobs is to act as quality control. I receive <a href="https://github.com/Automattic/harper/pulse/monthly">a number of PRs each week</a>, both from new contributors and old. Given the diverse pool of contributors, it makes sense that I review a diverse pool of code of varying levels of quality.</p>
<p>When I have my head down on technical and attention-intense projects, I have less time to review code. When I have less time, I need to set priorities. The question becomes: Would I rather let code from high-quality, reliable sources pile up, or code from sources of unknown quality?</p>
<p>I usually end up reviewing the high-quality sources first, since they’ll likely require fewer revisions. Fewer revisions means quicker merge means improving the user experience faster. Whether or not this is a good decision is something I’ve been thinking about all week.</p>
<h2>Code Ages</h2>
<p>As code sits stagnant in a PR, it ages. You might say I’m crazy, that there is no way the code itself changes as it sits still in an unmerged and unmodified PR. I’d say you’re right, except for one teeny-tiny detail: Code only has meaning when it sits within a broader context. If that broader context changes (for example, when other PRs are merged) the meaning of the unmodified code does too.</p>
<p>Let me put it another way. If the patch from a PR remains stagnant, but the code it gets patched onto changes, the actual impact of the patch does too. This can cause all sorts of problems, from merge conflicts to erroneous test failures.</p>
<p>The longer code sits in a PR, the more time it usually ends up taking me to get it merged (when I finally have the time to get to it), just from the merge conflicts alone. It’s the Lindy effect rearing its ugly head once more.</p>
<h2>Features Age Too</h2>
<p>Not only does code age when left untouched and unused, so do the features they represent. If a user requests for a button that marks some text as bold and they don’t receive that feature promptly, they’ll find an alternative solution, possibly from a competitor.</p>
<p>The rest of the app can evolve too. If you’re an individual contributor, it’s in your best interest for your code to make it to master. If that doesn’t happen quickly enough, another contributor (or, if the software is extensible, like Obsidian or WordPress) or plugin author might beat you to the punch.</p>
<h2>What Can I Do About It?</h2>
<p>I believe the way I’ve been handling this until now has been entirely wrong. I should be allocating more of my time to training new contributors and fielding PRs from established ones. Open sources is a team effort.</p>
<p>As for you, dear reader, that’s for you to figure out. The worst way code can age is if it stays in your head. Don’t let your ideas go to waste. <a href="./never_wait">Open that PR</a>, or remind your reviewer to take another look if you haven’t already.</p>

Failing to account for this reality can slow down development and dissuade contributors from sticking around.

<p>Failing to account for this reality can slow down development and dissuade contributors from sticking around.</p>

Code Ages like Milk

<h1>Why I Talk to Myself</h1>
<img src="/images/bike_sidewalk.webp" alt="My bike broke down. Luckily, I had my camera">
<p>Each week I sit down and reflect on what I've learned. I think about which of my efforts have helped the Harper endeavor, and which have harmed it. It's not easy, but I think it's one of the best habits I've built. More accurately, it's one of the best habits <a href="https://ma.tt">Matt</a> has encouraged me to build.</p>
<p>When I really think about it, I'm reminded of the original <a href="https://blog.afterthedeadline.com/">After the Deadline blog</a>, which coincidentally also had a category called "Talking to Myself". I wonder if Raphael Mudge (AtD's author) had a similar motivation.</p>
<p>I talk to myself to find the weaknesses in Harper's mission and focus my attention on what matters. It is an efficient way to get from <a href="https://ma.tt/2025/05/sharing-levels/">layer one to layer five</a>. It can help get other maintainers on the same page and build a body of knowledge that can be linked to from anywhere.</p>
<p>Not worrying about keeping information locked-down is one of the more beautiful parts of working in public. Open source code would be nothing without similarly open source knowledge. I talk to myself <em>online</em> so my users can understand my intentions.</p>
<p>In many senses, we are not unlike moths. We are drawn to the lights of distraction, hype, and procrastination. For me, setting up checkpoints to stop and reflect has been an effective deterrent from these lights. In fact, I think each minute for which I stop and think has paid itself back three times over in time savings. If I can better allocate my time and energy, I can avoid doing redundant work pursuing pointless goals.</p>
<h2>Bonus Points</h2>
<p>A <a href="./markov_chains_are_the_original_language_models">few</a> of my <a href="./local-first_software_is_easier_to_scale">articles</a> have become popular on sites like Hacker News and Reddit. We've gotten quite a few Harper installations from links on these articles. I would never rely on this kind of blogging as a source of advertising, but it is nice to see it help spread the word.</p>

It's not easy, but I think it's one of the best habits I've ever built.

<p>It's not easy, but I think it's one of the best habits I've ever built.</p>

Why I Talk to Myself

<h1>Product, Product, Product</h1>
<p>Working this past week with Jason Adams has given me a brand-new appreciation for the category of ideas that we engineers call "product."</p>
<p>For a long time, I've discussed the difficult-to-define word "Quality" and it's importance to the success of software projects.
To me, capital "Q" Quality meant that a piece of software was fast, extensible, and reliable.
It was a checklist and a series of metrics that could be tracked and optimized through iteration.
I had, and arguably still have, an engineer's definition of "Quality".</p>
<p>But the version of Quality that can be defined with numbers is not complete.
A complete definition of Quality includes something that I currently don't know how to define.
People like Jason Adams and Eduardo Villuendas can.</p>
<p>At the end of Radical Speed Month, my goal is to be able to describe it, at least shallowly.
Right now, I feel that I understand some of the base components, but not well enough to bring them together into a cohesive whole.</p>
<h2>Harper Desktop</h2>
<p>Harper Desktop is coming along amazingly!
My goal for this week was to get the full pipeline working.
That means:</p>
<ol>
<li>Reading text from arbitrary text areas on macOS.</li>
<li>Locating errors within it using <code>harper-core</code>.</li>
<li>Rendering highlights over those errors.</li>
<li>Showing a suggestion popup to users so they can review potential corrections.</li>
<li>Applying the corrections.</li>
</ol>
<p>This is a pipeline that we've successfully replicated in several other apps, but this is the first time we've tried to do it system-wide.
I'm pleased to say: It's all working!</p>
<video width="100%" height="400" controls>
    <source src="/videos/macos_harper_desktop_demo.mp4" />
</video>
<p>The only thing missing from a "complete" Harper Desktop experience is configuration.
Users need to be able to manipulate their dictionary, update their rule preferences, and whitelist (or blacklist) apps from being manipulated by Harper.</p>
<p>Fortunately, Jason Adams has been hard at work refining what Harper's settings menus look like.
Actually, to say that is <strong>all</strong> he has been doing would be disingenuous.
In reality, he has been revamping the entirety of Harper's design and look.</p>
<img src="/images/jasons_settings_preview.png" alt="A Preview of Jason&#x27;s Settings Page">
<p>The hope is that much, if not all, of Jason's work here will be ported back to the Chrome Extension.</p>
<h2>The Magic of Meetups</h2>
<p>I have never felt the magic of meetups more than during the short single-day meetups that Jason and I have been doing over the past few days.
I feel more productive, motivated, and optimistic than ever, and I think that is in no small part thanks to meetups. I get the hype now.</p>
<img src="/images/jason_elijah_garden_of_the_gods.png" alt="A Quick Jaunt to Garden of the Gods">

Working this past week with Jason Adams has given me a brand-new appreciation for the category of ideas that we engineers call 'product.'

<p>Working this past week with Jason Adams has given me a brand-new appreciation for the category of ideas that we engineers call 'product.'</p>

Elijah Potter

Product, Product, Product

Harper Desktop

The Magic of Meetups

Comments

Other Stuff

Markov Chains Are the Original Language Models

Code Ages like Milk

Why I Talk to Myself