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. 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 often the companies themselves that are 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

Not only does this create frustration it also in great way to create more Tech Debt.

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, very few companies in actuality create a supportive culture of learning. 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

Kanban Vs Agile

  • 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 in dedicated sprints and measure their team velocity, it also creates a 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, the software developer is focused on the estimated time for that ticket. Little time is left to guide someone else as a result. 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 it must invest 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:

  1. Mentor Tickets – Create specialized mentorship ticket tasks. Just
    as 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.
    • Seniors can break these tickets down further by assigning “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.
      Later, I’ll discuss how to approach and what to do in a mentorship ticket and how to conduct a successful mentorship.
  2. 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.
  3. 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. However, 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.

  4. 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.
  5. Either way, experiment –  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 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, 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 ends up 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, allocating 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.

Developer Personality/Ego

Software developers come in all sorts of personalities.
It’s common to come across a very intelligent, bright, and promising junior developer.
It’s also very common to come across confident developers with 1-2 years of experience that have gained some tracking. While these are just examples, I’ve seen many types of developers from closed off to feedback, especially in feature/velocity-focused companies.

I’ve met 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 other routes 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 measure how you produce, not just what you produce.

Review PR to understand openness

Review the PR, see how open people are to feedback, and have those that are resistant to change work 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 someone 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 satisfaction in working with a junior or mid-level software engineer or developer and helping him simplify complex code.

A sense of mastery and accomplishment is highly important for people to feel good and be creative, as well as to keep developer retention high. Good developers won’t leave a company that has 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 and improvement time. I’ll try to 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.