One morning on my way to my day job as Senior SW Engineer (actually SDET combined with SW Safety/Raliability), I saw a billboard advertising a free coding school in Prague – 42Prague.com, one of the global network of campuses 42.fr (henceforth, just 42School). It attracted my curiosity – what is this about?

Long story short, I fell for it, I absolutely loved it, and I recommend at least the 30-day C Piscine to anyone interested in IT career or Computer Science studies. What follows is a deep review dissecting how it works, the good sides and the weak sides – comparing my experience in IT (IRL SW development) with the 42School.

The 42School is based on a novel concept. Instead of a normal Computer Science, where students are taught advanced math, algorithms, principles of computing and then some programming – this school is 100% focused on pure programming only, 8 hours a day, for full 3 years (University Bachelor-length education), with internships, real-world projects and then job offer from the 42School sponsors (whom appear to be sponsoring the school to train their own pool of developers missing on the workforce market.)

And it teaches programming in hardcore C language – not in some buzzwordish Python or other such language. Cool.

Even more novel is the concept that the school is not run as a traditional frontal lectures with teachers. Instead, it relies on heavily automated software to run the processes and exams, on training the students to use documentation and honed search skills to get the answers they need, and on peer-to-peer collaboration and advice to help them move past obstacles. How can this ever work? Surprisingly well, read on.

The IQ test, the Piscine and the Core

The 42School uses gamification to an extent (more later) to lure, motivate and guide students as well as prospecting applicants. It has a three-stage process:

1. First, two online logic games which test aptitude for coding. 42School uses the graphical “code blocks” approach to allow even people who never coded before to think about how to achieve given goals with loops and recursion (without knowing them), thus testing their abstract and algorithmic thinking without discriminating non-IT people.
2. The people who pass the logic games are invited to a “C Piscine”, which is a 30-day intensive C-language course. Coding 8 hours a day for an entire month with your peers feedback is not just a best free C course on the market. It also provides invaluable feedback to the Pisciners and 42School. The School sees who has the talent or aptitude. But more importantly, by making students undertake such serious and rigorous coding work, it simulates the actual SWDEV work and the full-time studies, so that every student could judge whether they’d actually like to do this for a lifetime or not – before they commit! This is invaluable for the 18-years olds, or for people considering change of profession.
3. Those who pass the Piscine exams – based not on some rigid criteria, but more like attitude, aptitude, learning skills and personal development showcased during the Piscine – are invited to the Core curriculum, which is the actual 3-year coding school.

I went just for the 30-day C language Piscine. And because large part of my day job is analytical and systems thinking, unmasking patterns, architecture, feedback loops and how systems work, I will now dissect what I saw in the 42Prague school in a deep review.

How the 42School without teachers works? By code reviews!

In the real world, there are no teachers. You grow your career by self-training, trial-and-error experimenting, and then asking your peers for the small remainder of information which you just cannot get.

Eg. my career experience – I learned MS Server from the MSDN articles and GPEDIT.msc descriptions. The IBM z/OS from the MVS JCL reference and PL/I Programming guide. And expanded my career from QC to QA and Software Safety by reading IEEE standards, BS-7925 standard, the ARP4761 guideline, a lot of free NASA Software Safety handbooks… And a lot of trial-and-error on-job experimentation. Courses, if any, usually only came later on, after I was already doing the job.

It is crucial to “learn how to learn”, to master finding, searching and understanding Documentation and Reference Guides for any product, language or library, and to became autonomous in piecing together many sources of information. Quick-reading (scanning walls of text for previously unknown word patterns relevant to what you’re looking for) also helps a lot. The 42School enforces all this vehemently. In every assignment, they tell you:

They gave us few helpful hints – like that the Linux MAN pages (42School uses heavily customized Ubuntu) contain documentation for the standard C library functions (in 42School, it’s preinstalled, elsewhere you’ve got to install packages manpages-dev manpages-posix manpages-posix-dev).

There were few of us that already knew coding or the IT skills. So we were helping the others like these “peers on the left” the first days, acting as kind-of informal teachers. But what would happen when the course catches up and exceeds our previous knowledge and skills?

Magic. It’s a genius concept.

The Piscine works by assigning each student exercises, which have to be pushed to a GIT repo for that student/exercise combo and automatically verified by an automated test program called Moulinette.

But, and this is a big BUT, before you can even submit your work to the Moulinette, you have to have your peers students do two code reviews of your work – 42School calls this peer evaluation.

And crucially, anytime you have someone else do a code-review of your work, you lose an “evaluation point” which you have to re-gain by reviewing someone else’s code.

Why this bothersome and slow procedure? If 42School did it the other way around, like In Real World, everyone would just spam Moulinette with their attempts. We would trial-error-bugfix our work until it passes, exactly as when developers use Compiler to notify them of their syntax errors. Only then we would run a single successful Code-review as a pure formality. But that would be useless for the knowledge.

The way 42School has it? If you have the knowledge, you can finish the assignment in 1 pass – showing your code just to 2 other people.

But if you’re struggling… It means that for each unsuccessful pass of the Moulinette, you have to get 2 people read your code and suggest fixes, and you have to read code of two other students in exchange for their evaluation points. Which means that the more you’re failing, the more coding suggestions you get, and the more better code you have to read!

But wait, the automatic feedback loop goes even further. If you’re seriously lagging behind, you will get assignments to evaluate code of people who are already in the next assignment. Thus when you finally get there, you already know the algorithms and you just have to write your own to the already familiar notion.

And since this is automatically managed by the online server, even the introverts who wouldn’t have asked their peers have it all arranged for them.

Systems-engineering-wise, this is called a Balancing Feedback Loop. Beautifully crafted in it’s simplicity, it automatically gives the lagging students the resources to learn from their peers by reading their code and hearing their explanations, thus catching up! As I said, genius concept. Ever since I’ve understood how this system works “under the hood”, I admire it.

The 42School Piscine as a high-fidelity simulation/demo of the IT day job

Other schools are just schools – environment totally different than real-world job, with arbitrary school/academical rules, warped understanding of success (being good at taking understanding exam questions and saying what’s expected), and very non-linear and diverse workload (“workdays” of various lengths, some of them free entirely, many different subjects). You have no idea what the real world is until you’ve graduated and got your first IRL job.

On the other hand, the 42School intentionally simulates regular job. You sit 8 hours a day at your computer, coding continuously a single project and related activities (code reviews, peers asking for advice, overhearing interesting tech-related conversation and stopping by, etc.) Plus, off course, meetings to distract you – but voluntary in the 42School case.

Even the layout of the assignments simulates software developer job IRL:

1. you’re assigned a coding project
2. you have to read and understand the requirements, fill-in the blanks
3. you have to code it – and while doing so, learn any gaps in your knowledge needed for implementation from the Doc, Reference guides and peers
4. you can reuse your old code, which should motivate you to write clean, reusable and future-proof functions
5. you have to adhere to a Coding Standard
6. you have to Code-Review the results of your work
7. if you forget a compile flag, your work will not compile (Moulinette uses cc flag -Werror, which turns warnings into errors which prevent compilation). This teaches you to use Makefiles as soon as you get to them.
8. you have to make it pass the tests (the Moulinette simulates both the Customer Acceptance Tests and QC/QA destructive testing, with some very surprising test values and great test coverage). And if you don’t, GOTO 2; debug, fix and retry

So the Piscine students “works” 8+ hours a day in for 4 simulated work weeks, coding in a high-fidelity simulation of a real-life SW developer job.

Besides that, the 42School even teaches the importance of timeboxing and time management. Beginning with assignment 03, you can pick how much programs/functions you turn in – whether the bare minimum needed to advance, or whether you’ll grind through the basic to the interesting stuff. But if you mismanage your time, you will not get far ahead in the assignments, and thus not learn newer topics in time to know them for the exams.

All this is absolutely invaluable. Within just 30 days, the 42School Piscine teaches every student involved the same basic skills and hard lessons I’ve acquired over the course of a decade in IT, plus gives a sneak-peek demo into what IRL SW Development job is like!

42School’s scoring/gamification is about the only non-Orwellian and non-harmful metric in the IT

Given the overall nature and automation of the system, the system of 42.fr heavily uses “gamification” and computer-calculated scores. But not in the Orwellian sense depicted eg. in the movie The Circle (very trend-accurate and based on the Chinese Tencent/Alibaba scores and Social credit.)

Nor even like in the more subtle subconscious algorithm manipulation of social networks. And surprisingly, nor even like the typical IT corporate metrics and scores, which use arbitrarily picked, ignorant and irrelevant numbers to try to gauge processes the management is clueless about, always spawning damaging unintended consequences.

Instead, the 42 gamification comes in an individualist, web browser-based system. Each student has their own intranet homepage where they can subscribe to the exams, events and assignments, and where they control the code reviews a.k.a. evaluations. On the same page, you can also see your progress and scores of your past exams and submitted projects:

But you are constantly discouraged from comparing your scores to anyone else, and being told that it’s not important what score you achieve even on the exams, but rather how much you learn.

Indeed, even if you fail an exam, you can continue like nothing happened. The exams are for you so that you can see what gaps your knowledge has and address them. Each time I failed in an exam, I learned the missing part and it has helped me.

Eg. on the final exam, I failed to allocate 2-dimensional array of the double-pointer-to-char type with Malloc(). I thought that C is dumb, so I just allocate the total size of memory needed with Malloc and then point the initial double-pointer to the beginning address of the segment allocated. No, SEGFAULT. So after the exam, I asked around… And finally understood the nature of double-pointers – or rather, “pointers to the array of pointers”, which was my long-term nightmare topic in C! Each exam has pushed my understanding this way.

I’m told that even the Core curriculum (after the Piscine) works similarly. The students get assignments and they can fail them as many times as needed. They only have a deadline coming, like in the real world – but unlike IRL, this deadline is extended each time they successfully turn-in a working solution. Again, much unlike the academic environment, much more like the real world, and much better for learning how to learn IT!

The entire system is built like this. Providing information for you to guide you in your decisions and continuously learn, not about you so that you’d be judged by some ignorant authority.

What could be improved: unclear requirements are not up for guesswork

So far, I’ve only praised the 42School. Time for some constructive criticism.

The Piscine is divided into 13 assignments, each with multiple exercises going from easier to harder. You cannot skip any exercise, and you cannot start the next Assignment until you’ve successfully finished the previous ones as a pre-req.

Sometimes, this undermines the learning potential. Namely in C02 and C03 assignments, you are tasked to replicate (or reverse-engineer) the behavior of functions from the core GNU C Library – string.h library functions like strcat(), strcpy(), strlen() etc.

The very bad thing about this is that the requirements are unclear. Piscine tells you to consult MAN, i.e. the manual pages about these functions. But this doc is confusing, misleading, often self-contradictory, and as I found the hard way after many hours of debugging, sometimes even incorrect/bugged.

Naturally, such ambiguous requirements (or lack of them) causes any code to repeatedly fail at the Moulinette, even if it passed Code Review and if the code itself and the Pisciner’s understanding of the topic is good and clear. Just because noone could tell us what the code should even do.

When we wanted clarification what should we do (not how to do it), we were told to “guess”. Well sorry, no. IRL, Software Development is not about guesswork!

In Real World, when we encounter ambiguous requirements, we clarify:

1. we ask the customer representative, or Product Owner, or Business Analyst
2. we showcase the customer a few Mock Prototypes and ask which way they want it
3. only in the worst case, we hack together a working prototype demo and adjust the requirements based on customer’s feedback

It’s simple math and money – noone has time or resources to endlessly pursue dead ends, writing code which noone wanted based on “guesses”. No, not even in Agile. We must clarify everything we can before we start writing the code.

Thus on the Piscine, It was a source of great frustration and obstacle to learning not only to me, but many others that we were stuck guessing what the Moulinette wants, guessing the untold requirements, and not being able to proceed to the more interesting exercises which would boost our knowledge of C and algorithmization in C.

My suggestion: refine the requirements as if they were from a real customer, removing ambiguity and telling the Pisciners exactly what their code should do.

My professional deformation has some reservations regarding The Norm

The 42School enforces it’s own Coding Standard called The Norm. It is mostly reasonable, if very strict (no more than 25 lines in a function, no more than 5 functions in a single .C file – ugh, but I wanted to become better structured, right?)

But this Coding Standard has some requirements which I hold harmful from the Software Safety perspective.

For one, it strictly insists that variable declaration must be separated from their values assigned. That is nice for readability, and also enforces proper understanding of C pointers and arrays. But there is one case where this is unsafe – pointers.

It is the industry best practice that all pointers should be declared-initialized already with NULL as their default value, so that if someone forgets to initialize that pointer, it will not try to dereference random memory. The Norm should make an exception at least for this, and even contrary to the current practice – force all pointer variables to be declared-initialized as NULL.

The second reservation is regarding loops and their runtime safety. The Norm prohibits FOR cycles. I can guess of some legitimate reasons why (local variables which vanish after the loop finishes, although this can be avoided), but the other reason is absurd and harmful. The Norm gives following as the reason:

Cryptic language syntaxes that do multiple instructions apparently at the same time are confusing. The Norm asks you to create simple pieces of code, where the unique task of each piece can be clearly understood and verified, and where the sequence of all the executed instructions leaves no doubt. That’s (…) why for, do .. while, or ternaries are forbidden.

Agreed with ternaries (although I used them a lot!) but FOR loop? On the contrary, having multiple instructions in it is exactly the point!

It is Software-Unsafe and System-Unsafe to have a loop whose control is dependent on an independently-set iterator. Countless times along the Piscine, I’ve had a Runaway While Loop condition (endless loop) because I forgot to code the iterator increase, since it needs to be the last line in the loop.

If the condition was more complex and the runaway loop condition only manifested within specific state and boundary values, it may have not been detected by the tests (i.e. the Moulinette) and the result would be dangerous software released “to production”.

It is the point of the FOR cycle to have both the condition and the incrementation of the iterator on the same line, in the loop heading and not split something in the body and something in the heading! It’s much more reliable and secure, and since the format of FOR loop is standardized (init, condition, increment), it is not confusing and the sequence of the instructions leaves no doubt.

Yes, you can misuse FOR, but then the same could be done with WHILE. See a GNU LibC examples. Are you really trying to tell me that this WHILE loop “leaves less doubt of execution sequence” than a nice, normal FOR loop?

while ((*dest++ = *src++) != '\0')

Come on, you even need to read the MAN PRECEDENCE reference to properly decode the execution sequence of this! I wrote a Piscine blog on this topic, btw.

FOR loops are more systematically secure and reliable whenever we’re dealing with incremented iterators, period. On this one I absolutely cannot agree with The Norm. But that’s the smallest of things and subjective opinion.

Conclusions

Throughout my IT career, I’ve met a number of people who actually didn’t want to do SW development – but they made a wrong decision when they were 18, invested time and energy into becoming CS graduates, and now had no way back.

On the Piscine, some of the participants just made the same discovery – but before they wasted 3 years of education preparing for a job they don’t want to do. If nothing else, this is already a benefit worth it’s own weight in gold.

I’ve also met people who would have loved to work as developers, but they didn’t get the chance since they were not the academic types, and wanted to just code – not to study advanced math. For these people, the 42School is a life-saver.

I would highly recommend the C Piscine to every high-school graduate who wants to work in IT, even if they’d want to study “normal” university instead of 42School. You invest only 30 days of your free time – and in return, you get a free crash course into the C language and demo of what your future IT day job would be like, day-by-day.

And if you pass, you will have a choice between pursuing a Computer Scientist writing algos with advanced math on the Uni, or Pragmatic Developer writing software which makes the world run on the 42School.

There’s a 42School campus in most countries of Europe and few in Americas, Africa and Middle East. If you have a child considering IT career, definitely think about this option with them.

Compared to commercial C or C# courses, Piscine doesn’t go as far and as fast as the others. It’s not the point – the assumption is that it’s a demo both to the student and to the school, and those who fit in will continue with Core Curriculum “for real”.

Even if we have had all progressed to the last and final assignment C13 or the “BSQ” project, we would have “only” learned pointers, structs, malloc, basics of file I/O and Makefile. But the difference is how well we understood all those.

42School is carefully crafted to avoid superficial “ChatGPT-like” pseudo-knowledge of copypasting some words without understanding them. It pushes the point thoroughly, and stresses the understanding to build a good foundations. That both of my C Pointer nightmares have materialized and yet were swiftly overcome is a testament to the quality of the curriculum for it.

To sum it all, the system which runs 42School very un-school-like is amazing.

• Exams which doesn’t serve to crush and humiliate you, but help you learn with no repercussions?
• Code-review facilitated “automatic peer-to-peer learning”?
• Scoring which isn’t there to compare your worth to others or monetize you, but instead to help you and only you as an individual to progress?
• Curriculum carefully selected to give you firm knowledge of the fundamentals?

This is how any school should be, if only it could. The 42Prague can. And if I was my 18-years old self and I lived today, I’d definitely apply for the Core (provided I was selected in the Piscine to pass).

But I’m elsewhere in my life, so instead, it’s back to work for me. But 42Prague Piscine has left a lasting, overwhelmingly positive impression on me.

I hope I’ll continue do do C coding exercises on my way to regular work – and I am now a devoted 42Prague fan.