How to Reduce Developer Onboarding Time by 90% with One Service

In the very first line I admit that the title is a bit disingenuous. The thing is that the developers I worked with and for whom I launched this service are beginners, junior and middle-year university students. Many of them did not even have an IDE on their computers when they started working. However, I am sure that the method described below will help not only them, but also more experienced developers.

And I want to tell you about Coder – OpenSource tool for raising ready-made development environments on demand. That is, ready-made environments that you can connect to via ssh or using your favorite IDE, in which the necessary utilities are already installed, the necessary settings are made, the project is configured and all that remains is to write the code and run testing with one button.

Over the past years I've worked in a dozen different teams, and my least favorite part of the job in each new one is the first days, when you are shown a repository, a readme, and you spend tedious hours installing all the dependencies, receiving millions of different errors from “the linter doesn't work” to “this library doesn't support your OS/processor architecture/video card”.

There are quite a few solutions to such problems: large, rich companies can issue identical MacBooks to everyone, on which all developers have the same hardware and the same set of software will be installed; others write detailed installation guides, raise their own repositories with dependencies and fix these dependencies with hard versions; others have projects with Dev ContainersAmong the options there is also Coder, which seemed to me to be one of the most universal.

Coder is a “website” that allows a developer to go to a page from a browser, click one button, wait a bit, and get a ready-made environment. With the same operating system and the same dependencies as other developers on your team.

At the same time, you – the person who sets up Coder in your team or organization – have almost unlimited number of options where to raise these environments, thanks to the fact that Terraform is used for setup. The only exception is that it will not be a local deployment on the developer's machine, but some network location. Examples:

A server or group of servers in AWS, Google Cloud Platform, Microsoft Azure, Yandex/Sber/VK Cloud or any other cloud provider.
Kubernetes in your enterprise environment.
Docker containers are my favorite method and the one I mostly use.

If you are already familiar with Terraform, at least in a general way, then the examples from official repository And articles on the official website you will raise your first environment in a couple of hours regardless of the chosen hosting option. At the same time, Coder allows you to use different options for different project templates, and even combine them within one template.

Coder for developer

I have completely switched to Coder for developing all my pet projects and any other non-work activities. Once I have set up a Coder server, I now spend about 30 minutes to throw together a basic Docker image with all the necessary dependencies (or I even take a ready-made one if the project has dev containers) and start developing. I would have spent the same amount of time setting up the environment locally on my work computer, and on a new machine the setup time would most likely increase many times over.

Each microservice is developed separately. Instead of a bunch of folders and software on the local machine, there are separate environments in docker containers.

More advantages:

In a short time you get a fully prepared development environment.
There are no conflicts between different projects and software required to work with this project.
I am no longer tied to a specific laptop and can finish work on one PC and continue at any time from any other where I finished. And even if I forgot to push changes to git.
When you need to work from someone else's computer, you can launch VSCode right in the browser window and simply edit the code without installing any software at all.
If you password-protected your machine, you can create a new one in a couple of clicks.
When a project has a zoo of dependent services, it is very convenient to raise them in separate containers and delegate their management to Coder, rather than write sh scripts to raise all services locally. And you can share the result with colleagues without fear that it will not work.

But there are also disadvantages:

You need to have a powerful enough server where you will run development containers/cheap tariff from some hosting provider or rich dad for development on separate dedicated virtual machines.
You always need a stable internet connection to work. You can't work on a plane.

My Coder has a few ready-made universal templates that I use regularly:

General. Raises one Docker container with Ubuntu without any additional dependencies. Then you can deliver anything and use it. Convenient for some quick tasks, when you need to raise the environment once, test it and delete it.
Python FastAPI. My main working environment, running a Python-based container, Postgres and Redis containers. This is my main container, many of my projects are written on this stack, more or less, with minor modifications.
Node.js. A frontend container that is a common one, but with Node.js, pnpm and other little things installed.
Airflow. Probably the most complex of environment templates, raising a DB in Docker and Airflow, allowing you to quickly and conveniently develop graphs and debug tasks. Needed for a couple of projects.

As I already mentioned, I run all environments in Docker containers. I live quite comfortably on a machine with 4 cores and 8 gigs. On the same machine I have Gitea with a CI runner and JupyterHub. That is, it turned out to be quite lightweight for my loads.

I will note that Coder and VSCode do quite a lot to make using remote environments convenient. For example, Coder provides a public SSH key in the interface, which can be connected to your Github/Gitlab/etc. account. The private key is automatically forwarded to the machines and allows you to seamlessly work with a remote repository without entering a login and password, without forwarding an SSH agent. VSCode can forward ports to a local machine with one button (and often on its own), so the experience of developing web services is completely seamless, indistinguishable from working locally.

By the way, as far as I know, you can connect to environments not only through VSCode, but also through other IDEs. Examples with VSCode only because I have not used anything else.

For the manager

Sometimes I involve other developers in my pet projects. In general, they can set up their own environment with Python or Node on a local computer, but with ready-made environments, everyone makes the first commit in the first hour after discussing what is happening in the project, what and where needs to be coded.

But the most revealing experience was with the students who are developing the Tvoy FF application, which I wrote about here. In the summer, that team had an internship, in which 1st-3rd year students participated, in which I participated as a leader in one of the areas. I have been participating for several years, but this year I decided to test Coder. Last year, it took me weeks to get together with each of the interns and help them set up the environment on their Windows XP or Aurora OS that appeared out of nowhere (let's not ask questions about what kind of interns came to code and can't install Python)This year I spent an hour onboarding each person, which included describing the task and preparing the environment.

EasyCode button opens Coder with pre-filled settings. One-click environment directly from the readme.

For myself, I have identified several important things after working with Coder as a team:

Pre-built environments are very effective when developers are not very experienced.
If experienced developers also use Coder for work, the template for projects of this type will develop, acquire features and remain relevant, unlike the documentation in README.
In my observation, when choosing between clicking one link in the readme to raise the environment and local deployment, the developer more often chooses one link in the readme.

In half a year, Coder has become an integral part of my work environment due to its convenience and ease of use. I think that in addition to this solution, there are other convenient code-env environments or other ways to quickly raise developer “sandboxes”, but I did not do any research, got the first link to Coder and I think I did not lose. I will be very happy to read the comments about which options passed me by.