This is the first in a series about what software developers can learn from other disciplines that we often perceive as unrelated to our field.

1. What software developers can learn about onboarding from the crochet community
2. What software developers can learn about client engagement from preschools
3. What software developers can learn about estimating from road construction
4. What software developers can learn about consulting from hair salons

This blog post borrows from my conference talk Crochet, Code, Craft that I first delivered at Madison+ Ruby 2018.

One of the challenges we all face eventually is onboarding. Crafting a successful onboarding process is more difficult than it seems, and as a result, the onboarding process is often an afterthought. A successful onboarding process is more than giving the new team member time to set up their development environment and poke around the code base. Onboarding should be intentional and directed.

My experience within the crochet community has given me some ideas for ways we should improve our approach to onboarding.

Welcoming Community

The first and most overlooked step in onboarding is a welcoming community. Did we create a space where the new member feels comfortable asking questions and reaching out for help? If the answer isn’t unequivocally yes, then we can do better.

Within the crochet community, I’ve noticed an incredible willingness to answer questions and provide information for beginners. Questions are met with enthusiasm and answered thoroughly. In discussion forums, I often see follow up questions posed back to the original poster and threads started discussing techniques in depth. More so than in most social media (I’m looking at you Twitter…), I see debates and opinions shared respectfully which helps everyone learn and improve.

We should embrace this openness more fully in the software development world. I know I’m guilty of being “too busy” to sit with a new hire and help them set up their environment or answer questions about a particularly ugly part of the code base. But considering that this person is joining our team, we should be excited about helping them. We should reframe our attitude about onboarding; it should be a priority of the company and treated with the same importance as client/project work.

Discussions started during the onboarding process help everyone on the team learn, and questions from new team members can open our eyes to different perspectives and ways of thinking. This is a new team member’s first opportunity to bring their experience to the table and share their background with the team. Let’s make sure they feel comfortable doing so by creating a welcoming, inclusive space from the start.

Clarifying Shared Language

If you’ve ever started on a new project or with a new company, you know what its like to step into an alphabet soup of unknown acronyms and niche, domain specific language. Taking the time to clarify shared language for new folks is a great way to make them feel included. If this step is missed, at best the new team member will feel excluded and lost. At worst, they’ll miss crucial information to do their job well.

Well written crochet patterns include explanations for all of the stitches, abbreviations, and techniques used in the pattern. Even the most standard abbreviations are defined at the start. I appreciate this dedication to approachability. When a beginner downloads their first pattern, they have all the information they need to get started. Some pattern designers go a step further and explain their specific crochet style, e.g. “I tend to crochet really tight. You may need to use a smaller hook size for your project to look like mine,” which gives the crocheter even more information about how to interpret the pattern.

In software, we often speak in inaccessible jargon and new folks might not know if we’re talking about a new technology, something specific to our client’s domain, or company-speak that we made up to make internal communication faster. We should take the time to make sure we’re defining all of the jargon we use whenever we think there’s a chance our audience might not know it.

Multiple Modes of Communication

Maybe I’m alone in this, but whenever I need to learn a new codebase I’ve had to sit down with someone as they open files, read through code, and explain methods. This is a practical exercise to get through the project, but it’s not very creative and it definitely doesn’t accommodate many learning styles.

With crochet patterns, the pattern designer provides written instructions for how to complete the project. These instructions are often accompanied by step by step pictures so you can compare your progress as you work. But many pattern designers are going a step further and providing stitch diagrams for their patterns. For people who find written instructions difficult to follow, the stitch diagram can be easier to understand. The more ways someone communicates an idea, the more likely the audience will understand and enjoy the message.

When we are tasked with explaining code to a new team member, we should remember this. Instead of opening files and reading code, let’s set aside some time to draw pictures and show the data flow through the app or the composition of classes and how they fit together. It will be more fun and the new team member will more quickly be able to create a mental model of the project they’re joining.

At first glance, the larger crochet community and a tech company may not seem to share many similarities, but there’s a lot that the software development industry can learn from the crochet community. The crochet community kicks our butt at welcoming and onboarding beginners, and we should take notes.