When I started to experiment with docker, I had to run a debian system in a virtual OS as I primarily use windows for my everyday development and if you look at the development setup of our team you'll find a pretty heterogenous landscape with respect to the used OS's or IDE's. So in general, sharing (infrastructure) code for external resources and services is one thing we do to strive against this kind of fragmentation. 

Everyone can set up the required system easily and repeatable.

While working in a javascript project, we often had to do the same thing with promises over and over again:

Inspecting it and then doing some action based on the real content, while "doing" something could simply be doing nothing.

Some time ago I worked on a 20% project and finally, I got a version ready, which found it way up to the repositories of synyx now.

Today I want to talk about code reviews and the advantages and disadvantages of particular workflows with an eye towards changes in the future. A time will come when people will need to find out, why changes on the mainline have been done the way they have been done. There is always (for a positive thinking individuum) a reason or motivation behind a change and hope you are in the lucky position that