Six Things Junior Developers Wished They Could Tell You, and How You Can Use Them to Become a Better Teacher
(this blog post is based on a talk I did at YGLF 2016. You can find that talk here.)
I learned web development when I was building the product for my startup. I never thought I would become a developer, but once I tried, it turned out I really liked it. Ever since then I’ve been kind of obsessed with this question: What keeps people away from programming? I do a lot of work around this, and I talk to a lot of people about it. I want to know how we can open the gates to this profession and let more people in.
Part of the answer lies in how we teach people who are new to this industry. We tend to think about teaching as something that just happens. We think ,“here, you know a lot, you know a little, let’s just put you two together and… figure it out”. But teaching, like anything else, takes effort. Not just any effort, either. It takes work on what we today call soft skills, which is really just a sleek term for “being good with people”.
This is not easy, maybe particularly so for developers. And one blog post certainly isn’t enough to address the issue. Still, one of the keys to relating to others is good communication, and a blog post can help with that. So I want to use this post to facilitate some of the communications around teaching developers, specifically teaching on the job. I want to share with you 6 things junior developers are thinking, that you can use to become a better teacher.
#1 We have no idea what we’re doing
If you’re a senior developer, chances are you don’t remember your first day on the job very well, so let me paint you a picture. You’re walking down a hallway you’ve never been to before, about to open a door you’ve never opened, and you have no idea what’s on the other side. You’ve never worked at a company, you’ve never worked in a team. You have no idea what the code is going to be like, you have no idea what the people are going to be like. You don’t even know what to expect. Do you remember the uncertainty, now?
If you’re in charge of teaching a junior developer, make sure you’re not another factor that adds to their feelings of uncertainty and anxiety. A lot of things can be made certain in advance — their hardware, they seating and, most importantly, their schedule. Make sure you have a plan, and make sure your junior knows what it is. It could be anything; it could even be a company orientation, but you need to know what your junior will be doing for the first few days, and make sure they know it too, so at least some of the uncertainty is abated.
#2 We’re not going to interrupt you
Juniors know you’re there first and foremost to write code. We understand that what you’re doing is important. We are also hyper-aware of our own lack of ability to write code, and at the same time we really want to do a good job. The combination of these things makes it difficult for us to ask questions, but if on top of everything we feel like we might be interrupting you, we’re just not going to do it.
If you’re serious about answering your junior’s questions set aside a time and place of them. Schedule it in the calendar, reserve a room, and tell your junior the date and time, and how long they will have to ask you questions. Make sure you do this often in the beginning — every day if you can.
Keep in mind that at the end of the day you want juniors who are able to ask questions, because asking questions is crucial to team work, to problem solving, to innovation. So make sure they feel it’s truly OK to ask. That it doesn’t bother you and that it doesn’t make them look stupid because….
#3 We aren’t sure we’re good enough
We’re really not. This might be the single most important thing to keep in mind when your teaching a junior. Most of the time, we’re not sure what we’re doing. We search google for answers, but we have no idea which ones are good apart from their Stack Overflow score. We try to implement things, but we have no idea why they work or, indeed, why they break. Most of the time, we don’t really feel like programmers.
It may be impostor syndrome. It may just be the result of being new to something — it makes sense that we feel like we don’t know a lot. The point is: we have no ability to gauge our own progress. We don’t know enough to be able to evaluate ourselves. We need your evaluation.
As often as possible, give your juniors clear, relevant feedback, so that they can get a sense of where they stand. Make it clear by making sure whatever it is you’re saying is also understood by the person on the other side of the table. Make it relevant by focusing it on skills and outcomes rather than the person themselves.
Another great thing to do often (though maybe not that often) is share some of your experiences as a beginner. Since people don’t like to talk about times when they felt inadequate, junior developers often end up believing that they are the only person to ever not be good enough in the history of time. Sharing your stories about what it was like for you starting out can go a long way to making us feel more normal.
#4 We get bored too
All companies like juniors to start out small. You don’t want someone inexperienced getting access to the code and breaking things. Juniors understand this too, and we’re happy to take the more menial tasks. We still get bored though. Plus, if you have us doing a lot of low-level, repetitive work, we don’t learn.
In order to be constantly improving, we need to be doing deliberate practice. This means that we need to be working at a level that’s constantly slightly higher than where we were before. If you think about it, this makes sense: if you’re constantly doing tasks that are more complex and difficult, eventually you’ll be able to do the most complex and difficult tasks. Make sure the tasks you give your junior are always slightly different or more difficult than what they have been doing so far. If you don’t let them do the more advanced tasks, they will never learn how to do them.
#5 We know what you think of us
Training juniors is sometimes frustrating. You don’t always have the time and energy for it. We know; we can see you thinking it. That’s ok. You’re only human.
But we also know when you think worse things about us. We know when you think we’re stupid or lazy; we know when you think we’re not cut out for this. And if we see you that too often, we will start thinking it too.
We believe you. We don’t believe ourselves or trust our judgement very much, but we’re pretty sure you know what you’re doing. So if you think we can’t do it, we’ll take your word for it over our own.
And no, it doesn’t matter if you don’t tell us or anyone what you’re thinking. If you’re thinking it you will communicate it in a million small ways.
The truth is, there is no good solution for this problem. If you don’t believe in someone, you should not be teaching them. Because if you’re thinking that all young developers only want quick fixes, your junior will learn that they are lazy and shallow. If you think women just aren’t that good at solving problems rationally, your junior will learn she is not a good problem solver. If you believe your junior has any inherent quality that fundamentally prevents them from becoming a good developer, they will learn that from you faster, and more deeply and permanently than any coding best practice. You should not be teaching them, because in the end you will do them more harm than good.
#6 We can only be as good as you are
You shape how we see the world. We’ve never worked anywhere before; we have no idea what a good developer can or should look like. We have you.
One of the most basic ways that human beings learn is through copying. A baby trying to speak is basically mimicking her parents until she can create the same sounds they do. It’s not a conscious thing we do; it just happens, and it will happen throughout our whole lives. It will happen on the job too — we will learn by copying you.
So if you work crazy-long hours, we will copy you, and we will come to believe that’s what makes a good developer. If you are curious and excited about new technologies, we will copy you, and we will come to believe that’s what makes a good developer. If you are a team player, we will do that, if you are a lone wolf, we will do that. If you are an adventurer, a harsh-critic, a robot… you will set the limits of what we believe we can become.
Think about what you believe makes a good developer. Think about what you want us to be. And then go be that. We will copy you.
Next time you need to teach a new developer, try putting yourself in their shoes. What would they tell you if they thought they could tell you anything? How can you use that to become a better teacher? You are the gatekeepers of this profession. You’ve been put in the truly awesome position of shaping another person. Use that wisely.