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. Its super exciting! Getting to know your new team, a new product line, various functions within the company, on-boarding 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 then exploring a new codebase and playing around with it. But before we can do that, we need to bootstrap our machine first 🤯. On 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 😱). Its a cumbersome and lengthy task. Reading through the guides and experiencing the dead time during the installations themselves, which always feels like a waste of time.

What do we want to achieve

I'm a strong believer that developers should have their first commit to master in 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 on-boarding. 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 in the same day.

On the other-hand, developers really 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 achieve such a goal and might extend the learning curve.

There's also an additional concern: as the application and eco-system changes, so does 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 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 which does not allow to understand which tools are installed. Furthermore its hard to maintain over time, as the ones that are updating it are not developers but IT personal. Such a virtual barrier can discourage updates of the installation tool making it obsolete over time
• Guides are great for learning, but maintaining them overtime is cumbersome. And obviously, they are the slower path as they are completely manual

Proposed solution

I would like to introduce to the workstation installation script:

Its a simple bash script that automates the deployment of a developer (or any) workstation - from zero to hero 💪 in less then an hour!

Fast installation

installs and configures everything that a developer needs in order 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 strait forward. It allows everyone who wishes to browse through all the applications installed easily and understand all the automatic configurations applied. As a matter of fact - its 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 its a script which 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 there own 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 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 own use.

Photo by Luke Peters on Unsplash