DEV Community: Etienne Burdet

The one question that made me turn down a job offer

Etienne Burdet — Thu, 12 Mar 2026 09:55:47 +0000

Last month, I went through a full interview process for a tech lead role. It went well — I liked the team and product, and they seemed to like me — until the very last minute in the CTO interview. One question completely threw me off balance:

– Why is it you? I’m not asking about your resume, I’m asking about you.
-Well, I did all [this things…] and the job is what I aspire to do and…
-That’s your CV, and I don’t care what you want, but why should we want YOU?

I was so unsettled that the rest of the interview was an absolute mess. I more or less dodged questions. Something in me just didn’t want to answer that question. It felt wrong. The whole process was most likely screwed at that point anyway, but that interview was so unpleasant that I decided to pull the plug.

At first, you could think: well, this is a good question, no? It shows the candidate has reflexive thinking. It could highlight things beyond the usual: soft skills, personality, etc. It could also show that I can answer “harder”, unsettling questions. It took me a bit of time to understand what felt wrong.

The first thing that helped me pinpoint why it felt wrong was: who can answer this question well? None of the great devs I know would. At best, they’d give something commonplace; in most cases, they would collapse. And I truly believe they are great lead devs. So who do I know that would answer this question well? Bullshitters, of course. This is a godsend for anybody who hired a career coach, looks at themself in the mirror in the morning with a motivational speech. OSS maintainers? The people who will save your production server in the middle of the night? Inspiring, low-key, understated tech leads who will make your team run faster than ever? Not so much.

Then it started to click in my head. Why does this have to be about ME more than my work anyway? I truly think the most important data points are the work I’ve done and what I want to do. I really want my work to speak for itself and if I do what I aspire to, well I’ll do it well and put effort into it, no? I made a huge effort on my resume so that it told a structured story — which the team loved. But I want to share measurable data points: projects I’ve done, technical tests, honest aspirations. Everything else? I can just bullshit my way through it and make things up anyway. And I explicitly didn’t want to mention my trail running training program or snowboard-mountaineering adventures. They’re cheap ways to build yourself a “strong-minded” character, which is totally irrelevant to my job and totally none of your f*ing employer’s business.

Yeah, this was that. Why me? Like, the whole me? From snowboarding to parenting? How I handle emotions, my character? You want my eating habits and sex life while we’re at it, or what? And… actually, maybe yes. Seeing how many people share their training and eating routines on LinkedIn as a way to build their “optimized, entrepreneurial character”, they wanted that. Fuck that. I code, I help other people code, I build web products, and that’s it. Anything else is just comedy around the job.

But this kept getting worse. Isn’t that your job to know if it’s me in the first place? Shouldn’t the technical and product interviews show that anyway? There’s one kind of C-level executive I hate: the kind where you come to them with a question they really have to answer themself — that you escalated for a reason — and all you get is: “Well, you to tell me.” THANK YOU FOR NOTHING. It really smells like I’m going to have to do their job, while they’ll be judging me, and I’ll have to prove myself constantly rather than focusing on my work.

So I decided to pull the plug. I could have waited for the answer as a data point, but I just didn’t have the heart. Maybe I was defensive, maybe not. That’s not the point in the end. The very fact that the discussion was so different between the team and the CTO was a smell anyway. The whole thing opened my eyes to a few other red flags as well.

So what to think of all of that? Well, I have a strong belief that interviews are just as likely to validate the interviewer’s biases as they are to reveal the truth about the interviewee. As such, a question can tell more about the interviewer than its answer can tell about the interviewee. That was the case here, and maybe that’s a good thing in the end. When you hire, just be sure to ask questions that show who you are too, as an employer.

Origninally published on The Couloir

There's something off in the "dev with AI or die" narrative

Etienne Burdet — Tue, 19 Aug 2025 20:34:41 +0000

It's everywhere, it's eating up every other dev topic debate: learn to dev with AI or you'll be replaced. As a dev, I can't help but feel threatened by these claims. Way more than I should.

I mean, I love hacking around with the new cool toy as much as anybody. I use code assistants all day long, from Cursor tab to RefactAI. I felt so clever when I automated ticket creation with Jira MCP with full codebase and commit history knowledge. I felt not so clever when my "instant" refactoring took me a full day to review and rewrite to fix "just that little bug". I love automating my work as much as the next dev, but I also love to measure the results of automation.

So when big names come up with dull articles about the "4 levels of dev with AI" which is that close to "top 5 agents to pop up a unicorn out of thin air in 2025", I feel something weird. They use code assistants dozens of times less than I do, yet they see "evidence" of a total world transformation I don't even see the beginning of in my day-to-day use.

Where is the collapse of LLM reasoning? Where are the small models winning in the end? Where are the control groups? Show me the data, I'll believe you. Where are the failures too? I've experienced more than one, surely you have data about that too if you're a big tech CTO, no? And then again, why prophesy so much before having the data? The natural move would be to train your team, maybe even a bit secretly, then outperform everybody and finally brag once you have secured the win. Right?

There must be something else.

"Something else" is often money

The first obvious reason is of course to have people burn billions in LLM tokens. This kind of narrative is really effective with C-levels who aren't really using it daily. It make them feel they are losing ground on a huge competitive advantage and they'll force their teams to use LLMs for everything.

There is a nice side effect: you get social experimentation for free. I mean, hacking around commands, cursorRules and CLAUDE.md files is fun, but really the final product will have most of it baked in. But people are doing it for free—nope, people are paying to do that! They are running the experimentation at scale while burning tokens, documenting failures on the way. How convenient for an LLM provider?

And last but not least: hype drives capital. Meredith Whittaker puts it better than anybody:

Now, that a token dealer overhypes their product, I get why. That other "big money people" would be so eager to buy it that they wouldn't run A/B testing or measure gains? There's a bit more than FOMO or paying rent forever to an LLM provider. When I hear "Most of your code will be written by AI", I can't help but hear "now I own your means of production, so you better keep a low profile".

The good ol' dehumanization dream

How many times have we seen a desperate look from a PO, customer or designer that says "But, it's just a form, why is it that hard? You lazy devs will invent anything to avoid working". Because, we are a bunch of unmanageable weirdos aren't we? Sometimes I wonder if I don't ship software just to prove I'm an uncontrollable smartass. Why do we always have an obscure HN link that makes our CEO's "big vision" fall flat? Why is there always one of us to run a script proving financial forecasts are wrong? Why do we keep inventing squads and guilds and chapters and epics? Can't we just sit—not STAND—at our desks and do as the boss says?

Now, if you're managing a lot of devs, I get the temptation: "I have a big vision for humanity—that incidentally makes me rich and famous, but that's not the point—AI transforms that into a polished product". No more "what about… ?", no more pushbacks. No more human messiness. And if humans are not happy, the "big boss" can now close the precious token tap and give it to someone else. This would be much simpler, right? This would be all too tempting to make the devs more replaceable, more interchangeable, wouldn't it? Truly, I find it hard to ignore the power dynamics behind all of that.

It's a pattern we've seen before, from the Luddites to mines, from silk workers to the automotive industry or agriculture. With any wave of automation, there's also a shift of power that gets pushed. Whether it's wages, whether it's unions, whether it's outsourcing, there's often a power struggle that goes far beyond the actual productivity gain. And power is where we believe it is, right? (Yes, I'm totally citing Game of Thrones as the top of my philosophical references).

Be careful what you wish for

For the sake of argument again, let's admit that AI indeed replaces a good part of "the work". Now let me put a caricatured problem to emphasize things. We have two teams designing the same product. One is business school only with zero tech or design knowledge and automates engineering and design with AI. The other one is a group of hacky devs and UX who will automate PPTs, marketing and C-level jobs. Who do you place your money on, honestly?

Fun fact, there are only two things where I'm sure AI is saving me a lot of time as of now: writing tickets and doing large searches. Claude Code (or Goose) with Jira MCP is excellent at writing tickets from messy feedback and looking in the codebase to see if the workload is OK. Perplexity can save me an afternoon of searching with excellent links I could never have found. Large code refactoring though? Some of them "worked", but I'm still unsure if I spent more time reviewing them and eliminating dead code than I would have writing them from scratch.

And then, what if in the end we only need very small local models, called by pretty sophisticated agents that are a lot of regular code? What if it's pseudo-code to code models, transformers or SyntaxGuidedSynthesis that wins? Why do we need "Language" models, if it's autonomous anyway? Or is it? What if writing a specialized agent for your codebase becomes a required skill? Kimi K2 or Devstral aren't that far away, we don't need an expensive Claude to grep and make todos, to name only a few things.

At this point, I think we just don't know what "AI for dev" means. We don't know "how much" and we don't know "what kind". I have zero clue which approach will work or not, nor at which magnitude. What I see though, is that there's one narrative that's pushed way harder than the others. One where devs lose power and buy tokens by the billions.

How convenient, because in many other narratives there are teams of 5 hackers disrupting giants on the cheap, like early Rails days on steroids.

What's the sane approach then?

If authoritarianism is bourgeoisie being scared, then what to think of Sam Altman being scared by GPT-5 and doing whatever he can to convince your boss that you're gonna be addicted to his tokens? Maybe he is more scared for his job than for ours. We don't have proof of either, but this should at least be explored, right?

In this light, the skeptic developer crowd is absolutely needed. We need to have some people not budging until the product is actually good with proven gains. They are the reference against which we measure, the control group. Early adopters should be outliers, not the bulk of the market. This is how we develop good products in the first place and why we don't like it forced on us. The urge to push an unfinished product feels dubious to us at best and rightfully so.

The sane approach is just to stay curious, test and measure. You're a hacky enthusiast? Fine, build some agents and test them. You're a pragmatic skeptic? Totally fine as well, don't use it until it makes your job really faster. We need to know that too. I totally understand that a large company would run an A/B test of teams with and without LLM tools and measure the output. I don't understand why they would force the results if it's really efficiency that is at stake.

All those prophecies really make me think that it's not only efficiency that is at stake though. It's shifting people's perception of where the power is. But remember, if a "visionary" CEO fires you to be replaced by AI, don't forget to run Claude on your full company folder and ask it to make the slides, financial projections and OKRs for the quarter. Whether you email that to them as a middle finger or keep it to yourself to spin up your own thing is up to you. Just note that maybe it's not you who's been replaced by AI in the end.

Cover is Waterfront by Joseph Kaplan

The best TS utility ever. EVER!

Etienne Burdet — Wed, 04 Sep 2024 13:44:51 +0000

So enums are dead, right? Long live the as const:

const ODirection = {
  Up: 0,
  Down: 1,
  Left: 2,
  Right: 3,
} as const;

// It requires an extra line to pull out the values
type Direction = typeof ODirection[keyof typeof ODirection];

But it's verbose to type. So here comes my uber-intelligence. Brace yourself, you might not be ready for it. Here we go:

export type RecordsValue<O> = O[Exclude<keyof O, undefined>]
// ...
type Direction = RecordValues<typeof ODirection>;

Incredible.

Like if you want it to be part of native TS and save the planet. Or at least boost my ego. And of course feel free to share any improvement, I'm sure we all have it in our codebases somewhere ;)

Choosing a static generator for our Code library. And the winner is…

Etienne Burdet — Fri, 27 Nov 2020 14:49:45 +0000

This article was written with the help of my two co-workers: Nicolas and Fred.

Lately at work, we decided to move our code library (old version) to a new tech stack. Up until now, we used our data platform to mimic a CMS: we had a dataset (in JSON) where fields were our site’s content. It was a fun use case and we could leverage some in-platform functionalities, but it quickly grew impractical. The flow to add new articles was clumsy and complicated, the "dataset" we produced was useless as such, and, most importantly, we had little to no preview of the content before shipping to production.

The code library we wanted to build is pretty simple: read-only content with a live demo of what you can do on the Opendatasoft platform and some code for you to copy. This sounded like a perfect fit for a static site generator. So off we went to choose one!

What we needed

The ability to quickly add pieces of content with very similar formatting, including adding blocks of HTML and CSS code with text descriptions around it. We favored MD, but WYSIWYG was also an option.
Be able to copy the code to clipboard and edit it on Codepen
Have a quick dev mode to correct typos with a live preview, without having to re-upload everything.
All sorts of filters by sections and tags, as well as a search field to find resources.
Simple hosting. We didn't want our DevOps team to set up complex deployment pipelines for a side product like this.
The only front-end framework—if any—should be React. The frontend of our platform and some soon-to-be-released wrappers are already using React. We didn't want our users to have to load two libs, neither did we want to scatter knowledge internally.

So let's see our contenders of the day!

Gatsby: pure overhead 🙅‍♀️

You've read React and Static Generator: you're thinking GATSBY. You're thinking it so loud I can hear you from France!

Well, no. When I saw this kind of boilerplate for rendering Markdown, I didn't even bother trying it. Gatsby might be extremely useful for large editorial sites with many sources (e.g. fetching from a headless CMS and social sources) and complex UI. However, for primarily rendering Markdown on simple templates, it felt over-engineered. (Why people use it for blogs is beyond me…)

The wrong assumption here would be to think that because our site would include “some React”, JSX had to be our main templating language. However, we may really only need to render React components, nothing more. For this, we could just include the lib in the header and the JS files for the components in our assets,, and we would be just fine. It's not because you use a little React for rendering that your site is React SPA.

While we really needed markdown files to be as easy to add as possible, our UI needs were really simple.

NextJS (Nuxt, Sapper, Gridsome etc.): Same conclusion, but it might be more obvious since it is more "app" oriented… or at least more marketed as such.

Sphinx, Slate, mkdocs: not enough templating options.

Some of our docs use Sphinx and Slate and I have used mkdocs before. They are excellent tools. They might not be all new and shiny, but they work.

The problem is—which is part of their strength as well—that they are geared toward very specific layouts. The more you want to diverge from it, the more painful it is. Sadly we had to diverge quite a lot.

11ty: the challenger 🥈

I was very excited about 11ty. It seemed simple enough and very flexible, with good filtering abilities. The ability to choose your templating language and folder structure was also appealing. Sure, it also came with that simple config.json which would have probably grown into a new lifeform of its own—as they always do. But fair enough, let’s try anyways.

Yet, in my test, I realized with that freedom—e.g. in your folder structure—comes the freedom to botch up. For example there are many ways to implement internationalization: folders, file extensions, etc. However, my colleague and I came up with different solutions for the same thing. While it suits the little choices you have to make everyday, you will have to make sure you document conventions for your colleagues. This can end up being pretty confusing as everyone will start using their own clever tricks. Other brilliant ideas, such as template cascading, fall into the same trap.

The second thing was performance. Live reload wasn't fast on a test site. I can only imagine what it would have been on hundreds of resources with a variety of assets. I also had to ctrl+c much more often, e.g. for any config change.

Overall, 11ty seemed fun, but too brittle. I will definitely tinker with it on personal projects. For professional use though, the risk of being stuck in a dead corner seemed too big.

Hugo: solid win 🏆

Hugo isn't new or exciting. But it's fast, it does everything we need, it's stable, it's alive, tested and proven. Taxonomy? Tags? Built in. Speed? Lightening fast. Markdown support? World class leader. JS? The pipe is fast and reliable. Got a problem? Somebody probably had it before you and likely there is a solution hanging around on the Internet.

While it may seem a bit rigid at first, there's hardly anything you can't do easily. You have to conform to the Hugo way of doing things though, especially in your folder structure. In our case, that was a blessing. Sure, you have to learn it, but there is a single source of truth and it is documented.

Go templating may seem a bit alien and inelegant at first, but it's easy enough to learn. And while I still find it slightly inelegant, it is very efficient. Years of trial and error have made the team add quite a lot of functions. Really, it's hard to find something you can't do with Hugo.

Making your templates and archetypes is straightforward, as well as maintaining them. We have been able to easily build a system where, from a single source of html and css, the code to read and copy is generated, the result rendered in an iframe and the user given the opportunity to open it using codepen.

Now along with the *.html.inc and *.css.inc files (.inc because they are not meant as standalones), we only need a single file such as this one in the same folder :

---
title: "Dropdown module 1"
---

## Basic example

A very basic HTML so that you can see how the component works and to be able to edit it easily.

The result is this, with all the options to copy to clipboard or go edit with codepen:

As you can see, once you have good templates and archetypes, it's straight to content. We had over 50 resources to migrate and the process was overall quite smooth.

Additional libs

Search

We tried both fuse.js integration and Algolia for search. Fuse works excellently, but you do have to redesign all your search boxes from scratch and, more importantly, define all the weighting and sorting yourself. So we went with Algolia, although we ended up doing a decent amount of redesign on top of it. Still, it works more automagically than fuse.js.

CSS framework

Bootstrap v5? Tailwind? Nothing? That last option was quite attractive. However we didn't want to implement all kinds of boring components from scratch (such as tabs, accessible buttons, etc.).

Bootstrap still came with quite a few libs to load and is quite monolithic. Tailwind's tooling is quite complex and, as quick as it may be to build with it, I had serious questions about maintaining code build this way.

In the end we went with Bulma and couldn't be happier. It's pure CSS, very simple and extremely well-written. The fact that it's tuned with global variables was the killer feature for us: our designer gave us specs (from a design system) and we could implement it quickly and make the whole site very consistent.

We liked Bulma so much that we are beginning to inject it into other projects!

Van11y

One major concern was accessibility, especially for Nicolàs! Components such as tabs, modals or show/hide functions can be quite long to implement l. We could have rewritten everything ourselves following best practices, but the more JS and CSS you add, the more complicated it gets.

Fred found quite a nice library with http://van11y.net/. It's not rocket science, it's nothing we couldn't have done ourselves. We were even a bit dubious at first because it is almost five years old! Can you imagine that? Yet it works and its pure ES2015. The reason why it has never been updated in the last five years isbecause, well… it works.

Check it out, it's pretty neat!

The breakdown

I love tinkering with techs, libs and apps on my personal projects. You break things, you re-build, re-break etc. There is nothing at stake besides learning and having fun. Yet it was the first time I had to do this professionally and the stakes were quite different. Our resource site is nothing critical, it's not the end of the world if some CSS breaks: we can hotfix it. Yet, I didn't want it to become a burden, consuming bandwidth, for me and—most importantly—my colleagues, everyday.

Hugo, Algolia and Bulma might not be hot or “groundbreaking, but it's an excellent choice for this reason. It's nothing we can brag about during coffee breaks. There is no clever solution we had to develop that will give me some DEV street cred'. But we were able to save valuable time. During development, Hugo practically disappeared. We spent very little time searching for"how to do this in Hugo" and we spend the vast majority of our time actually building the website. This sentiment was only reinforced when I had to leave for one month. When I came back, everything was running smoothly, with no complaining about the tech stack.

There is a second lesson here: our solution involves very little JS. Resources on the web tend to involve tons of JS—because there is a big audience for click-bait Build this app in 10 easy steps tutorials. Yet, for content-first sites, it can remain minimal and it is possible to build very modern websites without transforming your node_modules into a black hole.

So ask yourself twice: do I have complex UI needs? Am I overwhelmed with state management? Do I need to fetch data from multiple services? If the answers are no, no and no, Hugo is as solid as it gets–and probably more!

You can visit our new Code library and see the code on github !

I am not at ease with open source asking money for american associations. Are you?

Etienne Burdet — Tue, 02 Jun 2020 20:27:04 +0000

Today, I was asked if I wanted to give money for american associations supporting justice for african americans on https://webpack.js.org/ and this very DEV. And I must say that that I had a strange feeling about it.

Don't get me wrong here: I am 100% behind the cause (feel strange to have to state that, but I am not taking a chance).

No, my problem is, I never saw any such emails or banners when families are randomly blown away by drones in Pakistan or when the Filipino police slaughtered people in the streets…or anything else outside of the US. Yet there are open sources contributors, users and readers from these countries. So what message is sent here? The open source community has been doing great toward internationalisation and superbly inclusive code of conduct. But all of a suden, I felt I was told that some nationalities were weighting more than others.

So what are your feelings about it?
Do you feel that it is too american centric and we might be losing audience and contributors? (like I do)
That, sure it could be more equal, but doing good in the US is better than doing good nowhere?
That well, if opensource main maintainers and community leaders are americans, then it is only normal that their voices are more heard?
That it is just to not the place anyways, whatever the cause and country?
Anything else?

I am sincerely curious to know.

🙏 Please, be sure to double check your answers and wording. It is a topic that has a quite more consequences than semis in JS. But I think it is a matter to be discussed 🙏

Three months into my new job: an honest review of Le Wagon bootcamp

Etienne Burdet — Sun, 31 May 2020 19:17:07 +0000

Haha, Bootcamper!

Yeah well, hello there! Nice to meet you too.

I indeed attempted Le Wagon bootcamp last winter in Paris. Before that I was an engineer in sustainability for buildings and urban planning.

I had many ideas to improve my job that implied some sort of web apps: solar access maps, land use sustainability calculator… those kind of things. I though they were much more impactful than PTTs—not to mention apps seemed to be much more fun to build. Everybody was keen on it and I tried to learn on the side, but it always resulted in super clunky projects, never really working, never finished.

So felt I had to give web development a real chance. Two month for real, with mentorship seemed to be all that I needed. Spoiler alert: it was.

Woh 7000€! You kidding?

Ok, let's do some quick math here. Nine weeks of five days, we are down a bit more than 155€/day. Most professional trainings sold to companies are sold somewhere between 300€ and 1000€ per day and are absolutely nowhere near the quality. Hiring a high mountain guide in a small group will cost you between 100€ and 200€ per day. Definitely not crazy numbers at all. I mean you have to pay people at some point.

Now, I had a very decent engineer job, but with the training I made a net +600€/month that's only likely to increase faster than before. That's an return on investment of less than 10 months. Find me any investment that yields more than 100% per year!

Last but not least, I was fully subsidized anyways. In France we have access to fundings for these trainings that cover for the cost of the bootcamp and my salary during it (!). So I had pretty much free lunch here. The staff is very helpful in trying to get you all the subsidies they know of and try to get the bootcamp financed if you are motivated.

I understand you have to get that money out of somewhere and that might not be possible for everybody. People who need such training the most are probably not the one with enough money aside to get it. That's the very sad thing about it. But you can hardly blame Le Wagon for that.

All things considered, it's quite a fair price for what it is.

Seems to be a lot of hype around the startup/digital nomad trends…

It's a lot of code wrapped in a bit of hype. Just enough to get you pumped.

The "it's more than code" punchline is somehow true, but can be misleading. You get to meet a lot of entrepreneurs and people with all kinds of ideas. You discover the Basecamp/Github way of working. You get to work you ass off, in cool and relaxed environment. You get to work on super close deadlines while having fun and never being stressed. There are more events, party, drinks, yoga and crossfit classes than you can probably attend.

For a lot of people—me included—all of these extra are quite important because it raises the bar as to what work should be. Once you have experienced this kind of working conditions, there is no way back to bullshit management and powerpoint nonsense, working crazy hours in a glass building. It's definitely part of the product they are selling.

Yet don't be fooled, it's coding six to eight hours a day. Everything else is bonus, but the core is coding web products. If you are there to get a startup holidays or just look cool with a MacBook, you'll spend a disappointing amount of time scratching your head in front of a terminal.

I want to be a dev, I don't want people on startup holidays slowing me!

While it's true some people come more out of sheer curiosity than anything, most have a career plan in mind. And even if, I have not seen a single person not doing its best to participate every day. In my project group we had a guy who was over 60 and certainly not looking for a developer job afterward. Still, he did his share of the work and never was like "let me enjoy my holidays".

You have people with all kind of backgrounds, all kinds of experiences, both among the campers and the teachers. This raw diversity of skills, ages and genders is really great, especially at a time of your life where you need some fresh ideas on your job.

I am an entrepreneur, will I have a startup full of investor cash startup after?

Well, no. It's a coding bootcamp, not a startup studio. Is this bootcamp still for you? Depends.

If you are the kind of entrepreneur who wants to build their product with their own hands, yes definitely. You will learn everything technical thing you need, you will have opportunity to pitch (your product or another), you will meet fellow entrepreneurs. One would say the bootcamp was ultimately made to bootstrap 100$ startups out of nowhere. Although, once again, it's code you learn, not marketing, accounting, PR, management or HR.

If you are the kind of entrepreneur who thinks his job is the raise to money to have other peoples do the work, you'll be disappointed. Not only Le Wagon's culture is overall cautious toward raising funds too early—if at all—but it is a coding bootcamp.

I think a few people have found their co-founder at Le Wagon, during or after their batch. It's not guaranteed, but it's not a bad place to find like minded people at all.

Meh, there are tons of free courses on the internet anyways. I can learn on the weekends.

Yup, see you in five years, when your hundredth unfinished side project will join the "learn to build [banal app] with [shitty framework]" graveyard.

Where to even start with this one?

First, Le Wagon staff is not stupid, they know people try to learn on the internet. So the prep' work you have to do before the actual bootcamp are free courses on the internet (Codecademy free tracks on Ruby, HTML, CSS and JS) and then you build on those basics. I would dare say that people who tried to learn a bit by themselves are the core target of this bootcamp and represent roughly 30% of the campers.

I'll get into more details as why, but still the structured learning path is in another league compared to anything I've seen for free on the net. The precise schedule is also key here. It makes sure that everyday clicks into the next one and it remove any sort of questioning on what you should be coding. You have much more brain available for coding this way.

Then you have all the "in person" a*nd the *"get together". You can ask any question, any time to a teacher whenever you feel stuck, you learn to code together and you learn when it's time to stop coding for the day and relax to be on top the next day. The social part not only is required to code professionally—you have to know how to code and ask questions in teams—but it helps a lot to keep the schedule and rhythm.

The internet wants you to think it's a matter of short tutorials. I tried and failed there quite a few times. And yet I have learned countless softwares by myself, from making maps for Quake 3 to making scripts for Rhino in my last job. I went from couch to running 50k/3500m+ in less than two years— training 6 days a week and losing 30kg in the process. I am not bragging, but just saying I can get motived at times and I have learned things by myself (and so can you!).

Yet learning a job is not learning a hobby. It is very unlikely that you learn as much as fast all by yourself. I have nothing but the deepest respect for people who are self-taught well rounded devs. But for me—and I think a lot of people—the boost provided by the bootcamp was more than needed. I would still be stuck kluging useless code without it.

Still, it is open to anybody, it must be pretty easy

Ooooh, be careful there. I had been doing a bit of programming in other language (scientific stuff) and I had tried to learn web dev' before. Heck, I already had my own site powered by Hugo, my own Ethereum smartcontract and I had "learned Vue"®. On top of that, I have always been quite good at school (again for the facts, no pride there). Should be a walk in the park, no?

Well, doing all the exercises everyday was quite a challenge, when I could do it all. The first ones are always basic applications of the day's concept. But then you quickly go into more complex katas, deeper OOP and MVC concepts. Try to write a class that count how many subclasses inherit of it without googling, you pros! Harder than you remembered, hmm? That was a second week exercise.

The last optional exercises are often pretty open ones. Like building a small game (snake game, space ship game etc.), building your own ORM, building some landing pages, wikis, jukebox etc. The more you do on these the better, but you're unlikely to be "done" there.

As for projects? Sky is the limit and they will only grow bigger, from one day mini-app (which is quite challenging), to full weeks of group code, where not only everything is possible, but you are vastly encouraged to go beyond the platform app.

Truly, there isn't a single day where I didn't learn something.

Woh, that sounds pretty hard after all. I am not sure I can do it.

Pretty much anybody can. I know they insist a lot on the fact that it is "super intensive". Don't get discouraged by that. It's more to tell people that it's not holidays, but it's nowhere near the kind of crazy work to get into top universities.

Then again, all the exercises are very progressive. There is something for everybody every day. The basics will get you through the essential concepts. And I've seen pretty much everybody doing their share of work during the projects.

Just expect a good eight hour day of training every day and you will be fine.

So the course is THAT good? From what I remember, classes have never been that great…

Yes, the track is really, really good. I still teach a bit at the university and the track is nothing like the PPT put together the day before by some graduate student who is obviously more into science than into teaching (totally not me, I'm saying for a friend).

The big difference with other academic or professional training is that the course is a real product, refined over the years and the batches. They put into a nine week program the same amount of work you would put into a SaaS product or some high end holidays camp.

You learn with a really great web platform as a companion tool too, with all the exercises, classes, products, videos, resources, auto validations for your exercises, some quick test for refreshing your memory etc. It's really neat and all tailor built for the course. Again, nothing like what I have seen on the web. I still use it on regular basis to find resources, go back to some classes.

On top of that, everything is planned like it's you're in some sort of high end sport camp, both for the coding and all the other parties, drinks, conferences, demos etc. You might frown upon the relax part and yoga classes, but it is very important to get some time off screen if you want to be on top the next day and Le Wagon is really good at that.

There is also a full-time person dedicated to career and a full week for that after the bootcamp. You could call that customer success. Laugh at the wording, but very few professional trainings do that and again, it shows the spirit.

Really nothing is left unattended. It's do one thing and do it well. Nothing like I have seen before.

Are the teacher as good as the course?

Mostly yes. Especially the more experienced teachers who are really good at giving some insights, while keeping everybody focused on the day's course and leave other questions for the next day. As I mentioned, a big advantage of the program is to weed out unnecessary questions and so that you can focus only on the most essential things.

It was a bit different with the less experienced teachers, although it was mostly OK. They didn't provide as much insight and are more prone to making mistakes. Some were harmless like "Bootstrap is made by Twitter", some slightly more problematic like "webpack is a server".

This a recurring problem with the scaling model of bootcamps. You need new teachers who know the course well to expand. Your best source for that are fresh grads who lack both a bit of industry and teaching experience. Nothing that ruins the experience or the training, though.

There was one exception to the overall great teaching: the JS teacher. He is a nice guy, but teaching is definitely not is thing. From the very helpful "it's this way because it's this way", to the endless anecdotes and missing some pretty important concepts (scoping, reference to functions vs. their evaluations etc.), this made for quite confusing days. The JS part being already quite short, this had some people just plain give up on JS.

One very important aspect, is how helpful and friendly the teachers and assistants are. I have never seen anyone being looked down with contempt, feeling dumb or inadequate because of a teacher. They really do their best to keep every single person motivated and this makes for a very nice atmosphere where we all try to get the best out of everybody.

During the project weeks, they also really, really work their ass off to help your group land a nice demo. It's really impressive to see how much they care about your project like it's their own.

Now give me some tech! What do you really learn?

You mainly learn to do all CRUD operations in an MVC pattern and use that to implement user stories using the github flow.

You will learn to model your data, pull it to your model, decide how to route actions, process things in your controller and display things in your views. And you will do that a lot. You learn a bit about model, you play with it the terminal, you make a small controller and mix all of that together. And some SQL, mix together, rinse, repeat. And some front-end, mix together, rinse, repeat. Add some Sinatra, rinse, repeat etc. etc.

You will loop on every single part of the architecture until it is literally part of your brain. All of this culminating into Ruby on Rails app living on Github, to help fit all the pieces togethers.

Now this the one thing I was lacking from trying to learn alone. Not Ruby on Rails, but truly learning a solid architecture and good design patterns, leaving no dead spots: data modeling, routes structure, where to write which part of the code. It is a lot of pieces of puzzle to find out and it is a lot of work to put them all together—when I could even find the pieces.

I also want to stress that I am really, really happy with the coding style I learned both for Ruby, CSS and JS. Your learn to experience very clean code and maintainable code and aim for nothing less. I recently took the PWA course from Academind. The concepts were OK, but the style and structure of the app got me tilting, really (deep nesting leading to unreadable var names, global vars for states, reimplementing your own iterators…). I learned to expect more.

This is typical internet solo learning: get fast to one precise feature, but at the expense of everything else. And then you are left with brittle app, that falls apart when you try to change a tiny bit of it. That's the difference between learning to build that one app or that one feature and learning the foundations to build any app or features—and to learn to learn the missing parts.

With solids basics, you can move to pretty much anything: new MVC frameworks, add some front-end technology, learn new paradigms etc. You can, but maybe you won't even need to, because with CRUD (and a bit more) in RoR, there is an awful lot you can build.

Whatever training you choose, definitely favor product, software architecture and clean code over any fancy technology name.

Ruby? LOL! Gimme my React!

If you say so… but I've learned to love—and miss—Ruby 😇And no, it's probably not React you're after.

True to Le Wagon bias toward building products, you learn to spend as few time as possible on the code for shipping as much product as possible. And on that topic, Rails freakin' work. It's the typical thing to build a start-up on and for good reasons.

Rails brings you ton of autonomy in every district of the code. It is a framework in which you can truly be full-stack. Lots of other hyped technologies will take care only of one part (often the front end…) and you will be left out tinkering with how to model and fetch your data, do secured operations etc. Rails makes sure you take care of everything.

The Rails ecosystem reflects that spirit and is much more sane than the I don't need paradigms and design patterns, just give me my npm packages! state of modern JS. Really, I am glad I can think outside of JS.

Which leads me to my second point: no, it's learning React you want, as it probably won't make you ship more finished, functional apps. What you're after is most likely good, modern basics s in CS, design patterns and software architecture. Again, Rails is not the main thing you learn, it is just tool that helps you implementing the MVC pattern and an excellent one to do so.

Le Wagon knows most people want to make functional app over learning any precise technology. It is actually quite a bold move by them to resist the temptation of stamping "React" all over their flyers and to stay true to their belief that Rails is both great for learning web dev and shipping products.

Oh and by the way you get a free React course as a bonus, should you need it.

Still that's not a lot of JS…

And on that I would agree. It's a hot and difficult topic about Le Wagon's track, probably one of the main source of complaints afterward.

On the one hand, your learn just enough to be dangerous. JS in Le Wagon's track is reduced to animations, hide show stuff etc. and add some useful packages (maps, calendars etc.). No state management, no routing or all that jazz. Plain ES6, precisely written and refactored, in a well structured webpack app. There is a long way you can go with all of this. It truly is a blessing that the scope of JS is actually reduced to the bare minimum, as the thing has tendency to spill all over the place for no good reasons.

On the other hand, I have seen teacher assistant—often fresh grads—being stuck with an npm package because they were trying to use an arrow functions in a place where proper function scoping was needed… and they had no idea what scoping even was. Now you can get quite some way in JS without caring about prototypal inheritance, but calling yourself professional fullstack with knowing virtually nothing about scoping, this and asynchronous code in JS… ugh 😫! It is very unlikely you won't encounter any those in a doc somewhere.

All in all, the few JS I learned, I learned it well and I am super glad I wasn't trained only in JS. Still I could have used a bit more. The problem is, there is only so much you can fit in nine weeks. So what would I trade for more JS? That I don't know and I am glad I am not the one making these compromises 😛

You need ten thousand hours to be a master. You know nothing Jon Wagon.

Fuck that rule, really. First the real rule is ten thousand plus or minus ten thousand hours. Then, you don't need to be a master to do a good honest work. You don't need to be Michelin three star to open a successful restaurant or be an olympian to be a great sport teacher. There is just an unlimited amount of simple and useful work to be done in web development, even if you don't have "that special part in the brain to understand pointers and recursion" (moron…😞).

Most importantly, it is misunderstanding the real benefits of the program. The important thing I learned at Le Wagon is what it really takes to learn to ship a product/feature, that is both useful and well written. Now, I have a lot of bells in my head that rings "Too much data manipulation in the front, let's look at the model", "Those routes are a mess", "My files are too long, not in the right place", "Waaaaay too much time on tooling, let's build things", "That code seems ugly" etc. etc.

I know infinitely better how to balance my effort between learning a library, integrating it with into a workflow with the right tooling, fitting it into good design patterns and then freakin' ship product with it (answers: very little, just enough, quite some time, a fucking lot).

Recently I had a simple but quite interactive UI to build that made POST request to an API, so I decided to go with Svelte and little Node.js API for proxying. I think spent on 30mn learning the syntax, the equivalent of a whole day for tooling and refactoring my codebase and a full week to ship the actual thing. But more importantly, I instinctively knew when it was "good enough" and how much effort I should put on which part*.* Well written modern code definitely is one strong point of Le Wagon and that will be an advantage from day one at work.

Judging by absolute level at the end of the bootcamp is also totally misleading. It is not like it puts you there, at a given skill level and then you stop learning. Quite the opposite. It's more a matter of setting you on the right track than getting you somewhere. Le Wagon is a just pinch in your whole career. But a pinch in precisely the right direction and that's what was very important for me.

You can really make apps after just nine weeks?

Yes, definitely, but just know that it is more websit'ish than app'ish.

The typical thing you learn to build is an Airbnb clone, where people can login, post stuff, rent stuff, pay, see stuff on a map etc. That's the basic everyone knows how to do in full. After that, you are encouraged to go as far as possible beyond the platform app. Some of the best projects included speech recognition and auto-correction on the fly, small "click" games, beer recognition with your smartphone etc.

The typical thing you don't learn to do is making your own google map or video player (I mean actual engines), games with physic etc.

The bootcamp is really not geared toward mobile either. That is really a drawback here. With the same technology it wouldn't be hard to design for mobile first and add the tiny bit for handling offline (quite a few project are on mobile though). Especially since the whole program is quite good on UI.

Now don't get me wrong here. Since the iPhone, everybody wants to make apps and website seems like thrown out of the 90s. **But there is an awful lot you can build with a good dynamic website (ebay, amazon, google, airbnb…) and it is real software by all standards.

So everybody is coding and has jobs after?

Meh.

Linkedin has been on fire in the few weeks after the bootcamp and since then, so jobs are not a problem. Coding…

Out of more than forty people of my batch, only six of us have regularly pushed code to Github since the end of the batch. Maybe some have changed account or are on Gitlab/Bitbucket… I doubt it and not possibly that many. Some might be stuck back to doing tutorials on their, but that's definitely not what we were taught to do.

I have a gut feeling that a large part—and I am deliberately vague on numbers here—hasn't shipped a single line of code since the end of the bootcamp. And the Linkedin updates I have are only fueling this feeling, with most people having product and growth jobs. But quite a few (six I know for sure, so probably a bit more) are already coding professionally.

That's puzzling and I would have excepted the opposite. Since a lot of people are at a turning point of their career, that they would need time to think and time to refine their skills would only be natural. That you stop building things when you learned to, when you absolutely have the skills to and you have projects to work on as teams is more of a mystery to me. Really, I have no explanation (nor real numbers).

You can hardly blame Le Wagon for that. We were told countless times to keep coding and to ship features in group rather than learning new technologies.

Yet don't get me wrong, you will only find super happy people who loved their times at Le Wagon and don't regret it a single day. You will also find lots a good devs who have been through the bootcamp.

So? Jobs: asbolutely. People: very happy. Github: mostly empty. Deal with that…🤷‍♂️

Le Wagon, Le Wagon, Le Wagon…

Yup, it's a commercial brand. They know how to sell themselves and they definitely want the word of mouth to be spread. So you will hear "Le Wagon" a lot. It comes with a few advantages, especially on satisfaction: people better be happy with what they get for the price or the thing will quickly run out of business.

Usually, I am also not so keen on school corporatism (I always hated the happy few elite life of french engineering school). Here the raw diversity of backgrounds keeps things fresh and make for quite a nice community and also a very welcoming and open one. There are tons of jobs offer shared, help on code or career, you can easily find freelance to work on projects etc. I surprised myself here, attending some events once in a while and even liking it!

And while this alumni life is fun when you found a job, it is quite essential when you are in between your bootcamp and finding one. You can come work at the place with other people (at a very moderate price), you can work a bit as an assistant teacher or just come and say hello at the events. You are not left on your own once it's done and I never felt "Your paid time is over, bye". Quite the opposite.

So no it is not some sort of open source collective or non profit, it is a commercial start-up. One with great people and a nice community around it.

So what you're doing now? Do you have anything to show.

My official title is Technical Project Manager at Opendatasoft. In practice I implement small apps on top of Opendatasoft platform, usually one pagers with a bit of logic to display datasets. It comes in either in full blown front app through our API or with the Angular widgets the dev team makes. My job typically involves some sort of mini-product design—although I have also implemented design specs.

I have been building a lot of COVID-19 dashboards for our clients (like this one or this one). I have also built some boilerplate for an offline first app, so that we can store results of our API calls for offline use. I have been toying around with scrollytelling as well or building SPA around our API (which, for one, is a very valid case of using SPA !).

I got the interview for the job three days after the end of the bootcamp, was confirmed that I had it three weeks after that and actually started the job less than three month after the end of the bootcamp (time to finish my previous job, mainly).

I am loving it so far and things are building up to get really exciting 🤞

You happy? 🤷‍♂️

Yeah! 😊

I did a move that was in my head for so long and I am not even slightly disappointed (which is disappointing, I like to be snobish about my situation). Now I am in a company culture and an everyday job that fits me much better. It gave me a fresh start and so many opportunities.

Couldn't be happier!