Hacker News Reader

Yes, they modelled it after Epita which was also about code, code, code.

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.

> Yes, they modelled it after Epita which was also about code, code, code.

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.

Coming from Epitech, I would say that you are right. The code, code, code mind is more Epitech and less Epita nowadays.

I've also been through Epitech which is the school that greatly inspired 42 (same founders) and I would like to add some details on top of that.

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.

They have the same rules at 42 to code, 80 columns, 25 lines for a function, ect... Where Epitech is better is that from the middle of the third until the end of the beginning of the five year, you have to work on a end study project. You need to prepare everything before coding, database schema, how will you do your tests, ect.. Even tough I find Epitech better than 42 on this, Epitech is also lacking a lot of things. Some teachers to explain to you the best practices, code review, ect.. would be really nice.

Are you really talking about the EIP?

That totally sounds like gossip to me. I'm very sceptical that "he [created] a school [as a] kind of a middle finger to them".

France is still very much an aristocracy.

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.

I don't think that's the main motive for his creating 42, but he does have a very strong anti-Grandes Écoles bias.

The personal history of the founders totally supports this narrative.

Their CVs should be findable on the public internet.

his grisp against big french institutions is very real and documented. Look at how he started his company Free, telling people that if they stayed at the big telecom companies they were "pigeon".

> Yes, they modelled it after Epita which was also about code, code, code.

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

For other reasons _in addition_ to that one? Many people make decisions based on a weighted linear combination of criteria.

encouraging them instead to rush to the keyboard and emit as much code as they can as if programming for the last day of their project

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.

It really depends on how long you wait before making the students sensitive to these issues.

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 work with a ton of people from Grandes Ecoles and while I think they're generally great coders, certainly as much so as if they'd spent their whole education madly typing as fast as humanly possible, as juniors they're not much better than the "indent and write lots of comments" level.

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.

It sounds like you are expecting junior hires to be senior, instead of training them. The average elite computer science student spends 3 years learning computer science before they start building professional programs.

It depends on the curriculum. At the last place I studied Computer Science, the department was led largely by Matthias Felleisen and Olin Shivers, and the first book they require reading is How to Design Programs: https://htdp.org/2018-01-06/Book/part_preface.html

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.

Meh, I've looked at my code when I was just starting out, and I can still trace my thought process and reasoning behind my code. Sure, there's a lot of mistakes and bad style, but I can tell that even in my first efforts I understood organization and design. Beginners shouldn't be held to the same standards as professional developers, but some guidance in terms of code quality is a good idea.

> To me, this is as silly as training Biathlon athletes to not even aim before they shoot.

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

> 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.

> coding is to software development what moving pieces is to chess.

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

The very next thing you teach them after the theoretical knowledge of how the pieces move is to sit on their hands, to avoid making impulsive moves.

This -- absolutely.

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.

Yes, and chess teachers will tell you, the way to improve as a beginner is through playing many many games quickly to get a wide variety of exposure and start developing intuition.

But most people wont go ahead 1600 elo easily without theory.

I know what you're getting at and it's a good mantra in a 'corrective' sense.

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.

Moving pieces is much simpler though... A lot of graduates of computer science didn't do much coding and are bad software engineers in my view.

Depending on the problem, I disagree with this idea "think before you code". I think /by/ coding, sometimes a problem is too big to fit into my head and if I write some code and try to string it together the code will tell me where my mental concept is missing something.

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 never wrote "think before you code", and agree that's not always the most suitable way to go about a problem, although I believe a lot of programmers would benefit from doing that more often.

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

I'm sick of dealing with code written by people that had no clear thought process before they started coding.

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.

Amen https://www.youtube.com/watch?v=f84n5oFoZBc

Have always been curious if 42 would inherit the "piscines" culture..

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 :)

Development requires analysis and programming. Some people are both analysts and programmers - they are the elite, not the norm.

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 !

Though it is quite common, I think this is a very bad way to organise a business. It's as if programming were bricklaying, a simple operation to be performed under instructions from an architect.

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

> if you're not programming any more, how can you define a modern technical architecture ?

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.

Even without the burden of understanding business requirements, it still takes programmers a fair amount of analysis to program without making a mess that will kill their ability to make progress; learning the latest JavaScript framework does not help at all in that regard. I'm glad to hear you manage, but your employer may want to consider hiring fewer programmers and paying them higher wages - I know a lot of companies would benefit from that.

> your employer may want to consider hiring fewer programmers and paying them higher wages

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 !

> This seems to resonate well with the culture of piscines at 42

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

Piscines are intensive multi-days coding sessions that are predominant in these schools (selection for entry is done with those sessions as well).

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

It equates to (more or less) the method of teaching to swim by throwing them in a pool: swim or drown. In 42's case, it's code something or fail your class, but without any (or much) guidance, mostly in self-taught way.

I think it refers to the culture of the first selection phase which is called 'la piscine'

It wouldn't even be that difficult to have a series of examples of developing tests, cleaning up, trimming down, and debugging other people's code. Almost all of the classes I took didn't allow collaboration, even though that's probably the most important working use case. Lines of (useless) code removed is at least as powerful a metric as lines of (usefull) code added when developing.

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.

I'm sure your critique is the same with graduates from any school. You need experience to understand not to do that. At least 42 seems to give you more experience than most schools.