I Don't Want to Be a DevOps Engineer

There. I've said it.

I'm a developer. I write software. I like writing software.

I don't particularly want to spend an afternoon working out why one Docker container can't talk to another—only to discover a third container has decided it dislikes the network.

And yet, sometimes it feels as though that's where we're all heading.

Just let me use WAMP

For my own development, I use WAMP.

Yes: WAMP.

Apache. MySQL. PHP. A little configuration. Done.

I can create a project, drop it into my www directory, create a database, point my browser at localhost, and get on with writing code.

No container. No YAML file. No virtual network. No Compose file to decipher.

More importantly, no 45-minute detour before I can start work.

I know WAMP isn't fashionable. I'm okay with that.

Docker has its place

I understand Docker. I've used it professionally, and I understand why teams rely on it.

A team may have dozens of developers using different operating systems, versions of PHP, databases, dependencies and machines. Docker provides a standardised environment. That's valuable.

If I join a project, run one command, and suddenly have the whole application running in the same environment as everyone else, that's brilliant.

That is exactly the problem Docker solves well.

But when I'm at home, working alone on my own projects, I don't necessarily have that problem.

I'm one person. I want to run some PHP.

And WAMP does that.

The complexity tax

Docker is often presented as making development simpler. For teams, it often does.

For an individual developer, though, it can introduce another entire layer to understand: images, containers, volumes, networks, ports, Compose files, environment variables, permissions, logs and mappings.

Then something breaks, and you're left wondering whether the issue is your application, PHP, Apache, Docker, the image, the network, the volume, or a configuration change you made three months ago.

At that point, I ask a simple question:

What problem am I actually trying to solve?

This isn't anti-DevOps

Docker is useful. So are AWS, CI/CD pipelines and infrastructure-as-code.

I wouldn't want to go back to manually copying files to a server and hoping I hadn't forgotten anything.

For a team, proper infrastructure matters. For multiple environments, automated deployments matter. For a production system handling serious traffic, scalability, reliability, monitoring and repeatability matter enormously.

I'm not arguing against any of that.

I'm arguing against the idea that every developer needs all of it just to write code.

Simple can be better

There is something satisfying about a simple development environment.

I turn on my PC. I start WAMP. Apache starts. MySQL starts. I open PhpStorm and write PHP.

That's it.

No orchestration. No local cluster. No wondering whether a container runtime has decided to have a bad day.

Just code.

Maybe that sounds old-fashioned. Perhaps I am resistant to change.

But I've learned something over the years: complexity is not automatically progress.

Sometimes we get very good at solving problems we do not actually have.

Use the right tool

Modern development gives us incredible tools: IDEs, AI assistants, automated tests, Git, cloud platforms, package managers, containers and infrastructure automation.

They can make us vastly more productive.

But they can also turn building a simple web application into an elaborate stack before we've written the first meaningful line of code.

If displaying “Hello World” locally requires multiple containers, a reverse proxy, local DNS, certificates and a Compose file, perhaps we have missed the point.

Use Docker if it makes your life easier. If you love containers and your entire environment lives in YAML, that's great.

But I'll be over here with WAMP.

When I sit down to work, I don't want to spend the first hour managing my development environment.

I want to develop.

Maybe that isn't DevOps. Maybe it's just common sense.

Either way, localhost is working—and that's good enough for me.