by Ryan Bigg

Stop asking senior developers who aren’t looking. Start mentoring juniors.


The “D” word

We have a diversity problem in the community, and that’s been talked about quite a lot when it comes to tangible things like gender and race. A diversity of skill — an intangible thing — is also something we talk about struggling with.

While I haven’t been a different gender or a different race, I have been someone who has been a junior Ruby on Rails developer.

When I started out as a Rails developer, I was tinkering around with the framework in my spare time, which I had a lot of because I was single and working casually at Coles and doing the odd spot of PHP/Rails freelancing.

I heard that there was a Ruby meetup happening in Adelaide and I caught the train into town and ran to the meetup because I was running very late.

When I got there, people asked what I did and I told them about Coles, PHP and Rails. They said “you don’t need to work for Coles anymore” and three people gave me their business cards and said I should apply for a job. I applied for a job at SeaLink and was accepted.

At SeaLink, I got mentored by a team of “senior” Rails developers who had a whole bunch of patience for my 19-year-old antics. I am very thankful to them for the time that they spent mentoring me, as I believe it helped provide a foundation for a career that I’ve been doing for very close to 10 years.

There are plenty of juniors at the Melbourne Ruby Meetup. I know because I help run the Hack Night where a lot of them attend also. If a junior from this meetup was to tell you that they were actively looking for a job right now, would you hire them? Probably not. There seems to be quite an aversion to hiring juniors, and the main aversion is that juniors take up valuable shipping time with mentoring time instead.

In the early days, there was a lack of available talent and so companies had to hire whoever they could find. That’s why I found it easy to get a Rails job back then. I think we have once again reached that point where there just isn’t any talent to hire.

I’ve been having a lot of discussions recently in the Ruby community about why companies seem to be shying away from hiring juniors. Instead, these companies want to hire mid-to-senior developers and do not want to have apprentices who are learning alongside those mid-to-senior developers.

Lawyers, mechanics and plenty of other professions have apprenticeships, so why don’t programmers? It’s pretty strange. I think it’s because those professions have had turnover in their companies enough to learn the lesson about training for the future. This is still a young community where most people have been doing it for less than 15 years. We need to think long term about this: who will look after our code when we’re gone?

Hiring seniors

Let’s look at why companies want to hire mid-seniors in the first place. At the companies I’ve worked at, we’ve wanted to hire a new mid-to-senior person because our workload has gotten to the point where it’s exceeding our capacity. I figure that this is the same at other companies too. Like where I’ve worked — and currently work — you’ll have people breathing down your neck asking when bugs are going to be fixed or new features are going to be developed.

To address this problem, you hire a new developer or rather: you try to hire a new developer. You want a mid-to-senior developer because they have the skills to instantly dive straight into your application with little-to-no guidance and they can start shipping code.

However: the trick is finding someone who’s available at the moment. In this current climate, it’s nearly impossible to hire a mid-to-senior Ruby developer to come work for your company. What typically happens is that developers get aggressively poached between companies.

Companies spend thousands of dollars on recruiters and lots of time posting to job boards, for often very little good return. Companies spend this money to hunt the elusive 10x Developer Rockstar Unicorns, but the Unicorns are no longer out grazing in the sunny meadows, readily available for capture. They’re already working somewhere else and the conditions of where they work are extremely good.

We, as a community, have drained the talent pool dry.

We’re out of freely available Rockstar Unicorns and so it’s time that we started to grow our own.

Companies are addicted to hiring the top 5% or 10% of developers and ignoring the rest. There is a lot of great talent in the remaining group of developers, just waiting to be mentored. If they got that mentorship, we would be able to bolster our community’s best and brightest. What if the next person your company mentored went on to become your next CTO? What if they went on to be that “10x engineer” who can help out anyone on the team with anything? I really believe companies are missing out on great talent by completely ignoring it when it is non-obvious.

Too many companies are focusing on the short-term goals of shipping code, rather than the long-term growth of their teams.

Companies hiring the best-of-the-best — the people with proven great track records — and getting them to build what is essentially CRUD applications which do, at best, a fancy version of string concatenation.

If we speak in terms of hiring piano players: you’re hiring the Chopins, Bachs, Liszts, and getting them to play Mary Had A Little Lamb.

You do not need to hire senior developers. You need to hire developers of any skill level, mentor them and grow them into the next great bunch of developers. Give these people a chance and train them on real world applications that real people are using. These could be the next great people that your company needs and you are not giving them the opportunity.

Contributing back

You might be thinking: what do we (as a company) get out of this? I think that’s backwards. The thinking should be “we have earned so much from the community, and now it’s time to give back”. If you invest in the long term health of the community, it will pay dividends. In the long run, you will have an active talent pool of developers who will be able to maintain your application. In the short term, you’ll be bolstering your team’s productivity with fresh talent.

You may think that you need to hire these best-of-the-best badasses because your application is a large unmaintainable behemoth monolith and only the badasses can understand it. That you need seniors to navigate the spaghetti that is your legacy code. That may indeed be the case. But in every monolith, there is a tiny bit of functionality that a non-senior developer can work on improving along with their skills, when that non-senior is paired with a senior developer.

It’s OK to hire non-senior developers to work on real live production code. We’ve done it at Marketplacer and we’re still in business. Your company will not go down in flames because you hire a junior.

Yes, it’s risky. Initially the cost of the employee is greater than what they provide for the company. But with the right fostering, they can grow into the best asset your company has ever had.

Julia Claven has a great graph for this:


When the junior is initially hired, their dollar value to the company is less than the output they produce. With good mentoring, they can get the other end of the graph where their value to the company outweighs their salary.

There is an initial productivity hit — that’s true — but that plateaus out within 6 months if you do it right. At the end of it, rather than having one developer, you have two developers. Even if the junior is half as productive as the senior, then it’s still a 1.5x growth in the productivity of your team.

At Marketplacer we’ve hired juniors within the last year that I would consider to be very productive members of the team,and they’re great people to work with to boot. We would’ve missed out on these people if we didn’t invest the time in hiring and mentoring them and instead focused on only hiring seniors who had existing Rails app development experience.

You might be thinking, “but what if they leave?” That’s a risk you take with any hire of any skill level. If people are leaving your company, you should be reflecting on why they’re leaving in the first place. Was it really them, or was it your company? Does your company have a culture that someone would want to leave? Is your company focused on building a culture that people want to stay in, or are they only interested in shipping code?

Finding Juniors

Where can you find those juniors to start with? Well, let’s start with Code Academies. Not any particular one — although Turing is my favorite. Code Academies solve part of this lack of mentoring problem.

Code academies get new programmers to pay thousands of dollars to learn the tricks of the trade. Sometimes, these new programmers even get a “guarantee” from the code academy that they’ll get a job at the end of the course. The code academies teach these newbies a range of programming skills. At the end of this, the newbie programmers have enough skills to know the basics of things like HTML, CSS, JavaScript and Ruby and can usually find their way around a Rails app easily enough. These people are very “green” and then they’re thrust out into the community to work at companies.

Unfortunately, due to our senior hiring addiction, we’re not hiring these fresh faces. The code academies produce great talent, and we’re not picking it up. These people are left to struggle for months at a time in developing their skills before they can even get a look in at a company. I’ve spoken to many juniors in that position.

Not all of these graduates have the time to spend doing that skill development, as they often have full time jobs or other responsibilities to take care of. Thankfully, they get a lot of assistance from their code academies after they’ve graduated. Well, at least the good code academies do that.

I would love to see companies breaking their addiction to seniors and more actively hiring from these code academies. More companies need to make mentorship / apprenticeship a part of what they do. The students that graduate from code academies are eager to learn and are, in my experience, very highly motivated.

There are definitely juniors who have that same kind of eagerness-to-learn and motivation who have never been to a code academy. These people have learned by themselves and by being mentored by people in the community. I can think of at least 5, perhaps even 10, of these people who would make great hires in a company’s mentorship / apprenticeship program.

If I were in charge of hiring at Marketplacer, I would hire a motivated junior, pay them a wage well enough to live off and mentor them.

Asim Aslam (@chuhnk) had a good tweet about this too:

There’s a great book I encourage you all to read: it’s called The Talent Code. As the subtitle says “Greatness isn’t born. It’s grown.” The book covers how skills of all varieties are grown in sports, music and plenty of other areas. All the industries that are covered in the book have active mentorship and apprenticeship programs. Yet, this is not cared about in the programming community for reasons mentioned earlier: we’re still quite a young community.

I’ll let you in on the secret that’s in that book: for anyone to get better at anything, they need to practice the hell out of it. How do we expect to have seniors to hire if we’re not hiring juniors and letting them improve their skills by practicing on real world applications?

So many people are talking about mentoring and hiring juniors. Let’s start doing it.


Now that I’ve (hopefully) convinced you to hire a junior developer, you might be wondering what you do once you have one.

I help run the Melbourne Ruby Hack Night and it’s a judgement-free environment where anyone and everyone can bring along a Ruby project and work on it. Some people are even there for the first time learning about Ruby itself, which is great to see. These Hack Nights work because these new developers feel safe and welcome and that no question is too “dumb” to ask.

You can start mentoring at your company by fostering that Hack Night-esque environment. It should be OK to put up your hand and ask a question about anything. If the questioner is getting eye rolls, sighs, or other passive aggressive signals from someone else, then that’s not the kind of environment where a junior is going to learn.

A great way to build that kind of fostering environment is to encourage pair programming. Pairing with juniors on small tasks initially is a great way to build up their confidence. When I’ve been mentoring juniors, the number one thing that I find that they’re lacking isn’t the skill, but the confidence. They know the answer, but they aren’t sure if it’s the rightanswer. They question if they’re using the right syntax or even if they should be writing the code that particular way. When a senior pairs with a junior, they can encourage them to try out things and learn from the things that they try. If the junior gets it wrong, the senior can ensure them that it’s OK to get things wrong and to guide them back on track. Pairing is the quickest way to upskill a junior and I can highly, highly recommend it.

I paired daily with some developers when I worked at GetUp and in a few months time they were confident Rails developers who could find their way easily around that Rails application. I’ve done the same at other companies too and each time I’ve seen great professional growth in the juniors that I’ve mentored. One of the best feelings in the world is when a junior says “Ahhh, I understand!”.

Pairing also helps reinforce your own knowledge. If you can’t explain something to someone clearly, then you do not understand it well enough yourself. Pairing is helpful to the junior because they get knowledge out of it, but it’s also helpful to the senior: they learn how to share what’s in their brain with other people in a clearer fashion.

What should you pair with your junior on? Well, Lydia Guarino has some good tweets about that.

I agree with both of these. Juniors thrive best when they’re given quick wins. You want that nice tight feedback loop to keep their confidence growing. Every time they “win” at code, their confidence gets that little bit more boosted.

Once they’ve built up a bit of confidence, you can let them go solo on a task. There isn’t a set timeframe for when this happens; it’s all about how confident the junior is with their own abilities.

Let them loose on something small and make it clear that they can ask any questions about what they’re doing and that there is no wrong way of doing it. Once they’re done, get them to submit their work in a pull request — you might have to teach them what one is first — and then sit together and review it.

Sitting together is important here because “why are you doing this?” written in text has no emotion, compared to it spoken with body language. Juniors may interpret a “why are you doing this?” comment as aggressive like “UGH! Why are you doing this?”.

Focusing on in-person communication helps establish a rapport between the developers much better than text-based communication ever will.

If a junior has made a mistake in the pull request then you can discuss it with them and correct the mistake. This way, that mistake will never make it to a live production environment.

Code review also allows the senior to assess how well the junior has been doing on the tasks they’ve been given. If they’re doing well on a 2-day task, then it’s probably going to be OK to give them a 4-day task too. If not, then some more mentoring may be required.

Ultimately, your mentorship should be about making the junior feel welcome and safe within your team. In fact, this should be what’s happening with everyone in your team. Google ran a project that they called “Project Aristotle”, wherein they attempted to find how to build effective teams. They interviewed hundreds of their own employees and they came up with 5 things:


The #1 item on this list is “Psychological safety”: “Team members feel safe to take risks and be vulnerable in front of each other.”

Google is not special. They’re made up of people just like your company is made up of people. You should keep this in mind when mentoring your juniors, and working with other people in your team.

Thanks for reading! If you found this article helpful, click the green heart below.


This was originally published on my blog.