diff --git a/report.md b/report.md index dc2f958..d3adf87 100644 --- a/report.md +++ b/report.md @@ -327,87 +327,6 @@ 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 @@ -540,6 +459,12 @@ expect few places to be as well-rounded as IMC. ## Vocabulary +Market-making + +: A market-maker provides liquidity to the market by continuously quoting both +sell and trade prices on the market, hoping to make a profit on the *bid-ask +spread*. + Bid and ask : Respectively the price for buying and selling a stock or other financial @@ -551,12 +476,6 @@ Continuous Integration : The practice of automating the integration of code from multiple contributors into a single software project. -Market-making - -: A market-maker provides liquidity to the market by continuously quoting both -sell and trade prices on the market, hoping to make a profit on the *bid-ask -spread*. - ## About IMC International Marketmakers Combinations (IMC) was founded in 1989 in Amsterdam,