Show me an architecture no one questions, 
and I’ll show you a system no one understands.

A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.
The architect? Well, he was calm. Unbothered. Certain.

“It’s not the design,” he said.
“The team just didn’t implement it properly.”

There it was: the dead giveaway. He wasn’t doubting the design. He was defending it like gospel.

Right then, I knew.
The most dangerous architect isn’t the one who lacks answers.
It’s the one who never asks questions.

If you’re an architect or becoming one, doubt isn’t your enemy. 
It’s your sharpest tool.

Consulting rule #1: Smile, nod, and translate chaos into meaning.  
Rule #2: Don’t let your sarcasm show.  
Rule #3: Break Rule #2 when appropriate.  

Trying to be client-friendly while carrying a sarcasm habit is like juggling flaming swords in a library: impressive if it works, disastrous if it doesn’t.

This is my daily dilemma: I’m in a customer-facing role, but my personality leans dry, cynical, and borderline allergic to buzzwords. I can steer through three political minefields per call and blueprint clarity from chaos, yet it still leaks out like House M.D.’s smirk when calling out bullshit.

A few years ago, I took a week off. First vacation in months. On day two, I got six Slack messages, three “urgent” calls, and by Wednesday, the team had spun up a new feature that killed the application’s performance like a toddler on an espresso overdose: fast, chaotic, and entirely unsupervised.

That’s when it hit me: I hadn’t built a system, I’d built a babysitting job.

errorless (adj)

Free from error, accurate, correct. Being complete of its kind and without defect or blemish.

Walk through enough architecture reviews and you start recognising a specific shape of failure. The system isn’t wrong. It’s too right. Every edge case has a handler. Every failure has a fallback. Every component is wrapped, secured, and isolated from everything else. The development cost is enormous. The operational cost is worse. And when the requirement changes, which it always does, nothing moves.

I’ve been wondering how to celebrate this milestone. Because yeah… today marks exactly 20 years since I hit “publish” on my very first blog post — April 18th, 2005.

That post? Honestly… it was bad. A clumsy “hi”, a confused tone, and zero clue about where I was heading. It was a start.

But hey… here we are. Twenty years later.
Still blogging. Still writing — even if what that means has changed a lot over time. I guess it’s time for a little reflection.

I was never into the whole American dream thing. Even as a kid, something about it felt… off. I couldn’t quite put my finger on it back then. But as I grew up, it became painfully clear: their values, their way of life, their self-image; it just never clicked with me.

Satya Nadella said up to 30% of Microsoft’s code is now written by AI . If the software is writing itself, what happens to the people who design the systems it runs on?

I’m rarely optimistic (the curse of architecture, I guess), but I feel safe.

So there I was, 8 years old, dragged to the shopping center by my dad because, apparently, shopping for socks is a family event. We’re walking through this temple of consumerism when—BAM!—I spot a computer showroom. Not just any computers. MSX/Sakhr machines .

If, after quitting your job, you hear or get notified about your ex-leader doing these :

1. Speaking negatively about your departure
2. Undermining your decision by criticizing you, your new role or company
3. Attempting to make you feel guilty
4. Spreading resentment throughout the organisation
5. Taking the resignation as a personal attack
6. Prioritizing their own interests over those of the team
7. Being absent or unavailable for the team during the transition
8. Spreading gossip about you
9. Delaying or writing vague performance appraisals or recommendations for you
10. Displaying an “it’s all about me” attitude
11. Failing to acknowledge their own mistakes or shortcomings
12. Blaming others for failures or problems within the team

These behaviours scream insecurity, selfishness, and a lack of confidence in building and retaining talent. They crush team morale, erode trust, and send a clear message to the rest of the team: ‘You’re disposable too.’

Back in 2014, I was at a meeting with a prominent French bank about a challenging project. At the time, “low-code” was a fresh concept, and the bank aimed to build its own low-code IDE to let business analysts craft UIs and speed up delivery.

The team already knew each other from previous projects, so introductions were a formality. Our manager introduced everyone: “This elegant lady is the delivery manager, that serious gentleman is the team lead…”
When he got to me, the bank’s IT manager interrupted, winked, and joked, “The guy’s doing nothing!”

We laughed sincerely and moved on.