From tourism to IT project manager

Sequence is the DNA Solutions podcast. We spend our days using technology to understand how people behave; in this show we do the opposite, and try to understand the technology industry through the people who actually live in it.

The first episode is a conversation with Sydney De Clercq, project manager and frontend web developer at DNA Solutions. He has been here six years. He was, by his own count, the fourth employee. And he has no computer science degree: he studied translation and interpretation, English and Chinese, then spent five years as a tourist advisor around Brussels' Grand Place before a five-month bootcamp put him in front of a hiring manager.

The conversation is in French. The article below retells its substance in English, for readers who prefer text.

The episode in five takeaways

• A bootcamp's honest goal is employability, not mastery. Sydney gave himself five months to get back on the job market, and the market of six years ago met him halfway. He says himself that window has narrowed.
• His translation degree was not wasted time. Project management is translation work: clients and developers speak the same language but do not use the same words, and most project failures start there.
• Side projects were the real school: a university application platform, an SEO-driven site for a travel planner, even a Pokémon card sorter. Each one taught something a course never covered.
• His take on AI tools is unsentimental: an expert available at every step, fine to trust for execution speed, never for the initial architecture. And vibe-coded systems break precisely where experience would have looked.
• Six years at the same company came down to culture mechanics, not luck: retrospectives every two weeks, fixing the source of problems instead of blaming people, and planning for the 0.1% failure case.

Translation studies were not the detour they look like

Asked whether starting in translation means he lost years, Sydney pushes back. His whole career, as he tells it, is one job: making people who do not share a vocabulary understand each other. Translation does it across languages. Tourism did it across cultures, five years of answering questions in whatever language walked up to the desk. Project management does it between clients and developers, who nominally speak the same language and consistently do not mean the same things by it.

His example is concrete. On one project, the client used three distinct terms: activity, session, event. Three separate concepts in their business logic. The development team merged them into one at the start, and paid for that shortcut for the rest of the project. Sydney's definition of his job is preventing exactly that: checking, continuously, that what the team is building is what the client meant, not what the team heard.

He extends the same idea to code itself. Code, he says, is just another language, a way of laying out logic so a human can talk to a machine. Coming from languages made that framing natural.

What a five-month bootcamp actually buys you

The bootcamp was the Wild Code School, five months, intensive, built for career changers. Sydney is precise about what it was for: being employable at the end. Not knowing everything about software development. Employable. He needed to pay rent, and five months was the time he gave himself.

What it delivered, in his telling, was less a curriculum than contact with the ground. Three projects during the course, the last one for a real client, who used the resulting prototype to go raise investment. A basic tour of the whole terrain of web development, enough to know what exists and where to dig later.

His comparison with the university route is not dismissive, it is economic. A degree spends years on the history of code, the layers of abstraction, the deep foundations. All of that has value, and he says you can acquire it later, while employed. What the market was buying six years ago was people who could start. Tech was hiring juniors everywhere, AI had not arrived, digitalization was accelerating, and companies expected to finish the training in-house. DNA Solutions hired him out of the bootcamp and seniors trained him on the job. Asked if he regrets not doing the academic version, his answer is that the bootcamp brought him exactly where he wanted to be, and that a developer is in permanent retraining anyway. The five-year degree does not exempt you from that; nothing does.

His honest warning to the 2026 candidate

The conversation does not let the story sit as a recipe, and neither does Sydney. Asked what he would tell someone attempting the same jump today, he starts with the uncomfortable part: a large share of junior positions have been conceded to AI, and the junior market is genuinely hard right now.

What survives of his path, in his view: it is still possible, self-taught or guided, and plenty of platforms and schools exist. But the differentiator is unchanged and now unforgiving. Passion, expressed as a trail of side projects. His examples are deliberately small: build something that displays your CD collection, catalogue your favorite films. Not because those projects impress anyone, but because a stack of finished small things is what proof of motivation looks like from the hiring side. Even for motivated candidates with a GitHub full of projects it is hard at the moment, he concedes. His position is that in every saturated market, the people who keep going are the ones who end up through.

The side projects were the second school

The pattern that stands out in the conversation is how much of Sydney's actual competence came from projects nobody assigned him.

Apply Future was the biggest: a web platform centralizing university applications for foreign students, mainly toward French universities, initially for a Chinese audience. Every school asks applicants for the same pile: personal details, language test results, motivation letters. The platform made students enter it once and apply everywhere. Covid stopped the project cold. He still thinks the demand exists.

A travel organizer's website, built for his partner, taught him SEO in the only way that sticks: needing real clients to actually find the site. His summary of the lesson is about focus, deciding what genuinely adds value to the product instead of what is fun to build.

A Pokémon card arranger, never deployed, exists to sort cards by color so they look good framed. He brings it up without embarrassment, which is rather the point: the habit of building is the skill. What each project is for matters less than the fact that each one forced a new corner of the terrain.

Before any of that, there was competitive gaming. Sydney played semi-professional Overwatch as a tank and shot-caller, the player who makes the calls and manages the team's temperature between matches. He describes the job in terms any project lead will recognize: information moving fast, decisions in seconds, frustration management when execution does not match the plan, replay analysis where everyone is sure the mistake was someone else's. He is careful with the analogy, project management rarely needs decisions within five seconds, but the core transfer is real: knowing the whole state of the project, the constraints, the objective, and keeping communication clear when it matters.

Reading between the lines of what clients ask for

The middle of the episode is a compact lesson in why iterative delivery exists. Sydney walks through it from the practitioner side: the agile manifesto is 25 years old, and the method it replaced, waterfall, had clients describe everything up front and receive a delivery six months later. Delivered to spec and rarely satisfying, because between what the client imagined and what the team imagined, the words were the same and the pictures were not. Two people reading the same book do not see the same scenes, as he puts it. Short iterations exist so the correction happens every two weeks instead of once, at the end, when it is expensive.

His best example of what listening buys: a scheduling tool for driving schools. The client's existing planning ran on a Windows program roughly thirty years old, dense information in tiny text, meaningful colors and abbreviations, and to them it was fine, because all the important information was there. The team rebuilt the view, and then delivered the thing nobody had asked for: every field customizable per activity type, so each activity could decide what information mattered on screen. The clients were delighted. Sydney's reading is that clients are focused on one main problem and cannot be expected to specify the quality-of-life layer around it; they do not have the technical vocabulary to know what is cheap to ask for. Proposing that layer is the job.

An unsentimental take on AI, from someone with nothing to defend

Sydney's relationship with AI tools is relaxed in a way the conversation probes directly. He uses Claude for his side projects and describes AI as an expert permanently at your side, on every subject, usable at every single step of a project, either to assist the human step or to replace it.

The boundary he draws is precise. Execution: delegate freely, if speed matters, tell the tool it has the rights and let it make the technical calls. The initial design of a system, the architecture, the founding reflection: never. Confront your own thinking with the AI's analysis afterwards, build from that exchange, but the decision belongs to the human. He cites the cautionary genre of AI agents deleting production databases because a human granted permissions without reading.

On vibe coding, shipping products by prompting without understanding, his critique is structural. Nothing is respected except the visible result, and the result works until it does not. When it breaks, and the AI cannot resolve the problem it created, the owner discovers vulnerabilities everywhere and a system grown too complex for the tool to untangle, with no experienced human who knows where to look. He points at the legal story of the week: both parties in a lawsuit citing AI-fabricated case law, verified by the bar, found to be invented, case dismissed and the lawyers sanctioned. His technical summary: the models are non-deterministic. Nine times out of ten the answer is sound, and the tenth is confidently fabricated. Building anything serious on that without experienced review is the whole risk, and the part of the iceberg vibe coders do not see is exactly the part a developer with a few hundred projects behind them is paid to see.

Asked why his relationship to AI is so untroubled, he offers a theory about his own path: he spent five months on formal training, not five years, so he holds his knowledge lightly. It costs him nothing to say that a given layer of what he learned can now be delegated to a machine, and to move his own effort up a level. He connects it to the phrase teachers always used on him, learning to learn, and to why trigonometry was worth studying for someone who ended up in translation: the subject was never the point. His bet for the AI era is that pure expertise in one thing will matter less than the ability to have touched everything, because the person who has touched everything can hold a real conversation with the machine. He closes on the English proverb: jack of all trades, master of none, but better than a master of only one.

Why he stayed six years

The last thread of the episode is retention, and Sydney's answer has no slogan in it. The company grew from four people to around forty during his time. He gets along with everyone, which he credits partly to the same communication background as everything else, tourists, teammates, clients: exposure to enough publics teaches you that people are almost never acting in bad faith, they have simply hit a problem they had not seen.

The mechanics behind the culture are concrete. A retrospective every two weeks, where the team reviews what went well and what did not. His role at the start of each one is to restate the rule: the goal is to solve the problem at its source, never to assign blame, because a developer's entire day is solving problems, frequently ones they created themselves, and that has to be safe to say. And a project lead who quotes Murphy's law often enough that it became method: whatever can go wrong will, so error handling covers the 0.1% case too, not because everything can be predicted, but because thinking about it is part of the job.

It is a fitting place for the episode to land. The path in was unconventional; the reasons for staying are the most conventional engineering culture there is, applied consistently for six years.