Ideas for Onboarding

I’m currently on my third engineering team at Pluralsight. While each team has had their similarities, they’ve also each had unique tech stacks and code bases. The first couple of months on a new team is a time of accelerated learning, especially if the tech stack is unfamiliar. When I’m new to a team I find myself wanting to contribute as much as possible, while also wanting to have the space to develop my understanding of the new and unknown. In my experience some tasks hit this balance better than others.

Tech Debt Reduction

This post won’t get into the details of what tech debt is or how to go about managing it. If you’d like to know more about that, or you are new to the concept of tech debt I’d recommend this post. I have found that tech debt reduction strikes the perfect balance between contributing and creating a space to learn. It is my first choice of tasks for onboarding whether for myself or others.

Tech Debt Reduction is Unique

By definition, reducing technical debt won’t change functionality. If the code is well tested, running tests should give a clear indication that functionality hasn’t changed. These two facts give me the confidence to get my fingers dirty in the code while working on tech debt tasks. If I inadvertently change the functionality, the tests will let me know. In many cases this gives me the ability to become intimately familiar with a small portion of the code base, without needing the big picture to be explained to me.

The Best Way to Learn the Code is to Work in it

I understand code I’ve written, or refactored, better than code I haven’t. I’m going to go out on a limb and assume that is a universal truth. When I’m walking into a new code base, I’m obviously dealing with code I haven’t written. From that moment forward my understanding of the code will slowly grow as I work in the code. If I’m always adding new features I’ll gain an understanding of those new features, but I won’t understand most of the code that existed before I arrived. By spending time working on tech debt reduction, I’m not just making the code cleaner and more maintainable, although those are huge benefits. I’m also writing code in places I otherwise wouldn’t, and therefore gaining an understanding of functionality I otherwise wouldn’t.

Writing Tests

You may be wondering, “What if the code is not well tested? Wouldn’t that make tech debt reduction dangerous and scary for a new member of the team?". In a lot of ways that is true, that’s why my second choice of tasks for onboarding is writing tests. In a perfect world there shouldn’t be untested code, especially if you practice Test-driven Development (more on that here) But this isn’t a perfect world and the code base will sometimes have untested or poorly tested code. If you can find places like this, it’s a good way to jump in and learn without worrying about changing functionality.

Writing Tests Has Similar Qualities to Tech Debt Reduction

The things that make tech debt Reduction ideal for onboarding also apply to writing tests. Writing tests will also not change functionality because it is testing existing functionality. In order to test code you have to know what it does, so you will learn the code base along the way. You won’t learn the code quite as well as you could have if you were the one to write it. This is why writing tests for onboarding is the second best choice to tech debt reduction.

Seeking Context

Whenever you find yourself digging through unfamiliar code, it is not uncommon to find yourself asking things like, “Why is the code doing X?” or “Why is it written this way?". Asking the other members of the team these questions can only lead to positive outcomes. Either you will receive the answers to your questions leading to greater understanding of the code base for you, or the team will identify areas of the code that are poorly written leading to opportunities to improve the code. As a fresh set of eyes on the team it is important that you bring these questions up, because they may not stick out the same way to a person that is familiar with the code. In many ways taking time to seek context will be the best way to provide impact when you are still striving to learn the code base. In fact, deliberately setting aside time to read and study the code is a great way to learn without risking breaking things. Create time to study the code and then ask questions to clarify what you don’t understand or what you think could be improved.

Conclusion

Many times onboarding can slow the team down or lead to long meetings of drawing boxes and arrows connecting those boxes. But it doesn’t have to be that way. The ideas in this post are some of the best ways I’ve seen onboarding help make the entire team and code base better.