report: add acquired skills section

report.md

@@ -327,6 +327,87 @@ Problematic: development of a benchmark framework
 
 # Illustrated analysis of acquired skills
 
+## Working in a team and project management
+
+Delivering a product is the goal of working in a business. However the process
+to get from zero to final product is unique to every company.
+
+During our project management classes, we were taught various ways of planning
+a product from before the first line of code to its final delivery. The
+prevailing culture in our industry in the last decade has been to adopt an agile
+work environment: evolve the product and its product backlog alongside each
+other, adapting to changing requirements. This is in sharp contrast to the
+traditional way of planning projects, called *Waterfall*, where a specification
+of behaviour is drawn upfront, and worked on for a long period of time with
+little to no modification done to that project charter.
+
+We can say that IMC has embraced a more Agile way of delivering new features:
+the products are continuously being worked on and improved, the work being
+organized into a backlog of issues, partitioned into epics. And similarly,
+the company culture embraces a few of the processes associated with Agile
+programming. The one has most affected me is the daily stand up, a meeting
+organized in the morning to interact with the rest of the team, summarising the
+work that has been accomplished the day before, and what one wishes to work on
+during the day.
+
+During the times of remote-work because of COVID, interactions with the team at
+large feel more limited than they otherwise would be when working alongside one
+another at the office. I have learned to communicate better with my colleagues:
+explain what I am working on, reaching out to ask questions, and discussing
+issues with them.
+
+## Working in a large code base
+
+IMC has a large body of code written to fulfil their business needs. It is rare
+to work on a pre-existing code-base during the school curriculum. The few
+projects that do provide you with a basis of code to complete them are at scales
+that have nothing to do with what I had to get acclimated to at IMC.
+
+This has multiple ramifications, all linked to the amount of knowledge embedded
+in the code. It is simply impossible to understand everything in depth, one
+cannot hold the entirety of the logic that has been written in their head.
+
+Due to that difference, my way of writing software and squashing bugs had to
+evolve, from an approach that worked on small programs to one that is more
+scalable: I could not just dive into a problem head-first, trying to understand
+everything that happens down to every detail, before being able to fix the
+problem. The amount of minutia is too large, it would not be productive to try
+to derive an understanding of the whole application before starting to work on
+it.
+
+Instead I had to revise my approach, getting surface level understanding of the
+broad strokes, thinking more carefully about the implications of an introduced
+change, coming up with a theory and confirming it.
+
+This is only possible because of my prior experience on the large number of
+projects I had to work on at EPITA, exposing me to a various subjects and
+sharpening my inductive skills, building my intuition for picking out the
+important pieces of a puzzle.
+
+## Debugging distributed systems
+
+My work specifically centers around running, interacting with, instrumenting,
+and observing production binaries for use in testing or benchmarking.
+
+Due to this, and because nobody writes perfect code the first time, I have had
+to inspect and debug various issues between my code and the software I was
+running under it. That kind of scenario is difficult to inspect, make sense of,
+and debug. The behaviour is distributed over multiple separate processes, each
+of which carries its own state.
+
+In a way that is similar to our Distribute Algorithms final project, to tackle
+those issues I had to think about the states of my processes carefully. I had to
+reflect on the problem I encountered, trying to reverse-engineer what must have
+gone wrong to get to that situation, and make further observations to further my
+understanding of the issue.
+
+This iterative process of chipping away at the problem until the issue becomes
+self-evident is inherent with working on such systems. One cannot just inspect
+all the processes at once, and immediately derive what must have happened to
+them. It feels more akin to detective work, with the usual suspect not being Mrs
+Pink in the living room with the chandelier, but instead my own self having
+forgotten to account for an edge case.
+
 # Benefits of the internship
 
 ## Contributions to the company