While I haven't personally mentored anyone into a mid-level developer, I've had the opportunity to work at various companies and observe both successful and unsuccessful mentoring approaches. These experiences have given me valuable insights that I want to share with you.
Ticket size & watching deadlines
In a perfect world, every ticket would be designed in a way that a mid-level developer could complete it within three days. However, in reality, refinement meetings are often necessary to clarify the scope and requirements of a ticket. It's not uncommon for developers to encounter unexpected challenges when they start working on a ticket.
It's important to teach junior dev not to take a ticket for granted and to thoroughly evaluate its worth before starting work on it. Here are some key things to consider:
- Is the ticket worth doing at all? Sometimes, there may be a misunderstanding or miscommunication, and the ticket may not actually need to be completed. Sometimes devs just need to update the docs or operation management can change the business process.
- Is the ticket a duplicate of an existing issue?
- Does the ticket have the correct label? A ticket labeled as "frontend" may actually involve backend work and not have other related to it tickets labeled "backend".
- Is the suggested UX good enough? As a developer, you may have ideas for how to improve the user experience or implement the feature more efficiently.
- Are there any other clarifications needed? Sometimes, additional information may be required from the client, devops, or another team member.
For junior developers, it's important to know when to seek help and when to try to solve a problem independently. In order to strike this balance effectively, I would recommend a few key strategies.
First, if a junior developer is facing a problem they can't resolve on their own, they should leave a "question comment" on the relevant ticket or bring it up in a common chat. This can help ensure that others on the team are aware of the issue and can offer assistance if needed.
However, it's also important for junior developers to try to solve the problem independently before asking for help. A good rule of thumb is to spend at least two hours working on the problem before seeking assistance. This can help ensure that the developer has thoroughly explored all possible solutions and is not simply relying on others to solve the problem for them.
Daily standups can also be a valuable opportunity for developers to discuss any challenges they may be facing and seek input from their peers. If a senior developer feels that a junior developer is facing a challenge that may be too difficult for them to handle quickly enough, they may suggest a pair programming call with screen sharing. In addition, senior developers may also review the problem ticket and offer their own opinion or suggestions in the comments.
Code Review
In my experience with various activities, including fiction writing, drawing, and coding, one thing remains consistent - after working on something for a period of time, it becomes easy to lose a "fresh glance" on the project. This is simply a biological response in the brain to conserve resources. While taking a break from the work for several days can help regain a fresh perspective, a quicker and more effective solution is to ask someone else to review your work.
This is where code review comes into play. While some may see code review as a way for senior developers to mentor junior developers, I see it as an opportunity for knowledge sharing. Developers can ask questions about the code or project, which can lead to valuable insights and learning opportunities. Even a junior developer who may not feel confident in contributing to the code itself can still test the PR code and provide valuable feedback by identifying and reporting a bug. Comments with attached screenshots can be especially helpful in this case.
In this way, code review becomes a collaborative effort that allows all team members to learn from each other and improve their skills.
When code review for a pull request (PR) starts to take up too much time, it's not uncommon for the developer who is most responsible for meeting sprint goals to step in and have the final say in any ongoing PR discussions.
Meetings
Organizing weekly 15-minute one-on-one meetings with each junior developer can be an effective way to monitor their progress and ensure that they are growing and developing in their role.
During these meetings, it's a good idea to ask the developer about any new knowledge or skills they have acquired over the past week. This can help you understand their strengths and weaknesses, as well as identify areas where they may need additional support or guidance.
Additionally, it's important to ask how the developer felt about the tickets they worked on during the week. This can help identify any areas where they may be struggling, as well as celebrate their successes and acknowledge their hard work.
Conclusion
Mentoring junior developers can be compared to raising children - it requires patience, guidance, and encouragement.
As a mentor, it's important to give your mentees space and time to learn and grow on their own. This may mean stepping back and allowing them to tackle a problem independently, even if it means they make mistakes along the way.
Just like with children, it's important to encourage junior developers not to compare themselves to others. Instead, they should focus on their own progress and growth over time. By tracking their own progress and setting achievable goals, they can stay motivated and build the skills they need to succeed.
The difference is that meeting sprint deadlines is crucial. If you're unsure about a developer's level of expertise, it's best to assign tasks with lower priority. That way, if the deadline is missed, it won't have a significant impact. However, if a ticket with an upcoming deadline needs to be completed, consider pairing up the junior developer with another experienced developer.
The junior devs should learn how to keep other devs in the loop efficiently but you also have to approximately track their time by yourself (based on information you receive at daily standups) and act if the ticket takes too long.
Top comments (0)