Software developer mentorship today has issues. Hiring junior software developers and mentoring them to become mid and senior developers is an important goal for many if not all companies. In an ideal world, we would see a lot more mentorship happen in practice. However, we do not live in an ideal world.
In the real world, some software developers have limited mentorship and support in their workplaces. The sad reality is that most junior software developers must figure things out on their own. Today I’ll strive to identify the main constrains that hinder software developer mentorship and how to tackle them.
Why is Software Developer Mentorship Broken?
For one, junior, mid, and senior software developers must complete tasks on each sprint to move up. This creates time constrains and limits mentorship and learning times. Today we’ll discuss this conflict. We’ll also explore the current state of software developer mentorship, why it’s broken, and how to fix it.
As you read this post, most junior software developers are left out there to figure things out on their own. Either that or they get very limited software developer mentorship and support in their workplaces.
Mentoring junior developers is a novel idea. I wish that a lot more of it were happening. Companies want to invest in developer mentorship, but sadly there are many reasons preventing that from happening in practice.
There are some very serious and common issues. While some have to do with the individual software developer’s personality, most can be fixed.
I’m very confident that it’s the companies themselves in a lot of cases that are the main obstacle preventing software developer mentorship from happening. Here are some common constraints or limitations that hinder successful mentorship from taking place:
- Company culture – Short-term business goals
- No manager – The senior software developer predicament
- Developer personality/ego
Company Culture – Short-term Business Goals
The biggest hurdle in software developer mentoring is the company itself and its culture and support for setting up a mentoring framework. While most places when hiring will ask senior software engineers how open they are to mentoring junior developers or to tell them more about how they mentor junior developers, among similar questions, very few companies in actuality create a supportive culture of cultivating learning that can allow junior developers to grow. Most companies don’t wish to hinder the mentorship, and the main reason for a lack of mentorship is business goals.
The Software Developer Mentorship Killers
- Scrum & Velocity – Many companies today work using Scrum, which means each developer needs to complete certain tasks or work items in a given sprint. While this allows companies to align business objectives nicely in dedicated sprints and measure their team velocity, it also creates a big downside. It directs junior, mid, and senior software engineers to focus on their short-term sprint-related tickets and on getting things working. They are measured against that, and the focus shifts to completing the task rather than on longer-term goals. This means that they push teaching (helping other developers) and learning (re-writing your code) aside to a lower priority. Even when teaching and learning do happen, I’ve found many junior or mid developers to be less open to feedback or re-factoring of their code. They’re more set on wrapping up their work and moving on to the next priority.
- Kanban with Sizing – While it’s more apparent in Scrum, even in Kanban when using measured tickets, which many companies do, the software developer is focused on the estimated time for that ticket, leaving little time to guide someone else. Yet again, focus shifts towards delivery rather than towards learning and re-factoring.
How to Fix It
The biggest and hardest fix for this situation is a shift in company culture and thinking. The company has to compromise and set up a framework for software developer mentorship success.
There a few ways to achieve this. They all require change, compromise, and focus on long-term individual software engineer success, not just on features and instant gains.
I’m not saying that the company shouldn’t produce and be agile and fast to iterate, but the company has to make certain investments in their developers.
Starting is Easy!
The good thing is that you don’t need to introduce this company-wide from day one. You can try it with a small team or even a sub-team. Try to experiment with even two developers, a junior and a senior. It’s very simple to begin. Here are three tangible ways to do it:
- Mentor Tickets – Create specialized mentorship ticket tasks. Just
like there are “story”, “epic”, “bug”, “spike”, and “task” items, I
suggest we also add “mentor” type tickets. These are work items that we
expect a younger developer to take on and learn together with a senior developer. These should be real tickets of work that need to be done. However, these tickets would be different in many ways:
- These are tickets for two people. So, if you’re using Scrum, you can have the developers split it up to mentor and mentee tickets.
- The time estimates of these tickets are flexible and might require double or triple the time of a regular ticket
- You can easily expect these tickets to include one or more re-factors during the ticket.
- These tickets can also be broken down further if a senior gives “homework”, such as tasks to investigate and learn.
- The delivery of these tickets is just as important as the learning process and the growth achieved through these tickets.
At a later time, I’ll discuss how to approach and what to do in a mentorship ticket and how to conduct a successful mentorship.
- 10% Improvement Ticket/Time – For those that prefer a more casual approach, they can allocate 10% to improvement/growth time. In this approach, a ticket, task, or time is allocated 10% of the time in each sprint. This time allocation allows developers to learn, read, and mentor each other. It might include things like reading about a specific design pattern and trying to implement it along with a senior member. Using this approach, you essentially allow your team to decide how to spend this time and with whom.
- Good Team Mixture – Another issue is your team mixture. If you have five senior software developers and one mid, that might not be the ideal setup for mentorship success. Such a team would be wonderful to work together on tight timeframes and urgent complex tasks, but to facilitate learning, you should create the biggest knowledge gaps. Have a ratio of at least two seniors to one junior software developer. Avoid too many mids (or ideally any mids) in this group.
Ideally remove mids from the mixture to start with
Mids tend to feel they are just like seniors and might resist mentorship. On the other hand, that might misguide juniors with a lack of experience or knowledge. The best thing to do is to have a large enough group of seniors that can still produce results and have juniors that are eager to learn and do some joint tickets together. This will create a harmonious team mixture while still allowing you to get business results from that team.
- Start Small – Grow Big – Any huge company culture shift is almost always doomed to fail. People tend to be resistant to change, especially when said change has yet to happen. The great thing about this is that you can start with a group as small as two people, a junior and a senior, and assign them 1-2 mentor tickets. See how they manage through those. You might find that the senior developer is still free to do his work while the junior is happy and excited to learn and grow.
- Either way, experiment – Just please remember that during this experiment you must remove all burden of deadlines from the equation. You can reintroduce them as the mentor and mentee become more comfortable with these types of tickets. Also, you want them to get “wins” on the board to feel comfortable and confident. If the experiment goes well, bring more team members on to do mentorship tickets.
No Manager – The Senior Software Developer Predicament
The second issue that I’ve come across is when the senior software engineer and junior software engineer are on the same team as peers. While the junior might respect and admire the senior, and while the senior has every desire to teach and mentor the junior, there still might be a gap.
As a peer rather than manager, the senior cannot ask the junior to re-factor, re-do, or follow his guidance. All of this is based on the deadlines, desires, and wishes of the junior developer.
Understand your junior engineer better
The junior may sometimes ask the senior for help, but only in cases when he is completely blocked or unable to perform. While that might seem like a good way to do the mentoring, it’s not.
You don’t want your junior software engineer going wild and only asking for help when he becomes blocked. I faced this issue myself many times. In these cases, I would see bad code and would try to help a young developer, only to find that it’s easier just to take that bad code and re-write it myself.
Understand your senior engineer better
It’s all because people and companies align their goals toward delivering features and completing tasks rather than learning, creating good code, and avoiding technical debt. As a senior software engineer, I can say that when you’re someone’s direct manager, it’s simple to mentor. It’s much harder when you’re just their peer.
How to Fix It
First off, it’s important to get company support. Just as I outlined before, if dedicated software developer mentorship tickets and a proper framework existed, perhaps some of the focus would shift.
It can be the goal of a junior software engineer to learn and produce good goal, and that can align with the company goals. I cannot image how much companies pay later for bad code.
Company support is crucial
If the company sets up targets for junior developer to learn and produce better goals and allocate the time and resources to do so, the output of the team will be better. The company can follow the suggestion of trying out mentorship tickets, which focus on learning with outcomes. It can also set up any other framework they feel works for them.
I believe that focusing on aligning personal goals to company goals can help resolve this issue as well.
Software developers come in all sorts of personalities.
It’s common to come across a junior developer that is very intelligent, bright, and promising.
It’s also very common to come across developers with 1-2 years of experience that have gained some tracking and feel very confident. While these are just examples, I’ve seen many types of developers from junior to mid closed off to feedback, especially in feature/velocity-focused companies.
Many times, I’ve come across various developers that just want to produce something. Their ability to accept feedback is limited, as well as their willingness to hear options.
This creates a problem as you have people producing hard-to-read, hard-to-maintain code. Since the organization is chasing features/velocity, no one stops to say that’s not how it’s supposed to run.
If the person noticing this is also a peer of the junior or a mid developer, he has limited authoritative power, aside from “telling the boss”.
How to Fix It
Fixing the organization and the approach to code would also address this issue well. You should empower your developers to think of code quality. Choose to dedicate time to improvement or choose mentorship tickets or any other route to improving the quality.
Helping everyone on the team work together towards quality and becoming better software engineers and developers will communicate to everyone that you also measure how you produce, not just what you produce.
Review PR to understand openness
Review the PR, see how open or not open people are to feedback, and have those that are resistant to change working with people they appreciate on the team. You can craft your culture to help people move from their mindsets.
It’s not an easy task. It requires out-of-the-box thinking. If after all you do a certain person still doesn’t react positively to feedback, I suggest re-thinking his place on your team. Negative and uncooperative people are toxic to your whole team. I’m not suggesting letting someone go, I’m just saying your team must be constantly striving to be better.
People must be open and have the right framework to learn or develop. Just like a business must grow and expand to survive, so must truly great engineers do the same.
Final Thoughts on Software Developer Mentorship
I tried to outline some issues we’ve seen in the workplace in multiple companies. Personally I enjoy mentoring.
Sense of satisfaction
There is a sense of satisfaction when you work with a junior or mid-level software engineer or developer and help him take complex code and make it simple.
A sense of mastery and accomplishment is highly important for people to feel good and be creative, as well as to keep a high developer retention. Good developers won’t leave a company that puts their personal development as part of their corporate strategy.
In future posts
In one of my future posts, I’ll talk in more depth about how to handle mentorship tickets or improvement time. I’ll try to better help senior engineers and managers to think in terms of how to get work done and mentor at the same time. We will discuss techniques to implement and ideas for how to approach software developer mentorship on the micro level.