This is the transcript for a talk that I gave at RubyConf AU in March 2018.
The video is up! You can watch it here.
I have seen the future.
Five years from now, someone will get on a stage like this one (or perhaps midseven this one) and blow your freaking minds. This person will astound you with a radical talk on a subject we, in the present, can only guess at. That person is not going to be Sandi, or any of the other speakers here. It’s not even going to be me – as much as I (and my ego) would like that.
In fact, the person who will blow your minds knows a model today as someone who would walk down a catwalk in some ostentatious outfit. They think that a view is what you get from that lookout up in the mountains. They think that “Ruby on Rails” is a cause for concern, as enough Rubies of significant sizes on enough Rails might derail a train. And what a waste of good jewels!
Today, this person has just started on Chris Pine’s Learn to Program. They have
invoked the puts method for the very first time.
Tomorrow, they will attempt the Ruby Koans. Next week, they will dabble a bit in HTML and CSS. A few months from now, they might learn that Ruby On Rails puts the HTML and the CSS and the Rubies together and it gives them those nice shivers of excitement when it all Just Works™.
And five years from now they will blow your freaking minds with a talk of astonishing brilliance, eloquently delivered with perfectly timed (and tasteful) jokes.
And five years from now, we will know very clearly who this person is. This is because they will be on stage, blowing our collective minds. And they will have a name badge and the badge will tell us who they are. But hopefully, they will tell us themselves.
But right now, we couldn’t pick this person out from a crowd, or even a small gathering for that matter. In our minds, this person simultaneously does and does not exist. We can picture who they might be, but I guarantee you: the picture doesn’t match the eventual reality.
I’m not one to give out spoilers freely, so I won’t tell you who they are. You’ll just have to wait and see.
What I can tell you is that one of you will hire this person as a junior developer and that will be their very first programming job. You will kick- start the programming career of someone astonishingly brilliant and it’s going to be all because of what I’m about to tell you, so pay close attention.
If there was one thing that I want to stick in your minds it would be this: hire juniors. Because those juniors you hire today will turn out to be the people blowing our minds in 5 years time. Hire and train these juniors to be mind-blowingly awesome.
Hiring seniors
“But Ryan, we only hire senior Ruby developers!” – ahh the classic ActiveMantra in the Rails community: “Hiring senior Ruby developers. Hiring senior Ruby developers. Hiring senior Ruby developers.”. Maybe if we say it enough and click our heels together our dreams might come true.
Yeah but how’s that working out for you at the moment? Probably not so great. It’s well known that there are only three hard problems in computer science: cache invalidation, naming things and hiring more senior Ruby developers.
We have drained the talent pool dry. And yet our obsession and our Active Mantra continues. We only hire seniors. But why do we have this obsession?
Well, we want a senior developer – but we might be happy to take a mid too – because they have the skills to instantly dive straight into our application with little-to-no guidance and they can start shipping code. That old expression: “they can hit the ground running”.
This is because our code is so brilliantly well-structured and organized according to the Rails best practices. Nobody will have to upskill on any single part of the codebase at all because we follow the Laws of Sandi and Commandments of Avdi to the letter. There is no legacy code with their legacy decisions that meta-programs the constants from Java, written in a hurry because we needed to ship that thing fast. HA.
You may think that you need to hire only these best-of-the-best badasses because your application is a large unmaintable collection of microservices written in obscure languages surrounding a ginormous monolith and only the badasses can understand it. That you need seniors to navigate the spaghetti that is your legacy code. Maybe you use technologies that only true geniuses can understand, like Node or Go. Or the Rails Asset Pipeline.
That may indeed be the case. After all, if our code was simple, elegant and only written in a single Ruby monolith, would as many of us still be employed?
Companies spend thousands of dollars hunting the elusive 10x Developer Rockstar Unicorns (note: term used ironically), 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 competitive. To keep with the analogy: the meadows are filled with the greenest of grasses and the brightest of rainbows. You will have a hard time luring these unicorns away.
We’re out of freely available Rockstar Unicorns because they’re already employed elsewhere. Attempting to hire them is an exercise in futility. And so it’s time that we started to grow our own. It’s time that we started to hire and train our own 10x Developer Rockstar Unicorns.
But where do we find these developers? Well, to start with need to lower our bar for engineering talent and not be so caught up on hiring the best-of-the-best now, but instead we should be investing more in people’s future potential.
Your next Rockstar Unicorn isn’t within today’s current top 5-10% of all developers. The top 5-10% already works elsewhere. Your Next Rockstar Unicorn is hanging out with the rest of their peers in the other part of this totally scientific graph that I made up. These people need some mentoring in order to grow into the next generation of brilliant people.
There isn’t an endless supply of brilliant people – sorry, I mean Developer Rockstar Unicorns – that we can just keep harvesting today. This talent pool of amazingly talented and gifted developers, as we’re painfully finding out, is not limitless.
We must lower the bar for our hiring, and hire outside of the top 5-10%. We must hire juniors. We must then train these juniors up to be our next generation of brilliant minds.
It is very, very difficult to hire a senior developer today in Rubyland. And so we must grow our own senior developers. This is a process that will take time. There’s no packet mix where you “just add water” and blammo you’ve got a senior developer. I’m talking about years of hard work. But these are vital years of hard work to ensure that our companies and this community continues to thrive and grow. This is necessary work to ensure that we have well-trained developers working at our companies. We will know they’re well-trained because we did the training ourselves.
Juniors make teams better
We should not lower our hiring bar and hire juniors just because we can’t find seniors though. I have a much better reason for why you should hire a junior developer and that reason is because they unequivocally make your teams better.
Juniors making teams better is a big claim, but I have some evidence to back it up.
We know from a lot of experience that gender-diverse teams perform better than either a team of all-men or a team of all-women. The same is true for teams that are skill-diverse as well; teams that have a mix of people with differing skill-levels and experiences out-perform their all-senior counterparts. The most productive teams that I’ve worked on have been teams that have had a mix of skill-levels and experiences.
Juniors make your teams better because that means things will need to be explained in simpler terms than they were before. This makes things easier to understand for all members of the team. Concepts are no longer talked about in a jargon-y or high-level way all the time; instead: people understand things in an easier way.
Juniors make your teams better because teams that have a junior tend to document things more. Or at all.
For instance, a team I was a part of recently documented the flow of an event out of our main monolithic Rails application and into some microservices. This documentation was done for the junior developer’s benefit and it consisted of a flowchart made up in Omnigraffle. The best part about this piece of documentation was that we had something we could physically point to when talking about things we would only normally keep in our head.
The funniest thing about that piece of documentation was that the senior developers ended up referring to it more than the junior! We stuck it on a wall and then talked about the structure of the system while pointing at the different pieces in the diagram. It really helped cement the structure into our heads and helped us know where to make improvements in the system.
If it wasn’t for our junior developer, we wouldn’t have drawn up this diagram in the first place. We would still be talking about this system at a high-level, with only code to point to. The diagram really helped our team become more productive.
This links into my next point:
Communication, especially when it comes to knowledge-sharing, becomes explicit out of necessity, rather than the implicit style of communication usually found in all-senior developer teams. When that team I was on was only senior developers, we communicated implicitly about the structure of the two applications. We all just assumed everyone knew what we were talking about. As soon as we got a junior, that communication changed to favouring explicitness over implicitness.
Also on the topic of communication: more questions get asked by the junior than the seniors on the team, usually because the junior wants to learn. It’s not the questions themselves that are the most helpful, but the answers. The answers to these questions not only help cement the junior’s knowledge, but they give the senior developer practice in understanding and explaining concepts that they might not have explained otherwise. I’ve also learned a lot from over-hearing someone else answering a question.
Sometimes a question from a junior can even spark a thought about how to structure something better in the code, or how to document a part of the system in further detail so that everyone on the team can better understand it. Those “why is this done this way?” questions from juniors are my absolute favourite because they often lead to system improvements.
One more thing: all of the juniors I have ever worked with have mentored senior developers on the most important developer skill of all: patience. This is the thing that juniors provide to your team that no senior can do. The seniors must explain things to a junior, and that takes time. They might even have to explain things more than once.
Patiently explaining something to someone, as I’ve said before, helps seniors understand their own systems better and, in my experience, makes the seniors much better developers than if they only had to explain things to other seniors. They need to slow down and methodically explain things, which helps solidify the senior’s knowledge.
Patience is a virtue that more developers should learn. The ironic thing about me saying this is that I’m a naturally impatient person (just ask anyone who’s known me for more than 5 minutes)… who’s getting more patient because of the mentoring I’m doing. Huh, maybe it works.
This is why we should hire junior developers: it makes our teams better. Things are better understood. Documentation exists more on teams with juniors. Clearer communication channels open up out of necessity. Patience is taught. The team is better for it.
Better teams ship better software and better software means happier users.
Hiring Juniors at Culture Amp
I know that juniors make teams better because we’re making it happen at Culture Amp. I live and breath this stuff as Culture Amp’s Junior Engineering Program Lead. My entire job is to train juniors up so that they can be productive members of their teams.
Last year, Culture Amp hired seven new junior developers. We now have ten junior developers across the company. This is a ratio of about one-in-five developers at Culture Amp being a junior developer.
Here are the ten juniors that we currently have at Culture Amp. Each of these juniors comes from a diverse background: They’re not all 20-35, white, and male and yet our company is still in business. Amazing, I know.
These juniors are a lot more fresh-faced than I was when I was a junior developer. Here’s a photo of junior-me. Definitely not fresh-faced.
At the end of November last year, we started up a structured training program for these juniors called the Culture Amp Junior Engineering Program. This program is designed to provide an accelerated learning environment for the juniors that we have at Culture Amp.
During the program, we provide structured training to these 10 juniors over the course of 6 months. When the 6 months are up at the end of May, they’ll be fully-fledged developers, capable of shipping things mostly on their own. At that point, they’ll then be working on their teams full-time. The progress that these juniors have made so far has been nothing short of amazing. They’re well on their way to being confident and capable developers.
I’d like to highlight the fact that we’ve hired people who aren’t all white, male, 20-35, utterly amazing, top 5-10% senior Rails developers and yet… everything is still OK. In fact, it’s better than OK: it’s awesome.
We’ve hired a mixed bunch of people with different skill levels and we train them up and get them to work together on our applications. There’s not a single fire or brimstone as far as the eye can see.
We’re growing the next batch of brilliant engineers today. And I can definitely say that all of Culture Amp’s teams have been made better by the addition of the juniors.
The Talent Code
If all of my points so far weren’t convincing enough, then I would encourage you to read a book called “The Talent Code”. As the subtitle says “Greatness isn’t born. It’s grown.” It’s about 300 pages long.
The book covers how skills of all varieties are grown in sports, music and plenty of other industries.
All of the industries that are covered in the book have active mentorship and apprenticeship programs. Yet, this is not deeply cared about in the programming community, and I think that’s because we’re still quite a young community. We aren’t mature enough to think long- and-hard about mentorship and the sustainability of talent in this community within our companies. We haven’t had to think about potential “succession plans” for our codebases: Who will maintain our code after we are gone? Our industry is not quite yet old enough to have needed this.
More established industries that have been around longer have learned this lesson. They realise that the people who are doing the work today are not going to be doing the work forever. And so they have these active mentorship and apprenticeship programs to ensure a fresh supply of talent to their industries. I think we’re on the cusp of realising this today.
Put another way: If Rails was a person, that person would not even be old enough to have graduated high-school, let alone make adult decisions. This is reflected in the design choices of the framework, but that’s a conversation for another day.
Back to my point: I think it might take us a touch longer to realise that training for the future is the right thing to do. It ensures that we have a stable talent pool that we can hire from, and overall leads to better performance for teams.
Back to the book: I’ll let you in on the secret that’s in the Talent Code: for anyone to get better at anything, they need to have three core components:
- They must practice the hell out of it
- They must have a passion (or a drive) for whatever they’re learning
- They must have a good mentor who is encouraging and can provide sound advice.
You should definitely read this book. It really helped me understand why it’s important to mentor newbies in any community, and taught me a bit about how people learn. It’s definitely worthwhile to read.
One thing that it really highlighted for me was that the best of the best, the Beyonces, the Kanyes, and the Ricks, didn’t just one day appear out of thin air. These people practiced the hell out of their craft, they have a passion for what they do and they had great mentors who helped guide them. These people were trained over years and that’s how they got where they are today. We should do the same for our industry to build our talent pool.
How do we expect to have more of our own great talent to hire if we’re not hiring juniors and letting them improve their skills by practicing on real world applications? Remember: these people need to practice the hell out of programming, have a passion for it and they need to have a good mentor.
These people do not simply pop into existence. This isn’t the Matrix: we can’t just plug in, and a few seconds later we just know Rails like Keanu and Kung fu. These juniors cannot just sleep on a copy of Rails 4 in Action and wake up knowing Rails. These juniors have to be taught.
We have to grow talent if we want talent. The Talent Code helped me understand this point very clearly.
You should hire a junior
I think your companies should try to hire juniors and to mentor them. I know I’ve said that a few times already, but I really want to drive that point home.
I’m not suggesting that you should hire a batch of them all at once like Culture Amp did. I think you should just start at hiring a single junior. Interview a couple and pick one from that batch. If your company is at least 4 developers and at least one of them wants to mentor, you can hire and support a junior. I believe in you. You can do it!
Rather than running a structured mentorship program like Culture Amp does, you can start by hiring a single junior and pairing with them to grow their skills and your team. This will lay the groundwork for hiring more juniors later on.
Your next question might be: “what do we (as a company) get out of hiring a junior?” Were you not paying attention at the beginning of this talk? They make your teams better! That’s what you get out of it: better and bigger teams. We as a community also get some new members, and that’s a big positive in my eyes too.
Finding Juniors
Now that I’ve hopefully convinced you to hire a junior, you might be thinking: where do you find these juniors? What do I do with them once I have them? Well, I have some tips!
Regarding finding the juniors: let’s start with two places where you can find a lot of them: Code Academies and universities.
Code academies and universities produce great talent, but that talent often has a hard time finding a job afterwards because, as I mentioned earlier, the bar for hiring at a lot of companies is too high. It feels to me like there’s a big chasm between someone graduating and getting a job at a Ruby development shop. I hear this from a lot of junior developers that I talk to as well.
In fact, I even drew you a picture using my amazing powers of illustration. The junior, shown here on the left in amazing detail, tries to make the jump from graduating these schools to being placed in what they call “a real job”. When they take this leap, they fall short, smashing into the Wall of Rejection and leave a bloody smear as they fall down into the Pit of Depression. When we hire and train up juniors we will begin work to close this chasm. We make it easier for juniors to make this transition into our community.
Remember: senior devs don’t grow on trees. We must give juniors a chance. If you want to hire a junior, first lower your hiring bar and then take a look at the people coming out of code academies and universities.
We’ve hired 3 people at Culture Amp from places like this: Jaime, Rebecca and Jasmine. Jaime comes from Coder Academy in Melbourne, and Rebecca and Jasmine both went to the same university, RMIT in Melbourne. All three of these junior developers have a great talent for learning and self-development and we’re glad to have them working for us.
But then there are definitely juniors who have that same kind of eagerness-to-learn and motivation who have never been to a code academy or a university.
Out of the Culture Amp juniors I mentioned before, three fit this bill: Rayma, Namibia and Julie. While they haven’t gone through intensive coding schools or universities, they still bring to Culture Amp a great set of skills that they’ve built up themselves. Their ability to learn on their own far exceeds those who have been classically taught, because they haven’t had that support net. Their tenacity for problem-solving and battling through things they don’t know is inspiring.
The people who come from coding academies, universities and who are self- taught are the future brilliant developers of this community and we all must hire and start training them today.
Interviewing Juniors
OK, now that you’ve found a junior you’re probably going to want to interview them to get an idea about who they are.
When interviewing a junior, it’s important to remember that it’s probably going to be one of their first ever programming job interviews. Treat them gentle. Do not try to trap them with programming riddles, or vague trivia. Your interview process should be more like a relaxed chat than an interrogation. You want them to feel comfortable and welcome, not like you’re their enemy.
And then after the interview, I want you to do something different: give them some feedback on how it went. Even if you’re going to reject them.
There are three simple rules for this feedback. It must be all of:
- Actionable
- Specific
- Kind
If the feedback is Actionable and Specific but not Kind, then it might seem like a criticism. If it is Actionable and Kind but not Specific, then the junior might not know what they could do to do better next time. And so on.
We did this with Culture Amp’s Junior Engineering Program, giving on average 7 pages of written feedback per candidate, for a total somewhere in the range of 400 pages. We’re a feedback company, and so we have a reputation to uphold. But this wasn’t the only reason why we compiled this feedback. The more important reason is that we dind’t want people to apply, only to slam into that Wall of Rejection and fall into the Pit of Depression.
We used the “Actionable, Specific and Kind” rules because we felt that feedback that is Actionable, Specific and Kind would motivate juniors towards self-improvement, even if they didn’t “pass” our interview phase. A flat “no” would be incredibly de-motivating to receive as a junior. We didn’t want that. We wanted to encourage them even if we rejected them.
When interviewing juniors, you should give them some feedback too. It doesn’t have to be seven pages worth of feedback per candidate. Even just a single page of feedback can be incredibly valuable for a junior.
Juniors thrive given this sort of feedback. It’s vital for their future growth. Putting in a little bit of extra effort for juniors will help them grow. Proivde them some Actionable, Specific and Kind feedback after you interview them.
Mentorship
OK, so we’ve talked about where to potentially find juniors and a little tip about interviewing them, but what do you do once you have interviewed and hired them?
Well, for starters: they’re going to need a lot of love and attention. You can’t just put them in the corner and expect them to thrive. Think more of them like a puppy than a cactus: the puppy needs love and attention and some training, but the cactus needs only sunshine and some water. The cactus is indifferent to your love, your attention or the intensity of the training you provide. Cacti are going to Cacti.
Junior developers don’t grow into senior developers with just sunshine and water. And they don’t do it just by practicing development by themselves, either. They need mentorship and thrive on direction!
As I said before when talking about the Talent Code: Juniors need to practice the hell out of developing things and need good mentorship to really thrive. We must provide them these opportunities to practice, and we must provide them with mentoring.
It’s OK to ask questions
There’s an event called the Melbourne Ruby Hack Night. This event is 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 so great to see. These Hack Nights work because these new developers feel safe and welcome and that no question is too “dumb” to ask.
Just like at the Hack Night, it should be OK for anyone to ask a question about anything when they work with you at your company. In fact, print this slide up on some A1 paper and stick it to your wall.
Very clearly outlining to juniors that it’s OK to ask any question about anything is a great place to start. And repeat that as much as possible, too.
Pairing
A great way to build that kind of hack-night-esque 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 necessarily 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.
Remember: puppy, not cactus. If we want talent, we have to train talent.
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. As I said before, it also teaches the most valuable skill of all: patience. I have benefited more than I can count by pairing as the more “senior” of the pair. Not just because I get to practice patience, but also because I have learned many new things myself when pairing.
What do you pair on with juniors?
Suggesting pairing is all well and good in theory, but in reality: what should you pair with your junior on? Well, Lydia Guarino has some good tweets about that.
1) 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.
2) Tasks with scope of more than 3 days are tasks that are not defined well enough. Break them down further.
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. At Culture Amp, we started our juniors out on fixing bugs or working on little features and then moved them up to trickier bugs and harder features from there. Most bugs didn’t take more than a day for the juniors to fix. Now we give them harder bugs and harder features. We kept the feedback loop short early on to build up their confidence with our codebase.
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. They won’t ship fast to begin with. The fast comes with practice. Let them practice.
Once they’re done, get them to submit their work in a pull request and then – this part’s important – 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 talk about possible ways to correct the mistake. Pull request reviews are great for this reason.
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. And that’s perfectly OK. Give them that mentorship and direction, and try again.
Feeling welcome
Ultimately, your mentorship should be about making the junior feel welcome and safe within your team. You’ve probably sensed this as a theme to my points already, but I want to take the last few minutes of this talk to really drive this point home: In fact, this should be what’s happening with everyone in your team.
Don’t just take my word for it. Google ran a study 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 isn’t “Feeling welcome”, but “Psychological safety”. The text underneath says: “Team members feel safe to take risks and be vulnerable in front of each other.”
You probably recognise that some of these things sound a lot like the “Love/belonging”, “Esteem” and “Self-actualisation” parts of Maslow’s hierarchy of needs. This indicates that Professor Maslow was probably onto something.
Juniors should ultimately feel safe to take risks and to be vulnerable in our teams. Juniors will make mistakes. We’ve all made mistakes. Ask me about that time I dropped the production database for a multi-thousand user client of a consultancy… and we had no backups. Hopefully you have processes to prevent this sort of thing happening with your juniors when you hire them.
The remainder of this list is not to be discounted. Dependability, Structure & Clarity, Meaning and Impact are all vital to junior developers progressions. A junior must be able to depend on the people around them for support. They must have clarity on what their direction is. They must feel like they’re contributing back to a greater whole to keep them motivated; it’s that drive that I talked about earlier.
When you hire a junior developer, keep these things in mind and ask yourself regularly if you’re following along with them. These things should underpin everything you do with the junior.
With a concerted effort to make the junior feel pyschologically safe, and some semi-structured mentoring in place, they can grow into the future’s most brilliant developers.
We must start hiring and mentoring junior developers. If not today (because you’re at a conference) then do it next week. Grow your company and this community and make your teams better. Hiring juniors is the way to grow our teams and this wonderful community.
I hope that with a concerted effort to hire juniors, our Active Mantra can change into “Hiring and mentoring junior developers”. That would be wonderful.