From 47bf3793fc5055dc5d509a997cba4dff8db61249 Mon Sep 17 00:00:00 2001 From: Bruno BELANYI Date: Wed, 21 Jul 2021 18:42:04 +0200 Subject: [PATCH] report: add acquired skills section --- report.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/report.md b/report.md index e01b902..dc2f958 100644 --- a/report.md +++ b/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