Let’s get this out of the way first:

I don’t hate Docker.

It’s brilliant for deployment.

Containerization is magical.

Dockerfiles are poetry when done right.

But when it comes to local development environments, I dodge Docker like it’s trying to sell me an enterprise Java certification. 😑

This is not a purist rant.

It’s a tired developer speaking from experience.

Someone who’s shipped enough code.

Fixed enough “why-is-this-not-working-on-my-machine” bugs.

Wasted enough hours debugging in container hell to make this a conscious, intentional choice.

👨‍💻 Devs Aren’t Meant to Be Sysadmins (At Least Not Every Day)

Yes, Docker is supposed to “abstract away the environment.”

But in practice, it often ends up replacing simple local tooling with complex orchestration.

Instead of running npm run dev, you’re now dealing with:

docker-compose up --build

And when something breaks?

You’re Googling obscure Dockerfile flags or trying to mount your volumes right for the hundredth time.

You become the part-time maintainer of a container orchestration mess you didn’t ask for.

I’m all for reproducibility - but reproducibility after the dev loop, not inside it.

🐛 Debugging in Docker? No Thanks

Want to read logs in real time?

Want to mount your code without weird permissions?

Want to use your IDE’s debugger?

Cool, now layer in Docker and watch all of that get clunky real fast.

I remember once trying to debug a Python app running in Docker, and I spent more time configuring remotePath in VSCode than actually solving the bug.

The containerized environment becomes a black box.

One more place where state leaks, errors hide, and you end up wondering if the container is even picking up your code changes.

I don’t want to SSH into a container to fix a typo.

⏳ Docker for Dev Adds Latency - Mentally and Literally

Ever tried making rapid changes to code, only to wait for Docker volumes to sync or for the container to rebuild every time?

That dev loop latency adds up - and so does the mental latency.

When you’re deep in flow, the last thing you want is to context-switch into Docker’s abstraction model.

Every layer between you and your code makes iteration feel heavier.

Like trying to code in a space suit.

⚡️ Local Dev Should Be Fast, Loose, and Bare Metal

Let’s not confuse dev environments with production.

Your dev machine is your playground.

It should be flexible, hackable, and optimized for speed and feedback - not enterprise-grade reproducibility.

I want to brew install or apt install, maybe run a quick script, and be done.

If I want to test something experimental, I’ll use a VM, a separate user profile, or even a lightweight container.

But not Docker as the default dev runtime.

⚙️ “But It Works on My Dockerfile!”

Sure, it works in Docker.

But if no one else on your team understands that setup…

or the image breaks silently because of a version mismatch in Alpine vs Ubuntu…

or the container dies because of an unexposed port, then what did we really solve?

Docker doesn’t remove config hell. It just relocates it.

🧳 What I Do Instead

• Scripts > Containers: I write good setup scripts (setup.sh, initdevenv.py) to install what I need.
• Dotfiles + Docs: My dotfiles + README keep things reproducible enough.
• Vagrant / VM if Needed: For heavy isolation, I’ll use a dev VM. At least it’s predictable.
• Docker for Prod, Not for Local: I always Dockerize for deployment - staging/prod builds, yes. - But never for live development.

🐳 When I Do Use Docker in Dev

Okay okay, it’s not all fire and brimstone. I’ll use Docker in dev when:

• I need a DB or service (Postgres, Redis, etc.) - those are clean to run via containers.
• The target prod env requires container parity (e.g., special kernel stuff).
• I’m working with a team that already has an excellent DX setup with Docker (rare).

But even then, I keep my app code outside the container.

I let Docker handle services, not the dev runtime.

Here’s a quick cheat sheet to sum up where Docker shines - and where it doesn’t:

_ The Bottom Line

Docker is great.

Docker is powerful.

Not every local Docker setup is a “mess” - some teams build excellent DX around Docker.

But let’s be honest:

Great DX with Docker is rare.

Most of the time, it’s overused in local development.

If it’s slowing you down, breaking your flow, or making onboarding a pain…

It’s okay to drop it.

Simpler is often better.

A clean dev machine is still a valid stack.

Let Docker shine in CI/CD, deployments, and staging.

Not in your everyday creative loop.

You’re not wrong for wanting your tools to disappear so you can just build.