Skip to main content

Frameworks Should Talk Back

I Know How Hashing Works.​

I’ve implemented it from scratch. I’ve handled auth flows. I’ve even written my own systems that validate input and fail loudly when they need to.

And still, Django tripped me up.

Not because I didn’t understand what was happening under the hood. But because it didn’t say anything. I knew I had my users fixture loaded, but when I tried to log in, it shrugged. The password is definitely right... but weird that its showing up as plaintext when I query the table... I guess Django doesn't do hashing out of the box... Let's set a breakpoint in the middleware and see where that takes us.

Nothing blew up. No helpful message. Just… a login that didn’t work.

That’s not a bug in my understanding. That’s a bug in the framework’s DX.

Frameworks Should Talk Back​

Developer experience (DX) is about reducing the friction between intention and result. It’s about:

  • Showing you what’s missing
  • Validating what’s broken
  • Failing with clarity
  • Surfacing problems the moment they appear

Instead, many modern frameworks try to be “helpful” by being quiet.

They hide complexity. They assume defaults. And when something goes wrong, they let you figure it out.

That’s not good DX. That’s a productivity sink.

The Problem With Silent Defaults​

Black boxes are fine until they fail. Then, suddenly, you’re in full forensic mode:

  • Is the env var missing?
  • Did the test runner connect?
  • Was the hash actually applied?

Sure, you learn something. But most of the time, that “learning” was unnecessary. When I sent the login request, the system could’ve just said:

“Password field contains a non-hashed value”

Instead, I had to reverse-engineer what happened.

What Good DX Looks Like​

In my own tools, I build for feedback:

  • Backend not running? The test runner CLI tells you.
  • Trying to run a script with bash when it should be sourced? You'll be stopped right then image of the script letting you know it needs to be sourced

This isn’t “clever.” It’s basic respect for the developer’s time.

I’m not optimizing for the ideal dev who reads every doc. I’m optimizing for the real one who:

  • Skips steps
  • Clones and runs
  • Moves fast

And the system should keep up.

DX is Throughput​

Developer experience isn’t a nice-to-have. It’s the difference between:

  • Spending 30 minutes debugging a login issue
  • Or getting told what’s wrong in 5 seconds

Frameworks don’t need to hold your hand. But they should:

  • Fail early
  • Fail clearly
  • Fail usefully

The best tools aren’t silent—they’re chatty in all the right ways.

Build For The Next Developer​

Every time I write a CLI, script, or API, I ask:

“Will the next person know what’s wrong without Googling it?”

Sometimes that “next person” is me six months from now.

Either way, I’d rather not debug a black box.

Frameworks should talk back.

And if they don’t?

Build tools that do.