<h1>The One Hard Thing</h1>
People (myself included) love to make cascading lists of tasks.
Actions, each of which are needed to improve a product, release a feature, or manage people.
These lists tend to explode in size, as more is asked of you.
There's one problem: I have only eight hours in a working day.
With so little time, how can I be expected to both maintain existing projects (bug fixes, etc.) while consistently delivering new functionality and maintaining a fast iterative loop?
<h2>Insight</h2>
I've had two key insights that have led to some tremendous personal productivity gains.
First: I've observed that the difficulty of my tasks tends to follow a <a href="https://en.wikipedia.org/wiki/Pareto_distribution">Pareto distribution</a>.
A small number of tasks are shockingly difficult to solve, while a much larger set boil down to communication.
Second: the morning is my most productive time of day.
For some reason, I'm able to tackle problems with an otherwise unusual mental clarity.
I suspect it's something to do with the natural human circadian rhythm or digestion.
<h2>Leveraging the Pattern</h2>
Motivated by these two observations, I've developed a habit: I dedicate each morning to its own difficult problem.
This is a single task that is chosen specifically to stretch my limits.
I call this my daily one hard thing.
Previous examples:
<ul>
<li>Developing the first version of <a href="https://writewithharper.com/docs/integrations/language-server"><code>harper-ls</code></a> which is now used by thousands of developers daily.</li>
<li>Building the first 80% of the <a href="https://writewithharper.com/docs/integrations/obsidian">Harper Obsidian plugin</a>, which is also widely used.</li>
<li>Grokking how <a href="https://github.com/Automattic/jetpack"><code>Jetpack's Write Brief with AI</code></a> feature works (before I joined Automattic).</li>
<li>Compiling Harper to WebAssembly and embedding it somewhere no one has put a grammar checker before: inside the web browser.</li>
</ul>
<h2>Think About It</h2>
I implore you: think about how you work.
How is your energy affected by the things you do in the day-to-day?
If you enjoy your eight hours, maybe the rest will be better too.

Reach further each day. The minimum effective dose.

Reach further each day. The minimum effective dose.

The One Hard Thing

<h1>How to Write a Discord Bot in Rust</h1>
Discord is an instant message platform with more than 150 million monthly active users. The main appeal seems to a combination of the wide reach that platforms like StackOverflow have, as well as the instant delivery of the instant messaging concept. One of the best features of Discord is it’s seemingly unlimited hackability of the platform via it’s “Bot” system. The Bot system allows developers to add functionality to Discord communities by writing software that interfaces in a similar way that people do. I want to give you an introduction on how to do that in Rust.
<img src="/images/flat_ferris.png" alt="A Flat Render of Rust&#x27;s Mascot, Ferris">
<h2>Interaction</h2>
Most interaction with Discord bots happens via commands, not dissimilar to terminal applications. Commands may look like <code>!play Eat it by Weird Al</code>.
<img src="/images/ping_pong.png" alt="Ping! Pong!">
The bot we are going to make now will simply respond to <code>!ping</code> with "Pong!".
<h2>Template</h2>
<img src="https://github.com/elijah-potter/discord-bot-template" alt="cargo generator template">
<h2>Setup the Project</h2>
Using a functioning Rust environment, use cargo to create a new project. E.g:
<pre><code class="hljs language-bash">cargo new tutorial-bot
</code></pre>
Next, we have to add <a href="https://github.com/serenity-rs/serenity">Serenity</a>, the library for creating Discord bots in Rust. We also have to drop in Tokio, because Serenity takes advantage of it's async runtime.
You can do this either via cargo-edit:
<pre><code class="hljs language-bash">cargo add serenity
cargo add tokio --features full
</code></pre>
or by just adding them to Cargo.toml:
<pre><code class="hljs language-toml">[dependencies]
serenity = "0.10.5"
tokio = { version = "1.5.0", features = ["full"] }
</code></pre>
<h2>Setting up the Standard Framework</h2>
Serenity has a lot of flexibility. You have access to a event handler that allows fine grain control of events. You also have access to a standard framework that makes it ridiculously easy to respond to commands.
Before we do anything else, we have to make our main function async. It is super easy to do that, just replace it with:
<pre><code class="hljs language-rust">#[tokio::main]
async fn main() {
}
</code></pre>
First, we want to get our bot token in. In an actual bot, please obtain it via an environment variable or some other method. We are only doing it this way for simplicity.
<pre><code class="hljs language-rust">let token = "{your bot token}";
</code></pre>
If you do not know how to get a bot token, please follow <a href="https://www.getdroidtips.com/discord-bot-token/">this tutorial</a>.
The Serenity Standard Framework splits your bot's commands into groups. Each group can have multiple commands. For example, a bot might have two groups: one focused on fun and one focused on math. The former has commands like !meme, while the latter may have various math functions, like sin!. This is also how we will add commands to our bot.
First, add the needed structs and macros to the file:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
</code></pre>
Next, create a struct that we will attach our commands to:
<pre><code class="hljs language-rust">#[group]
#[commands()]
struct HelloWorld;
</code></pre>
Once we have added our commands, we will enter them into the commands sub-macro.
Create an instance of <code>StandardFramework</code> and add our group to it. We can also configure our command prefix now.
<pre><code class="hljs language-rust">let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
</code></pre>
Notice that we used a reference to a static struct called HELLOWORLD_GROUP instead of just adding our group. This is the output of the #[group] macro.
Now that we have created our framework, we have to attach it to a Discord client.
<pre><code class="hljs language-rust">let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
</code></pre>
Start it.
<pre><code class="hljs language-rust">client.start().await.expect("The bot stopped");
</code></pre>
<h2>Adding the Command</h2>
Now that we have the framework set up, let's add a command.
<pre><code class="hljs language-rust">#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
}
</code></pre>
This command only needs the Discord client's Context, the message that contains the command, and returns a <code>CommandResult</code>.
 Do not forget to add the command to the group:
<pre><code class="hljs language-rust">#[group]
#[commands(ping)]
struct HelloWorld;
</code></pre>
If you don't, it will simply not get run.
We want the bot to reply to the !ping command with "Pong!", so let's add that to the inside of the ping function:
<pre><code class="hljs language-rust">msg.reply(ctx, "Pong!").await?;
Ok(())
</code></pre>
<h2>Full Code</h2>
Here is the full code for the bot:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
#[tokio::main]
async fn main() {
 let token = "Your bot token";
 let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
 let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
 client.start().await.expect("The bot stopped");
}
#[group]
#[commands(ping)]
struct HelloWorld;
#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
 msg.reply(ctx, "Pong!").await?;
 Ok(())
}
</code></pre>
<h2>That's it</h2>
If you build and run your app, you should have a functioning Discord bot!
Serenity is an amazing crate and is an absolute joy to work with. I hope you learned something. There is a ton more stuff that I did not cover here. Feel free to look at the <a href="https://docs.rs/serenity/latest/serenity/">Serenity docs</a> and examples to learn more!

We go through step-by-step how to build a Discord bot using the Rust Serenity Framework.

We go through step-by-step how to build a Discord bot using the Rust Serenity Framework.

How to Write a Discord Bot in Rust

<h1>Transformation-based Learning for POS Tagging</h1>
<img src="/images/ctlm.webp" alt="CTLM">
<a href="https://writewithharper.com/">Harper</a> is currently undergoing some pretty radical changes when it comes to its language analysis. These improvements will improve the output of our existing rule engine, in addition to making entirely new corrections possible. This post will cover our existing NLP pipeline, the recent changes and improvements to our machine learning approach, and what will come next.
While AI is a common topic of discussion online, I don’t hear much about actual machine learning. In that light, I hope this post piques someone’s interest.
<h2>What is POS Tagging?</h2>
POS (Part-of-speech) tagging is the first step of most NLP (Natural Language Processing) pipelines. For any grammar checker worth its salt, POS tagging is essential. Apart from the basic corrections you’re capable of doing with simple string manipulation, most grammar checking directly or indirectly depends on POS tagging. High-quality tagging results in high-quality suggestions.
What is POS tagging? It is the process of identifying which possible definition of a word is being used, based on the surrounding context. For those unfamiliar with the territory, I’m certain an example is the best way to explain.
<blockquote>
“I am going to go tan in the sun.”
</blockquote>
Here we have a simple, English sentence. In this case, it is clear the word “tan” is being used as verb. The linguists in the audience would point out that it is specifically in the first-person future tense. Consider this similar sentence:
<blockquote>
“I am already very tan, so I will stay inside.”
</blockquote>
In this sentence, the word “tan” is being used as an adjective. How can we tell?
As intelligent humans, some of whom have been speaking English their entire lives, it is easy for us to determine which words are serving which roles. It’s not as easy for a computer to do the same. From an algorithmic standpoint, there are a number of ways to go about it, each with differing levels of “machine learning” required.
Before this week, Harper primarily took a dictionary-based approach. In short: we ship a “dictionary” of English words to the user’s machine and use hash table lookups to determine the possible roles each word could assume. The authors to our rule engine could then use rudimentary deductive reasoning to narrow the possibilities down. This strategy is remarkably effective and it has scaled to tens of thousands of users with surprisingly few hiccups.
That said, there are edge-cases and systems (which I’ll cover next week when I discuss chunking) which require extreme specificity from POS tags. My mission: improve our POS tagging to increase the confidence of Harper’s output and open the door for more advanced algorithms.
<h2>Why Transformation-based Learning?</h2>
The literature highlights four underlying machine learning model strategies that seem to work well for POS tagging.
<ul>
<li>Hidden Markov Models (probabilistic models that predate the modern deep learning era)</li>
<li>Maximum Entropy Models (statistical models closely related to logistic regression).</li>
<li>Transformer-based Models (which use deep neural networks)</li>
<li>Transformation-based Rule Models (which are based on learned rules)</li>
</ul>
While I heavily considered using a neural network (either via an HMM or MEM), I discarded the technology for three reasons.
<ul>
<li>TRMs are typically more accurate (barely; measured in basis points).</li>
<li>TRMs are more amenable to fine-tuning.</li>
<li>TRMs are exceptionally low-latency and can be compressed quite small.</li>
</ul>
Transformation-based learning is remarkably simple. It boils down to just four steps:
<ul>
<li>Use a simple, stochastic model to label your data. This can be as simple as tagging each token (or other discrete component) with that variant’s most common tag. It doesn’t need to super accurate, just enough to establish a baseline.</li>
<li>Identify the errors between the tags in your canonical data and that which produced by your baseline model.</li>
<li>Using a finite list of human-defined templates, generate candidate rules that transform the output of the baseline model into something else. This is where the term “transformation-based” comes from.</li>
<li>Apply each of the candidate rules to the baseline model’s output. Check if the result is more accurate than before. If so, save the rule for future use.</li>
</ul>
These saved candidates become your model.
<h2>POS-Tagging using Transformation-based Learning</h2>
Let’s apply these steps to build a POS-tagging system.
For our baseline model, we will just assign each word in our dataset the most common POS tag associated with that word. If the word is “tan”, we’ll assign it’s most common POS tag (verb). It will often be incorrect, but those cases will be handled by our rules.
To identify the baseline model’s errors, we’ll use an off-the-shelf tree-bank from the Universal Dependencies project.
Our rule templates will take the form of these <code>PatchCriteria</code>. By initializing our candidates with any one of these enum variants and initializing the child variables to random values, we can cover a good number of cases.
<pre><code class="hljs language-rust">#[derive(Debug, Clone, Serialize, Deserialize, Hash, PartialEq, Eq)]
pub enum PatchCriteria {
 WordIsTaggedWith {
 /// Which token to inspect.
 relative: isize,
 is_tagged: UPOS,
 },
 AnyWordIsTaggedWith {
 /// The farthest relative index to look
 max_relative: isize,
 is_tagged: UPOS,
 },
 SandwichTaggedWith {
 prev_word_tagged: UPOS,
 post_word_tagged: UPOS,
 },
 WordIs {
 relative: isize,
 word: String,
 },
 /// Not applicable to the Brill Tagger, only the chunker
 NounPhraseAt {
 is_np: bool,
 relative: isize,
 },
 Combined {
 a: Box&#x3C;PatchCriteria>,
 b: Box&#x3C;PatchCriteria>,
 },
}
</code></pre>
Finally, we’ll apply each of the hundreds of thousands of candidates to our treebank to see if the result of their transformations have a lower error rate than the baseline.
Here are a couple of the candidates we found:
<pre><code class="hljs language-json">[
 {
 "from": "PRON",
 "to": "SCONJ",
 "criteria": {
 "Combined": {
 "a": {
 "WordIs": {
 "relative": 0,
 "word": "that"
 }
 },
 "b": {
 "WordIsTaggedWith": {
 "relative": -1,
 "is_tagged": "VERB"
 }
 }
 }
 }
 },
 {
 "from": "PART",
 "to": "ADP",
 "criteria": {
 "Combined": {
 "a": {
 "WordIs": {
 "relative": 1,
 "word": "there"
 }
 },
 "b": {
 "AnyWordIsTaggedWith": {
 "max_relative": -4,
 "is_tagged": "NOUN"
 }
 }
 }
 }
 }
]
</code></pre>
That’s the whole process! With it, I was able to bring our previous accuracy all the way up to 95% (from 40%) without a meaningful change in linting latency or compiled binary size.

Harper is currently undergoing some pretty radical changes when it comes to its language analysis. These improvements will improve the output of our existing rule engine, in addition to making entirely new corrections possible.

Harper is currently undergoing some pretty radical changes when it comes to its language analysis. These improvements will improve the output of our existing rule engine, in addition to making entirely new corrections possible.

Transformation Based Learning

notifications

<h1>Notifications</h1>
I have found that the first couple hours of the day are my most productive.
I try to move tedious tasks to later so I can focus on solving "hard problems" that need my full attention.
In the past, this has been hard to do for one reason: GitHub notifications.
They pull me in and consume hours of my time.
Responding to and working with OSS contributors is important to me, but that can happen later in the day.
So I wrote a little ViolentMonkey script to hide the notifications icon during these early morning hours.
<pre><code class="hljs language-javascript">// ==UserScript==
// @name Hide Notification Indicator
// @namespace Violentmonkey Scripts
// @match https://github.com/*
// @grant none
// @version 1.0
// @author Elijah Potter
// @description 1/29/2025, 8:16:11 AM
// ==/UserScript==

function hideEm() {
 const matches = document.getElementsByClassName(
 "AppHeader-button--hasIndicator",
 );
 for (const element of matches) {
 element.remove();
 }
}

new MutationObserver(hideEm).observe(document, {
 childList: true,
 subtree: true,
});
</code></pre>

Elijah Potter

Notifications

Other Stuff

The One Hard Thing

How to Write a Discord Bot in Rust

Transformation Based Learning