A guide to a great developer onboarding for a faster, peaceful start – The start of a new job or project can be a source of excitent, or fear (or both, or something in-between). There’s a lot to learn, technically and business wise. You don’t want to feel like a burden to your (new) colleagues by drowning them in questions, but you also want to start fast.
The onboarding of new members on a project can be eased by a few actions that I’ll explain below. I’ll also go through what I think is interesting to share quickly with newcomers. So yeah, this article is particularly meant for those who onboard new engineers (project managers, tech/dev leads, senior/medior developers…), but if you are yourself a developer struggling with starting on a new project, I encourage you to share it with your team, propose some solutions and make sure they’re implemented, and make the world better for your future colleagues 🌈.
“Don’t panic” *
What should we teach the newbies during their onboarding?
Anything that you get asked or must repeat every time there’s a new hire. Here’s a list to begin with but feel free to add your ideas in the comments below!
Work flows
How do we organize our day, how do we do code reviews, how do we handle the follow-up of our tasks/tickets, how do we work with the business, where does our responsibility start and end, when and how do we release, what’s our CI/CD pipeline… This seems obvious but I often had to figure out a lot by myself, while this is different in every team, and you usually end up learning how to do it right when you got it wrong.
Social contract and values
What do we expect from each other, how do we communicate, what are our boundaries, what do we value in our colleagues, what do we expect in terms of mentoring, what does “team spirit” mean to us, what are our social rituals.
Business
What’s our business, what’s the goal of the project, who’s our client, who’s our end-user, how do we gather the needs of the business, explain the specifics of the business and of what’s to be implemented in the application.
Tech
What’s our technical stack, what are the other systems that communicate with our(s), what are our preferred (or mandatory) tools in the team, why those tools/techs, links to the official documentation.
Environment setup
How to set up an environment for local development. The most painful of all topics.
Team and project management
Do we scrum, what Agile tools are we using, do we work on several projects, how do we assign our resources, what are our regular meetings, who are the owners.
The “tools” to onboard new colleagues: how to make life easier for the noobs
Reusable content
In a field where it’s still pretty difficult to hire and the turnover is higher than in most sectors, any training material or documentation that can be reused, should be reused. Giving a training or an explanation to a newcomer, or even to current members of the team? Record it (especially if it’s a video meeting, which makes it super easy)! You write some explanation on a topic? Save it for later reuse.
An up-to-date wiki
With great tools like Confluence or Teams wikis, it’s really easy to create a central point of documentation. It should be a must in any team. That’s honestly become one of my questions to the company when I get a job interview. If there’s no wiki or it doesn’t seem to be taken seriously, big red flag for me.
Documentation is all about empowering team members and sharing knowledge (I’ll publish a post about knowledge sharing in development teams soon, subscribe to get notified), and it should be a team effort everyone contributes to.
An easy-to-read code
KISS and YAGNI. Don’t overcomplicate your code. Write it in a way that can be read by most people, not only geeks and senior developers, choose good names, make it concrete… As someone once said, code is like a joke, if you have to explain it, it’s not that good. Sometimes, adding one or two lines of code, a variable assignment, or using a less exotic way of writing your code can save you some time when you don’t have to explain it later. And for obscur part of the codes, document what it does with comments.
README
Have a readme file with all projects on how to install and start them, a bit of explanation of the purpose of the project, the connections to other ones…
All this doesn’t erase the need for mentoring and follow-up!
Adopting those tools doesn’t mean they should be given to a newcomer without any other explanation or that it’s sufficient for the whole duration of the project. Receiving explanations from someone or reading documentation/watching a video is really different, and the chosen method should be decided upon several criteria, like the kind of stuff the person has to learn, their experience, their way of working…
But those tools can help lighten the workload of the engineers who usually give the explanations, and should be considered as a starting point for basic tasks or project overview, or as a memo (there’s so much to learn at a project start, that it’s difficult to remember everything the first time).
Credits: Illustration image based on a picture from Pixabay
*Quote from Douglas Adams’ “The Hitchhiker’s Guide to the Galaxy“
