Okay cool, so I want everybody to think back to their first day in their careers
so, probably as a developer, full of enthusiasm, getting to grips with the company
codebase. Perhaps even building one from scratch, and then, I want you to fast-forward to today.
I want you to think about that journey that you've taken along the way. Everything you've
learned, experiencing, and all of your achievements. I'm going to make a wild assumption. You probably
didn't get to where you are today by yourself. You probably had supporters in a variety of
different forms within whether that is friends and family, colleagues, colleagues with loads
of experience, but also I'm guessing you learned a lot from colleagues with not that much experience
too. It's those less experienced developers that can really benefit from your support
and teachings. That's what I want to talk to you about today. The way that you work
with junior developers on a day-to-day basis can have such a big impact on their careers,
and help them get to the next step on their career ladders. Today, I have been an official
developer for two years and ten months, and I realised after I did this slide, actually,
I did that thing that kids do when they want to make themselves sound older than they are!
If you ask a simple-year-old how old they are, notifications simple but simple and three-quarters
because that three-quarters really matters. My ten months matters because it means I'm
nearly three years old! It means still, compared to a lot of people in this room, I'm new to
the tech world, still learning a lot and figuring stuff out. Also, for the left last 11 months,
I've been a software engineer at FutureLearn where we're enabling online learning through
conversation. Before I started here, I was on a great scheme at Marks & Spencer. That
was a 12-month grad scheme, and for me, the majority of my junior part of that career
happened in that period. What we found is that, as junior developers and grads, we were
learning so much so quickly, I couldn't even accurately portray it, that we got to a point
where we wanted to focus on moving to the next point in our careers. We knew that we
need to learn how to code. That was kind of a given but not sure what else we needed to
be focusing on. That's where the confusion kicked in. We thought what are we supposed
to do next? We didn't know. So, before I share what we learned along the way, I am using
the term "junior" here, but where you work, you may have different titles for junior developers
- you could an intern or a grad. I will stick to using the term "juniors". What I found
is that we could tackle this from two different aspects. You could be doing things as a junior
developer in a supportive and healthy environment, but also you, in this room, as supporters,
can be doing things to encourage and uplift junior developers to be moving on to the next
stage in their careers. So, I want to start with junior developers, though, in the hope
that you will take this advice back to the junior developers that you work with but also
remember what it was like when you were a junior developer. When starting the fact that
junior developers need to be in an environment where they feel they can stretch themselves.
Whether this is in areas they struggle with, or the areas they want to develop most. And
I really, really wanted to improve on my communication skills at the time. So, whether I was in pairing
sessions, in reviews, or just general presenting, I really wanted to improve myself in this
area. I was really fortunate to be working with a great team that would encourage me
and help me to improve in that area, without any judgment. I also worked with another grad
who knew they were starting to move on from a junior developer mind set when they thought
they could start teaching people in their team things. I found that a lot of the juniors
I talk to today, they feel they're not ready to teach, and I don't think that's true at
all. Local meet-ups, like Codebar, Black Girl Tech, Code First Girls, they're always looking
for coaches to come and support completely new people that haven't even seen a line of
code before. So these are great opportunities for them to learn more about teaching, or
stretching themselves in a new area. But I found it is important when you're looking
at ways you can stretch yourself is to think about it in this kind of zone. If your junior
developer is picking up an easy task that they know they can do, completing them really
quickly, and picking up similar once and - one and probably sticking in their comfort zone.
You want to come outside of that, out into the stretch zone where they're being challenged
but also where they are developing. This is the optimum area for them to develop and learn
new skills. But you can go too far. What you don't want them to do is to end up in this
zone - the panic zone. This is literally just stress. You do not learn anything in this
area, and, if your junior looks at you and says, "Wait, you want me to do what now?"
You've probably stretched them too far. But just because something in is not in their
panic zone today, doesn't mean they can't move into their stretch zone. The more they
learn and develop, the more this changes for them. What I found was the - what I found
was good is how to make a change in our wider business. Your adjourn developer can be looking
at things specifically on your team but also specifically in the tech department or the
whole company. An example of this is that, on my graduate scheme be I was in the same
role for the whole 12 months. We thought it would be really useful if we could try out
different areas in the business - so maybe I could try Android development, or iOS development,
just to see what these different areas are like. We talked to engineering managers, and,
with the other grads, to get this in place for the next graduate cohort. It's those kind
of changes when you're involved in them make for good chats for new interviews when you're
looking for new roles, but also looking at getting promoted to the next level too. When
the junior developer that you work with is making all these amazing changes and stretching
themselves in new ways, you really want them to start gathering all that evidence, whether
it is in a Trello board, a Google doc, whatever, helping them keep track of that is really
important, and, again, it will come in useful for those interviews for roles that are at
a higher level. This is something that I did retrospectively, which took a really, really
long time. I wish I had done it as I had gone along too. Before I move on to what supporters
could do. I was going through Twitter on the weekend, and I came across this tweet by Carolyn.
I couldn't agree more. As a new person or a junior in the company, you could feel as
though you're a burden to your team. You're not. Yes, it is completely challenging, but
their energy, their curiosity, and their fresh perspective are absolutely invaluable to your
team. So I want you to make sure they know that but also make sure that you value that
perspective too. That's a lot about juniors. How can you support the junior developers
that you work with? Well, just start by investing time. Because we want them to work towards
that point, that they feel independent enough to pick up tasks by themselves. So teach them,
and transfer your knowledge to them too. One of the things that a lot of people do will
be pairing but think specifically about good pairing. In my first couple of weeks as a
grad developer, I was working with a more senior engineer on integrating and linting
tool into our build process. It was the it was quite hard to follow along. I was looking
at the code, and they were explaining it to me but it got to a point where I actually
fell asleep in that process! Like, it wasn't that bad, it was just for a second! But, if
that person had just given me the keyboard, given me the mouse, and let me drive, go and
go at a pace that suited me, I would have been a lot more engaged in that session and
learned a lot more. Also, think about asking specific open questions. So, it's easy to
explain a complicated concept, and then at the end, just say does that make sense? Usually,
it does at the time. But later on, you will probably forget. If you ask something specific
to the code that you're looking at on the screen, if I move this decoration of code
to - declaration of code to this other file, what will happen and why? If I run the tests
against this code, do you think they're going to pass? Why do you think that's the case?
And asking those kind of questions, you really get a much better understanding of where they're
at. Do they actually understand what it is that you're talking through? Then, if they
don't, you can go back and explain that in a little bit more detail. I found that really,
really helps for me. And, as you start to get the know the junior developers we are
working with, we need to create opportunities for them to develop. So, a great way to know
what kind of areas to focus your attentions on is something that I did as a graduate developer
if that worked really well for me, and we called it Living" objectives. All of the areas
around the outside were the things I wanted to focus on. After chatting with my line manager,
I decided on these things based on personal interest but also what I needed to be good
at in order to do my role. The lighter orange shape was my goals area, I wanted to be confident
in JavaScript, CSS, and user experience as a front-end developer. The shape in the middle
was my confidence level. But each one-to-one, my line manager and I would focus on a specific
area, so maybe that was the ES6, and my line manager would show me the right person to
talk to, or recommend some tutorials, and I would come back and feel more confident
in that area. Or maybe, they would recommend that I speak at an all hands and get more
skills at present be and speaking. What you'll find is that each time you come back to this,
your confidence level is growing, and it's a great way to show your progress as a junior
developer. The final thing I want to talk about for people that are supporting juniors
is just giving regular feedback. So, this is something that will come up over and over
again. We've already heard it a couple of times today. Feedback is so important. One
of the graduate that I worked with as well mentioned how confirmation was really important
to her because, when you look around as a junior developer and see a lot of people who
know more than you, it's hard to see what stage you're at. Getting that confirmation
from the people you work with is really useful to know where you should be focusing your
areas and knowing where to improve. So like I said, giving feedback is hard, but think
about giving specific and actionable feedback. Reference a specific moment in time, and think
about what you want that person to do with the feedback you give them. So, for example,
in a Sprint review yesterday, I liked the way that you structured your presentation.
It made it really easy to follow. So, if you're not where to start still, I always liked to
this structure, and this is something I've done in retrospectives but I find it lends
itself well to giving feedback as well. Think about what you should be doing more of, what
that person should do less of keep doing, and this I find is really useful when somebody
has asked you to give feedback and you're not sure where to start. So, if you don't
take anything away, please do just give your junior developer that you work with lots and
lots of feedback. But, to wrap up, I really think junior developers should be looking
at ways that they can stretch themselves, and make change in a wider business, and then
gather all that evidence of ways that they can be, that they've been amazing. As supporters,
please invest time in developing the junior developer that you work with. Create opportunities
for them to progress and increase their skills, and then just give them regular feedback so
you know where they are at. But just know, if you already work with a junior developer
already, you already are making a serious change in their career, and you're already
an inspiration. It's amazing that you are hand-crafting the next generation of developers.
Thank you so much for this! [Applause].