Chris Wiegman

Justis Ovus

<h1>Code Ages Like Milk</h1>
<img src="/images/front_range.webp" alt="The Front Range in the summer is hard to beat">
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.
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.
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?
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.
<h2>Code Ages</h2>
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.
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.
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.
<h2>Features Age Too</h2>
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.
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.
<h2>What Can I Do About It?</h2>
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.
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.

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

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

Code Ages like Milk

<h1>Local-First Software is Easier to Scale</h1>
<img src="/images/flatirons.webp" alt="The Flatirons">
The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.
<a href="https://writewithharper.com">Harper</a> recently received a massive increase in both traffic and user count.
How?
By making it to the front page of Hacker News.
If you couldn't tell by the extent to which I talk about this, I'm thrilled.
This amounted to a tremendous amount of free advertising, if nothing else.
I've been thinking a lot about the wondrous benefits of working at the edge.
That's just one term of many that people use to describe Harper: "edge-first".
Others include "local-first" or simply "on-device".
They are all just jargon for a simple idea: We run all the relevant grammar checking code as physically close to the users as possible.
That way, we can serve up suggestions faster than anyone else.
To achieve our goal, we make sure that everything is well-optimized and lean.
Harper barely uses any CPU or memory at all.
What does all this mean in the context of the recent uptick in user acquisition? Imagine, for a moment, we are LanguageTool.
Our software is written in Java, with questionable attendance to the efficiency of our code.
Since our software requires a big server to run, we have a certain number of servers on standby to handle a certain amount of expected load.
If suddenly the number of requests we received were to double (as it did for the Chrome extension), we would be big trouble.
To avoid increasing the latency on requests (or dropping requests all together), we would need to scale up the number of running servers.
This not only takes hiring an expert in cloud architecture, but also additional funding to pay the AWS (or whatever) bill at the end of the month.
Because Harper runs at the edge (no server required), we don't have to worry about that.
In fact, I only noticed that our user count had spiked after I visited Hacker News the morning after.
No hiccups at all.
Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all.

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

Local-First Software Is Easier to Scale

Back in my day, we used math for autocomplete.

Back in my day, we used math for autocomplete.

Markov Chains Are the Original Language Models

<h1>Writing in Visual Studio Code</h1>
I <a href="./my_writing_environment_as_a_software_engineer">write this blog in Neovim</a>, and I'm aware of a good number of other nerds who do the same.
I suppose I never considered that people might use other code editors for writing prose.
In fact, it seems that there are a nontrivial number of people using <a href="https://chriswiegman.com/2026/01/harper-my-new-grammar-checker/">Harper in Visual Studio Code</a>.
They seem to be using Harper mostly for Markdown and comments in code, but I'd love to get <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>LaTeX</mtext></mrow><annotation encoding="application/x-tex">\LaTeX</annotation></semantics></math>LATE​X working as well.

People are using Harper for writing prose in Visual Studio Code.

People are using Harper for writing prose in Visual Studio Code.

Elijah Potter

Writing in Visual Studio Code

Comments

Other Stuff

Code Ages like Milk

Local-First Software Is Easier to Scale

Markov Chains Are the Original Language Models