report: add acquired skills section

.gitignore

@@ -1,2 +1,3 @@
 /report.pdf
 /result
+/.pre-commit-config.yaml

.markdownlint.yaml

@@ -0,0 +1,4 @@
+default: true
+
+# I use top-level titles for each section
+MD025: false

flake.lock

@@ -2,38 +2,65 @@
   "nodes": {
     "futils": {
       "locked": {
-        "lastModified": 1618868421,
-        "narHash": "sha256-vyoJhLV6cJ8/tWz+l9HZLIkb9Rd9esE7p+0RL6zDR6Y=",
+        "lastModified": 1623875721,
+        "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=",
         "owner": "numtide",
         "repo": "flake-utils",
-        "rev": "eed214942bcfb3a8cc09eb3b28ca7d7221e44a94",
+        "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772",
         "type": "github"
       },
       "original": {
         "owner": "numtide",
+        "ref": "master",
         "repo": "flake-utils",
         "type": "github"
       }
     },
     "nixpkgs": {
       "locked": {
-        "lastModified": 1619180214,
-        "narHash": "sha256-wt1uDD9RAxc3wdWOQp8zM3+ZyLb2rbnGIeaIuXGzw80=",
+        "lastModified": 1626764163,
+        "narHash": "sha256-TB+mtRpwn6pnoUXjBvJPIgHKkwLtjzFji4tkANlZWJQ=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "112a3b08e9bcffa58e0f79af0072fc8273933b87",
+        "rev": "1441fa74d213d7cc120d9d7d49e540c1fc59bc58",
         "type": "github"
       },
       "original": {
         "owner": "NixOS",
+        "ref": "nixpkgs-unstable",
         "repo": "nixpkgs",
         "type": "github"
       }
     },
+    "pre-commit-hooks": {
+      "inputs": {
+        "flake-utils": [
+          "futils"
+        ],
+        "nixpkgs": [
+          "nixpkgs"
+        ]
+      },
+      "locked": {
+        "lastModified": 1624971177,
+        "narHash": "sha256-Amf/nBj1E77RmbSSmV+hg6YOpR+rddCbbVgo5C7BS0I=",
+        "owner": "cachix",
+        "repo": "pre-commit-hooks.nix",
+        "rev": "397f0713d007250a2c7a745e555fa16c5dc8cadb",
+        "type": "github"
+      },
+      "original": {
+        "owner": "cachix",
+        "ref": "master",
+        "repo": "pre-commit-hooks.nix",
+        "type": "github"
+      }
+    },
     "root": {
       "inputs": {
         "futils": "futils",
-        "nixpkgs": "nixpkgs"
+        "nixpkgs": "nixpkgs",
+        "pre-commit-hooks": "pre-commit-hooks"
       }
     }
   },

flake.nix

@@ -2,12 +2,34 @@
   description = "Ambroisie's CV";
 
   inputs = {
-    nixpkgs.url = "github:NixOS/nixpkgs";
-    futils.url = "github:numtide/flake-utils";
+    futils = {
+      type = "github";
+      owner = "numtide";
+      repo = "flake-utils";
+      ref = "master";
+    };
+
+    nixpkgs = {
+      type = "github";
+      owner = "NixOS";
+      repo = "nixpkgs";
+      ref = "nixpkgs-unstable";
+    };
+
+    pre-commit-hooks = {
+      type = "github";
+      owner = "cachix";
+      repo = "pre-commit-hooks.nix";
+      ref = "master";
+      inputs = {
+        flake-utils.follows = "futils";
+        nixpkgs.follows = "nixpkgs";
+      };
+    };
   };
 
-  outputs = { self, nixpkgs, futils } @ inputs:
-    futils.lib.eachSystem futils.lib.allSystems (system:
+  outputs = { self, futils, nixpkgs, pre-commit-hooks } @ inputs:
+    futils.lib.eachDefaultSystem (system:
       let
         inherit (nixpkgs) lib;
         pkgs = nixpkgs.legacyPackages.${system};
@@ -16,19 +38,46 @@
           pandoc
           (texlive.combine {
             inherit (texlive)
-            scheme-small
-            # Extra packages needed
-            changepage
-            enumitem
-            placeins
-            ;
+              scheme-small
+              # Extra packages needed
+              changepage
+              enumitem
+              placeins
+              ;
           })
         ];
       in
       {
+        checks = {
+          pre-commit = pre-commit-hooks.lib.${system}.run {
+            src = ./.;
+
+            hooks = {
+              nixpkgs-fmt = {
+                enable = true;
+              };
+
+              markdown-lint = {
+                enable = true;
+
+                name = "Lint each post's markdown";
+
+                entry =
+                  let
+                    pkg = pkgs.nodePackages.markdownlint-cli;
+                  in
+                  "${pkg}/bin/markdownlint";
+
+                types = [ "markdown" ];
+              };
+            };
+          };
+        };
+
         devShell = pkgs.mkShell {
           name = "report";
           inherit buildInputs;
+          inherit (self.checks.${system}.pre-commit) shellHook;
         };
 
         defaultPackage = pkgs.stdenvNoCC.mkDerivation {

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
@@ -457,6 +538,25 @@ expect few places to be as well-rounded as IMC.
 
 # Appendix
 
+## Vocabulary
+
+Bid and ask
+
+: Respectively the price for buying and selling a stock or other financial
+instrument. The closer the spread of the two prices is, the more liquidity there
+is in the market for that product.
+
+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,