The Bright Side of Entry-Level Workers

This is Building Better Developers, the Develop-a-newer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We're continuing our season where we're looking at the bright side of things. We're looking at the things that sometimes bother us and flipping them on their head and trying to find some benefits, trying to find an upside. This episode, we're going to look at entry-level workers. Now, you may be sitting there and say, wait a minute, I'm an entry-level worker. There is nothing but positives that come from me. I am nothing but beneficial to the entire human race. And that may be so, but there are frustrations in dealing with new people. And this is not, for the purposes of this discussion, this is not just about new to work, new to industry, somebody fresh out of college. This is also sometimes, and we'll cover some issues, where it's somebody new to the company. They may have some level of experience, but they're essentially new to their role or their responsibilities. So, a newbie of some sort. Now, the negatives are you've got to teach them. They tend to be a little slower to get things done. At least initially, they're not going to be as productive probably as their peers because they just don't have the experience. They don't have the knowledge. But I think there's some positives we can take from this, and it's worthwhile to do So again, not only because this is a season that's focusing on the positives. The first positive with dealing with the junior level or people new to a role is that they have not gotten the mindset yet of what that role or set of responsibilities is. And that is actually, I think, more valuable than people give credit for. The whole idea of thinking outside of the box is considered a positive. It's something that we chase after at times, especially when we're looking for maybe an ingenious solution or maybe some sort of market pivot or something like that. There's definitely a call for people to think outside of the box and not just in Taco Bell commercials. And so this is, I think I said, I think this is something that is actually highly underrated because when somebody comes into a situation and one, they don't know what they don't know and two, they typically ask questions about everything. There's not things that are going to, it's almost like dealing with a child. They're not going to be told something and they're just going to say, oh, okay. In most cases, they're going to say, why is that or what does that mean? They're going to ask for more than the short or the flippant answer. They're going to dig a little deeper because they want to understand. They want to learn the why and the how and maybe the what and the where and the when as well for the various topics and items that they need to know as part of their new, their responsibilities or their role. Now, combined with this is that we, as we advance, we sort of, we essentially build our own mental frameworks as well as actual frameworks and software and things like that. And we also have processes and procedures and things that are what we do. It's just how we get the job done. And it's not uncommon, nor does it take very long to get to a point where it's almost like a knee-jerk reaction. You have this problem, so you go through the process. You've done it dozens or hundreds or thousands of times before and you just plug it into the process, take the solution and you move on. You don't really, you don't really examine it and you definitely don't question it because you didn't question it a thousand times before. Or if you did, somewhere along the way you stopped asking questions because you just said, oh, well, this just works. And while that may be true and that may be a shortcut to help somebody new to get the job done, especially after time, there may be a better solution. Or honestly, there may have been a better solution on along. Maybe you just didn't think about it or whoever created that process. It's a blind spot maybe. And this is where new people come in because they will, while they will have a background experience that we can relate to if we've gone through the same process, if they've come fresh out of college with a computer science degree, we went through college and got a computer science degree. There's definitely going to be some similarities to what was taught, some of the basic topics and focus. But over time things change, especially in the technology world. So what we were taught may not be, may not have ever crossed the mind of this new person and vice versa. They may be taught, may have been taught things that we had no, that didn't even exist when we went through school. Like I said, almost vice versa, there may be things that we did that we use that really don't exist or not in a practical sense anymore. So those tools that are available, those procedures and processes that are part of that teaching experience have changed and evolved over the years. That means that there may be, there's mental paths that maybe we would have strolled down that they won't. They may stroll down completely different paths. And for a sort of, I guess, maybe obvious kind of an example would be think about application development. If you go back, I don't know, 15, 20 years and then longer than that, if that was when you got your degree, basically everything was command line or a desktop application. If somebody's gotten their degree in the last four or five years, probably nearly everything did, they probably did some command line, but most of what they did were web applications. There's a very different mindset. If you, and you know this, if you've built a desktop application and you've built a typical web application, not some fat client thing, but a true web application, then there's a very different concerns, very different mindset. There's very different approach across the board. Things like how you look at the interface and events and messaging and security and users and all that kind of stuff. It's a very different world. And so from that very different world, you're going to get very different suggestions, recommendations and approaches to problems. If you throw the same problem at people that only know desktop applications and people that only know web applications, you may get a very valid solution from both teams, but it will be very different, almost guaranteed. And even if you probably, I would say, even if you do something like demand, the solution has to be a command line. So if one only knows desktop and command line, the other one only knows web and command line, I bet you're going to get a rather different set of solutions. There's just certain things or certain tools that are more comfortable to one group than another. And this would just be from a physical tool sense. You would run into the same thing. There may be some people that are builders, contractors, that do more cutting. And so they're more comfortable with saws and things like that. And maybe there's somebody else that does more construction, putting stuff together. So they're more comfortable with screwdrivers and screws and nails and hammers. Your focus makes you, doesn't necessarily limit what you have, the arrows you have in your quiver, but it seems like we tend to go to certain arrows over others a lot. And when you have somebody new that comes in, they, one, they've got a smaller tool set and two, they may have a different tool set. So some of this is just the general different experiences. But the thing about people that are new is they're more likely to ask questions and throw out some ideas, just generally saying, well, hey, have you tried this? Have you thought about that? Then somebody that's been around for a while, somebody that's been around for a while, that's a little more experienced, they may know that people try that all the time or the people have tried that once or twice. They may have certain options and questions that they just forgo because their experience has taught them it's not worth asking that question. But maybe it is. Maybe things have changed. So suddenly that question that wasn't really smart to ask six months ago leads us to a whole new valuable solution currently. In a similar vein, but a different positive, new people bring in new tools. They bring in new information. They can help expose us to things that otherwise we may not have been exposed to. You think about web application. If you're a web developer and you've been doing it for quite a while and you've got somebody that comes in new, they may work with, say, well, probably wouldn't work with some JavaScript libraries that you haven't messed with yet or have some tools that they used in school that didn't exist when you went through. Maybe you haven't had time to go out and look at stuff. So now you've got these people bring something new. They also really force us, and this is moving, diving right into another positive, they really force us to assess, I guess, our information, our knowledge, because you're back into teaching mode to some extent. Like I said, there's things that we take for granted that we just do. There's these processes or procedures or tools or whatever that we've gotten used to and we just, they just work. We just use them. They just are. When you bring somebody new in, you have to actually assess that and find some way to break it down, maybe document it, explain it in some way so that the new person can understand enough to utilize it and to do it in an annoying way as opposed to just, maybe you have this, but probably not where they're just pressing some buttons or entering a couple of stock commands, more than likely they need to have an understanding of the tools, the environment enough for them to be productive, to get the job done, to write new code, to do enhancements, to maintain stuff. So these new people give us a lot of a fresh breath into our team. Another thing that they give us is actually, and this goes back a little bit to the whole grunt work thing, but they give us people that we can push simpler stuff off onto. We can push these things, these tasks onto them that are not, I don't want to say necessarily as challenging, but not as mentally challenging, not the kinds of issues that you can do without having a lot of experience. So the experienced people can more easily be focused on the things that do require that experience. It's a difference, maybe as simple in some cases as designers and developers and architects that really need to work on that architecture and design piece versus coders, people that just need to follow a spec and write some code. You've got to have those lower end entry level people sometimes to make a budget because they're not going to demand the same price, the same salary as somebody more advanced. Sometimes you need the right tool for the right job. Not that I want to call these people that are new a tool, but the right resource for the right job. So you bring these people in, you have these resources that maybe they have limited skill sets, but they're skill sets that you really don't want your senior people using anyways. So it's a win-win. You get new resources to come in, they get to learn stuff, they don't cost you as much, and they take a load off of the senior resources that you want the senior resources to avoid doing. If you don't have a mix of senior and junior people, then you may end up in a situation where you have these very senior people doing very menial junior level tasks. That's essentially not going to be a good use of resources. It can even become frustrating to the seniors because they may say, hey, this is not something I enjoy doing anymore. I did this years ago. I don't want to do this anymore. I want to use my skills. I want to stretch my wings and I'm stuck doing all of this grunt work that I think I'm past or something like that. I know I've mentioned grunt work a couple of times, so I guess you can always pause and go jump on that episode if you haven't listened to it yet to see where some thoughts about that. So new people, they provide us a fresh breath. They give us a steady stream potentially of labor for doing the lower end, the low hanging fruit, the easier work that they can, which of course then frees up higher end resources to do the work that we need them to do. It gives them some free time. Somewhat, sometimes there is a cost because you need your experienced resources to train your entry level resources, but usually there comes a point where you can actually cut them loose and you don't have to do that training and then you get that time back for your senior resources. So the next time you have somebody new to the team, and maybe it's a little bit of a burden because you've got to hold their hand and drag them along a little bit or train them up. I understand the inclination to maybe gripe about a little bit even to yourself or under your breath, sort of, gosh, I've got better things to do. But this may be an investment that you are very happy you made down the road. And I think more often than not, you will find that's the case. It has been rare that I've had a situation where I've worked with somebody that's new onto the job or into the career and it hasn't been rewarding and even in the long run, productive to bring them on and make them a part of the team and allow them to eventually carry their own weight. Challenge of the week. When was the last time you were the new guy or the new gal? Did somebody take you under their wing or under their wing? Did they train you up, mentor you or lead you down the merry road of becoming an experienced employee at that place? And one, did you ever thank them for that, for the time that they did? If not, you may want to do that. Two, you may want to, I guess, repay the favor, give back, as they like to say. And next time somebody new comes in, don't be afraid to be the one that sort of helps that person up and gets them ramped up and gets them ready for their career, their job, that company or wherever they're at. And this is one of those systems that it feeds itself. And so if we go out there and we are happy to be trained and happy to train others, then you may find that the whole developer environment grows and not only do we individually become better developers, as a whole, we become better developers, not just one at a time, but a community at a time. And that being said, maybe that's a little too heavy, but hey, we'll try to walk out of here light. And as always, go out there and have yourself a great day, a great week. We'll talk to you next time. We'll talk to you next time.