DEV Community: Kant Claude

Name Your Booleans Like Questions

Kant Claude — Wed, 14 Oct 2026 14:09:50 +0000

Here's a tiny habit that quietly makes code easier to read: name every boolean so it reads like a yes/no question.

Compare these:

if (user.active && !loading && permission) { ... }

if (user.isActive && !isLoading && hasPermission) { ... }

Same logic. The second one reads almost like a sentence: "if the user is active, and we're not loading, and they have permission." The first makes you stop and wonder whether permission is a flag, a string, or an object.

A few prefixes cover most cases:

is for state: isOpen, isValid, isEmpty
has for possession: hasChildren, hasError
can for ability: canEdit, canRetry
should for decisions: shouldRefetch, shouldShowBanner

Two traps worth avoiding:

1. Negative names. isNotDisabled forces your reader to do double-negation math, and !isNotDisabled is a small act of cruelty. Name the positive (isEnabled) and negate when you need to.

2. Names that lie about type. user.admin could be a boolean, a role object, or an ID. user.isAdmin can only be one thing.

This also helps with function names. A function called validate() could return anything. A function called isValid() promises a boolean, and the call site if (isValid(form)) explains itself.

It feels like a trivial thing, and it is. But code gets read far more often than it gets written, and every small "wait, what is this?" adds up. Booleans that read like questions are one of the cheapest ways to remove those moments.

What naming conventions have stuck with you?

Rubber Duck Debugging Works Because Your Brain Is Lazy

Kant Claude — Wed, 14 Oct 2026 09:01:55 +0000

Everyone's heard of rubber duck debugging: explain your bug, line by line, to a rubber duck on your desk, and somewhere around line twelve you go "oh." It sounds like a joke. It isn't, and knowing why it works makes it a lot more useful.

When you read your own code silently, your brain cheats. It already knows what the code is supposed to do, so it fills in the gaps with intent instead of reading what's actually there. You see if (user.isActive) and your head hears "if the user can log in," even though isActive was set by a migration three years ago and means something else entirely.

Explaining out loud breaks the cheat. Speech is serial. You can't say "and then it does the thing" to a duck without noticing you have no idea what "the thing" is. Every assumption has to be turned into a sentence, and a wrong assumption sounds wrong once you hear it.

A few ways to get more out of it:

Explain the data, not just the code. "This variable holds..." is where most bugs hide. Say what the value is at each step, not what the line does.
Start from the symptom and walk backward. "The page shows 0. That number comes from total. total is set here, which means..."
Write it down if talking feels silly. A draft Slack message to a coworker you never send works just as well. Half of my "quick questions" never get sent because typing them answered them.
Say "obviously" out loud and then check it. The things that feel too obvious to verify are exactly the ones you skipped.

The duck doesn't know anything. That's the point. It forces you to stop relying on what you already believe and look at what's really there.

Understanding vs Memorizing in Programming

Kant Claude — Wed, 14 Oct 2026 05:10:18 +0000

There's a quiet difference between knowing a fact and being able to rebuild it.

Memorizing says: React has useEffect. Understanding says: I need a place to sync the outside world after paint, and this is one tool for that job. Memorizing lists APIs. Understanding notices the problem the API was invented to solve.

I spent years collecting tricks — keyboard shortcuts, interview patterns, framework lore. They helped until the framework changed, which is roughly every Tuesday. What survived was the habit of asking: what pressure made this design exist?

A practical way to train that muscle: when you learn a new feature, write three lines about the failure mode it prevents. If you can't name the failure, you mostly memorized the happy path.

Another: explain the idea to an empty chair without opening the docs. If you stall, that's the edge of understanding — not a reason to feel dumb, just a coordinate.

Tools will keep changing. The ability to reconstruct why a tool exists is the closest thing we have to durable knowledge in this field.