One of my first jobs was as a security guard in Belgium. I was quite into sports at the time, particularly Penchak Silat with Fred Mastro. I remember training with one of his bouncers who was also my instructor – he was surprised by my stance, despite me being 20 kg lighter and 10 cm shorter than him.
I was slim and young, not really the standard physique of a bouncer. It wasn't always easy, believe me. I worked at the Bunker, a nightclub that has since gone bankrupt. One evening, a much more imposing guy suggested we "step outside" – What a genius. My solution? Let him go first, invite my colleagues over, and close the door.
These not-exactly-academic experiences taught me things that, oddly enough, apply perfectly to my job as a developer. Here are the five most important ones.
1. Rely on the right tools to stay vigilant
No one can stay on high alert 24/7 - it's just humanly impossible. The solution? Use systems and tools that compensate for our limitations.
During my security guard nights, I quickly understood that working smart was better than working hard. It's the same when I code. Instead of pretending I can control everything manually (good luck with that!), I use code analysis tools, automated tests, and monitoring.
It's not laziness, it's humility. True expertise isn't about doing everything yourself like a superhero, but knowing which tools to deploy to create a system more efficient than a single developer could ever be – even after drinking liters of coffee.
2. Continuous learning and networking are essential
I quickly realized you can't know or anticipate everything alone. When you're facing a group of ten tipsy guys, believe me, you appreciate having colleagues and their experiences.
What really helps me with bugs and technical challenges isn't some mystical ability to foresee everything, but my network. I continuously learn new things and exchange with seniors who have already faced the same problems.
I participate in developer communities, and I don't hesitate to ask for help. In security as in development, lone heroes usually end up failing – and often spectacularly.
3. Communication is complex but essential
Perfect communication is like the perfect bouncer or perfect code: it doesn't exist. Despite all good intentions, misunderstandings are inevitable when human beings talk to each other.
The worst was really handling the last drunk patrons leaving, I developed a more methodical approach. Sometimes, persisting in explaining the rules to an intoxicated client is pointless. Better to de-escalate and come back later – or find another angle of approach.
What I appreciate in development is the empirical approach. Understanding how people actually use technologies, rather than imposing my geek vision on them, changes everything. It's like understanding why this client absolutely wants to enter with muddy shoes rather than simply blocking their entry.
The important thing isn't to always be right, but to be authentic. Each interaction is a moment of sharing, even when things go sideways.
4. Knowing when to say no is more important than adaptability
"Be flexible," they say. "Adapt yourself," they repeat. But I've learned that knowing your limits is much more crucial. Saying I can adapt to everything is false and pushes us into situations we don't want.
When you manage the entrance, if you let everyone in to be "flexible," you create chaos. In development, it's the same. Boundless adaptability extends deadlines, dilutes quality, and leads straight to burnout – I've seen it too often.
I've learned to say no. No to certain projects. No to unrealistic demands. No to impossible deadlines. I can't do everything, and pretending otherwise would be lying. I prefer to be honest about my capabilities and deliver quality work rather than playing superhero and crashing mid-flight.
This transparency about my limits has paradoxically strengthened my clients' trust. Like in security: "see those two there, don't let them in?", "okay, Pierre, why?", "they're little shits", "Okay, guys, you can come in, thank Pierre ;)"
5. Service humility before visibility
Here's a surprising revelation: being visible doesn't automatically create trust. In fact, in a nightclub, the bouncer who shows off too much often causes more fights than he prevents.
I understood that it's not my visibility that matters, but my ability to put my ego aside. Projects belong to the client, not to me – even if sometimes their ideas make me internally roll my eyes (like absolutely wanting a parallax effect on their nail salon website).
Being present doesn't mean bombarding the client with updates to show that I'm working. It's being available when necessary, listening to real needs, and sometimes knowing when to step back. Like when you're monitoring a room: you're not there to attract attention, but to ensure everything goes well.
This service humility has become one of my most valuable skills. My role isn't to be the star, but to make the project shine.
Conclusion
These five lessons from my not-exactly-conventional journey have shaped how I work. They remind me every day that technique alone doesn't make a good developer.
It's not superhuman vigilance, but the right tools at the right time. It's not solitary expertise, but networking and mutual aid. It's not perfect speech, but authenticity in exchanges. It's not saying yes to everything, but knowing when to say no. It's not putting yourself forward, but serving the project with humility.
In the end, moving from the Bunker to code wasn't such a big leap. In both cases, it's about creating spaces where people can enter, navigate, and leave with a good experience – without tripping over the carpet.
