Photo by Luke Peters on Unsplash
Imagine this scenario:
After a grueling interview process, off-boarding from the previous position, and a bit of vacation, you're starting at a new company. It is super exciting! Getting to know your new team, a new product line, various functions within the company, onboarding sessions...
And of course, the new codebase(s) you're going to be working on in the next couple of years. There's nothing more exciting for developers than exploring a new codebase and playing around with it. But before we can do that, we need to bootstrap our machine first 🤯. In some cases, it can be as simple as installing the runtime and IDE, but in most cases, we'll need to install many applications and perform numerous configurations before we can start working on the codebase.
In my many years in the software industry, I've found myself doing these installations many times - when moving to a different place, or within the same company replacing my previous machine (don't ask me about these 😱). It’s a cumbersome and lengthy task. Reading through the guides and experiencing the dead time during the installations themselves, always feels like a waste of time.
What do we want to achieve?
I'm a strong believer that developers should have their first commitment to master on the first day of the job. Doing so facilitates a quick feeling of accomplishment that eases the tension and stress of starting the new position and gives confidence for the rest of the onboarding. Pushing through the workstation bootstrapping stage as quickly as possible is crucial, so the developer can pull the code, get to know it a bit, and push to master it the same day.
On the other hand, developers like to know what is installed on their machines. Knowing an application is not just knowing the code, but understanding the eco-system, the runtime environment, the dependencies, and the configurations. The workstation bootstrapping allows developers to do so. Moving quickly through the installation process might be counter-productive to achieving such a goal and might extend the learning curve.
There's also an additional concern: as the application and ecosystem change, so do the dependencies and applications being used to develop it. Revising the installation over time by the developers who use it should also be considered when coming up with a solution.
To summarize, we have three goals:
1. Fast installation
2. Reduce the learning curve of the eco-system
3. Maintenance over time
Over the years I've seen many attempts to solve the developer workstation installation. From guides to installation scripts to IT tools. Unfortunately non of these tools had the right balance to achieve the goals mentioned.
For example:
- Pushing the problem to IT professionals usually creates a black box installation that does not allow them to understand which tools are installed. Furthermore, it’s hard to maintain over time, as the ones that are updating it are not developers but IT personnel. Such a virtual barrier can discourage updates of the installation tool making it obsolete over time
- Guides are great for learning, but maintaining them over time is cumbersome. And obviously, they are on the slower path as they are completely manual
Proposed solution
I would like to introduce the workstation installation script:
https://github.com/ysa23/workstation
It is a simple bash script that automates the deployment of a developer (or any) workstation - from zero to hero 💪 in less than an hour!
Fast installation
installs and configures everything that a developer needs to run the application. Doing so automatically takes about an hour, depending on the number of applications installed
Learning curve
the script itself is open to everyone and very straightforward. It allows everyone who wishes to browse through all the applications installed easily and understand all the automatic configurations applied. It is highly recommended to do so before or even during running the script. It can also be used as a reference when needed to understand some of the configurations
Maintenance
Since it is a script that is source controlled and available to everyone in the team, anyone can make a change, and suggest a pull request. Furthermore, if anyone wants to do a specific configuration they can easily either fork it or create a branch and add their customization. Their favorite theme to zsh for example, or configuration of shortcuts they prefer to git commands
Please note: This script is not meant to be used as is, although you can if you want to. It is meant to serve as an example to fork and make your own, with a bit of scaffolding for convenience.
My recommendation, and the way I applied it so far in the companies I worked with it, is to fork and make the adjustments that fit the team, with the relevant tooling and matching configurations.
The script itself is meant for Mac machines but is said, it can be used as an inspiration for similar ones to Windows and Linux development machines.
The repository is open-sourced with an MIT license, and we accept PRs and issues with open arms 😉
Hopefully, you can find it a good inspiration and make it useful for your use.
Originally published here.