Most conversations about software quality gravitate toward things that are measurable: test coverage percentages, cyclomatic complexity scores, deployment frequency. These are fine proxies. But I’ve found another reliable signal – how much friction I feel when I go to change something.

My personal threshold for friction is low. Annoyingly low, some might say. If I open a file and have to scroll past 400 lines before I understand what it does, that’s friction. If adding a feature means touching five separate modules in sequence, hoping I don’t miss one, that’s friction. If the local dev setup requires following a seven-step README, two of which are outdated, that’s friction. None of these are catastrophic individually. Together, they’re a sign of rot.

Quality isn’t what the code does when everything goes right. It’s how hard the code fights you when you need to change it.

The subtle thing about friction is that it accumulates slowly and invisibly. Each shortcut is defensible in isolation. The test you skipped because the deadline was real. The abstraction you deferred because the requirement felt unstable. The naming you left vague because you’d come back to it. You always intend to come back. You rarely do. The debt compounds quietly, and then one day a routine change takes three times as long as it should, and you can’t quite say why.

I like to think about maintainability less as a property of code and more as a property of the future developer experience (that future developer is usually me, three months later, with no memory of why I made any of these decisions). Writing with empathy for future me is a forcing function. It pushes toward smaller functions, honest naming, and architecture where the seams are obvious. Not because some style guide said so, but because future-me is going to feel it if present-me is lazy.

This is why I’ve come to treat my own friction response as a legitimate quality metric. When something feels annoying to work with, I try to resist the urge to push through and instead ask why it’s annoying. Usually the answer points directly at something worth fixing – a missing abstraction, a leaky boundary, a function doing too much. The irritation is diagnostic.

Good software doesn’t just work. It stays workable. It stays workable when the requirements change, when the team changes, when the context you had in your head six months ago is completely gone. That durability doesn’t come from clever architecture alone. It comes from a consistent, almost stubborn refusal to let friction slide – catching it early, naming it honestly, and fixing it before it fossilizes into the codebase.

How you do one thing is how you do everything.

That applies here. The developer who lets a confusing variable name slide is the same one who lets an unclear API boundary slide. The team that skips the test because it’s “just a small fix” is the same team that ships the outage. Standards aren’t rules – they’re habits. And habits show up everywhere, whether you’re watching or not.

The AI Angle

I’ve been thinking lately about how this threshold in the age of AI coding. AI coding tools are genuinely useful. I use them. But they have a particular failure mode that maps directly onto everything above: they generate plausible code faster than you can evaluate it. The friction of writing is gone. The friction of understanding what was written is very much still there.

If your standard before was “I’ll clean this up later,” AI gives you ten times the surface area of later to deal with. It will happily produce a 200-line function, inconsistent naming, and a abstraction that almost makes sense – and it will do it confidently, in seconds. The output isn’t wrong enough to reject immediately. It’s just subtly not right, in ways that compound.

This is why a low friction tolerance might be more valuable now, not less. The bottleneck has shifted. You’re no longer constrained by how fast you can type – you’re constrained by how fast you can think critically about what’s in front of you. Developers who trained themselves to feel friction, to notice when something is harder to follow than it should be, have a real edge here. They’ll catch the AI’s lazy abstractions. They’ll push back on the generated code that technically works but quietly makes the next change harder.

The old excuse was that there wasn’t time to do it right. AI has largely killed that excuse. There’s now almost always time to do it right – the question is whether you’ve built the habit of caring. How you do one thing is how you do everything. If you accepted slop before, you’ll accept AI slop now, just faster and at greater volume.

Low friction tolerance is a feature. In the age of AI, it might be the feature.

Agents can now churn out code and features faster than ever, and can run ²⁴⁄₇. That means even a brief window of package compromise can have a much larger blast radius.

The axios issue was live for only a few hours in the middle of the night in my time zone. The team was asleep, so we weren’t exposed. But as teams increasingly rely on unattended AI, that risk grows exponentially, giving bad actors more leverage.

It’s a reminder that guardrails matter more than ever: tighter dependency policies, version pinning, lockfile enforcement, audit automation, and human review for critical updates.

That is why I keep arguing for exact versions in How NPM’s Defaults Set You Up for Failure. This is another case study. It is not even just the packages you chose, it is the transitive dependencies you inherited. When you rely on semver ranges like ^ or ~, you are opting into silent updates. In the real world, those updates are not always safe or even predictable.

If you are going to keep ranges anyway, add friction to newly published releases. The latest npm includes a --min-release-age flag you can set in your .npmrc so packages must be at least that old before they are eligible for install. It is a small guardrail, but it gives the ecosystem time to surface problems before they land in your CI.

Pin what you can, review what you must, and add guardrails where you will not. Supply-chain safety is the sum of boring, repeatable habits.

I first heard about it while listening to a ChangeLog podcast titled Kaizen! Let it crash. One of the hosts casually mentioned Mole as a tool they’d had great luck with, and that was enough to send me digging. I’ve tried plenty of Mac “cleanup” utilities over the years. Some are beautiful. Some are functional. Most eventually hit you with a paywall or subscription right when you actually need them.

Mole felt different almost immediately.

My M1 MacBook isn’t slow—not even close. Apple silicon still holds up incredibly well. But after years of installs, experiments, abandoned apps, and random tooling, it was clearly overdue for some TLC. I wasn’t looking to wipe my machine or reinstall macOS. I just wanted to clean house properly without blowing everything up.

That’s where Mole really shines.

Its real value, at least for me, was truly uninstalling apps and aggressively cleaning caches, logs, and leftover system junk. Not just removing an app bundle, but all the hidden remnants that quietly pile up over time. On my first run, Mole reclaimed over 70GB of cached data—which immediately justified the install. (why was my slack cache over 500mb??)

Mole is multiple utilities rolled into one: deep cleaning, a smart uninstaller, disk usage insights, and live system monitoring—all in a single, lightweight binary.

No bloat. No upsell. No account creation. Just a free tool that does its job well and gets out of the way.

Software like this reminds me how good small, focused utilities can be. Huge shout-out to tc39—I’ll definitely be keeping Mole in my core Homebrew installs.

DI is a familiar pattern used to keep application code modular, clean, and maintainable. In the Node.js + Express ecosystem, you’ll often come across tutorials where services, database clients, and configuration are wired directly into the app. That works, but there’s a simpler and more flexible alternative using FP principles like composition and higher-order functions.

What is Dependency Injection (DI)?

In a typical Express.js app, services, database clients, and config values are commonly wired up like this:

const express = require('express');
const app = express();
const dbClient = require('./dbClient');
const userService = require('./userService')(dbClient);

app.get('/users', async (req, res) => {
    const users = await userService.getUsers();
    res.json(users);
});

app.listen(3000, () => console.log('Server running on port 3000'));

While this approach is functional and easy to follow, it has a few downsides:

• userService is tightly coupled to dbClient, making testing and future changes harder.
• The app logic is directly tied to how the services are instantiated, which reduces flexibility.

Bringing in Functional Programming

Functional programming encourages passing dependencies explicitly via parameters. It focuses on pure functions, composition, and clarity. Here’s how that can play out in your Express.js app.

Step 1: Create Pure Business Logic Functions

Instead of defining userService as a class or an immediately invoked function, use a factory function:

const createUserService = (db) => ({
    getUsers: async () => {
        return db.query('SELECT * FROM users');
    }
});

This keeps your business logic clean and makes it easy to pass in any kind of db — a real client in production or a mock in tests.

Step 2: Compose Routes Using Injected Dependencies

Route handlers can be built in a similarly modular way:

const createUserRoutes = (userService) => {
    const router = require('express').Router();

    router.get('/users', async (req, res) => {
        const users = await userService.getUsers();
        res.json(users);
    });

    return router;
};

Now your routing layer doesn’t know or care how the service is built — it just uses what it’s given.

Step 3: Assemble the Application

Finally, you bring everything together in the main application file:

const express = require('express');
const dbClient = require('./dbClient');
const createUserService = require('./userService');
const createUserRoutes = require('./userRoutes');

const app = express();

const userService = createUserService(dbClient);
const userRoutes = createUserRoutes(userService);

app.use('/api', userRoutes);

app.listen(3000, () => console.log('Server up on 3000'));

This approach keeps your main file focused on configuration and composition.

Why This Approach Works Well

Adopting functional programming for DI offers several benefits:

1. Improved Testability – Easily swap in mock implementations without rewriting core logic.
2. Greater Modularity – Each component is self-contained and can be developed in isolation.
3. Enhanced Reusability – Functions and services can be reused across routes or even projects.
4. Simplified Maintenance – With clear dependency boundaries, the code is easier to understand and refactor.
5. Reduced Dependency Overhead – There’s no need to rely on an external DI framework. Let’s face it: npm packages can be black holes—pulling in way more than expected.

You don’t need a complex setup or heavy abstraction to apply DI effectively in Express.js. With just a few functional programming patterns, you can keep your app lightweight, testable, and easy to evolve.

If you’re looking to simplify your architecture while staying flexible, this approach is definitely worth trying out.

Let’s be honest: the thrill of solving problems and shipping features tends to make us a bit reckless. We’ve all experienced the coding flow state – that zen place where you’re cranking out solutions, piling up commits like there’s no tomorrow. It’s exciting! But tomorrow does come, and it’s not as kind as you might hope. That’s when maintainability steps in. Think of it as a sort of wisdom, gently whispering, “Future You will be the one cleaning up this mess. Be kind to Future You.”

A Love Letter to Maintainability

First, let’s define this beautiful concept. Maintainability isn’t just about making things “easier to fix later.” It’s about creating code that your teammates can read without taking headache medicine, code that will remain functional and reliable under the stress of future updates, code that won’t spontaneously combust just because the product team had an epiphany at 3 a.m.

There’s an underrated elegance to maintainable code. It’s code that fits together neatly, like a well-organized sock drawer. You’re not just throwing things in randomly, but folding, sorting, and arranging with intention. The goal? To make sure that every future visit to that code is painless. Blissful, even.

It’s All Fun and Games Until Someone Says, “Let’s Add a New Feature”

The real test of code isn’t whether it works today but whether it’ll still work – and be adaptable – tomorrow. Picture this: you’re deep into a project, your code is humming along nicely, and the product team suddenly decides to add a new feature. If your code is a spaghetti nest of confusing logic, scattered files, and function names like doStuff123, then I’m afraid you’re in for a long night. Adding anything to a mess is just going to make a bigger mess.

But if your code is maintainable, your response is different. Instead of a sinking feeling, you get to say, “Sure! That’s an easy tweak.” Because your functions are readable, your components are organized, and your logic makes sense. That’s the power of maintainability: it’s a gift you give yourself, wrapped in clean, readable code and a bow of future-proofing.

The Perks of Maintainable Code

So, what exactly makes maintainable code so precious? Here are some benefits that make it worth prioritizing above all else (yes, even above “It Works™”):

Readability – Imagine writing code that makes sense even to someone who didn’t write it. Cue gasps of amazement. Well-structured, maintainable code is like a well-written novel: anyone can jump in, understand the plot, and see the purpose behind each character (er, function).

Adaptability – Remember that feature request we just talked about? Maintainable code makes changes feel like a gentle adjustment rather than a Herculean task. When your functions are modular, your variables are meaningfully named, and your logic flows naturally, new features fit right in.

Collaboration – Writing code isn’t a solo act. You’re a part of a team, and nothing says “team player” like writing code that someone else can actually understand. After all, there’s no better feeling than receiving a Slack message from a teammate that reads, “Your code was so clear – adding that feature was a breeze!”

Easier Debugging – Bugs are inevitable, but debugging doesn’t have to be a nightmare. Maintainable code means that, when things break, they do so in predictable ways. Debugging is like following a trail of breadcrumbs through the forest instead of hacking your way through dense underbrush with a dull machete.

Longevity – Code that’s maintainable can withstand the test of time. It’s robust, resilient, and – dare I say it – timeless. You might move on to another project or another company, but your maintainable code will be a gift to those who come after you, and they will sing your praises in hushed, reverent tones. (Okay, maybe not, but they will be grateful.)

The Art of Maintainability: A Few Tips

Achieving maintainable code isn’t rocket science, but it does take a little intentionality. Here are some practical ways to start putting maintainability front and center in your codebase:

Name Things Well – Clear, descriptive names are your best friends. A function called calculateTotalInvoiceAmount beats calc1 any day. Don’t force Future You (or anyone else) to decipher what you were thinking.

Keep It DRY (Don’t Repeat Yourself) – Write reusable functions and avoid copying and pasting code blocks. Not only is DRY code easier to maintain, but it’s also less error-prone.

Comment with Purpose – A well-placed comment can be a lifesaver, but too many comments can muddy the waters. Focus on explaining why you did something, not what you did.

Write Tests – Tests are the unsung heroes of maintainable code. They give you confidence that changes won’t accidentally break everything.

Refactor Relentlessly – Maintainability isn’t something you achieve once and then forget. Revisiting and refining code is essential for long-term maintainability.

Embrace the Boring Virtue of Maintainability

In a world that loves the new, the flashy, and the cutting-edge, maintainability might seem like the shy kid at the back of the class. But here’s the truth: the shiniest, most performant code in the world is useless if no one can work with it six months down the line.

So next time you’re coding, embrace the humbling virtue of maintainability. Write code that’s clear, organized, and prepared for whatever the future holds.

Here’s why it’s time to rethink the default use of caret versioning in NPM, and how it sets developers up for future pain, particularly given the complexities of semantic versioning (semver).

Why ^ Versioning Isn’t a Safe Default

The caret (^) prefix in NPM allows minor and patch version updates automatically. For example, if you run:

npm install lodash

NPM adds the following entry to your package.json:

"lodash": "^4.17.21"

This means that any future installation can upgrade the lodash dependency to anything below 5.0.0. While this aims to provide developers with bug fixes and new features without manual intervention, it introduces significant risks: unexpected changes, hidden regressions, and version incompatibilities in complex projects.

1. Semver is Hard—and NPM Makes it Harder

Semantic versioning (semver) is designed to make versioning predictable: major versions introduce breaking changes, minor versions add features, and patches fix bugs. However, not all packages in the JavaScript ecosystem strictly adhere to semver rules. Accidental breaking changes are common, even in minor or patch versions.

By defaulting to ^, NPM shifts the burden of semver compliance onto developers, who must constantly monitor updates to avoid potential breakages. This behavior creates unpredictable outcomes that often surface in production or CI pipelines. NPM’s default makes the promise of semver nearly impossible to uphold, resulting in wasted time troubleshooting issues that stem from unintended updates.

2. A Reproducible Developer Experience Should Be the Default

An idempotent development environment ensures that every code checkout and dependency installation yields the same behavior, regardless of when or where it happens. This level of consistency is essential for stable CI/CD pipelines, reliable production releases, and seamless collaboration across teams.

Other ecosystems, such as Go and NuGet, use exact versioning to prevent dependency drift. In Go, the go.mod file locks dependencies to specific versions, ensuring builds are reproducible every time. NuGet favors deterministic package management for similar reasons. These approaches prioritize stability by ensuring nothing changes unless a developer explicitly updates a version.

In contrast, NPM’s default caret (^) versioning can lead to differing versions on different machines. Reproducing bugs becomes a nightmare when dependencies shift between development, CI, and production environments, making stability difficult to maintain.

3. ^ is a Time Bomb Waiting to Go Off

The flexibility provided by ^ introduces risks that compound over time. Here’s why:

1. Invisible Updates: Dependencies can be updated silently, resulting in unexpected issues.
2. Version Conflicts: As the dependency tree grows, conflicts arise between direct and transitive dependencies.
3. CI Pipeline Failures: Even if code works locally, a new patch version of a dependency may cause unexpected CI build failures.

These issues could be avoided by making exact versioning the default. Developers should have control over when to upgrade dependencies, whether through planned reviews, automated tools like Dependabot, or manually tested patch releases.

4. The Case for --save-exact as the Default

NPM should default to --save-exact behavior, where every dependency is locked to the precise version installed. This would look like:

"lodash": "4.17.21"

This ensures that the versions used during development are identical across all environments. Developers can still upgrade dependencies intentionally, but only when they are ready to manage the risks. This approach reduces reactive debugging and ensures a reproducible development experience by default.

How to Implement an Idempotent NPM Workflow

If NPM doesn’t change its default behavior, you can take these steps to enforce stability in your projects:

1. Use npm install --save-exact. Set this behavior as the default: npm config set save-exact true
2. Leverage npm ci for CI pipelines. This ensures only the versions listed in package-lock.json are installed, preventing unexpected updates.
3. Use automated tools to manage updates. Tools like Dependabot can help you control upgrades in a systematic manner.

Conclusion

NPM’s default use of the caret (^) for versioning creates more problems than it solves. In an ideal world, semantic versioning would work flawlessly, but in reality, semver is hard — and NPM’s current behavior makes it even harder by encouraging version drift and unpredictable builds. A reproducible, idempotent developer experience should be the default, not the exception.

By shifting to --save-exact, NPM would align with practices of more stable ecosystems like Go and NuGet. This change would empower developers to upgrade dependencies on their own terms, reducing surprises and enabling smoother workflows. The minor inconvenience of managing updates manually is a small price to pay for long-term stability and consistency.

It’s time for NPM to rethink its defaults and prioritize stability—because predictable software is better software.

Enter the Digital Hero: Paperless-NGX

Then, I decided enough was enough and started scanning all these documents to keep them in Paperless. It was cool, but when I upgraded to Paperless-NGX, things got a whole lot cooler. Why? One word: ASN (archive serial number) labels. Sounds fancy, right? It basically means I slap a number on my paper documents, scan them, and bam – I can search for them in Paperless-NGX, then find it physically based on the number.

The Magic of ASN Labels

So, I stumbled upon this nifty tool by Tobias L. Maier that lets me print out these ASN labels right at home. But oh boy, did I go through a ton of label sheets trying to get the printer settings right. Eventually, I found just the right printer settings so I wouldn’t waste more labels. It was a game-changer. (I have a fork of the tool with my notes here)

My New Workflow

Now, here’s how I roll with my documents:

1. Slap a Label: Every new document gets the next number in line. No guessing games.
2. Scan and Upload: I scan the doc, upload it to Paperless-NGX, and it’s in the system.
3. Physical Filing: Then, the paper version just goes on top of my physical pile. Easy to find with its number if I ever need it again.

This setup has made my life a whole lot easier. No more digging through folders or wondering where I put that one bill. It’s all there, a search away in Paperless-NGX.

Wrapping It Up: Living the Organized Life

Switching from a chaotic pile of folders to a neat, numbered system with Paperless-NGX felt like a huge win. If you’re tired of playing hide and seek with your documents, give this method a shot. It’s pretty laid back once you get the hang of it, and you’ll wonder how you ever managed without it. Plus, you get to feel a bit like a librarian with your very own indexing system. Who doesn’t love that?

The story? Yeah, it’s in there somewhere, but good luck finding it. It keeps getting swallowed up by this jungle of words. And let me tell you, it’s not even that great of a story. In fact, it could’ve been told in a fraction of the pages. But no, we’re treated to this never-ending maze of verbiage instead.

The writing itself is a bit odd, especially when we venture into the simulated “souls” in the virtual world. Those characters speak in this archaic, overdone high fantasy language that feels totally out of place. And get this—they draw inspiration from Norse, Greek, and Judeo-Christian mythology, which they just assume the reader to understand.. I mean, cool, but it’s done in such an obvious and random way that it just doesn’t make sense. The virtual world, which should be the heart of the book, ends up feeling forced and unconvincing. It’s like, come on, give us something to believe in!

Towards the end, we spend almost all our time in the virtual world, and guess what? It turns into a typical, run-of-the-mill Quest fantasy with a weak and predictable ending. Talk about a letdown!

Overall, I hate to say it, but it feels like Stephenson wasn’t giving it his all. It’s like he was going through the motions, throwing together a mishmash of parts that don’t fit well. It’s a shame because we all know he can be a fantastic writer when he wants to be. Unfortunately, “Fall; Or, Dodge in Hell” isn’t terrible, but it sure isn’t a masterpiece either.

Individually the “parts” offered a very interesting premise which could have been a story unto themselves. The hoax’s propogated by the internet and then believed in by certain demographics. The idea of Ameristan, the idea of “souls” living in a digital world. All very interesting, however I was very much left wanting.

Rating this one? Well, I’d say it’s a solid 2.5 out of 5 stars.

Scott Hanselman wrote a blog post about how to set this up, and it’s a pretty easy process. Basically, you just need to create a webfinger file for your domain and add it to your site.

The webfinger file is a JSON object that contains information about you or your service, like your email address or URL. You can also include links to your social media profiles or a brief description of what you’re all about.

In my case, I’m running this site on GitHub Pages, and the tricky part is getting the webfinger file accessible from the well-known URL on your domain. By default, GitHub Pages doesn’t serve up files or directories that start with a .. But fear not, my friend! You can use the _config.yml file to override this behavior and include the .well-known directory in your site.

All you need to do is add the following line to your _config.yml file:

(for a full list of overrides see Jekylls Configuration Options documentation)

include: ['.well-known']

That tells Jekyll to include the .well-known directory in your site’s output, which means your webfinger file should now be accessible at https://yourdomain.com/.well-known/webfinger.

Once you’ve got your webfinger file set up, Mastodon and other decentralized services should be able to discover information about you and your domain by performing a webfinger lookup. This can help others find and connect with you, which is always a good thing!

So there you have it, folks. Adding a webfinger file to your GitHub Pages site is an easy way to improve your discoverability on decentralized social networks. Follow the steps outlined above and start making some new connections today!