Fancy Code Is Not Good Code: Why I'm Choosing Boring on Purpose

Let me start with a confession: I have written code that I knew was harder to read, purely because it felt cleverer. Not because it was faster, or safer, or more correct. Just because it made me feel like a better engineer in that moment.

I'm fairly sure I'm not the only one. Most of us have done it, and we do it more often than we'd like to admit. This post is about that habit: where it comes from, what it costs, and the one question I now ask myself before I commit something "smart."

The Urge to Look Smart

There's a quiet pressure in this field to prove you know things. You pick up a new language feature, a new pattern, a new one-liner, and the first instinct is to use it somewhere. Anywhere. A dense line of code feels like evidence of skill. A plain, boring one feels like you didn't try hard enough.

But that's backwards. Anyone can write code that's hard to understand. The real skill is writing something complicated and making it look obvious. When I read code that's easy to follow, my first thought isn't "this person is basic." It's "this person respected my time."

My Favourite Offender: The Unnecessary Ternary

The ternary operator is where I catch myself the most. Don't get me wrong, ternaries are great. When you're picking between two values, they're often the best tool for the job:

// Choosing a value: the ternary earns its place here.
const label = count === 1 ? 'item' : 'items';

That reads naturally. One decision, one result, one line. No one has to think twice.

The trouble starts when I reach for the same tool for something it wasn't built for. Instead of picking a value, I'm running actions, and I cram them into a ternary anyway, because it's shorter and it feels slicker:

// Technically valid. Slightly annoying to read.
isAdmin ? console.log("This is already an Admin account") : await db.user.update({ userId: user.id, role: 'admin' });

And here's the same thing written the boring way:

if (isAdmin) {
    console.log("This is already an Admin account");
} else {
    await db.user.update({
        userId: user.id,
        role: 'admin',
    });
}

It's longer. It's also instantly clear that this code does something rather than produces something. A ternary tells the reader "I'm computing a value here." When there's no value being used, that signal is misleading, and the reader has to pause and work out why it's written that way. I knew the if/else was easier to read. I still wrote the ternary. That's the whole problem.

The Moment It Got Called Out

What made this click for me was an ordinary code review. I'd been going back and forth with an LLM about some code I'd written, and one of its notes stopped me. It said:

I swapped the ternary for an if/else, since using a ternary just for side effects is harder to read.

And it was right. I had used a ternary purely to fire off side effects, with no value assigned and nothing returned. No good reason for it, apart from the fact that it looked compact. It was one of those small, slightly embarrassing moments where someone (or something) points at a thing you already knew was a bit silly.

What stuck with me wasn't that the tool caught it. It was how plainly it explained why: not "ternaries are bad," but "this particular use makes the code harder to read." That's the right way to think about it. The question was never whether a feature is allowed. It's whether it helps the next person.

The Same Habit, at Project Scale

This doesn't stop at single lines. It scales up into how we start projects. You've seen it, and so have I: a simple page that could be built with plain HTML and a little CSS, and before the first line of real work, someone has already run npm install react, picked a router, added a state library, and set up a build pipeline.

Frameworks are not the villain here. React, and tools like it, solve real problems at real scale. But a handful of static pages doesn't have those problems. What it does get is a dependency tree, a build step that can break, upgrades to keep up with, and a longer onboarding story for the next developer. You've taken on all of that cost to solve a problem you never had.

A few questions I try to ask before adding anything to a project:

• What problem does this solve that I actually have today, not one I might have someday?
• Could plain HTML, plain CSS, or a few lines of plain JavaScript do the same job?
• What does this add that someone else will have to learn, maintain, and update?

If the honest answer to the first question is "nothing yet," I try to wait until it isn't.

Write for the 3am Version of Someone

Here's the mental model that changed how I write code. Picture someone opening this file at 3am. Something is broken in production, they're tired, they're stressed, and they don't have the context you had when you wrote it. They don't want to admire your cleverness. They want to find the problem and go back to sleep.

And a lot of the time, that person is going to be you. Future you, months from now, has forgotten the clever trick and the reasoning behind it. All that's left is the code and a vague feeling that past you thought this was a good idea. I've been on the receiving end of that, and I was not grateful to the person who wrote it.

Code is read far more often than it's written. Optimise for the reader, because the reader is usually future you.

This Isn't an Anti-Cleverness Rule

I want to be careful here, because the lesson isn't "never use advanced features." That would just be a different kind of dogma. Ternaries are the right call when you're choosing a value. Frameworks are the right call when the project genuinely needs them. A clever solution is sometimes the only way to solve a hard problem well.

The point is to be honest about why you're reaching for something. There's a simple test I use now:

• Am I doing this because it's clearer, or because it feels impressive?
• Would a teammate who didn't write this understand it in one read?
• If I came back after six months, would I thank myself or sigh?

If the answers point toward clarity, go ahead and use the fancy thing. If they point toward ego, write the boring version.

What I'm doing differently

• Using if/else when I'm running actions, and saving ternaries for choosing values.
• Starting small projects with the simplest tools that work, and adding to them only when something starts to hurt.
• Reading my own code back the next day, as if someone else wrote it.

At the end of the day, the best code isn't the cleverest code. It's the code that does its job, stays easy to change, and doesn't make a tired person curse your name at 3am. I'd rather be that engineer than the one who looked smart for an afternoon.

If you're building something and want a second pair of eyes on how to keep it simple and maintainable, get in touch.