Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Today we are going to answer the question, how do you onboard junior devs to AWS? So we're going to chat about what fundamental concepts to focus on first, how to make a plan, pairing and giving hands-on experience, learning troubleshooting skills and creating a virtuous cycle for learning. My name is Eoin and I'm joined by Luciano and this is the AWS Bites podcast. Luciano, is there one tried and tested method that works for you when you're onboarding junior devs onto AWS? Yeah, that's a really interesting question. So I think there is a method and probably that's what we're going to try to cover today.
Luciano: But I also think that it's very important to recognise that everyone is different to some extent, different people learn in different ways. So don't just try to apply the method to your own So don't just try to apply any method, I guess, not just the one we are about to suggest blindly, but try to always listen, be ready to adapt and also ask for feedback regularly. And then, of course, the next question is, how do you get the feedback from the users?
So I think that's a really interesting question. So I think there is a method and probably that's what we're going to try to cover today. But I also think that it's very important to recognise that everyone is different to some extent, but also try to always listen, be ready to adapt and also ask for feedback regularly, try to make sure that what you're trying to achieve, the way you are proposing it is also comfortable enough for the other person.
And maybe if they have preference to try different things, be ready to support them and adapt to whatever is the suggestion. OK. I would probably start by having a goal that is very well defined and agreed between the two parties. We are trying to, of course, we're not expecting anyone to just come in and learn everything. So we just need to agree on a subset of concepts that make sense for a beginner.
And just to make an example, you might agree on, OK, we are just going to try to learn about IAM, S3, API Gateway, Lambda and SQS. And that's probably a good enough body of knowledge that somebody can use that and build something with it. And of course, that comes a little bit with understanding the basics and the basic tools. So you probably might want to explore something for infrastructure as code.
Probably it's not going to be cloud formation from date zero, but probably you want to do something a little bit simpler like SLS or some. But you definitely need to start exploring the CLI and the SDK. So also these things will get into the mix, I suppose. So probably what I will do at the very beginning is start to explain in general all the account system, what is an account in AWS, how do you log in and how IAM works, how do you set up the CLI and then maybe based on the subset of services and knowledge we want to learn, we can discuss about, I don't know, what are those services for, what are the basic topics and how do you use maybe in a very simple way some of the services. And yeah, it's very common to hear people saying, oh, you need to explain how VPC work and networking and all this. I think there are like 15 different concepts that you need to understand just to make sense of all the networking stuff. But I have a feeling that in 2022, especially with all the serverless stuff that has happened in the last few years, you can probably get a long way without really having to fully understand VPCs. So probably I would leave that as a secondary topic unless you know that in your company, you are actually dealing a lot with VPC and networking at a very low level and that's required for the job. So yeah, you'll need to learn it in that case. So did I forget, I don't know, anything or would you do something different?
Eoin: I think that sounds like a really good plan, having that goal and knowing what subset of topics you're going to deal with because you could very easily get completely swamped and overwhelmed otherwise. And I think one thing to be considering is how much time do you leave them, the other person just work on their own versus how much time do you work with them and do you watch over their shoulder too much.
So you want to get the balance right. You want to give people enough freedom to learn on their own, but you want to give them the right amount of support as well. So part of that is just pairing to make sure you're explaining the concepts well. Having a pair of sessions where you show them, but they also get the opportunity to drive as well and you give them constructive feedback and tips along the way.
Hands-on experience I think is probably the best way for most people to pick up these skills. Maybe a good idea would be to propose a project in an area that matches one of their interests. So maybe if there's somebody with front-end development experience, it could be building an API that they could talk to from a web app, for example, or if they're a data scientist, it could be something in that field with some of the AWS data science services.
It depends also on the context. So if you're in a company where you've got real projects that they can contribute to on day one, that can be a really good thing too, because it's much more of a real world tangible context. The only thing to be careful of there is don't, I suppose, get involved in areas that have too much complexity around them. You know, if you've got lots of edge cases, lots of integrations, and they need to understand the whole holistic system in order to just understand the one piece they're working on, it's very easy to get lost.
So I think you need to find the right project that people can get involved with. But it's always possible that if you've got teams of people working on AWS projects, have the junior devs shadow them and see what it looks like to work on a project. And they can even mix the two. They can work on a training project at the same time. The main thing is to offer the support when it's needed. So if they're working on a project, follow up regularly with one-to-one sessions to answer questions and find out areas where they need to invest more time and just help them on a continued basis. So I think it's important to have the review cycle so people need feedback. And when you look at the work of somebody who's just starting out with AWS, usually you can give them a lot of nudges in the right direction, some tips and tricks that you've learned just from your hard-won experience and some gotchas as well. Absolutely. Do you think there's a system you can put in place that allows you to make sure that you don't forget to give that regular feedback and you keep that level of support ongoing and not just for the first two weeks? Yeah, I think this is a very big topic.
Luciano: And as with any big topic, it's good to do baby steps and then repeat. And so I wouldn't do it in any different way in AWS. So probably if you're supporting somebody, you want to have a face, you can create a virtual loop, a virtual loop where you repeat this kind of process over time. And you probably start by explaining or exploring together some new concepts. Then maybe if there is something a little bit more practical, you can show them how to do that.
And then the other way around, you can tell them, now try to do this yourself and you oversee what they're trying to do and see if they're on the right path. Also, you might just leave them alone to build something for a while and trying to also build up that self-confidence that they don't need to have somebody looking at them all the time to do something. But even when that happens, make sure that you are ready to offer help and to offer review. So as you said, oh, and that's the best opportunity to try to give some tips and tricks and opportunity for exploring other concepts. And of course, if you keep repeating this, every time you do this loop, you can add new concepts to the mix and that over time will build a good body of knowledge. So yeah, I don't know if there is, though, any other fundamental skill that we haven't mentioned yet.
Eoin: There is one thing that I find is really always good to focus on from very early on is helping to build troubleshooting skills. We forget that as developers, software engineers, engineers, engineers, engineers, we have to in general, you spend a lot of time fixing existing problems and not developing new code. And sometimes when we think about training people, we're talking about developing new applications from scratch all the time.
So it's not necessarily very representative. So think about troubleshooting skills. And one of the easy patterns you could fall into for any developer is to try to go as quickly as possible from the problem you see to getting it fixed. And the fastest approach isn't necessarily the best one. And usually, actually, the fastest one is the one that gives you the least opportunity for learning. So you can imagine you see an error message, you Google it, you get the Stack Overflow answer, you paste it in.
You've really missed a teachable moment, as they say. Treat every failure or every problem you encounter as an opportunity to really understand how things work and understand what is this error message telling me? How can I trace this back to what I've been doing, understand it, and then work forwards then towards a solution? So it's really about following the evidence. And once you've fixed it, then you could maybe have a retrospective and look back at how you got from the problem to the solution. Just repeat that and reinforce that learning. That's one that I'm particularly keen on. What do you think about training and certification? Are those useful at this point?
Luciano: Yeah, just before we move into that, I really like what you said before about the retrospective. And I think that's also an opportunity, especially when you're talking about an incident or a bug, which is most of the case why you are troubleshooting. To ask the question, what can we do to avoid this from happening again? Because that's another opportunity for, first of all, making sure that you understood the problem, but also you understood it up to a point where you can start to see a little bit more long term and try to apply decisions that will make your life easier in the future because you're not going to have to deal with the same problem over and over again, hopefully.
So I really like that part. And I just wanted to say, yeah, let's also see if it's something that you can proactively address for the future. But going to training and certification, this is a topic that, by the way, we explored quite in depth in another episode. So we're going to have a link in the show notes. But I think it's very important to also have, first of all, a library of material that people can use to explore all sorts of different concepts and make sure that this library provides a list, a basic introduction to things that otherwise might be a little bit more complicated to approach in an organic way.
Other than that, getting a certification is also something we discussed a lot. And it can be very useful, especially the basic certifications. So the cloud practitioner and the associate ones, they tend to give you an overview of all the important concepts of AWS and understand what are all the different areas. So those might be a little bit tricky and might be a little bit intensive, but definitely useful if somebody is willing to put the effort and try to get a certification.
They should be supported because that definitely is going to boost the learning process in my opinion. Yeah, we'll put the links in the description. And hopefully you can tell us if that makes sense to you. And if you did that kind of journey, how much did it help you to ramp up in AWS? And one final thing that I want to say is that we mentioned all this process from the kind of the perspective of somebody senior that is trying to help somebody that is just starting with AWS.
But I think there is another angle to it, which is as soon as you acquire a little bit of knowledge, you should be in a position to teach somebody else that knowledge. You don't need to be a master to basically be able to help somebody else. Right? And I think this is something we can introduce in our virtual cycle if you want by making sure that if we have more and more people coming to the company, you don't have to take the most senior engineer to train the most junior engineer. But you can use also your junior engineer that have some degree of knowledge to start to teach something to people coming in the company. And that's a great way for them to, first of all, build confidence and reinforce their learning in general. But also I found as somebody who has done this activity that sometimes when you try to teach somebody else, you realize all the gaps in your knowledge, you get very interesting questions. And these are great prompts for you to revisit your knowledge and try to understand what are the gaps and what you need to learn a little bit more in depth. Yeah, that's really good one.
Eoin: It definitely, I've been there so many times when you try to explain something you think you know very well to somebody and then you realize you've got to fill a whole number of gaps in your knowledge. That's a really good point and maybe a good place to finish. So thanks everybody for listening and watching again on AWS Bites and we'll see you in the next episode.