report: add benefits of the intership section
This commit is contained in:
parent
0e7c2a7b05
commit
46d6011c8a
53
report.md
53
report.md
|
@ -283,7 +283,58 @@ Problematic: development of a benchmark framework
|
|||
|
||||
# Illustrated analysis of acquired skills
|
||||
|
||||
# Added value
|
||||
# Benefits of the internship
|
||||
|
||||
## Contributions to the company
|
||||
|
||||
The work I have accomplished during my internship has resulted in tools that can
|
||||
be used as the basis for extensive testing using production binaries during the
|
||||
iteration of the development process.
|
||||
|
||||
From this work we can retain two main points for IMC:
|
||||
|
||||
* An extensible framework to use for benchmarking the gateways, and measure
|
||||
their performance. Thanks to the ease of writing new scenarios, and the
|
||||
integration of running the benchmarks with the build system in use at IMC, and
|
||||
its Continuous Integration pipeline, it can easily be used to monitor the
|
||||
evolution of performance and watch for regressions. Further down the line, it
|
||||
can be integrated with the change point detection service that is being
|
||||
developed in house, to simply contact the relevant people when the system
|
||||
detects that a regression has happened: the offending change can be identified
|
||||
more easily that way. This is key to staying competitive, ensuring the latency
|
||||
of our systems remain as low as possible and do not creep upwards.
|
||||
|
||||
* My work on compatibility testing, which is an important step in avoiding any
|
||||
surprising behaviour or downtime in production. Due to the long turn around time
|
||||
of upgrades in certain regions, and the cost of lost opportunity for any down
|
||||
time, minimizing the probability of any problem that could be experienced
|
||||
results directly in more profits being made.
|
||||
|
||||
## Furthering my learning
|
||||
|
||||
During my internship, I got to work on a large code base, interact with smart
|
||||
and knowledgeable colleagues, and tinker on what constitutes the basic bricks of
|
||||
IMC's production software (FIXME: phrasing).
|
||||
|
||||
Working at IMC was my first experience with such a large code base, a dizzying
|
||||
amount of code. It is impossible to wrap you head around *everything* that is
|
||||
happening in a given program. Up until that point I had only encountered school
|
||||
projects, of relatively small size and whose behaviour could easily be
|
||||
understood. Dealing with problems by trying to understand everything that is
|
||||
happening in a program is a valid strategy for those. It is not, however, a
|
||||
scalable way of working on software, and I needed change my way of thinking
|
||||
about and dealing with the problems I encountered during my work. To cope with
|
||||
that, I learned how to better handle problems I encountered by trying to isolate
|
||||
the actual source of the problem, instead of trying to understand the whole
|
||||
system around it.
|
||||
|
||||
Interacting with the team was a great help in that endeavour. Knowing who to ask
|
||||
questions to, and learning how to ask relevant questions are once again
|
||||
essential in achieving productivity in those circumstances. This is doubly so in
|
||||
times of remote-working, when turning around and asking your colleague a
|
||||
question is not so simple. I had trouble at first to actively use the internal
|
||||
messaging app to ask questions, and was encouraged to ask questions liberally
|
||||
instead of staying stuck on my own.
|
||||
|
||||
# Conclusion
|
||||
|
||||
|
|
Loading…
Reference in a new issue