loading...
The DEV Team

Any tips for onboarding developers? Let us know for the chance to be featured on a DEV podcast!

graciegregory profile image Gracie Gregory (she/her) ・1 min read

The DevDiscuss Podcast begins with an interview and ends with commentary from listeners β€” and we like to feature the actual voices from our community!

This week's prompt: "What are some good practices when onboarding junior devs β€” or devs in general? "

For your chance to appear on an upcoming episode, answer the question above by:

  • Calling our Google Voice at +1 (929)500-1513 and leave a message πŸ“ž

  • Sending a voice memo to pod@dev.to πŸŽ™

  • OR, leaving a comment here (we'll read your response aloud for you) πŸ—£

Please send in your recordings by September 2nd at 5 PM PT (8 PM ET, 12 AM UTC)


Don't forget to check out the latest episode, released on Wednesday!

Posted on by:

graciegregory profile

Gracie Gregory (she/her)

@graciegregory

Content Manager @ DEV. "You know what this sentence needs? An Em dash!" - Me to Me

The DEV Team

The team behind this very platform. πŸ˜„

Discussion

pic
Editor guide
 

Pairing, pairing, and a little more pairing.

It naturally provides opportunities for them to learn:

  1. The tools
  2. The codebase
  3. The domain
  4. The workflow(s)
  5. The etiquette
  6. The people

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:

  1. An overview of how the company works, its major areas of operation and how it makes money
  2. A detailed intro of the team's mission, expectations, and related teams
  3. A quick briefing on how project management works at the team
  4. How to navigate the corp bureaucracy if we are talking big company (ticket filing, compliance stuff, etc)
  5. Slack/email/general communication etiquette
  6. How to set up your local environment and start working
  7. Coding standards, test and deploy guidelines
  8. Where to look for internal documentation
  9. How to collaborate with other teams
  10. Who to ask for help when things get funky
 

When I was starting out as a developer at a startup, we had a practice that the new dev would have to spend their first 2 weeks in QA. The reason was so that they could learn the product, meet a team that would be looking at their code through a different lens and get a feel for how we shipped software.

Anywhere I've lead development teams, we've continued that practice - it's a great way to gain an appreciation of where your code goes, who has to see it and what quality should be - from the UI screen all the way down to troubleshooting logs and errors.

The secret to this practice was to also identify if the developer is willing to learn new things, how they handle being thrown into their comfort zone and whether they really are respectful of everyone on the extended team.

This was/is our probation, if they made it through this, we know we can teach them anything and they are willing to learn whatever we can throw at them.

Apart from that, I always like starting off junior devs with bugs, get them a broad appeal across everything the product does - not only does this help them learn the product suite, but they learn about source control, they learn about the designs used in the software, they learn about unit testing, they learn how to make things better.

 

Hi Greg! Thanks for these thoughts! Would you consider submitting this as a voice recording also? Instructions are above 🎧 🎧 🎧

 

Left a message on the google voice this morning - hope it came through okay!

woo hoo! Thank you :) 😊

 

Onboarding starts before "getting on board": thinking about new dev onboarding (also known as "thinking about team scalability and resilience") means having:

  • general/product goal/architecture documentation well laid out and kept fresh
  • clear processes for HR (first), and commit/push/test/CI/collaboration/release (better if automated)
  • and a practice of reaching out and speaking about how the organization works and how it pursues its goal of attracting talent and doing good business.

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.

 
  1. Don't be a dick. And being a "nice asshole" (backhanded, passive aggressive, etc.) doesn't count as not being a dick.
  2. Don't make assumptions, about what they know or what they don't know.
  3. Should be a duh, but usually isn't (relates to point 2): Good documentation AND discussion is a must. You may think your code is self-evident, but they haven't been working on this project for months or years like you have.
  4. Not nearly enough people do this: Architect with the junior developer in mind. It doesn't matter what your project accomplishes or aims to accomplish. It should be simple enough for a junior dev to quickly get up to speed to add or make modifications to the project as they learn (relates to point 3, but specifically addressing the code/infra here).
 

I only have experience with very small, early-stage teams, and in terms of technical onboarding I really liked the process I went through.

  • The README contained all the information I needed to set up my local environment
  • If there was anything missing, I could ask a colleague for help, and add the missing info to the README. This was also my first commit and contribution to be merged, which gave the nice feeling of a quick first win, and improved the README for future onboarding.
 

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:

  • Onboarding steps documented and up to date.
  • Automating things like permissions to projects.
  • Culture doc for things like meeting expectations, fun events, or slack channels to join.

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.

 
 

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 :)

 

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.