While contributing to the obsidian-tasks project with Clare Macrae, I was introduced to two powerful concepts that helped me tackle one of the hardest problems in programming - naming variables.

In the early years of my career in embedded systems, I encountered some truly dreadful variable names, often packed with type information, like bufferSizeUInt8. While the last five characters were technically necessary, they weren’t exactly pleasant. That experience made me hyper-aware of how I name variables, classes, interfaces, and everything in between.

I cared so much about proper naming that I would often go in circles, constantly renaming things - draining my energy without producing meaningful improvements. Worst of all, there was no end to it.

The 7 Stages of Naming

The first concept that helped me break this vicious cycle was a tweet by Arlo Belshee: The 7 Stages of Naming.

Now, every time I name a variable, I ask myself, “Where does this name fall on that scale?” The key is to evaluate the name after choosing it, rather than trying to pick a stage first and then force a name to fit.

This matters because naming happens in the context of existing names. If I pick a name too deliberately, it might create subtle inconsistencies, forcing me into endless renames. But if I take a step back, I can at least ensure that my names are honest - even if they’re not perfect.

The Apple Sauce Method

The second concept is the Apple Sauce Method. I noticed that when naming things, I often try to predict what they should be called, rather than naming them based on what they actually do. But predicting the “right” name upfront is nearly impossible - especially before implementation, when there’s no behavior to analyze.

This problem is trivial when working with real-world objects (a Location with latitude and longitude is obvious). But as soon as I introduce abstractions, things get messy.

First, abstract concepts are inherently hard to name. Second, when refactoring, I usually know the next step but not the entire journey - so I have no idea what the final abstraction will look like. How can I name something when I don’t even know what it’s becoming?

The solution: don’t name it (yet). Instead, I give it a temporary, attention-grabbing placeholder - like AppleSauce or fooBar. These names act as glaring reminders that I need to rename them before merging my code. And there’s no need to limit myself to just one applesauce name - I can use several at once.

Here are some examples from my own code:

interface AppleSauce {
    bar: (id: string) => Promise<Device>;
    foo: (id: string) => Promise<null>;
}

// Another example

type Foo = (action: Action) => Bar;
type AppleSauce = { [key in ActionType]: Foo };

Interestingly, these placeholder names don’t ruin readability - as long as the overall structure makes sense, the meaning still comes through. More importantly, AppleSauce keeps me focused on the big picture rather than getting stuck in tiny naming details too soon.

When Does the Right Name Appear?

The funny thing is, the right name usually reveals itself before I finish the implementation - around the 75% mark. At some point, a realization hits:

“Wait, this isn’t AppleSauce, it’s actually a DeviceClient!”

And just like that, the renaming happens naturally.

In a way, this approach feels like a startup mindset for naming. The AppleSauce name is just an MVP - it exists, and that’s good enough. The final product (a proper name) evolves iteratively, once more information becomes available.

Since learning these techniques, my approach to naming has changed drastically. I spend far less time agonizing over the perfect name upfront and far more time writing good, maintainable code. And ironically, the best names tend to emerge when I’m not even looking for them.