Dare To Give Your Junior Developers Permission To Fail

Abstract

You must be willing to let your junior developers try, and possibly fail, at implementing patterns or tools they feel strongly about. This creates an environment that fosters mentorship, rapid growth, and respect. Less experienced developers must be willing to push boundaries, take risks, and fail and the right environment will help them feel safe and supported as they learn and grow. This talk will focus on how to be a good mentor, and the qualities you should seek when searching for a mentor.

Details

Outline

• Introduction
  • My journey from junior to where I am now after only 2 years of experience of Rails
  • Brief story about when my mentor, Nate Hopkins, gave me space to experiment and what an impact that had on my imposter syndrome and confidence
• Explain what kind of space juniors need to grow
  • Why failure is important
  • Fostering mutual respect and creating a safe space
  • Encouraging experimentation
• Benefits of creating an environment that encourages creativity
  • Mental health and burnout
  • Turning failures into teaching moments
  • Walking beside, instead of in front of, juniors
• Conclusion

Desired Outcomes

The main takeaway for mentors and senior developers is a better understanding, or gentle reminder, that they can help level up junior developers by getting out of their way and giving them the space to explore their ideas. For juniors, this talk will give them an insight into what a great mentor is, and what they should be looking for in a mentor.

Intended Audience

This talk is aimed at mentors and junior developers.

Pitch

The more experience you have, the further removed you are from the needs of your junior developers. With only two years experience, I have a fresh perspective on the positive and negative mentorship tactics that many juniors are currently being exposed to. The main premise behind this talk comes from a discussion I had with my team lead about a pattern I had introduced that others didn’t seem to like. The takeaway from that conversation is my lead wanted to give me the space to explore my ideas. If I succeeded, we would have a great new pattern to use moving forward. If I failed, it wasn’t something we couldn’t recover from, and I would have learned a great deal. The key to these two possible outcomes is that regardless of whether I succeeded or failed in my attempt, my mentor was excited to help me realize the lessons I learned from the experiment that would help me to become a better developer moving forward.

The other reason this talk should be considered is because juniors and mids need to see someone like them on the stage. I have been to two RailsConf’s and one RubyConf and took a lot out of the many talks I attended but none of them look like me. Most of the speakers are older, well respected Rubyists and it’s hard to justify taking the time to submit a talk when you think only talks from these more experienced developers will be accepted. By giving this talk, my hope is that I inspire other developers with similar experience to submit their conference talk ideas and continue growing the Ruby community.