Markov Chains Are the Original Language Models

It didn't work for me, and if you reading this, it probably won't work for you either.

<p>It didn't work for me, and if you reading this, it probably won't work for you either.</p>

Do Not Type your Notes

<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.md">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

never_wait

<h1>Never Wait</h1>
<blockquote>
<p><em>Preface:</em> This post is specifically about Pull Requests for <a href="https://github.com/Automattic/harper">Harper</a>.
Read the contributor guidelines for a project before opening a PR.</p>
</blockquote>
<p>I get it.
Opening a pull request is an intimidating proposition.</p>
<p>It is non-trivial to put your blood, sweat, and (let's be honest) tears into code and put that onto the internet for the world to see.
I remember my first pull-request: it wasn't pretty either.</p>
<p>But I want to highlight a couple reasons why I want potential contributors to open their pull requests as early as possible.</p>
<h2>Drafts Reduce Duplicate Work</h2>
<p>When a contributor to a project is assessing the viability or usefulness of some work they're preparing to do,
most look at existing Pull Requests first.
Even if you're still working on the patch, it's a great idea to open a "draft" PR so no one starts work that could go to waste.</p>
<p>Further, if you have a draft open whose CI is failing, a maintainer may see it and fix whatever the problem may be.
I find myself frequently browsing <a href="https://github.com/Automattic/harper/pulls">Harper's Pull Requests</a> looking for failing builds, since I'm often the best equipped to find the issue.</p>
<h2>It Helps With Debugging</h2>
<p>I try to make myself available to contributors in case they have any questions regarding the architecture of Harper.
I'm also game to help debug their code, partly because I am of the opinion that debugging is a skill which is best learned by example.</p>
<p>But it is hard for me to debug code if I don't have it.
If a draft PR has been opened, I can usually see the problem without even cloning the code, since our CI is so comprehensive.</p>
<h2>Conclusion</h2>
<p>So please don't wait; open that PR.
I am thrilled each time I see a name I don't recognize on a GitHub notification.</p>

Elijah Potter

Never Wait

Drafts Reduce Duplicate Work

It Helps With Debugging

Conclusion

Other Stuff

Markov Chains Are the Original Language Models

Do Not Type your Notes

Code Ages like Milk