So here we are. I can’t decide if the past 4 weeks flew by or if they felt like a year. But it doesn’t really matter, because I am very proud of my progress during the Piscine.
I’ve learned so much, that it definitively feels like more than just a month. I feel like everything I studied can be applied to much more than Shell or C. I think that I have a much better understanding of the “structure” of programs, how computers work, memory management, scripts, and even how to write semantic code, and this can be applied to any programming language.
In the Piscine, we develop many more abilities than just coding. From social skills to time management, it’s a whole collection of “level ups”. For example, by the second week, I was already suspicious of any set of instructions that were in front of me. You have to learn how to follow the instructions. This could sound very basic and silly, but that extra line you put to be easier to read but wasn’t in the instructions can make you fail a whole project. Really.
The attention to detail has to be present not only on your own code but also when evaluating your peers. It’s not about criticizing someone else’s work or giving your opinion on how to do things, but instead testing each case and being confident that you know how to spot the right output from a wrong one.
This brings me to the next thing I’ve picked up: testing. I used to be clueless on how to test code. Most of the time I could even get to the right solution but didn’t know how to test to be sure if it was right or wrong. Especially from C02 to C05, testing is as much part of the challenge as coding the solution.
Also, the way that the evaluations are randomly assigned, you can be working on C00 or not even started C yet and be asked to evaluate someone on C03, C04… I saw people that could write tests for exercises that they didn’t even solve yet, just from reading the subject and understanding what the answer should behave like.
Before the Piscine, I was familiar with the concept of pseudocoding and writing tests, of course, but to be honest, I never found much use for the first or much need for the last, but now I see both as really important. Often before starting to code a challenge I would write down an outline of what needed to be done. Most of the time because I understood what had to be done but didn’t know how to do it, so I wrote down what I thought I had to do and started my research on how to get it done.
This process also helped me a lot with explaining and defending my code. Situations like the ones I described above happened to me a lot, but the other way around: I was evaluated several times by people that still hadn’t reached the project I was on. And when this happens, it’s super important to be able to explain your code in a way that the person could really understand. I noticed soon enough that I got easily lost or at a loss of words during the explanation, so I started writing my “defenses”, line by line of code. Like “on line 15 I’m doing this and that, on line 20 this is happening” and so on. This helped me not only during evaluations, but also played a very important role in reviewing my own work, being sure I understood what was going on there, and feeling confident about it.
And there is, of course, “the Norm”. As I mentioned in my previous posts, 42 has its own syntax norm, and it is… different. To say the least. There are rules on how to name your files, functions, variables, but also things like “each function must be maximum 25 lines” and “each line must be at most 80 columns wide” or even “one instruction per line”, which made life quite annoying. I had to constantly refactor my code to fit the norm, and although I know it’s supposed to be a good exercise, I just kept thinking “but whyyyyy????”. 😅
Ok, so, we all know I got a little paranoid towards the end. (If you don’t know what I’m talking about, go check out my post about the last week of the piscine) BUT — I definitively have the feeling that some things are really made for us to fail.
Don’t get me wrong, I’m not saying they don’t want us to succeed, it’s actually the opposite. I think they do some things for us to fail, and learn how to deal with failure. These tiny little details with Norminette and Moulinette, the often vague descriptions of the exercises, and even the lack of answers to your questions — “ask your peers!” is the most common answer you will get from the wolf p.a.c.k. — are carefully crafted to make you go after information, try a solution, potentially fail and THEN learn from it.
Ironically, I feel that I “failed” on that lesson, because I still hate failing and felt just angry and frustrated when I did. But I get the importance of the assignment, and I’ll try to learn it somehow. I am very confident that if I get in, I’ll have plenty of opportunities to fail. 😅
One thing that I can say for sure is: the Piscine from 42 is not easy. And I’m not just saying that on a technical way like “the coding challenges are difficult” — well, they actually are! — but also on a mental, physical, and even social level.
You will have to interact with people that are very different than you, you will have to see people testing and trying to break your code and keep your cool, you will have to find a way to tell people that they are wrong without making them feel bad or defensive. You will also have to put in long hours sitting in front of the computer, probably sleep less than usual, you won’t have weekends to relax. And of course, you will be under an insane amount of pressure, you will be tempted to compare yourself to others, you will think you are not doing enough, or that you are being set up to fail. You may cry, you may get pissed off, you may get angry, frustrated, you might think of giving up, or find yourself without the will to push forward and be tempted to just survive.
And for that, the only advise I can give is: stay strong, keep going, keep swimming, it will be worth it.
Thanks for reading about my participation in the 42 Wolfsburg Piscine! In case you missed something, here are the links to the “full” experience: