The DevDiscuss Podcast begins with an interview and ends with commentary from listeners — and we like to feature the actual voices from our communi...
For further actions, you may consider blocking this person and/or reporting abuse
Pairing, pairing, and a little more pairing.
It naturally provides opportunities for them to learn:
on the team(s) that the onboardee needs to know.
Hi Nathan — this is great! Would you consider sending us a voice recording of this comment and/or other thoughts and suggestions on onboarding devs? Instructions to submit a recording are above.
We love to feature actual voices from the community on DevDiscuss 🌟
I've worked in very small and very big companies with different approaches to onboarding, here's a list of what a great one should have IMO:
Onboarding starts before "getting on board": thinking about new dev onboarding (also known as "thinking about team scalability and resilience") means having:
If you have this in place, then onboarding is really easy, and adding hands to the team is no more hassle than picking the right personality and some familiarity with the tools.
Oh, and all that will be beneficial all around, so making onboarding easier is just icing on the cake.
I have a lot of thoughts on this :D
Onboarding: How to give new hires a soft landing
Helen Anderson ・ Feb 10 ・ 5 min read
Hi Helen! We'd love to feature your voice on this episode of DevDiscuss! Would you consider sending us a voice recording summing up your thoughts on onboarding new devs? Instructions to do that are above 🙂
Done! Hope it fits the brief :)
In my experience, I would argue that the most important onboarding work is done by actively maintaining your project documentation.
There have been too many cases where little inconsistencies or additional steps are added throughout the development process that quickly turn onboarding into a minefield for new hires.
I think the goal of onboarding is to provide context. Any dev coming onto a new project doesn't know the history of the project, the decisions made, or the architecture. A good onboarding will provide info on all of these.
The actual process could vary depending on the level of the developer. A senior developer may be fine with a few diagrams and documentation. But an early in career developer might need some more hands on onboarding e.g. through pairing or knowledge sharing. The onboarding process should accommodate both of these options!
Good onboarding experiences for me have been:
Finally, a good onboarding process should have continual check in's. Either through an onboarding buddy or through your team. When I first started as a developer, I didn't ask questions because I was worried about disrupting others. This caused me lots of pain and slowed down my onboarding.
Making a safe space for someone onboarding to ask questions is really important. And we want to give developers the time to soak in all the new information.
I only have experience with very small, early-stage teams, and in terms of technical onboarding I really liked the process I went through.
Hi Greg! Thanks for these thoughts! Would you consider submitting this as a voice recording also? Instructions are above 🎧 🎧 🎧
For me mainly giving chances, I think with a good conversation instead of a "test" you can tell how someone is, if they are willing to learn.
So give them a chance to prove themselves.
Pairing with other people in the team, updating the onboarding documentation as they go over setting things up and reviewing things with the new developer.
woo hoo! Thank you :) 😊