From the stage to the code editor

Before writing a single line of code, I spent years working in festivals and tours. Technical production: one more cog in a machine where a hundred people who don't know each other have to execute the same plan at the same time, without the audience noticing a thing.

When I got into development I thought I'd have to learn everything from scratch. And partly, yes. But what surprised me most was discovering that the hardest part of the job — which isn't the technical part — I already knew.

Talking to people who know things you don't

In production you're one specialist among specialists. The sound engineer knows more about audio than you. The lighting tech knows more about lights. Nobody expects you to know everything, but they do expect you to understand enough about each area to do your part well and not get in everyone else's way.

In a development team it's the same. Product understands the user and decides what to build. Infrastructure knows the real limits of the system. Design knows what makes visual sense. Your job as a dev is to do your part well within that context: write code that reflects what everyone agreed on together. If you don't listen well, you end up building the wrong thing perfectly.

Trust as infrastructure

At a festival, the event works because each person trusts that everyone else will do their part. Not because someone controls everything, but because the goal is clear enough for each person to make good decisions within their own area.

Development is no different. A team that works well — product, infra, dev — doesn't need anyone hovering over everything. It needs everyone to understand where they're going and move in that direction.

The real problems show up live

No matter how much you plan, the dress rehearsal is never like the actual show. What you learn after enough unexpected problems isn't how to avoid them, but how to stay calm when they happen and communicate clearly in the middle of the chaos.

In development that means fixing a critical bug in production or pushing through a last-minute change before a release. The situation is different. The pressure and the skills you need are exactly the same.

I changed industries, but I didn't entirely change jobs. I'm still a technician inside a team, still managing uncertainty, still trying to make something complex look simple from the outside.

The difference is that now problems get solved over Slack instead of through an earpiece. And I can stay home when it rains.