These transcripts were captured live by a captioner. As such, there may be small errors. If you spot any, please feel free to submit a pull request with amendments.

Hello, everyone. Today, I want to talk about career progression, and specifically upskilling and moving on in your careers to mid-level, seniors, and beyond.

I want to start first by asking a question that Sascha kind of asked this morning, can you picture someone in your industry who you respect, someone you think is awesome, someone maybe that has really like high-quality skills. Like what their characteristics might be, something that you look up to. Why is it that you respect that person?

So I thought it was really funny that morning, Jo mentioned social media celebrities, because I'm a sucker for all of those peel. I always think of someone called Ire Aderinokun? She's based in Lagos in Nigeria, a booming tech scene out there. She's a front-end developer, she's also a designer. She's an expert in web technology. She is a writer, has a blog called Bits of Code. If you can think of a front-end topic, she's already written about it. She's amazing. She's an international speaker, talking about things like progressive enhancement, accessibility, web components. I don't know if you've heard of the term "career crutch"? I want to be able to do what she does too one day.

The point I'm making is that developers like Ire and the people you're thinking of, they weren't born with the skills overnight. They've been developed over a period of time. Maybe they built new features. Maybe they did some mentoring and got promoted at different areas in their careers. But they all started out at juniors. Some of them are self-taught. Some of them went through some sort of formal learning. Some of them have learned on the job. They all went through stuff. Right, so juniors are really, really important, and we want to make sure that today's junior developers and designers are all progressing through their careers, so they, too, will be amazing, people, people like us in this room are inspired by Pip, especially because there just aren't enough people in the STEM industry. There was a study that came out that, for every 13 jobs available in a STEM subject, science, technology, engineering, and maths, there was only one person qualified to do that job. This has a knock-on effect. It means that companies are unable to progress at the rate they want, and also technological innovation will be happening at a stellar rate, because we don't have enough people with the know-how, but, if we imagine a world where we do a good job of training at the junior developers that we have, and they go on to train up other juniors, and those juniors train other juniors, we just go on this like great cycle - that's the dream - but it's hard to do. I want to talk about how we can do this.

Before I get into it, as mentioned, I'm a software engineer at a company called FutureLearn. I've been at FutureLearn a little over a year and a half. I love working there. I do a lot of front-end development work. FutureLearn, if you don't know about it, is a soft social learning company, so you can access online learning and courses through lots of different universities and institutions from around the world, from business and management, to teaching, to household technology. Before I started at FutureLearn, I was working at Marks & Spencer. There I started on a 12-month software graduate engineering scheme. That's for me where the junior part of my career happened, and I learned so much on that process.

So, when I talk about "junior" in this talk, it's not a title but I'm aiming it at anybody early on in their careers. I also want to target the people that work with you, the tech leads, the mentors, and the managers. They can be instrumental in your development. A lot of what I want to share with you today came out of confusion for me, because I was confused by what my career progress is supposed to look like. How I was officially supposed to move from a junior developer to a mid-level developer, I had no clue. I had no idea how long I was supposed to be a junior developer for. Nobody had the answers to the questions. But I think we can get on that career progression by looking at it from these two angles.

There are things that you as juniors today can be doing to move on to the next stage in your careers, but there are also the things that the support the work that you're doing to help you progress. So starting with juniors, first, start thinking about ways that you can stretch yourself. This is something that I actually always groan at when somebody tells me to stretch or push myself. You're going to tell me how to do something that I find uncomfortable. I don't really want to do that, but it's like a necessary evil. For me, ironically, this was public speaking, and communication, because I'm generally quite an awkward person, but the idea of putting yourself out there, through lots of different things, makes that whole process a little bit easier. That might be something else for you. One of the graduate developers I used to work with, for them, it was all about teaching. When they started to be able to teach other people in their teams things, they felt they were moving on from the whole junior developer mind set. The teaching in itself is quite a crucial skill that you expect from senior engineers, or senior designers, but it's something that you can start doing today.

Jo mentioned this morning, there are places CodeBar, or Black Girl Tech - so many organisations looking for coaches to come and teach complete beginners to technology, people who haven't even seen a line of code before. It's a great experience. I once did it, and somebody asked me "what is programming?". Such a good question! I don't even know how to answer it. You learn so much from teaching other people. And, when you think about ways that you can stretch yourself, if you think about it in this model, in the middle, you have your comfort zone right? These are your everyday activities. You don't really learn that much in this area. I mean, it's called your comfort zone for a reason because you feel comfortable here.

But what you actually want to do is come out into this stretch zone. So all the tasks that fit into this area are really challenging, maybe it's something that you've never done before, or you take something that you do in the same way over and over again and switch it up and do it in a different way. That's the way to stretch yourself. And this is like the prime space for learning new things. But you can go too far. Where you don't want to end up is in your panic zone. This is literally just stress. You're not going to learn anything. You're not going to learn anything here. It's not going to benefit you in any way. So, you can tell this by just imagining yourself doing that. So, for example, if you think of yourself coming up on stage and doing some talks, some public speaking, if you want to throw up just at the thought of that, it's probably in your stretch zone, maybe don't do that today, but think about it for the future, just because it's in your stretch, your panic zone today, it doesn't mean it can't move into your stretch zone tomorrow. It's fluid, and things are always changing as you're developing and progressing.

I think it's also worth thinking about ways that you can make a change in your widest areas. So think thinking slightly out of your role and looking to make a bigger impact. One of the things on the grant scheme that myself and the grads wanted to do was look at rotations. So I'm the on the 12-month scheme we were on, we were in the same role for that whole period. We thought as we started our careers, it would be a really good opportunity to learn from different areas of the business, so like front-end development, back-end development, APIs, the development team. That would be a really good opportunity for us to learn different skills. So we got together, we talked engineering managers and directors of the company to make this happen for the following cohort, and it's just that we had an idea, we thought it could be better, and we made that change happen. It's these kinds of extra extra curricular activities that look good when you go for a promotion chat, or an interview to talk about some of the stuff that you are doing outside of the main role. And, when you see a chance to improve some of these types of things, fix it if you can. In fact, fix all the things because you're making life better for everyone. And it's a great development opportunity for you.

One of the things I really struggled with, because I was really reluctant to share my opinions as a junior developer, and I can probably improve in this area, actually, I felt I didn't know enough to contribute to a lot of the discussion that is were happening. Sometimes, they just went straight over my head. But I think it's really important to recognise that all of your thoughts give really good insights into the teams that you work with, because it's really interesting to see how a new person sees the kind of things that you've been working on, that teams have been working on. And it's really important that you're working in an environment that lets you feel safe enough to do this. A tweet that I saw a little while ago now, by Caroline who might be here, is that juniors have a perspective that deserves to be heard. And this is so true, because I felt at the time being a junior, I felt like being a burden, but it's not.

It's a very challenging experience, but your energy, your curiosity, and your fresh perspective are invaluable to your teams. So share your thoughts, because it's useful for your development and the teams that you work in. But do remember that it is okay not to know. That you are just starting out. You're still learning a lot. And you can't know everything on day one. You can't know everything ever. So ask lots of questions. Learn lots. And I find a top tip that worked for me was just to state the obvious and reiterate the assumptions that people are making in the room. Because you'll find that we don't all think in the same way,and just because it's obvious to you, it doesn't mean that it's obvious to the rest of the people that you're communicating with. Just a really useful way to make sure that everybody in the room is on the same page. While also contributing to the discussions that are happening. And then, you can go away and pick up on those extra informations that you're not sure about later. And then one last thing that I want to pick up on for junior developers is the importance of celebrating your achievements. You're going to be to make the amazing progress at a super-fast rate. It can be hard to stop, and just appreciate that you did something really cool, and it doesn't have to be consumed by all the other things you're planning to do too?

Has anyone heard of Lara Hogan? She's another social media celeb. She has this page on her website. It's a way for her to celebrate her career goals, so every time something core happens in her career, a book deal or a promotion, she goes out and buys a donut, takes a picture, and puts it on her website, because it is so important to celebrate the progress you're making. And each doughnut here is like a mini celebration. What I like about this is just, it's also a great confidence boost when you look pack at the different pictures and see the different ways that you've been progressing. It's also good documentation which brings me on to the next point of collecting evidence, because that documentation becomes your evidence of your personal growth. After you've been stretching yourself, making changes, a little bit outside of your role, you don't want to forget all of that stuff, but it's all really important. Just write them down. This is something I really wished that I'd been better at. I ended up doing it retrospectively at one point when I applied for a new role. When you look back at all of your different achievements, it's great to great for competence when they ask you to tell you about a time that you worked in a team, for example. You've got a list of all of these things you've already done. You've got a list of examples when you've already shown this. And, if you're not sure what kind of evidence you can be collecting, think about the combination of soft and hard skills.

So you probably all come across the term "soft skills" already today, and soft skills are general attributes that aren't specific to a job or an industry. So these things in soft skills, like leadership, or empathy, communication, all those really important ones. They're generally hard to learn without just doing it and learning from your mistakes, whereas the difference with hard skills is that they can usually be taught in a series of concrete steps. So you might find that teaching someone how to code in a simpler process than trying to each someone how to listen and communicate effectively. But those hard skills are important to develop depending on the role you're doing. Because you want to be able to perfect your craft. Whether you're a designer, or a developer, you have very specific hard skills, and, with the right resources, you can improve them and work on them. Because I don't know about you, but when I was learning how to code, my own question would be does this code work? Am I happy when I look at it again? It's fine. Eventually, you get better, look back and see ways that you can improve what you did as a developer. So think about how you can do this specifically for your hard skills. This will be one of the first things that some of the companies that you work at will look at. And think about how you're planning the new things that you learned to the job that you're doing. How are these skills building up your knowledge base? And someone taught me about your ... not so long ago.

I think this concept of T shape is useful for deciding what kind of things to learn. As a front-end developer, I was really focused on learning JavaScript and I didn't leave that scope of just learning JavaScript. But if you think about having a shape, you have a foundation, a base skills, or base knowledge, and then you build depth in one or two areas that you're interested in. So, things in here could be anything from writing, to drawing, coding, to making music, and that could all sit in your base knowledge. And then, thinking of areas that are of interest to you, or relevant to your work, then think of areas that you want to excel or be amazing at. That is where you start building depth. So once you decided this, that's how you can split your time - your development time. If I relate this to my experience in my base and knowledge, I have learned a little bit of Ruby on Rails. I've learned a little bit of APIs, I've learned a little bit of Android development, all because they sounded interesting, so I learned a little bit in those areas. But the place where I'm building my depth is in JavaScript and front-end tools. So that's where I spend the most of my learning time. So, if I have two hours a week to develop, I will spend one hour learning something more advanced in JavaScript, and one hour just picking random bits of tech I heard about today. What I found is, having that base knowledge in different areas of technology, just different areas generally, has made me a better front-end developer. Because, while you're not focused solely on JavaScript, you have a better understanding of how to work with different kinds of teams of people around you. It also makes you more attractive to the employers that you work with. And, who knows, maybe while building your knowledge base in some completely random area of tech you find something that you enjoy a little bit more, and maybe want to change your focus to that new thing.

And if you don't have a career framework where you work, some general things that you might want to document could be specific hard skills like I mentioned, but soft skills including communication, sharing ideas, how you share ideas with your team, how you shared ideas with your eider technology team, maybe you're interested in public speaking. Are you being proactive? How have you been working on your own personal development goals? Are you coming out to events like this one and making your own efforts to improve your working environment? How are you at giving and receiving feedback? That's something I'm going to come on to again later, but it's also really useful for personal development. And then teamwork. Can you work just at well independently as well as part of your team? Can you provide examples of that? And just having this listed out is a great way again for competencies and taking these to them. I started off with a Google doc and moved it over to a Trello board. It looks like this now. You could use whatever. Generally write some notes out. Maybe you could make your own doughnut web page too if you're a fan of doughnuts. For me, this is a combination of my own things that I'm interested in for personal development reasons, and things that the career ladder at FutureLearn wants to see examples in.

But the most important thing here is keeping track of your personal development. Because I was able to print this out, take it to a meeting, and use it as a way to see to say that I deserve a higher salary. That's not just about juniors. I want to touch about what we can be doing as supporters to help juniors progress in their career. Starting with just investing time, I know so many junior developers who have been hired and they've had the experience where they've just been expected to get on with things from day one without any support, or the atmosphere is just too busy to give them much support. And that is a really difficult situation to navigate, especially as a new person with little experience. I think a good first step is to make your colleagues aware of this. Consciously set aside time to discuss a plan for your personal development within the company. Because it is a worthwhile development, and that's yourself. Supporters invest in time speeds up your development ten-fold. Ideally, you want to be able to have a mentor. As a junior, you don't have to have one designated mentor. I have had a lot of different unofficial mentors that have supported me in my career. But having someone to direct all of your even small questions is so useful, and having a mentor that can help you learn how to get up and running, answer all of your questions, and just share things like best practices and tips with is useful in your career.

If you can get that information out of their heads by asking them lots of questions, that's great too. If you are a mentor, make sure people feel comfortable asking you those questions, and try and find that balance between supporting from one, at also giving them that independent to figure things out by themselves. Just be there to help them out. I'm sure a lot of developers will probably do a lot of pairing. I always want to make sure that people do good pairing. Don't let the junior developer you work with be a passenger. I have had an experience in the past where I was pairing with a more senior developer on my graduate scheme - it was probably the second week of being a developer officially - and we were working on something so complicated that I lost track of what we were doing to the point where I actually fell asleep! [Laughter].

But clearly, that whole situation was just not attractive. It could have been a lot more interesting and a much better opportunity for me to learn if the person had given me the keyboard and the mouse and let me go at a pace that was much better for me, because most people learn by doing. Letting the junior developer drive gives you a better understanding of how they're doing, and what they're picking pup. Also ask open questions. Sometimes, it can be easy to explain the concept, and then ask, "Does that make sense?" At the time, it probably does, but it's easy to forget. If you ask them something more open, like, if I move this code over to the other file, what's going to happen? If I run a test suite now, do you think the test is going to pass? Why? It gives you a better understanding of how that junior is doing if they're picking up what you're trying to teach them, and, if not, you can explain it in more detail. It has two-way benefits. The junior developer is learning, and, while you're developing your key skills too. I think the most important thing that supporters of juniors is to be able to create opportunities for you. So, giving you a chance to develop things that you class as your weaker areas.

One of the things that I found really useful as a graduate was something called "living objectives" so it looks a little bit like this. Around the edge are all the skills that are relevant to my goals, so I was really interested in developing my JavaScript knowledge, CSS, and ES6. I also wanted to get into speaking and presenting, and the biggest shape in the orange shape, was my goals in all of those areas. And then the smaller shape in the middle was my confidence level at the time. I first did this about two years ago. What was good about this is just having a single place to look where we can focus my personal development. I would have regular one-to-one s with my line manager every two weeks, pick something here to focus on for the two weeks. If I chose JavaScript, my line manager might create an opportunity for me to give a talk about the JavaScript thing that I just learned in the next engineering catch-up, or he might choose someone who knows a lot about JavaScript to come and pair with me on a new feature. But it's a great way to decide what kind of opportunities that you can be working on, and you can develop in. And what you'll find is that every time you come back to this graph, you start developing your confidence in lots of different ', and it's just growing and growing, and you can see how you're developing over time.

The final thing I want to talk about is regular feedback. This is something I personally wanted the most, and something that I found really useful. This can be anything. Like, "I like the approach you took in the pull request" to the full report that the junior developer you're working with can be improving on. One of the grads I worked with said they wanted to make sure they were going at a good pace. Just having that that feedback makes a big difference in your career. Giving feedback is really hard. So I always find it useful to give specific and actionable feedback. Thinking about a moment in time, referencing that moment in time, and thinking about what you want them to do with the feedback afterwards.

So an example might be in the sprint review we just had, I wasn't completely sure what you were trying to get across. Could you maybe think about structuring it this way instead? And I came across this graph in a retrospective one, and I found it's really useful for giving feedback to. What kind of things do you think that person should be doing more or less of? Do you think they should stop or start doing something specific where or do you want them to do something that they were doing really well? It's usually a good starting point to coming up with ideas for feedback. But wrap it up, if you're a junior developer, start thinking about the different areas that you want to stretch yourself in and grow your career goals.

Think about ways that you can share your opinions in a different scenarios that you're in at work, and make sure to celebrate your achievements. That's really important. And, if you're a supporter of a junior developer, invest time in helping them develop. Create opportunities for them to focus on the things that they consider their weak areas, and keep giving them regular feedback so they know where they are. One final quote from from another graduate developer I used to work with. You don't wake up one day and realise you're not a genius any more. It's true. You don't do that. For me, I became a mid-level developer when I had enough examples against the mid-level role in our career framework, and it could be slightly different for each of your team. But absolutely don't worry about where you're at right now. I can guarantee you're doing great, that you've got this!

Thanks for listening. [Applause].