Also, while it's nice that Xavier Niel finances a school that is free, most of the universities and Grandes Ecoles (where many developers graduate from) are also free, and financed with public money. They work great and produce really skilled developers and architects.

The reality is that Xavier Niel didn't do a Grandes Ecoles, he's mostly self-taught. When he started to succeed in the telecom industry other companies, full of alumni from Grandes Ecoles didn't see him with a good eye because he didn't have the pedigree (and didn't hire many of them either). So he has a grudge about the Grandes Ecoles system, and creating a school with private money is kind of a middle finger to them.

I don't know where you last got your information about Epita, but this has been less and less true for around 10 years now.

They sought to have a state certified engineering degree for a long time and implemented a lot of changes around 2003-2007 that made the cursus a bit less about code a more about common engineering stuff (maths, physics, english, ...) with more structure (they structured classes with a credit system, made more standard student evaluations, ...)

Source: graduated in that era, been in touch with later students.

Even if it's true that Epitech us mainly about coding, the program enforce a coding standard that is a huge part of the final grade of each coding project (small functions, 80 char per line of code...). Fom the second year, components decoupling and basic design patterns are part of the program.

Nevertheless, the school doesn't really make the most to teach basic good engineering practices or at least I don't remember (doc, tests, vendoring, observability...) and this is one of the main pain point.

Niel did not come from the traditional path of the elites (Polytechnique Paris, Centrale, etc.).

He was self taught, and god forbid, earned money through minitel porn. The aristocracy considers him, well, gross.

Their CVs should be findable on the public internet.

Yeah, no. 42 was modeled on Epitech. If EPITA was about "code, code, code", why did Sadirac leave and founded Epitech and 42 ?

I believe this is a good method for beginners. A beginner doesn't need to think much because he/she doesn't have the material/experience for that anyway, but instead just practice as much as possible. Later, he/she will reflects on what he/she think he knows and get a more structured / professional work.

Wait 6 months or 1 year, and you've given them time to gather sufficient experience for motivating a more mindful way of working.

Wait 3 years or more, and you've just taught them bad habits.

I'm tired of interviewing candidates who were supposedly trained extensively in programming, asking them "how do you approach making quality software?" and hearing the usual "oh, I indent my code and write a lot of comments" as an answer.

I've been to a "regular" university and I'm pretty sure I said some variant of "I write lots of comments" w/r/t my code maintenance approach in a very early interview. I could have written any algorithm you gave me -- but I had no idea what maintaining an application with users entailed.

My experience is you can't really "teach" writing maintainable code beyond just having people fix bugs for 6 months in a million-line codebase that's reasonably well written.

You could write 100% functional code that handles every edge case you could think of, and you could still get a B- on an exam for not using the 'Design Recipe.' While frustrating, the students do emerge as 'junior SWEs' with a grasp on how to design organized, efficient, and complex programs themselves.

People should learn this mantra: coding is to software development what moving pieces is to chess.

And on a more serious note: I really like this mantra, but I do not think it's true or relevant:

There are many examples of success stories of what you would call "coders": Gates and Allen's Altair Basic and Zukerberg's Facebook are the famous ones - but I would argue that many software related business are also a product of "coding" and not "software development". See also WordPress or Wikipedia as examples. "Coding" is very important.

Software development is a very wide subject. The driving force of schools is mostly economical - training developers to fill a huge demand on this huge market. The thousands of open jobs require different sets of skills - and again I will argue that a high percentage of these jobs will allow a (very) junior developer to build good products as long as he knows to "code" and he can be managed and mentored by a senior developer. Being able "to code" will be a hard requirement for these jobs. Simple examples would be web and mobile development. enterprise/huge software projects. "Coding" can get you a job.

And, as I wrote in my other comment above, "training software developers" is not the same as "developing software". There are many ways to train developers - and where to start from and how much time it takes are good questions. Assuming a year (or 3-4 years) in college is very expensive and not accessible to anyone who can and want to be a software developer, finding other/more/different approaches to enter the software industry is needed. "Coding" is an eligible trailhead for starting to learn software development.

AFAIK, when teaching kids chess, the best way to start is teaching them how to move the pieces.

Knowing how to move the pieces is a foundational piece of information, but without the understanding of the theory of the game it's useless information.

Perhaps a closer (nitpicky?) metaphor would be running to basket ball.

It's clearly important to be able to run well above average but trying to get to sprinter/marathoner levels has little to no benefit. Especially if it's at the expense of other skills like shooting, jumping, reflexes, etc.

If the real underlying problem/solution is a shape too big to put in your head, what do you propose? Pen and paper as superior to code for modelling things?

I wrote "think about what you're doing".

It comes through in the code, it's messy, there are entire classes and functions that are never used. The logic is all over the place. The code is messy to look at. There are edge cases that haven't been handled.

Well engineered code I should be able to look at understand what the developers thought process was as he was writing it.

I've seen a Dev write a piece of code, that wasn't that big, maybe a few hundred lines then later that day he couldn't explain how it worked in a meeting. Even going through his code line by line he couldn't follow what was happening.

If he can't follow what is happening in his code or explain it coherently, how can anyone else!

And it was because he dived into coding something without thinking.

That said the opening year they let people try student challenges and they were brilliant. Tiny and principled, out of the box thinking, mostly relying on creative and critical thinking.

Anyway, there's a need for patience driven cursus :)

I can manage large business requirements, I write functional specifications and negotiate them with users, I plan technical architecture... And then I'm happy enough with programmers who need hand-holding at every step - anyway my telco employer has long stopped having budget enough to pay contractors who understand our business.

Pure programmers may be short sighted but they provide the value some of the market needs, for people such as me who are decent analysts and exceptionally bad programmers - learning the latest Javascript framework is a dirty job but somebody's got to do it !

That's just not true, the main reason being that if you're not programming any more, how can you define a modern technical architecture? If you don't know the precise technical limitations, how can you negotiate functional specifications?

Engineering is Engineering, whether it's IT systems or bridges

Knowing one's limitations is key - I certainly won't get in the way of implementers. But functional requirements do drive some architectural decisions and spotting them upstream helps, for example once the conceptual data model and typical query usage are defined, one can decide whether the contractor one sends a purchase order for needs to grok graph databases or relational ones.

I do advocate a high-low mix with fewer people and a higher proportion of the higher tier, but the purchasing department loves low unit prices and has decision over them. Well, at least we have the developers co-located with us in the same office and no longer work with offshore Indians through two layers of intermediaries... Progress !

I do not understand this. What does "culture of piscines" mean? I assume it's not literally pool culture.

This is to encourage the "get shit done" mantra of these schools.

It wouldn't directly teach them to think before writing, but they might learn the downside of failing to design the program structure well, and the pain of refactoring. It would be hilarious to give them back one of their early projects and slightly change the (marketing) requirements... (then require functionality can't be broken for testing more than X min-hours), just like real life. They'd learn they ARE the jerk writing unmaintainable code.