Onboarding a new developer is a fun but hectic time for any project. There are several hurdles you need to jump, such as getting credentials, explaining the domain, and demonstrating any number of team processes. However, I have found that assigning meaningful work can be the most challenging among all of these hurdles.
If you are anything like me, you may have struggled to assign work. Have you been stretched by endless pairing or just felt a constant pressure to provide constant guidance? Well, if so, here are a couple of ways I provide meaningful work.
Break Down Expectations
When a developer is starting out, break down the expectations. Be explicit about what you are looking for and how they can have success. I believe it’s crucial to have an engaged and open team to continue being productive. To achieve this, I focus on a few major steps.
- Ask questions: Initially, do not expect new developers to know the domain. There will be confusion. This is normal. Instead, focus on providing clarifications. When you see something that they don’t understand, ask. Also, the new developer should take the time to ask. Not knowing is only a temporary state if you work to alleviate it. Normalize openness.
- Make modifications: Once there is familiarity with the code, have the new developer make a small modification. This could be anything from changing some CSS colors to adding a button in the user interface. Keep it simple, and walk through where to add modification properly. Making small but visual changes can help reassure the new developer of their progress.
- Pair on a feature: Working in close tandem, pair on a large feature. Be explicit about your logic regarding how and why you used a given approach. Equally important, vocalize the bad ideas that you have. It helps to show this is an iterative process for everyone. Walking through the logic helps to explore the philosophies that drive the project.
- Drive a feature: Have the new developer drive a feature. Prompt them regularly for their thought process and help normalize talking it out. This can help to address any misunderstandings on the project quickly. This also helps build confidence in both general technical skills and the project.
Break up the Pairing
As great as pair programming is for efficient, high-quality development, it is important to recognize that pairing full time is hard. Onboarding a new developer can be difficult and tiring for both you and the new developer. Additionally, it’s not always productive. As a result, it can be crucial to give time for individual work, providing a much-needed break for both new and experienced developers.
This can be achieved in several ways, but here are a few examples:
- Do a deep dive on a crucial concept: Have the new developer dig into a concept on their own and report back their understanding so you can discuss.
- Walk through a feature: Point at a feature and help the developer walk the call stack to understand how all of the components fit together.
- Hypothesize an implementation: Grab an upcoming feature and ask for a thoughtful exploration of how to implement it. Ask for diagrams and graphs of how and where the changes should be made.
The most crucial part of any of these examples is providing the time to come back together and work through the findings. Blind exploration does no good if it leads to incorrect understanding.
Time Box Work
As great as providing solo exploration time can be, there is a point of diminishing returns. So how do we avoid wasting time and, instead, make meaningful progress? Time box work with goals. Be explicit about the action item for a time block and what deliverables you are looking for.
To achieve this, I break time boxed work into three phases:
- Talk about planning (what needs to get done). Discuss pitfalls to avoid and patterns to emulate.
- Give time for thoughtful exploration and executing the plan.
- Come together and review/constructively critique progress/answer questions.
Limit this time to no more than a couple of hours. Check in regularly to avoid true churn, but give the new developer space for exploration.
Struggle is Healthy
Finally, remember that struggle can be good. Exploring a new codebase can be a difficult and confusing experience on any project. No matter how familiar the new developer is with the technologies, every project has its own unique spin. This time dedicated to just being in the code will slowly but surely start to build familiarity.
This is a skill that is only learned by doing. You can give pointers and hints on how to explore a code base, but until you have done it yourself many times, these lessons often don’t sink in.
Final Thoughts About Onboarding a New Developer
In the end, it is most important to give the new developer the time and space to become comfortable with the project. Rushing this process will only lead to more stress and, in the end, create a less productive environment. Find work that is meaningful and that will impact the project. Then provide the support, time, and space for the new developer to understand.