How can you coach level 1–2 developers?

As a principal developer, one part of my job is to help senior developers to coach level 1–2 developers.

I recently built some tips on how it can be done!

Finding options

Level 1–2 developers have less experience and are less familiar with the existing system. Making something work is sometimes a challenge in itself. This leads to situations where the implemented solution is the first one they find. Discovering a non-optimal solution at the review phase is costly.

Try to encourage level 1–2 developers to challenge themselves by finding at least two ways of solving a problem. And by listing pros and cons for each. The goal is not to be super strict with documentation and everything but just to help create a new habit. Depending on the maturity of the level 1–2 developer, maybe the developer will need help to find other options or select the best one.

Showing bad examples

Level 1–2 developers sometimes learn better with real life examples. Reading theoretical concepts in books is sometimes not the best approach because they are not able to translate that new knowledge to past experiences.

When you are implementing a new feature or refactoring some code, and you struggle to achieve that because the existing code does not respect some well documented good practices, take some time to pause everything. Share your screen with a level 1–2 developer. Explain the context, what you are trying to achieve and what is blocking you. Then show how to fix the existing code if possible, to demonstrate how it enables future development.

Pro tip 1: If you are not well structured in your explanations, it can confuse people, and they will not learn anything. Take a couple of minutes just to prepare yourself before doing your demonstration.

Pro tip 2: Do not finger-point. Everybody makes mistakes. Focus on how to make things better.

Sharing references

We are not aware of what we do not know. Level 1–2 developers are particularly affected by this. At some point, any guideline should be backed by some references.

During code reviews, do not hesitate to share reference links that fully address a subject or a comment.

Pro tip: Include a summary and simplified version directly in the comment, that applies specifically to the related code. References should be added on top for deeper understanding.

Leaving traces

Level 1–2 developers do not realize how much information they will be exposed to over the years. Do not trust your “2 years later” self. Highly complicated things you are managing right now can seem easy to understand. But in 2 years, you will have forgotten the details.

Encourage level 1–2 developers to keep notes of things they are working on. It can be:

• tips how on to test some scenarios
• reasons leading to a difficult choice
• high-level flow of a business process
• etc.

Pro tip: Documentation is not for everybody. But if you detect that some level 1–2 developers are good at it, encourage them to make those notes public. Others can benefit from that.

Co-debugging

Tracking issues is sometimes an art. Level 1–2 developers are typically better at writing new code than understanding and debugging an existing system.

Do not hesitate to take control and share your screen when you help troubleshoot. Be verbose in your mental process. Explain your theories, what you want to try in advance, then show how to validate hypothesis. Give your tips and show how you work.

Pro tip: If you feel the developer could be able to continue the investigation, consider stopping after the first breakthrough or after you establish a new hypothesis to validate. But do not let them be stuck for hours for nothing. Good live investigation explanations could be better than letting people become discouraged.

No upfront gold plating

It can be tempting for a senior developer to maximize the risk reduction of sprints by analyzing everything upfront, and tasking everything with so much detail that level 1–2 developers just implement what they are told to.

Let people make mistakes. Then let them fix their errors. Level 1–2 developers learn so much by doing that. And they do not forget.

Pro tip: Use your judgement. If the work is done on a critical path for something really important, it is probably not the good time to prioritize learning. Be strategic and pragmatic. There is a balance between team velocity and an individual’s learning. But a lot of the time, focusing on the learning aspect will increase velocity in the medium/long run. Judgment calls each time. Yes, it is hard to do.