How to automate the onboarding of new developers (and keep them happy)
Good onboarding is like a first date – it can make or break a long-term relationship. In fact, employees (and developers) are 58% more likely to stay with the company after three years if they receive proper onboarding.
Unfortunately, it still happens often enough in the beginning that new developers have to wander around like confused tourists in a strange city. Without directions. Without a map. They have to navigate on their own through narrow alleys and spend days looking for information (keyword: equipment and documentation). It’s like waiting in line at the supermarket: You actually want to pay right away, but you have to wait until it’s finally time to move on. And when it finally goes further, the cash register may fail or the ATM card may not work. For developers, this means they have to get to grips with the local development environment and get the company’s own software up and running. That takes time.
But there is another way: Setting up the development environment could also be done via self-service at the push of a button. Standardized. Fast. Simple. But let’s start at the very beginning. With the story of developer Sarah.
Table of Contents
The not-so-great onboarding story of developer Sarah
Sarah, a new developer, just started her first week at a new company. She was excited about the company from the start, “Dream job found.“.
But on the very first day, her anticipation was dampened. The promised laptop and access data were not provided.
Despite asking, she couldn’t be told an exact date when the equipment would be ready and she could finally start working properly. So she had to wait. After a day, there was still no laptop and no access data in sight. Sarah became impatient and asked again. A few hours later, she was finally handed a laptop and everything else. The laptop, however, was relatively old and weak. But ok. At least for now she can start working.
Now it was time to set up the local development environment – the IDE, the software to be developed…just everything. That took time. The documentation was minimalistic and partly outdated. When she was working on a problem with a colleague, he just said: “That’s the way it is with such complex software. We regularly struggle with our development environments.” Several days passed before everything finally worked.
The setup was then completed at some point. But when a testing tool was started a few days later, the laptop completely crashed. All to no avail.
Sarah was disappointed and frustrated. She felt like her time was being wasted. She wondered if the company and the software were really as good as she thought they were. Unfortunately, Sarah’s experience is not unique. Many developers have had similar experiences.
Technical onboarding: hardware, software, documentation and access data – efficiency looks different
Among many other areas, “technical” onboarding is probably one of the most important. After all, you can’t work without equipment and tools. Without access to documentation or a wiki that explains how the software works and how to set up the development environment, everything comes to a standstill. Ideally, everything is prepared and functional. In practice, unfortunately, things usually look a bit different.
Instead of a smooth start, developers have to wait for days until everything is finally in place and working. And even then, developers encounter the next hurdle: The documentation is reduced to the minimum, outdated, or even worse – it doesn’t exist at all. Then it takes hours, often days of research and trial and error, just to finally get the local development environment up and running. In fact, this is one of the biggest hurdles to getting started with actual work.
Problems with the local development environment then perpetuate themselves and cost valuable time – in fact, 61% of users surveyed in a GitLab poll say they spend at least once a month and 31% at least once a week troubleshooting their development environment.
This frustrating process is not deserved by developers, managers or HR. And especially in times of a shortage of developers, it is even more necessary to offer a good onboarding and experience from the beginning.
Onboarding with Remote Development Environments (RDEs)
Remote Development Environments from Cloudomation help to get the “technical” onboarding done in seconds. With RDEs, development environments are available instantly. The constant troubleshooting of local development environments is reduced to 0.
Read more: What are RDEs?
With RDEs, developers can start working immediately and focus on what matters most: Writing code. To do this, they can continue to use their favorite IDE, because with Cloudomaton RDEs all sources are included via a file mount. Changing branches is child’s play, since only the RDE needs to be changed. Compiling, testing – this is all done on a remote server. This also solves the resource problem. Low-powered laptops are not a problem. Theoretically, developers can also work on a tablet.
In Sarah’s case, that would have meant waiting a day for the equipment. But then she would be able to get started immediately and without waiting.
Read more about RDEs in our Whitepaper: Take the productivity of your IT team to the next level. With Remote Development Environments
For DevOps teams, RDEs are a dream: They can define and standardize the RDEs in a way that is best for business and software development. Developers can then launch the RDEs via self-service.
Managers get a system that prevents code theft because the RDEs can be air-gapped. With standardization, efficient work is guaranteed.
And HR? HR can enjoy fast onboarding and a developer staying with the company for the long term.
Reduce onboarding time. Free developers like Sarah from time-consuming tasks. Standardize your development environments with Cloudomation RDEs.
Subscribe to the Cloudomation newsletter
Become a Cloudomation Insider. Always receive new news on “Remote Development Environments” and “DevOps” at the end of the month.
Why Bug Fixing Costs Companies a Fortune
Why managers and developers get in each other’s hair when buying remote development environments (and what we can learn from this)