Imagine working on a project where you have to sort a list of numbers, but you can only have two
sorting stacks, you can only push the first number from one stack to another, you can switch the top
number to the bottom, or bring the bottom number up, or swap the first two numbers in a stack.
Additionally, you are restricted to using only four pre-defined library functions – the rest must be
self-coded. Lastly, your most important goal in this sorting game, and the real focus of the project:
move complexity. Sounds like a lot of constraints, right?
There is no book, no teacher and no AI guru that is going to teach you how to solve such a unique
problem. I bet you that software engineers, game developers, and cybersecurity professionals ‘out
there’ are faced with unique challenges every day; and it is their job to come up with uniquely fitting
solutions.
The 42 model will always force you to dive into the deep end. Throughout time you will become more
resilient to being faced with unique problems that require original solutions. If you are interested in
the 42 model, a project workflow can be summed up into four phases:
1) You don’t know what you don’t know
As someone who had no prior coding experience before starting at 42, I always found this to be the
most daunting part of the project – the start. If I don’t know what I don’t know, how can I even know
what to type into the Google search bar?
That’s the good thing about peer learning: You can simply swivel your chair and ask the person right
next to you. If you are working from home, you have access to a Slack channel with over 25,000
active students and alumni who can answer your questions.
Gradually, you gather some keywords and concepts that you canlater search for.
2) You know what you don’t know
Now, you Google all the keywords and concepts you can think of, open a Wikipedia page and click
through every link that looks the least bit useful. You might end up reading a chapter of a book that
explains some seemingly distant theoretical concept about sorting algorithms, or another about a
mathematical analysis on the move and time complexity of sorting numbers. You can also try watching
YouTube videos of people coding simple exercises that look useful for the project.
By the end of this stage, you have a somewhat idealistic view of what it is going to take for you to
begin the project. You have a list of goals you want to achieve, and an architecture planned out.
3) You don’t know what you know
At this stage, you feel like you have had a setback. You have done the research, talked with your
peers, compiled a to do list, and are at the first coding stage of your project.
You sit down to write the code, and little by little you realise that actually you don’t know how to put
into practice all the things you read about. Perhaps your code doesn’t compile, or it is flat out not
doing anything. Or maybe you are at a later stage, when your code actually works, but the overall
architecture of your project has been so naively planned out, that it would take more time to write
functions to overcome the pitfalls of a flimsy architecture, than to tear the whole thing down and re-
write it all over again.
This stage, occasionally also known as the desperation phase (we have all been there), pushes you to
keep looking for that unique solution. You are too deep in to back down now – you must figure this out.
There is no shame in going back to the previous stage. Or you can also resort to the peer learning
sandwich: ask your peers about something you are stuck on, put it into practice and ask again once
you have hit a wall. Repeat this process until you are officially unstuck.
4) You know what you know
You have invested your blood, sweat and tears into this project, and what once looked like an
impossible feat, has somehow been achieved. You sit down for an evaluation with another student, and
you can answer questions about your code, like how you optimised your sorting algorithm for the best
move complexity, or how you made sure you program was water-tight and would not crash with
unexpected inputs, and lastly, you can tell them everything you learned from this experience.
Congratulations, you now know what you know. The next project awaits. Are you ready to start all over
again?