<h1>Quality Is the Most Important Metric</h1>
Harper's Chrome extension continues to come along beautifully. I'm actively working to make it more useful and responsive, slowly crushing bugs that I hear about from our users and contributors. I will not go over them here, since our <a href="https://github.com/Automattic/harper/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aclosed">closed pull requests</a> should speak for themselves. I would, however, like to rapid-fire some of the small improvements and ideas about Quality that I've been brewing up this week.
<img src="/images/guggenheim_2.png" alt="Living in a college town is strange. The whole place gets empty in the summer.">
<h2>Quality</h2>
I first heard about big-Q Quality from Zen and the Art of Motorcycle Maintenance by Robert Persig. The book's length—whose main subject is the idea of Quality—speaks to its complexity as a topic. It's a great read, and I'd highly recommend it.
One important point the author makes is that Quality is inherently a human idea. It is hard, if not impossible, to define algorithmically or on paper. When one interacts with an object or a system, they come away with a sense of its Quality, without necessarily knowing exactly what led to that sense.
Some argue that in today's world of LLMs and fast-iterations, the real value of a good software engineer derives from their sense of Quality. We know whether a design decision or change to the code is worth exploring. We know how it will affect users. I don't think this argument is relevant to the LLM discussion at all, but I do agree with it in spirit.
<h2>The Most Important UI Element</h2>
Harper's Chrome extension has one critical UI element that user's should be interacting with more than any other: the suggestion box.
<table>
<thead>
<tr>
<th align="left">Before</th>
<th align="right">After</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><img src="/images/before_suggestion_box.png" alt="Before the changes to the suggestion box"></td>
<td align="right"><img src="/images/after_suggestion_box.png" alt="After the changes to the suggestion box"></td>
</tr>
</tbody>
</table>
When Harper locates a problem in a user's text, it underlines it and waits for them to notice. When they do, they have the option to click it and review Harper's suggestion. This is a flow typical of most spell and grammar-checking programs, so you're likely familiar with it. This process makes the contents and behavior of the suggestion box extremely important for user satisfaction.
After receiving some feedback related to the suggestion box's visual unpleasantness and difficulty to understand intuitively, I've started making some modifications. Nothing drastic—I don't want to confuse existing users. I've focused on making it more compact and use more visual storytelling. Now, when a spelling mistake should be corrected, it shows an icon rather than a full "Add to dictionary" label. I'm already getting positive feedback about the changes.
All-in, it seems like much of the design philosophy of the UI is being pushed further in the direction of Harper's core tenet: to get out of the way.
<h1>Why Quality is Important</h1>
<img src="/images/chrome_web_store_front_page.png" alt="The Chrome Web Store Front Page">
Quality is important for the Chrome extension (more so than other integrations) because of the Chrome Web Store's front page.
Extensions that get featured on the front page get a significant amount of free advertising. Millions of users view this page monthly. Getting on the page is guarantee of tens of thousands of new users, if not more.
Here's the rub: you can't get on the front page by paying for it or by chance. An extension is placed on the front page if and only if it meets a high bar of value and quality. In other words: you have to earn it. This is the essential reason why I've been working so hard on Quality these past few weeks: I'm trying to get on the front page.
Most of the steps I've taken in this direction are small enough to not be worth mentioning here. If you're curious, feel free to reach out!

After receiving some feedback related to the suggestion box's visual unpleasantness and difficulty to understand intuitively, I've started making some modifications. Nothing drastic—I don't want to confuse existing users.

After receiving some feedback related to the suggestion box's visual unpleasantness and difficulty to understand intuitively, I've started making some modifications. Nothing drastic—I don't want to confuse existing users.

Quality Is the Most Important Metric

<h1>A Case for Procrastination</h1>
<img src="/images/model_t.jpg" alt="A linup of Model T Fords">
The most valuable, unique aspect of software development is the speed at which we can iterate.
Software projects that don't iterate quickly and frequently usually stagnate and fail, while projects that work with user feedback on an almost real-time basis are the most successful.
I've noticed the difference personally, with my work at <a href="https://archytasinc.com/">Archytas Automation</a>.
Most recently, I've read The Lean Startup, Zen and the Art of Motorcycle Maintenance and The Pragmatic Programmer.
While each uses their own terminology, both go into depth on the depth on the topic of fast iteration cycles.
<h2>Lean Manufacturing and Lean Thinking</h2>
Lean manufacturing, as explained in The Lean Startup is a production methodology focused on avoiding waste.
The book's primary example is the Toyota Production System.
In the mid 1930s, the world's largest car manufacturer was Ford.
Ford's factories produced thousands of unique parts, which together could form a car.
They produced these parts in bulk, and each distinct part had an entire machine dedicated to producing it.
There was a machine that made springs, a machine that made nuts, and a machine that made bolts.
No machine could make any part other than the one it was designed for.
This was great: it meant that cars would be cheaper than ever, and more people could experience car ownership.
Around this time, Toyota entered the automotive industry.
However, they did not have the time, nor the money to design and build the same kind of hyper-specific manufacturing machines that Ford used.
Instead, they chose to purchase comparatively few hyper-generalized machines.
Their strategy was to build one car at time, and sell it as soon as possible (ideally the moment it rolled off of the factory floor).
This way, if there is an issue with the vehicle, the design can be modified before too many faulty cars are assembled.
The Toyota Production System emphasized flexibility over efficiency.
By staying flexible, Toyota gave itself the ability to optimize all aspects of the business in the middle of a production run.
On one hand, the Ford process looked like this:
<ul>
<li>Get materials for one hundred cars.</li>
<li>Fabricate over a thousand distinct parts required for each car (likely more than a hundred thousand total parts).</li>
<li>Assemble one hundred cars .</li>
<li>Sell one hundred cars.</li>
<li>Receive feedback on vehicle and production process.</li>
<li>Perform all possible changes to the vehicle's design and production process (which would be very little).</li>
</ul>
With this many steps, each taking place over a comparatively long time, the iteration cycles are few and far between.
On the other hand, the Toyota Production System looked like this:
<ul>
<li>Get materials for one car</li>
<li>Fabricate the relatively few distinct parts required for the car</li>
<li>If there is an issue with the production process (a machine breaks, someone gets hurt, etc.).
Stop the whole process and fix the issue, so it will not affect future cars.</li>
<li>Assemble one car.</li>
<li>Sell one car.</li>
<li>Receive feedback on vehicle and production process.</li>
<li>Perform all possible changes to the vehicle's design and production process (which could be quite a lot, given the flexibility of both).</li>
</ul>
Counterintuitively, performing each step with a batch size of one actually ended up being more efficient.
Even though Ford experienced a higher level of efficient within each batch, their process led to many more wasted parts being manufactured,
as well as a lack of communication between steps, which dramatically increased the amount of wasted effort.
Additionally, because the Toyota Production System allowed comparatively rapid iteration, Toyota vehicles were simply better: more durable, and more useful to their customers.
<h3>Lean Thinking In Software</h3>
In software development, it can be tempting to go the Ford route:
create a detailed plan of all the features you wish to add to your service,
then, develop the features, and deliver them all at once.
Only then do you accept feedback and evaluate the usefulness of each feature.
In The Lean Startup however, Eric Ries suggests an alternative methodology, inspired by the Toyota Production System.
Before deciding on which features to include in your service in an all-at-once, shot-in-the-dark manner, perform experiments.
Create an absolutely minimal prototype of the feature, give to a customer, and observe how they use it.
It is possible they find the feature unhelpful, or they use it in a way you didn't expect.
By running the experiment early on, there are far fewer unhelpful features introduced, and the customer gets a product more closely tied to their needs.
Further, it is possible that your understanding of the problem domain is misinformed.
Planning out the entire product release months in advance is problematic when the requirements of the project change (and they will, often).
<h2>Why Interpreted Languages Can Be So Productive</h2>
Interpreted programming languages are almost laughably pervasive.
Of the top ten most popular programming languages on the 2023 StackOverflow Developer survey, six were interpreted.
That count does not include TypeScript, which can be used in a semi-interpreted manner.
Interpreted language popularity is often chalked up to their ease-of-use, abstraction, and simple, English-like syntax.
However, I believe there is an additional reason: they allow one to iterate much, much faster.
<h2>Micro-iterations</h2>
Iterations can happen on any timescale.
Micro-iterations occur happen over the shortest time scale.
These are small, incremental changes that occur (usually) when debugging or optimizing code.
It is the amount of time (and by extension, mental overhead) that results from a change.
The longer it takes for tests to compile and run, the longer it takes to debug.
I believe you can model it like so:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><mtext>time to debug</mtext><mo>=</mo><mo stretchy="false">(</mo><mtext>time to test</mtext><msup><mo stretchy="false">)</mo><mn>2</mn></msup><mo>∗</mo><mtext>text editing</mtext></mrow><annotation encoding="application/x-tex">\text{time to debug} = (\text{time to test})^2 * \text{text editing}</annotation></semantics></math>time to debug=(time to test)2∗text editing
<blockquote>
This is not an exact, representative equation, merely an abstraction to illustrate my point, based on personal experience.
</blockquote>
In other words, the total debugging time increases super-linearly as the time it takes to test a change to the program increases.
Notice how, as the <code>time to test</code> increases, the actual amount of time <code>text editing</code> falls to a negligible ratio of the total.
I believe this comes from the fact that as compilation time increases, the amount of information gleaned per micro-iteration tends to decrease.
<h3>JIT Compilation and Hot Reload</h3>
This is where we get to the title of the article.
The concepts of lean thinking extend into compiler technology.
The Toyota Production System includes the concept of "Just-in-time", meaning,
"to only produce exactly what is needed for the product, exactly when in the process it is required."
Avoid planning resource requirements ahead of time and build systems that only produce what is actually needed.
While the meaning of "Just-in-time" is different when we refer to compilers, the line of thinking is ultimately the same.
Instead of wasting valuable, human-scale time on compilation and optimization of irrelevant code, just compile the code you need, when you need it.
This drastically reduces the amount of time to test, and ultimately, the time to debug.
Further, technologies like React and Flutter's Hot Reload make it possible to complete these micro-iterations without having to restart your program.
I believe this is partly why interpreted languages are so beginner-friendly (other than the high level of abstraction they typically provide).
Newcomers to programming spend most of their time on syntactic issues and simple runtime errors.
By making micro-iterations happen as fast as possible, you make these issues less annoying to deal with.
<h3>Procrastination</h3>
If you are in university (like I currently am), or any other level of education, it can actually be beneficial to hold off on doing your homework.
It is not uncommon (at least in my experience) for the project or paper requirements to change at the last minute.
Some of your peers may choose to complete the project or paper as soon as possible.
If this is the case, you may benefit from their experience.
If a certain chain of logic or analysis is confusing or misleading, they can warn you to avoid losing time.
Assuming they are willing, they can also provide insightful feedback on your work mid-way through your writing or study process.
<h2>Conclusion</h2>
Iteration is incredibly important to any design and development cycle, especially in software.
Since I have embraced iteration, I've seen a dramatic improvement in my productivity and effectiveness.
So I encourage you: if your build process takes 30 minutes, spend some time on improving it.
If you are working on a project that hasn't been put in front of a customer, try showing it to a family member or non-technical friend.
Ask them for brutal honesty, and your project will be much better off.

Or: why doing things at the last minute actually saves time. I talk about the importance of shockingly fast iteration cycles and lean manufacturing.

Or: why doing things at the last minute actually saves time. I talk about the importance of shockingly fast iteration cycles and lean manufacturing.

A Case for Procrastination

<h1>Photography as Meditation</h1>
The goal of meditation is to become more mindful and aware.
For me, it is often an attempt to get an appreciation for my surroundings—to see how utterly complex the world is.
<img src="/images/pink_flower_tree.webp" alt="Spring has sprung in Colorado. That means pink flowers everwhere.">
Photography does something similar for me.
The heft of the camera in my hands reminds me to slow down and take in the view.
My mother is a photographer—a great one at that.
She's been in the business for at least as long as I've been alive.
She tells me something similar: the act of framing a picture is itself a way to understand your subject better.
<img src="/images/puddle.webp" alt="Spring brings rain and rain brings puddles.">

Reflecting on the clarity photography brings.

Reflecting on the clarity photography brings.

Photography As Meditation

code_ages_like_milk

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

Elijah Potter

Code Ages Like Milk

Code Ages

Features Age Too

What Can I Do About It?

Other Stuff

Quality Is the Most Important Metric

A Case for Procrastination

Photography As Meditation