0:00

What we really need from engineers, and it doesn't matter which sector of the industry you go in, is that the biggest thing you need is a willingness to learn, because even now, and I'm 20 plus years into my career in it, I'm still learning every day. And you've got to embrace the fact that there is no end to the learning. Hello and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Eldeboz. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Right. Welcome to another Pie Bytes podcast episode. This is Julian, and I'm actually not here with Bob. I'm here with someone different. I'm here with Reese Powell. Rhys, do you want to introduce yourself? Yeah, hi. Thank you, Julian. My name's Reese. I am an engineer of sorts, mostly infrastructure, but dabbling in the realms of development a lot more these days. Currently working for a large service integrator, I think is the best way to describe them, with my role focused around capabilities. So training and things like that, particularly graduates to fill the gap in the market, because, as we all know, it's an exciting place to be if you work in it, the number of jobs that are out there at the moment with the lack of people. So focus on getting grads up to a capable level, and that's about it. Awesome. Thanks, man. Well, everyone listening, Reese has been a, I'm going to say, huge fan. Reese, I'm going to put words in your mouth. A huge fan of pie bytes for yonks now, almost from. Since we started, I think. And, yeah, he's in. Many of you who are in the slack community probably seen him around, and, yeah, it's just been a pleasure getting to know Reese over the years. So I thought it's about time to have him on the podcast. There is a story of us hanging out in London a couple of years ago, I think maybe two years ago now. And, yeah, I don't think we remember too much of that night, but we won't go into that. I remember it all, Julian. You don't want to know. You don't want to know. Yeah, don't forget, I get to edit this after we're done, so anything you say didn't happen. So. Yeah, look, one of the reasons I've asked you to pop on here and have a chat, Reese, is exactly what you mentioned with regards to the grads. So there are a lot of people listening to this who are trying to get into, you know, the python industry, trying to get into the coding industry, be developers, all that stuff. And it almost doesn't matter how old you are, right? It. If you're fresh and you're coming in, well, you kind of need to learn the same things, or there are some pitfalls. There are skills that people should know coming into it. So with all of the experience you've had, you know, training up these grads and with their, you know, mentoring them through learning python and being developers, if we were to just dive straight in, what are some skills that you feel people should, could work on or should have coming into something as a grad or an intern, perhaps, or even a trainee? Yes. Surprisingly, none of them are really technical skills. So the grads that we get, the trainees, the interns that come in, some of them come in with amazing degrees from amazing universities, but know absolutely nothing about it at all, even if they've done a computer science degree, because it's a lot of emphasis on just do this. What we really need from engineers, and it doesn't matter which sector of the industry you go in, is that the biggest thing you need is a willingness to learn, because even now, and I'm 20 plus years into my career in it, I'm still learning every day. And you've got to embrace the fact that there is no end to the learning. Problem solving skills is the next thing. That's the next big thing I get. An awful lot of my time is spent teaching people how to break down and how to analyze. There's a lot of binary trees. It aligns with development in the fact that there's a lot of binary trees. Start at one point, chop it in half, have a look. If it's not broken, decide which side you're going to go and keep chopping stuff up. And then there's the understanding how you as a person learn. We're all very, very different. You can give people books, you can give people YouTube, you can give people online courses, but actually, that might not be any good for them. So a lot of what I do to help the grads in particular, but I've even rolled out the training program that I've got now to some very senior engineers, and it's been a surprise to them, is they don't ever actually tell them what to do. It's that I would like you to deliver this for me. How you get there is your choice, but if you start, come back and have conversations, I can help you. What I want to understand is where you've been, what you've done, what the problem is. You see what you thought about, what you think you can do next. So, surprisingly, it's nothing deeply technical. It's all about understanding you as a person and how you learn and your willingness to learn and how you broke down problems. That's really cool and definitely in line with a lot of the stuff bob and I talk about from week to week, especially on this podcast. But when someone's on the outside and going to come into this role, you know, they have to interview and so on as well. So I think from my perspective, being aware of, you know, how you learn, being able to communicate and show that enthusiasm, that willingness to learn, I feel that that's also important in the interview process that grads. I mean, in your experience, did you find hiring the grad, you lean towards people who did that as opposed to just pure technical skill? Absolutely. So I have two essential questions that I ask, and the first one is, why are you in it? How did you get to it? What brings you into it? Because what I want to see is, and it's not necessarily a GitHub, repo or anything like that, what I want to see is this spark of enthusiasm, this passion, because it will grind you down. The industry is a very hard industry, as you know. You work in it, and there are occasions where it's long, painful, boring hours of doing the same stuff you've done time and

time again, or you get called at 03: 7:11

00 in the morning because there's an outage and somebody's done something stupid. And you've got to realize that that is a thing. So you've got to have this passion to be able to get through that. But then the second one is, where do you see yourself in three to five years? And I generally reject the ones that say I'm going to be leading a team and doing this and that because that's not, you know, that's not the right answer. You might be leading a team because you might show in a special adeptness of people management. But as I'm into interviewing people for a techie role, what I want to see is the fact that, well, hopefully I'm still learning. Hopefully my knowledge has grown. I'm more independent. I'm able to start to deliver things on my own. But what I realize is this is a very long journey and I'm still growing, and hopefully I'm growing every day. And it's that kind of response that I want it certainly because technical skills can be taught. It's very easy to teach people really how to develop because you can just say, oh, you've done that wrong. Have you thought about this? But that willingness to embrace the fact that this isn't a, I'm going to do this for three months and then that's it. It's done and dusted. I am the best in the world. It's a constant process of building knowledge, seeing stuff and being prepared to read your code from three months ago and cry at how bad it is, thinking, how did I manage to be that bad? Yeah, no, you know, that's a really good point. And I think these, the perspective that you're talking about here that people should have, I think it's applicable to any role that you go into anyway. You know, if you show up to a job completely cocky, full of yourself, you know, as opposed to having this growth mindset, this humble sort of attitude, you know, you're shooting yourself in the foot, you should be always be humble, know that there's always something to learn and that, you know, a bit of, I guess when you ask that question three to five years ahead, think three to five years ahead. Having a bit of uncertainty there, I think is a good thing. Saying I don't know, sometimes, you know, the road could take me anywhere. It depends what I'm passionate about at the time. And so I think that's really cool. As you know, I am a prime example of not knowing what I'm going to be doing next month, let alone three to five years. It's a vague plan. There's a vague plan idea, but yeah, it definitely, and you're right. Every, every job does, you know, you've got to show the willingness to learn. But I think the it industry is a particular one because the pace of change is that prolific. I come from an old school manufacturing engineering background originally and I did that for ten years before switching to it. And the most exciting, exciting regular change there was they would stick a different color coating on a drill bit to make it last a few more whole drills before it burned out and things like that. So the general principles were there, set in stone and a few tweaks would come in. But yeah, one of the biggest changes over the past so many years has been the likes of Cubanadis coming along and that changes every three months and quite dramatically every three months. So this, you know, I see every three months a change that didn't happen for like five years in my previous industry so it's definitely, you are right. Every, every job should see that willingness to learn, but I think you've got to be dedicated to it. Yeah, the enthusiasm helps. Right. It's funny because you've just made me remember my first corporate role was at Sun Microsystems. And when I interviewed for it, I'd never worked in a data center before, nothing like that. Hadn't worked on enterprise hardware. But my manager at the time told me that I got the job because I was enthusiastic, because I cared about the hardware, I just cared about learning more and just wanted to dive straight into it as if I was Scrooge McDuck, you know, diving into a pool of gold, of money. And after I got the job, I remember him telling me exactly what you're saying, that there were other uni students that applied and a lot of them came in with just those goggles on of, I want this to be my step up into the industry. I just want this because sun micro systems will look good on my cv. And it was all very much a. Not a growth mindset from a dedication from. From a skills level. It was more of a, I just want to earn the most money, you know, I just want to look the best. And so I definitely agree with this, with what you're saying, I think it's great. We see a lot of that. The company I work for is one of the major indian suppliers of people and there's such a big level of, oh, it's them. So people want to work rather than is this going to actually assist me in getting to where I want to go? Are they, are they going to give me the skills I need and things like that. I've had a random, varied career where I've worked everywhere. And you're right, somewhere I can imagine for you, somewhere like Sen did look good on your cv, but I bet knowing people who've worked at Sen myself, that they actually, it was a great company to work for that trained you and put a lot into you, making you good, as well as this fact that it was good for you. And I think people should sometimes ignore the brand and remember it's a lot more about what can this company provide me to help me move forward while I'm providing value to them. Yeah, yeah, yeah. It's like the whole seven habits of highly effective people. The synergistic, I think that's the word relationship. You know, what's win win for both parties? I think it's a great way of looking at it. And to be clear, and people might hate me for this. I didn't even know what Sun Microsystems was when I applied. It's this little company from America doing a few things with hardware and software, like, you know. You mean that they're not a solar power company? I'm confused. So, yeah, it was great. Let's move into the next part. I had another question for you, which was about success and also the failures. So, as you've mentored these people, these grads, you see them growing, you see, you've probably seen the. The good and the bad, for lack of a better word. Right. And there were some people that have the right attitude that will lead to success. And some people probably fall into some pitfalls, some common pitfalls. Elaborate. Do you have anything on that? Yeah, there's two big ones. The first one is the fear of failure. It's unbelievable. It's like, you know, I've spent my entire. I've spent more of my life failing at things than I have of being successful, I believe. Yes. Thank you. But that's good, because at the end of the day, I could tell you not to do things because I've been there and I've done that. But, you know, if everything you do is right first time, then I suspect you're not particularly taking any exciting kind of challenges on, because the reality is, to learn, you need to fail very often. And it's not failure. There's so much, because they've come from university, a lot of these directly, where it's a case of you pass or fail, and they're like, well, I don't want to fail. It's like, well, have you failed? And they've gone, well, no, because I've finished it, the task in the end. And it's like, so do you not consider that you're. It was just a meandering path to the truth of what should have been delivered. And, you know, you've learned a lot of other stuff on the way. Embrace the fact that sometimes you are going to get things not quite right, I think is the best way to describe it. And that's what I push to them, because we all make decisions. We make decisions with the best of our knowledge at the time. That takes us a step forward and say it was just a binary decision. That doesn't mean that taking the other choice would have been any better. It could have been far worse. But what you are now at is another fork in the road, and you've got to make another decision to keep moving forward with that fraction more of information. So there's an awful lot of embrace your failures because they're learning paths. The other big thing, and once again, we're outside technology again, is understand what your customers, the people you're delivering things for, actually want. And sometimes they will say words, and those words aren't what they want, so you have to question them. They don't, they don't. They'll say stuff and you're just like, no. So let's break this down. What are you looking to achieve? So there's a lot of that. And this also falls from the side of, I see so many grads and senior engineers. Just destroys me. Running off doing random stuff that is not related to the ask. Oh, but I thought this would be better. Congratulations. Well done for thinking like that. But is that really what people wanted? You've spent all of this time. Is it bringing value? Is this what the users themselves that are beyond the client are asking for? So sometimes it's a case of being very, very clear what you are delivering, because this is what the client is, or the consumer, however you want to word that person that you're giving your stuff to. This is what they actually want. I just, you know, head in hands. Just why have you spent an extra three days doing this? That has nothing to do with anything that this product needs. Congratulations on making me sad. I feel like we've all been there at some point, seen that happen. So, hang on, did you find that any of your grads came in already knowing that, or do you feel, or did you have to teach them that sort of thing? Like, hey, make sure you're explicit with the deliverables here. Don't just assume no. And we've recently hired between mid and senior and lead engineers as well. And the lead engineer kind of got it. I think that there's this whole lack of experience and understanding that you need to actually ask what people want instead of. I think there's very much this idea within the industry that you just do what you're told. And it's like, well, no, because you've got previous experience that might suggest that what they're asking for is wrong or they. They're wishy washing. You know, I. I've contracted in the past and was brought in because of specialist skills. And I would ask three times and the first time was, are you sure? What were you trying to aim for? And they would say, yes. And then you'd go, my experience is this have come from the background, you know, do you really think, based on that bit of knowledge, that maybe this is really what you want. They say yes again and you go, okay, that's an extension on my contract. Because, you know, the fact that they're not listening and they don't really understand as well and, you know, so it plays off both sides and maybe it's a bit of a specialist skill, but it's definitely something that I see missing quite often from the industry as a whole and certainly from developers. Developers just like scrum masters added this to the product owners, added this ticket in. I've just got to do it. Just do it. Yeah. That's a really good tip for anyone wanting to get into coding, get into a developer role, to remember that because, yeah, it is very easy to get sucked into that mentality of I'll just do what I'm told. I'm the tool, I'm the coder. And whatever they tell me to code, I'm going to code. And that's not always the case. Never be afraid of asking questions. Never be afraid of digging in to find out really what they're trying to achieve with the story ticket or whatever you run it. What do you really want? What you mean by this? Because it doesn't quite make sense to me. Yeah. And that's a communication skill because, I mean, I find with developers I've worked with, I've seen both sides of the spectrum where there are people who can communicate their ideas very clearly and that means they can ask, they're comfortable asking the questions when something doesn't quite sit right in the request or the scope of the project. And so they ask the question and then more often than not, that raises flags and people think, oh, wow, didn't even think of it that way. And it may not be malicious, it may just be they honestly didn't think of it. So if you, you could essentially say, save yourself months and months and how many hundreds of thousands of dollars of dev time and people's time by just speaking up and asking a question. So that's a really good skill. Absolutely. It's very, very weird, the industry that kind of, you know, I'm kind of being very stereotypical here, but there's a lot of introverts in this industry. But it's amazing how that we've got an industry that is so full of introverts where actually we need people who are very comfortable in the communication side of things because that is still to me, the most important skill anybody can have. And you call it out, if you are able to articulate your ideas to any level of people, be them deep techs all the way up to my mother, who knows what a phone looks like. You're on to a winner. Your skill set beyond that, in the technology area, python development, be it infrastructure, whatever, is just then an added bonus. But if you can communicate and convey your ideas, then you've got a very, very strong career ahead of you. Yeah, that's a great, great exercise for people. If you have written a Python, a basic Python app or script, go and explain it to your. To anyone who just doesn't know coding whatsoever, your mom, your partner, whatever it might be. So I'm fortunate to dabble with a few side projects with a guy who's fairly technology literate. But what I realize is I've often gone off down paths because I'm explaining it to him, and I'm like, what the did I do that for? Because you realize then when trying to explain it to him, he's just like, all right. Yeah. Okay. Yep. You've gone too deep. You've gone full on nerd, and you've piled in there. Yeah, that's a great way to catch bugs as well. I've had meetings with people where I've. I've gone to explain my code or walk through the project, and I thought, oh, wait, you know what? I'm not ready to explain this just yet. Just give me another hour to fix something, and I'll come back. You know, that's great. We're doing it now. We've got a little bit of a turnover within the team of people leaving, so we're handing over stuff, and my boss is having to pick up stuff as well, so it's great. The people who are handing it over, have you documented it? Right. Let me follow the doc. Oh, oh, this is completely different to your documentation. And they're like, yeah, maybe I should just patch that up a little bit and fix this and add a ticket into Jira and so on and so forth. So it's a very useful exercise to go through. Hey, you know, that's a nice segue into the pitfalls part. Not documenting, I found, has been a really a big gap in a lot of people's skills. As they come in, they just start coding, they just start writing, building. But there's almost zero documentation on what they're doing, on why, on any of that. And I think that's a common pitfall people fall into, you know, amongst not being able to communicate. So what other pitfalls do you have? You can think of. Yeah. And read the code. And code comments are not the answer to not documenting. What are the other pitfalls? I think that there's a couple of things, particularly when. When actually writing code, not writing tests. And look, if you could see me, I am holding my hands up. Julian will confirm this. I am the first to go, yeah, I should be writing tests, but never mind, I'll just bang this out. Writing tests makes your life a lot easier, even if it is your own personal projects, because you'll come back and you'll go, why did I do that? We're back to this. Looking at code a month later and going, what the. So writing tests is a good way of making your life easier forever. I think one of the other pitfalls is that self confidence, and not to the. I'm a ten x dev, I'm amazing. But we go through these cycles of actually not believing in ourselves, and that has affected me personally, where, you know, the imposter syndrome, and it's talked about quite a lot. I think maybe it's when you. When you're first in the industry, you don't see this because you know that you're not particularly good. But we go through this imposter syndrome, and what we need to realize is that normally we've got that good foundation, we are capable, we are doing the right things, but the reality is, it's based on the information we've got. And it might be a failure, but it's not a failure. It's just a learning experience that we can make another choice to move things forward and things like that. So it's. That's another important one for me. And that kind of then ties into this. I've got to get a specialist at a particular technology. No, because things are changing so quickly. You and I have been developing python since the 2.7 days. You know, I doubled way earlier than that. And Python has changed so much that we hit three and then. 3132 we're at three nine now is becoming like kubernetes. They're banging them out every three months. I'm lost. You know, I'm just about 3.4. Apparently. I can't use our anymore. I should be using 3.6. There's been so many changes that it's hard to keep up with these things. So what it boils down to then is, and this is another thing that people have come to us recently and talked a lot about, is the sheer mountain of tech that there is to learn, that you can learn and can get distracted by. And I think a lot of you. To tie this back to the topic of this episode, is that, you know, a lot of people feel to come into even grad roles, they should know mountainous stuff, you know. And to go back to what you were just saying, it's not even about that. It's about your willingness and ability to learn, your ability to seek out what you need to know to get the job done. That's one of the most crucial skills, I think. Yeah, we're back. It's the non technical skills that are actually more important. If you know how you learn, that means that you can quickly learn how to do something. Once you've got the foundation in of whatever you're doing, you'll be surprised how easy it is then to expand out and take on more additional roles. But if you don't do something, and I know a lot of people who would rather just keep going over the tutorial paralysis that you and Bob talk about all the time, just get out there, just do it. Because you're not going to improve if you're not doing it. And you will pick up more skills as you go along, because suddenly you'll come across a problem that you need to fix that you've never covered before. I love it, man. That's great. It's always insightful, inspirational having a chat with you. I really do appreciate it. Random as well. I'm sure we could have gone down ten tangents during this chat. What I will summarize with for everyone listening is that, you know, this comes back to a lot of the stuff that we talk about a lot, which is just that the technical skills can be learned. And I think, Reese, you put it perfectly where he said, you can learn tech, but it's your ability to deal with the situations, to deal with failure, to understand that it's all about growth, to understand how you learn and that, you know, being able to learn again, the skills that you need to get the job done, that's the key. That's, that's what we want. That's what people want when dealing with new employees, with dealing with grads, interns, trainees, new hires, senior devs, whatever it is, you know, the skills come with that. So if you get that foundation right, then you'll be fine. So, Reese, thank you so much. If I was to tell people where to find you, other than your house, and I'll post your address below, where could people find you? The pub down the road. Otherwise, normally the best place I look around, the pie bytes slack quite a lot. You might see things occasionally appear on GitHub. Other places is Twitter and things like that. But they generally tend to be about me djing on Twitch or drinking beer, so they're not quite as technically focused as the rest of my life. Hey, you know what? That's a really good point that I wanted to bring up. One of the best things to do to keep yourself sane in the technical world is to have some sort of a hobby that doesn't relate to coding or your day job or whatever it is you tend to work on all the time. So I love Reese that you have a twitch channel and you dj, so I'm going to put that in the link below. And I want everyone to check out his stuff because please, please do. I want a few more followers. Always welcome new people in the get him up to 10 million. It's one of the best things to listen to while I'm working away on stuff for pie bytes. So I absolutely love it. But yeah, Reese, thanks so much for your time, man, and it's a pleasure as always. And I think it's time for you and I to drop off the call and go grab a beer. What do you think? Thank you very much for inviting me on. It's an honor to be invited because I know the quality of previous guests way beyond me. I'm just this odd random welshman in the UK. But beer to beer. Let's go to the beer. All right, thanks, man. You took yourself down, but you're right up there with him. So cheers for your time. Thank you very much. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends, that is Pybit Evan, and receive a free gift just for being a friend of the show and to join our thriving slack community of python programmers, go to Pibytes community. That's Pibit es, forward slash community. We hope to see you there and catch you in the next episode.