On GitLab’s Data Team we were inspired by this post from @claire to make an onboarding script that incorporates many of the mentioned tools and techniques. So now as part of our onboarding, we ask new hires to run the script right when they get access to their new machine. This leads to 2 main benefits:
1. Time is Saved. A lot of the tasks in the script would need to be done on a new machine anyways (e.g. installing dbt). By putting all of the scripts together in one place, we can save new team members from having to do all of these steps individually. When a new hire has all of their dev software installed and configured “out of the box”, they can theoretically start contributing to our projects immediately.
2. Consistency. Because each member of the team has a similar setup on their local machine, collaboration within our data team becomes much easier. When I recently ran into errors running dbt tests locally, @emilie was able to diagnose my problems quickly, in part because she knew that our local environments were nearly identical. On other teams that I’ve been on in the past, these collaborative debugging sessions would always cause headaches because each individual had their own unique dev environment (ex: mismatching python installations, different path variables).
The nice thing about our script is that it’s meant to be a set of guidelines, not rules. For example, the script installs Atom as the default code editor, but I’m personally more productive in VS Code. After running the script, I still installed VS Code and set it as my default, and that was totally okay. The benefits of everybody using the exact same stack are outweighed by the productivity gains that come from people using the tools they’re the most productive in, so everyone is allowed to customize their environment how they see fit.
Since GitLab is open source, both the script and our onboarding issue template are available to the public. We’d love to incorporate any feedback into improving these. Thanks to Claire for the inspiration!