How to Unabstract an Abstraction

Abstractions in code are easy to add and challenging to remove. Sometimes we feel stuck with them. But the good news is, you can back out of almost any abstraction with the right mindset. Let’s look at an example. A Breaking Abstraction Imagine a currency formatter. function formatPrice(amount) { return `$${amount.toFixed(2)}` } formatPrice(10) // "$10.00" Soon our company decides to launch in Europe. Let’s add that conditional. function formatPrice(amount, currency) { if (currency === "EUR") return `€${amount.toFixed(2)}` return `$${amount.toFixed(2)}` } formatPrice(10) // "$10.00" formatPrice(10, "EUR") // "€10.00" 😊 Hang on; the Czech Republic puts the currency symbol after the monetary amount. I guess we have to add a conditional that supports this: ...

February 1, 2026

Naive Implementations

A naive implementation is a programming technique that prioritizes imperfect shortcuts for the sake of speed, simplicity, or lack of knowledge. Naive implementation example What is ’naive’? Here’s the dictionary definition: naive (adjective) marked by unaffected simplicity : ARTLESS, INGENUOUS –Merriam-Webster Dictionary Let’s see it in a programming context! A pangram is a sentence that contains all the letters of the alphabet, such as: “The quick brown fox jumps over the lazy dog.” Consider this problem I borrowed from Exercism, asking us to build a function that detects pangrams. We have written a failing test that describes our desired function. ...

June 23, 2022

How to Make Renames Easy

Names in software are hard. But what’s worse than a bad name? Sticking with it because you can’t change it. I want us all to be able to effortlessly and fearlessly fix bad names. That’s the topic of this post. Considering a “Bad” Name What’s a bad name? Here’s a contrived, but not production-unrealistic, example: function longName() { if(useLongName) { return `${this.firstName} ${this.lastName}` } else { return this.firstName[0] } } A few issues I can raise with this name: ...

March 22, 2022

Write Better Code by Knowing When Not To Refactor

When I review code, I sometimes request that refactoring changes be removed. Even when I think the changes are objective improvements, and even when they support my personal preferences. My reasoning? Refactors are not free. In this post, I’ll list a few times when I think a refactor is worse than leaving the code unchanged. No automated tests Do you have automated tests? Can you run them? Do you trust them? If you don’t, don’t refactor. ...

August 26, 2021