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.
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 focussing 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 unmaintable 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 focussed 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 focussed 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 favourite. 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:
When hiring remember that someone once gave you an opportunity when you didn't have the experience. Hire smart raw talent and mentor them.
— Asim Aslam (@chuhnk) April 14, 2016
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.
Mentorship
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 eyerolls, 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 right answer. 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.
5) For junior devs, a good guideline for scope is something that can be completed in 2-3 days. You want to keep your feedback loop short.
— Lydia Guarino (@lydiaguarino) April 13, 2016
5) Tasks with scope of more than 3 days are tasks that are not defined well enough. Break them down further.
— Lydia Guarino (@lydiaguarino) April 13, 2016
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?".
Focussing 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.
