Onboarding new developers into a project is a time-demanding and costly process, isn't it? Just finding a proper specialist isn’t sufficient. We all know that every software development company has its own practices and uses its own tools. And those tools might be even in-house developed.
Therefore, it doesn't matter how skilled and experienced your new team member is, they will need to learn a lot. Sometimes, it takes pretty much time for them to learn all about the project they start working on (to start coding new features, for example), about the company’s corporate culture, and the commonly accepted practices and processes. Needless to mention the extensive documentation, and similar.
In most cases, you might not even be sure that your new team members can handle all the load of new information on their own. So, somebody more experienced is needed to help them, to guide them through the labyrinth of new information. This "somebody" is one of your more experienced developers, and they also will spend their time on onboarding procedures, guiding and coaching their new colleagues. It means more expenses.
At Mad Devs, we aim to reduce onboarding costs. To do so, we provide new developers with extensive documentation, tests, and high-quality code. No, we don’t eliminate the need for coaching and guidance from more experienced team members. But the mentioned prerequisites allow us to ensure the reduction of the learning curve for new developers. Therefore, they can move to the actual work faster. Here are some of our practices that help us to make the onboarding process cheaper and faster.
Clear ReadMe documentation
For us, onboarding is the transfer of knowledge. In this specific case, it is pushing somebody new from not knowing anything about our practices to pushing code in production. We do it by creating and maintaining clear ReadMe documentation.
Let me clarify what clear ReadMe documentation means.
First of all, a clear ReadMe document shall be easy to understand (for a new developer) and easy to write and maintain (for an experienced specialist, the one who writes it). A ReadMe document can become a great guide into the project if it:
- Explains how the team works;
- Indicates the correct code or the code your new developer shall look for;
- Answers the questions your new developer might have;
- Is asynchronous, which means that a developer can read it and find all needed information without involving anybody.
Here, everything might be clear except for the last position: questions that your new developer might have. Ok, let me elaborate. What can those questions be if a person is just about to get involved in a new project? I have selected the most crucial ones, but you can add your own, depending on the specifics of your company and practices accepted:
Questions about a product
How to get it up and running locally? A developer can launch tests locally to ensure they run successfully.
How can it be used?
How to configure it?
Questions about code organization
How is the code organized and how can I find the needed code?
How is the code written (the process, patterns)?
Questions about the team’s processes
How can I submit a PR?
How can I deploy the code?
Basically, clear ReadMe documentation allows a new developer to understand what the project is about, to launch it locally, to test, and to deploy it.
Extensive test coverage
There is not much to talk about here. Tests covering more than 50% allow a new developer to understand the project’s business logic. If tests are clear, properly written, maintained, and updated, and if the developer can launch them, it will reduce the onboarding costs significantly.
An infrastructure architecture diagram
If you have seen an example of an infrastructure architecture diagram, you know why it is needed and how it can help. It shows the new developer the project’s constituents and how they are connected.
I would compare an infrastructure architecture diagram with a roadmap. Like a detailed roadmap, it explains where and how you shall move. It also allows reducing the guidance from more experienced developers.
CI/CD (continuous integration and continuous delivery) pipeline
A CI/CD pipeline automates your software delivery process. It builds code, tests it, and deploys a new app version.
With CI, every change in the code triggers a build-and-test sequence. Then, it delivers the feedback to the developer who has implemented the code changes.
CD performs infrastructure provisioning and deployment.
Any failure at any stage triggers a notification to a responsible developer. If everything runs smoothly, the entire team receives a notification about a successful deployment to production.
How can a CI/CD pipeline be used to reduce the onboarding costs?
It helps a new developer to understand how the project is assembled, in what stages it is done, and how it is deployed.
Transparent issue tracking and IDE
We link all merge-requests and commits to a specific task in the issue-tracker. By revising the task, a new developer can see the work process on a specific task in progress:
- How the task was described and what goal was set;
- Who has been working on it;
- What actions have been performed and by whom;
- Who tested the task and what tests were run;
- What fixes were implemented, if any, and similar.
Along with the organization of the team’s work, IDE (Integrated Development Environment) application allows eliminating the need for manual configuring and integration of multiple utilities. Every utility that is commonly used by the team is already integrated into the team’s workbench. It also allows new developers to start using the team’s utilities and tools asap and develop new features.
You might be wondering what happens if some artifacts are not available in the code repository or they are not as required? Well, in such a case, be ready for the long and costly onboarding of every new developer.
Latest articles here
