<h1>My Writing Environment As a Software Engineer</h1>
<blockquote>
<p><strong>TL;DR: <em>Get a good text editor, and get good at using it.
Keep a notepad by your side.
Find a quiet place to write.</em></strong></p>
</blockquote>
<p>Writing is one of life's greater joys.
It's a mental workout that often brings me a level of clarity that is hard to find elsewhere.
I have never sat down to write for an extended period of time without coming away with a greater understanding of myself and the universe.</p>
<p>I imagine that sounds pretty cheesy.</p>
<p>I just want to impress upon you the importance writing has had in my life.
As with anything this important, I have an instinctual urge to optimize it.
As software engineers, isn't that part of our modus operandi?
To spend an unnecessary amount of time optimizing things?</p>
<p>Well, that's exactly what I've done.
Over the years, I've spend a unruly amount of time tweaking and changing the tools I use to write.
I'd love to talk about 'em.</p>
<h2>Neovim</h2>
<p>In the past few years, Neovim has the talk of the town.
Its ancestor, <code>vi</code> was borne from the observation that most writing is re-writing, and thus it includes a vast array of specific tools for editing text, rather than writing it.
<a href="https://www.reddit.com/r/neovim/"><code>r/neovim</code></a> has swelled to more than 110 thousand weekly visitors and thousands of plugins and LSPs to choose from.</p>
<p>Unless you choose a pre-built distro like <a href="https://www.lazyvim.org/">LazyVim</a>, Neovim does very little out of the box.
It is through relentless customization that it becomes something truly powerful.
Beside the various keybindings in my config, the important plugins and tools that I use are:</p>
<h3><a href="https://writewithharper.com">Harper</a></h3>
<p>As I'm the chief maintainer, this one should be of no surprise.
Don't worry, I won't give you the marketing spiel.
I'll simply say that Harper is a grammar checker that happens to work exceptionally well in Neovim.</p>
<h3><a href="https://github.com/folke/zen-mode.nvim">Zen Mode</a></h3>
<img src="/images/zen_mode.png" alt="Zen Mode: Activated">
<p>Plain Neovim organizes each file to cover the maximum amount of space on-screen.
Practically, this means most of my text ends up on the left side, which can hurt my neck.
Zen mode restricts the width of the file and centers it on the screen.</p>
<h3><a href="./the_simplest_neovim_markdown_setup">Tatum</a></h3>
<img src="/images/tatum_screenshot.webp" alt="A screenshot of Tatum at work">
<p>Tatum is a small tool I wrote in a few hours that lets me live-preview my Markdown as HTML.
I won't repeat myself.
If you're curious about Tatum, check out my <a href="./the_simplest_neovim_markdown_setup">previous blog post.</a></p>
<h3>More Details</h3>
<p>If you're thirsty for <em>all</em> the details of my Neovim setup, take a quick look at the configuration code on <a href="https://github.com/elijah-potter/dots/tree/master/nvim">GitHub</a>.</p>
<h2>ReMarkable 2</h2>
<p>A few years ago, while I was still in school, I splurged and purchased a used Remarkable 2.
Even now, there is rarely a day that goes by where I don't use it.
Sure, everything it does could be easily approximated by paper.
On the other hand, the thin device saves my back whenever I have to travel and there's a certain joy that comes from using an e-ink device like this.</p>
<img src="/images/remarkable.jpeg" alt="A Recent Brainstorming Session on the ReMarkable">
<p>I mostly use it to read digital books and blog posts, but it's also come in handy for getting around writer's block.
Being forced to slow down and use my hand to write, rather than a keyboard, is quite helpful in some inexplicable way.</p>
<h2>A Quiet Space</h2>
<p>More important than any text editor, at least for me, is a quiet space.</p>
<p>As I said before, writing can take real cognitive effort.
A space with distracting noise can make it unnecessarily hard to get words on paper.
I've found local libraries or co-working spaces to be great places for quiet authorship.</p>
<p>Whatever you do, do not listen to music with words in it.
Even if it <em>feels</em> more productive, I retroactively find that it makes me less so.</p>
<h2>Conclusion</h2>
<p>There's probably some more important points I'm leaving out, but I definitely believe I've hit the big three.
For me, the most important parts of a good writing environment, as a software engineer, are my text editor, a notepad, and a quiet space.</p>

Writing is one of life's greater joys. It's a mental workout that often brings me a level of clarity that is hard to find elsewhere.

<p>Writing is one of life's greater joys. It's a mental workout that often brings me a level of clarity that is hard to find elsewhere.</p>

My Writing Environment as a Software Engineer

Back in my day, we used math for autocomplete.

<p>Back in my day, we used math for autocomplete.</p>

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>Linkarzu: Harper Is Getting Better</h1>
<p>Linkarzu's recent video about Harper is a great primer on what it can do if you spend a ton of time in Neovim (like I do). It's true: Harper is getting better.</p>
<iframe width="100%" height="400" src="https://www.youtube.com/embed/he8V6gj9IG0?si=mbw6q8m3jqi1qhSf" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Linkarzu's recent video about Harper is a great primer on what it can do.

<p>Linkarzu's recent video about Harper is a great primer on what it can do.</p>

Elijah Potter

Linkarzu: Harper Is Getting Better

Comments

Other Stuff

My Writing Environment as a Software Engineer

Markov Chains Are the Original Language Models

Code Ages like Milk