Abstract
You were living alone in the town of Ruby-on-Rails until you decided to open up your spare room to guests. Now your first visitor has booked in. Her arrival is imminent.
How do you prepare? How can you make sure she has a great visit?
Let’s explore the art of code hospitality — working on codebases in a way that respects your teammates and provide for their needs. By working hospitably, we can facilitate team productivity and help new members quickly feel at home.
Details
This talk will mix code examples into the story of our guest while sharing practical guidelines for code hospitality.
Throughout the talk, we will revisit case studies introduced in Part I and see how they map onto different ways of writing code and explaining that code to others. We will explore what makes some approaches more effective than others.
Proposed outline
Part I: What makes a good host?
An introduction to the story in the abstract, and a discussion (maybe as an interactive Q&A, show-of-hands) of what it means to be a good host.
Part II: The host’s perspective
The guest’s arrival is imminent. We discuss how to prepare considerately for their first encounter with your codebase. We look at how you map out your codebase graphically and practise explaining that diagram to somebody else.
Part III: The guest’s perspective
Your host wants you to have a great visit, but it’s not all on them. As a newcomer, how can you investigate a new codebase effectively and work with team members to get the most out of your early days?
Part IV: Managing surprises
Now our two characters are in the same place. Despite preparation, there are always unexpected challenges. We discuss how to manage such issues, so that guest and host can both have a good experience.
Conclusions
There are practical steps that you can take when organising your codebases to help with the onboarding of new team members, particularly those who are less experienced.
Audience members will leave the talk with:
Guidelines for creating a hospitable codebase
A framework for explaining concepts to others designed around the analogies relating to map-drawing/map-reading and an effective guest-host relationship
A pair programming challenge. When done constructively, pairing is a valuable way to accelerate the learning process for less experienced developers. However, it is often seen as a counterintuitive practice, which makes it difficult to introduce into workplaces. Hence, I will announce a pairing challenge, and invite my audience members to participate if the talk has intrigued them. I’ll set a time limit — e.g. 4 hours — and a few guidelines. I’ll encourage developers to approach one less experienced team member to complete the challenge with. Participants completing the challenge will be encouraged to join a discussion online, sharing their experiences whether good or bad.
Pitch
“It’s like Rails is my city and I’ve lived here all of my life," my pair said to me.
I was struggling to pick up a concept that was simple for him. I was frustrated and anxious that he was disappointed in me. His words put me at ease and put my struggle in perspective.
I was a visitor in his hometown. I was hoping to make this place my home too. I had a friendly local by my side. How could I make the most of this?
At the heart of great software is solid teamwork. Many teams suffer because developers do not know how to guide those less experienced than them. The exercise of writing a hospitable codebase helps you to keep in mind that two people often approach the same problem with completely different mental models. Having this perspective means you can more effectively help new teammates.
Bio
Nadia co-founded Ignition Works in order to find fun and sustainable ways to build worthwhile software products. She has taught good engineering practices through pair programming at Pivotal Labs and on their Cloud Foundry team. She originally learnt to code at Makers Academy and she runs The StoryGraph, a creative writing e-publication, in her spare time.
RailsConf 2016 - Accepted [Edit]
GORUCO 2016 - Accepted [Edit]
Nordic Ruby 2016 - Accepted [Edit]
Abstractions 2016 - Accepted [Edit]
Add submission