(upbeat music) (applause) - [Inga] Hi everyone, a short introduction. I work at SMG Studio, it's an indie game development studio in Sydney and I'm a head of QA and QA is considered to be this a nice entry level into game development so we get a lot of juniors coming in of people who want to get into games.
I also work-- do a lot of work for Women Who Code and Muses Code JS teaching people JavaScript, React and all of this magical things.
So I work with juniors a lot, and I'm here today to share some of my experience with them.
So, juniors of today are seniors of tomorrow so let's talk about it for a second.
I'm going to talk about some good things working with juniors, bad things, and ugly things and then on how you can remedy all of those amazing things that can happen. Okay, good things about juniors.
Juniors are amazing because they don't know much but, have you tried to convince a mid level developer try unit tests? I did, it works with juniors much better because juniors will ask you how high they need to jump or how many times they need to jump, or how to jump but, you won't need-- you will need a less explanation on why, so literally being that tyrant is much easier with juniors, just a side note.
But yes, they don't know how to do things so they're easy to direct it's easy to communicate with them to convince them to do things.
They're also trusting, they trust your directions unless you mess up really really bad and you have more authority with them.
The most important thing in my opinion is they're a fresh set of eyes.
Best juniors ask questions and some of those questions will actually underline some problems that you're currently having and probably ignoring.
There is this amazing book, it's called Dare to Lead by Brene Brown, and I want to quote it.
Trust is the glue that holds teams and organisations together, and how do you build trust? You build trust by questions because surprisingly when people ask you questions you start trusting them more.
Because for example, you give a person a task and if you know that if they encounter any problems they will come for you-- come to you for help you trust them more, just because you have this. You know they will ask questions if there are problems. Questions are very helpful.
Example, your junior tasked with writing tests for the scene, some of the scene objects have spaces in their names, some don't.
Now the question, why? The answer, because you don't have a code guide so your developers just give names whatever they want. So here is the question that underlines the problem that you're currently having, fresh eyes.
From the contrary of nice and good things let's get into bad things.
Again, they're easy influenced and direct.
Not just to you, and not just to good things they also pick up bad things really really fast. Example, your developers don't talk to your artists they just pick up some placeholders for their main and move on.
Your junior Dev comes to the mid developer and asks how do I get art from artists? And your mid says, oh who cares about them? Just pick up some placeholders.
Here's the result, you had a very bad practise that just moved on.
So again, this is very helpful.
It shows you that you have problems.
Another thing, they don't know their own value. They're just really happy to be hired and they don't know why they get hired.
They're like, they picked up me, yay! And they're thankful, and they see themselves as expendable, and that's what makes them not comfortable asking questions sometimes.
They're shy, what your mid developer will ask you why the hell we have analytics called in 22 different classes? Your junior will just continue to add analytics to new classes because it's done for a reason, right? They don't know much in general.
They're green, that's why we love them that's also a bad thing because if your team is 90 percent of juniors that makes you the most knowledgeable person and if you don't know the answers you better to know where to find them fast. And that's not just about coding.
Quite often, especially if you take juniors from uni they're just not used to workplace communications they're not used to workplace environment.
I know a girl who actually worked for two weeks without lunch, because in the team everyone had their own time like they just got up and went for lunch and she had no idea where she was supposed to get lunch so her boss literally had the hungry developer for two weeks, and I mean hungry not hungry for knowledge, literally hungry. So those things happen, and you need to notice them when you work with juniors.
What's left, let's talk about ugly things.
I love those ugly things actually.
They can, and they will break everything you give them. You need to be ready for this and you also need to welcome it because that's how they learn.
Also in my experience, juniors quite often believe that quantity becomes quality so they just write a lot of stuff.
And again, that's something you need to teach them and they quite often cannot solve the problems because they don't see the problems.
In my experience in unis and courses we quite often teach juniors to solve the problem at hand, and because of this they don't see the bigger underlying problem. Example, I know, let's look at React.
They just put anonymous functions everywhere they don't care what it does to everything else in the project.
Or your junior QA person who just goes into testing on the live server for debug because why not? It messes up all of your analytics but he or she never thought about it again, because they don't see the bigger picture. They just see this top level problem that they have to solve.
And again, they're not adapted to work environment. They don't know your processes they generally don't know much about workplace culture. So how do you work with juniors safely? How can you help them grow? How can you help them get better at all of these things? Let's look back, they break things.
They need to break things and you need to allow them to break things so put them into a safe environment surround them with the wall of tests.
Allow them to immediately know that okay test passed, it's green, I can push it tested, not passed, it's red, I need to work more. If you can implement TDD because TDDs are amazing in that sense that they gonna teach us your juniors to test their code, and break less I guess? This gets us to the next important point.
Teach them when they're little teach them the delivery mindset.
Don't teach them that done means in QA teach them that done means done because that's what you get otherwise.
You have Dev, you have QA you definish the picture, posted a QA.
At best here, she checked that it compiles and pushed. One week passed, your QA person finally got to the ticket and it doesn't work, it never worked.
Here, she sends it back your developer have no idea what happened there was a week, here she does not remember of the code or anything, here's the problem.
Here's the problem that was created and now you have to deal with it.
It's a bad mindset, and you need to fight it you need to fight it from young age.
More on code-reviews, again, juniors don't know their worth they don't know your ways, so use anything you can to fix that, to give them feedback.
Also, if you have more than one junior allow them to teach each other.
Allow them to read each other's code allow them to contribute each other.
It's an addition, it's not a replacement.
But in my experience, reading other people's code is one of the most important skills that you can get, and it gets us to a refactoring. A refactor, plan it, build a religion around it make sure everyone at your company worships it. Because unless you're happy with really badly written code that you're never going to reuse for anything else in your life, celebrate refactoring celebrate in moving lots of code.
Celebrate questions like, why do we have those two functions that literally do the same thing? Again, juniors give you fresh eyes.
Questions that they ask you, you need to pay attention to those questions, and you need to teach them refactoring because refactoring is very important.
So, if you cannot answer a question about those two functions, there must be a person who knows the answer, so make them available. Availability is the most important quality of the rest of your team, they need to be available for your juniors if you want your juniors to grow. An example, I gave a task to one of my juniors it was a QA task, and it was a pretty simple task but because it was very close to release by the time he had got to it, it was undoable. But it was, again, it was very close to release so I was running around, very busy so he felt uncomfortable approaching me and talking to me about it like I have this task, but I cannot complete it. What ended up happening, we had an untested feature at the day of the release.
The problem is like, for me it would take me maybe 10 minutes to fix it and make it testable for him but because I was unreachable, and he couldn't approach me we ended up with an untested feature.
That takes us to the next point this is a very important point.
Set them up for success, and that doesn't mean the only big things like code reviews code guidelines, like learning it actually comes down to very very small things. I know a junior who worked for three months without access to the internal VEKIN.
So she had no links to anything she had no access to analytics, she had no logins for the server or anything.
So in those three months, she was actually asking questions and making her own VEKIN.
You know what she could do in those three months? Her actual job, instead of literally searching for the data that should be available for her. And, make doing the wrong thing hard like usually, it's very easy to do the wrong thing. You need to make sure that doing the right thing is as easy as doing the wrong thing, at least. And, talking about culture just make them feel as team members.
Code is not all, and people are social in general at least, so they will teach each other if you give them a chance but for that to happen, you need to have a team. You need to have like-- you need to make sure that everyone in the team is inviting and they're happy to have the new members and introduce them to things.
For example, in one of my study projects where I teach juniors React, Electron and Node.js we had a very good plan, we had tickets and no one was claiming them.
People were eager to work, they wanted to start as soon as possible, but no one claimed the tickets. Finally, someone gave me a very good advice. They asked me, allow them to claim the tickets together. And it was the answer, the moment I told them okay, if you feel uncomfortable just claiming this one ticket for yourself just do it together, join into this small team of three/four people and claim this ticket. And this had an amazing result people not just started working they've started exchanging ideas they started working together they had like conference calls and all of this magic so project moved at a very very good speed because I just took this pressure of responsibility for one person, one task.
So, allow them to work together especially if they want to if they don't want to, make them.
Access to coworkers is another part of it.
We all heard about those like team activities when they-- when you go to the forest and I don't know, hug the trees.
The goal of this is to actually to hug the tree the goal is to build your team.
To make sure people in your team are spending time together and talking to each other.
And that's how education in company culture happens people just share their experiences.
They say, okay if you want you take it to be tested really fast send it to this person but if you wanted to be tested really thorough send it to this person.
All of this is education in your company culture isn't written anywhere, like no one will write it this guy is fast, but this guy is thorough. No one's going to write it down, but it exists and then your juniors need to be introduced to it. They need to know this thing.
And, they need to have leadership access.
You need to be approachable, or you need to make sure that someone else is approachable because there will be problems there will be boring projects, there will be broken projects and your team needs to support itself if you're not there and if you're not there, think about it you need to be there actually.
The most important thing about working with juniors is that their problems actually highlight your problems. Bad code, people write bad code.
Let's assume it's not because they hate you personally let's assume that there are more interesting and deep problems, maybe the task wasn't clear for them maybe they had no idea where to start with it. Or maybe they were uncomfortable asking their team leaders here's the problem that's highlighted for you. They're not comfortable asking questions.
Another example, yeah, a remedy for this.
You need to give them learning resources you need to give them documentation, you need to have tests you need to have code reviews you need to teach your juniors.
Bad timing, no one is perfect with their estimations and again, if your junior does not estimate tickets it doesn't mean that he or she has no idea how to do it maybe there is a different problem.
For example, I had a junior who never estimated her tickets in backlog, and finally we had this conversation about why the hell did it happen and apparently, a while ago she put the wrong estimation in her ticket, like it was a one hour task but she put it like 10 hours or something.
But it was one of those day when we had clients coming in looking at our like charts and everything and her team leader actually told her like you made us look bad in front of the client. As a result, she stopped estimating her tickets. The problem is not the junior not knowing how to estimate tickets the problem is that you scream at your juniors. So how do you remedy bad timing? Again, guides and mentoring, break down tasks. Give your people access to their old tickets so they can see, okay, last time it took me that much time. Allow time buffers, don't scream at your pupil again. And, there are some things that you need to watch out for. First one is sitting for hours on a problem. I would assume we all love our work and sometimes we get pulled in and we enjoy solving the problems.
But sometimes, people sit for hours on a problem because they literally have no idea what to do about it or how to start, so you need to make sure if they're sitting for hours on a problem you need to make sure that's the first thing because they want to not because they literally have no idea what to do. Avoiding team members, this is a very important sign. There will be conflicts, there will be misunderstandings there will be avoidance, but I've never heard about the problem being solved by avoidance so keep an eye on your team members avoiding each other try to figure out what's happening there and intervene. There is also a thing as lack of interest in a specific area I have an amazing story about this.
I actually know a guy who got a new job got up for lunch, and never came back.
They literally-- like guys from the company literally had to call his family to make sure nothing bad happened to him, what happened? He started, he immediately understood that that's not what he was looking for and that's not what he wanted to do, and he left. So, there is a chance you will hire a wrong person for a job, that can happen.
You just need to make sure you don't keep this wrong person for the job, that you will give them the job they want or you'll find a new person.
And, another thing to watch out for is tasks being too easy. Because we talk about juniors, we talk about sandboxing caring, mentoring and all of this but still, tasks have to be challenging.
They have to teach them something so try not to make it too simple.
At the end of the day, it all gets down to communication. Talk to people, ask them questions listen to their questions.
Don't dismiss them just because they're juniors. Because again, they will become seniors.
If you're lucky, they will become seniors at your company. If you're not, they will still become seniors just at a different place.
So, that's all I had for you thank you so much, and you can find me there if you need to. (appplause) (upbeat music)
