Project Corewar Part 4: The End Is Always The Hardest

By Goki Ly / 15 Nov 2019

This will be the last post of the 4 parts mini-serie on the Corewar project from 42. In this post, I want to talk about a dreadful feeling I get everytime I am almost done with a project. When I am at the end of a project, I am never sure if my code is good enough. So I get in a indecisive state where I do not know what to do. Should I review my code for the 20th time to see if I can find an error that I did not find in the previous 19 times? Or is it good enough? I could be in this state for several days before I finally decide to close the project and be evaluated.

The evaluation system at 42 is quite harsh. The code needs to be perfect and a small mistake can make your project fail as it did on ft_printf for me. I think it is a good thing to be strict like this. The reasoning behind it is that in the real world, you can not deliver a 80% finished product to your client and expect him to be satisfied. It's all or nothing. So, being evaluated like this accustoms us to this mentality.

In addition, the downside of failing at a project is only time loss. You can retry the project as many times as you want. It only takes you evaluation points that you can earn by evaluating other students (= time spent evaluating others), and getting evaluated by others (= time spent). So it should not be a big deal. Presented like this, it should not be a big deal to fail a project. However I have this irrational fear when deciding to close the project that I have missed something and that I will fail the project. I think that this feeling stems from the traditional education I got before going to 42 where when you submit something for evaluation, it's irreversible. You don't have a second chance. I want to erase this deep-rooted conviction as it is an obstacle to my development as a programer. The first step toward my liberation is aknowledging this fear and trying to understand why I have it. Which is what I am doing in this post.

In the Corewar project, I felt like this fear was diminished because of the fact that I was in a group. I think there are two reasons why the group setting reduced my fear.

First, the code was reviewed and tested by 4 persons instead of myself only. Thus, I felt more confident of our work than if I was alone. Secondly, it is harder to review your own code than reviewing somebody else's code. When reviewing your own code, you already know what it is supposed to do and the syntax is what you are used to. It is hard to see where things could look suspicious. On the contrary, for somebody else's code, you do not know beforehand what it is supposed to do, or at least how it is doing it. When reviewing it, you are also simultaneously trying to understand what it is doing. In that context, it is easier to discover suspicious code. In addition, if a part of the code is too complex to be easily understandable, it is a potential place for bugs to hide. Asking the author to explain the code could unburrow a hidden bug.

This project made me realize another benefit of working in group, and made me rationalize a little bit about my fear of closing project.