Need to prove oneself

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we are looking at mistakes and missteps and errors. In this episode, it's not going to be one in specific error that I'm going to look at. It's something that is more a general attitude. And it's one that I've seen a lot over the years. It's sort of a rookie mistake, but not really because it happens a lot when you are a rookie, even in a, you know, you're a new person in a place, even when you've had experience for a while. And this centers around needing to prove yourself. I think it's probably the best way to look at it. Now, when you're starting out, you just get out of college or get into your first job, however it is that you happen to do that. There is a definitely desire to prove yourself, to show that whoever it is that hired you made the right decision. And I think that's pretty much across the board. Certain people that don't have a really strong work ethic, I have seen them when they start into a new environment or a new job that they're sort of pumped up about it. I think it's hard not to be. It's new. There's lots of stuff coming at you. And it's exciting. You know, there's new opportunities. If it's a first job, you've got your life and your career ahead of you. If it's your 50th job, then it's a change from what you've dealt with in the past, maybe. And when we get in those situations, I think it is useful to remember that we are new to the environment, that we have not been there for a year or five or 20 years or however long some of the people have been there. And so even things that they take for granted, we aren't going to know. And we don't need to. I mean, they really don't expect us to know it because it wouldn't make sense for us to know maybe the ins and outs of their company and how they do things. But I know we tend to want to jump up and prove ourself and say, hey, I'll take that on or I can do this or I can do that. And we don't need to. We don't have to have the answer to all the questions. We don't have to know everything right away. It is OK to say, I'm going to have to look into that. I'm going to have to get back to you on that. That's something that I don't know exactly what the answer is. So I'm not going to guess and maybe get you a wrong answer. Instead, I'm going to go back and get you the right answer. And what brought this up is early in my career, looking for projects that were a little different. That was something that would be highly visible and ending up in a lot of companies that were startups where by your nature, everything is highly visible. And there were a lot of times that I was more than happy to share my opinion about whatever it was we were discussing and throw information into a discussion. But it was not. I don't know that was always needed. And I don't know that I got burned by it as much as there were, I guess we'll say mea culpas or I'm sorry or apologies or that at times because I would go into something and it would look a certain way. This actually goes back to our perspective type of thing. I would think it worked a certain way or things flowed a certain way or the solution resolved itself in a certain way until I got deeper into it and realized that there's some intricacies or some details that I didn't understand that I didn't know yet. I was ignorant of those. And so I had to learn them so that I could provide a proper solution. Now if you want to see this happen a lot, it is with what usually it's in consulting things, but also when you have a turnover, you have a couple of people leave a company and the intellectual knowledge, the intellectual property sort of goes out the door with them. There are things that they learned on the job. There are experiences that they had. There are things that they built deliverables that they delivered that they know because they did it. They've been through it. When somebody new comes in, they may not know all of that and probably 99.9% of the time are not going to know all of that because they weren't involved in all the decisions. And if the documentation isn't there for why the decisions were made and what decisions were made, then you sort of have to start all over in a sense. You're going to have to look at stuff and say, oh wow, they did A, B, and C. I have no idea why they're doing that. And then the urge for most people, particularly when you're newer, I think, is to come in and say, ah, they just didn't really understand what they were doing. And so you end up ripping it all out only to find out later that, oh shoot, that actually was required for some reason. There's some special case, some outlier. There's something that required it to be done that way. And they didn't just make that up. That was something they had to do. So now we're going to have to go back and fix what we pulled out. And you can see this sometimes as an ongoing issue at companies where people come in, they change a bunch of stuff, they get almost there, and then they leave. And the next people come in and they basically change some stuff, get almost there, and leave and rinse and repeat. And it's because each time somebody comes in, they make that mistake of, it's not really I hate to say that they're assuming that the people before them didn't know what they were doing, but it more or less falls into that kind of category. And sometimes that assumption is probably pretty valid because maybe people got fired or kicked out or for whatever reason you can. It was obvious that they didn't know what they were doing and that's why they failed. But I don't know that that's even the majority. I think most of the time people move on because they move on. They were doing the best that they could with the knowledge that they had. So if you look at something and it doesn't seem right, then you don't step in and immediately say, well, you've got to do it this other way. And this was myself. And I think a lot of people that have come out of, particularly you come out of college, you've been in the academic world for four plus years and you read all the books on this is how it's supposed to work. This is what's supposed to do. This is how these things are. And then you get in the real world and that's not how they are. But we grouse against the reality because we say, no, this is the way it should be done. Academically, in a clean room, this is how this thing should have been done and documented and tested and all of that goodness. Whereas once you get out in the real world, you don't necessarily have the time, the skills, the people, the well-defined problems to be able to do that. So instead you make do with what you have. And that's where we make our mistakes. I think even when we get further into our career, there are many times that I can recount walking into a situation where somebody was, we'll call them an expert in the field, somebody that had solid experience. They come into a company and they say, well, in this line of business, this is what needs to be done. This is how it gets done. So you guys aren't doing it this way. You need to change to do it this way. Not considering that maybe there's a reason that that company did it. Now it could be that they're just doing it because that's the way they always did it. But it also could be hundreds of reasons that are very valid why they do it. It may be because they have slightly different customer base or expectations from their customers. It could be that they have to go with the second place approach because they spent more time on that, invested in it early on. And it would just honestly, it would be too costly to switch to the best in quotes solution. And they wouldn't get their money out of it anyway. So they're not going to get the return on investment. And that's something I think we overlook, particularly the techies amongst us, is what is the real value that we're bringing sometimes with some of these changes? If you're making a change and it's going to save a tenth of a second a week on some process, if it takes you any time at all to make that change, then it's probably that change cost more than just leaving it where it was. Not to mention that whenever you touch something technology wise, whenever you start messing with code, you effectively could break everything, which means you're going to have to do some testing and depending on what they've got set up, it could be very time wise costly to change stuff. If you're on a train and you're going down the track, and that track ideally would be five feet over from where it was, you're not going to go do a big lift the track up, move it over, rebuild the track five feet over. They're just going to say, okay, well, that would have been nice, but we don't have it. So we're not going to worry about it because the cost of making that change is too much, is more than the value, the solution that that change brings. And so I think the mistake that we make a lot boils down to wanting to prove ourselves. We step into a new environment, we want to leave our mark. We want to say, hey, I've got skills or knowledge or wisdom or experience and it's different from what you have, whoever your new environment is. And there is some level of that where you're bringing something new and you want to find a way to take that difference and make a difference. So people say, wow, this was great. We hired you and a week later, we more than earned your salary or whatever it is. Something along those lines where people say, hey, you're a great addition to the team. What you will find is that you're probably going to have most environments, unless it's just a negative environment, you're probably going to have people tell you that you're a good addition to the team. Even if you don't make earth shattering changes, if you just come in and help them do what needs to be done, you're going to be a contributor to the team and they are going to appreciate that. You don't have to make big earth shattering improvements and definitely not right away. So this is one of those situations where patience is very, very useful. It actually goes back to there's an old saw that it's better to keep your mouth shut and have people wonder if you're a fool than to open your mouth and remove all doubt. And that's a little bit harsh for this situation, but you have to go into a new company, a new situation and own the fact that you have, there is ignorance that you have about that situation. You may have some great skills and knowledge, but there's also going to be gaps. There's also going to be blind spots. And so the smarter approach is to sit back and absorb as much as you can and ask questions. We talked about this in an interview process. Don't be afraid to ask questions. And as you ask questions and as you learn and you build on that and you start asking, maybe initially you're asking simple questions or easy questions because it's stuff that everybody there knows if they've been there for six months or a year, but you don't. But now you're ahead of the curve because you asked that question early. And then you can take those answers and you can use those as a foundation to build knowledge and start asking more difficult questions and more useful questions as far as the answers are concerned and start making a difference. You don't have to do it right away. You don't have to go zero to 60 in two seconds, especially if you top out at 60. If instead you can go to zero to 100 in five minutes effectively, then you can get somewhere faster. And I know that's not the best analogy, but the point here is don't think, and this is, I feel like this is so much a something that needs to be said when we walk into a new situation, whether we're new in our career or whether we're in a new job, is to not assume that you need, you know, that people assume you need that, that you know everything or that you will know everything. They're probably going to assume it'll take a little bit. That can be a little bit hurtful to us to have people look at you at work and be thinking, ah, this person's not quite carrying their weight yet, but it's not wrong. It's one of those that, yes, I mean, you can make a contribution, but if you're making the best contributions in your first month and you're not making better contributions six months or a year into it, then you actually probably weren't a good hire. If you came in and you blew it all out in the first month and that was all of your good ideas, then there's no reason for them to have you as an employee. They should have just brought you in as a contractor or a consultant and had you share your ideas and then move right on. Heck, they maybe would have paid you more for that month that you were there, but then they'd take them and go on. You should not expect that you're going to hit the ground at 100%. It's going to take time. I think the flip side of this is don't get frustrated when it does. Sometimes it takes a bit for that momentum and for that building of knowledge, of strengthening that foundation to get to a point where you can make meaningful impact and input into discussions. Sometimes it takes a while. If you find yourself sitting there after a few weeks and you're just like, gosh, I just don't feel like I really have grasped this stuff yet, that's okay. Sometimes it takes a long time to really get your head around the company, the business, the processes, the interactions, the politics, and all the things that can go on in a company, even smaller ones, much less huge ones. It's just the nature of the beast. I think if you spend some time talking and really more listening to people that have been there for a while, you'll see where some of those gaps are. You may be surprised. You'll find people in some companies that have ... They're in a company and there's other people in that company that have been there for 20 years and they still really don't know who each other are because it's just that big. Their paths don't run across that often. Maybe they show up on their names on an email so they go, oh yeah, good old Bob Jones. I see his name on emails all the time but I really don't know what he does. I wouldn't know him if he came up and punched me in the face. There are always going to be gaps. There's always going to be lacks of knowledge and ignorance and blind spots even in our career, even in our positions, and so much more so when we get started. You should expect that what you do in the first week, in the first month is nowhere near what you do in the sixth month at the end of the first year. That is the nature of growth and that is why in a lot of places you start with a lower salary and you get a bigger salary as you go on or you have maybe a low salary or a trial period and then at some point they say, yep, now you've gotten to a point where you know enough. Some places they have a very formal process for it. You go through training, you go through all sort of like almost an apprenticeship type period where they are bringing you up to speed on all this and that may actually service everybody better because then it has you in a situation where it is very clear to you that you're not expected to make a big impact right away. If you do walk into situations, which sometimes happen, where somebody says, you know, we're hoping you're going to make a big impact right away and say, I hope I do too, but don't feel like it's something that you have to. I mean, you may be in a situation where they say, if you don't make a big impact in three weeks then you're gone. So be it. I hope that you know enough going into it, but I don't think that's going to happen very often and particularly when you're newer into a career. You just, there's just a lot for you to learn. And so don't expect that you need to be, you know, the diamond in the rough that first week or that first month. It takes a while. And so those are mistakes I made that didn't really hurt much other than I think those are kinds of mistakes. If I look back that they probably, they slowed me down because I went down a path assuming that I knew what I needed to know and I didn't know what I didn't know. And I didn't ask enough questions. And part of it was, you know, it's that desire to not, you know, in quotes, be a burden to somebody. I didn't want to feel like I was bugging them with questions, but I think we all would have done better had I bugged them more often, asked them more questions and then more quickly been able to get up to speed and avoid some of the missteps that happened because I just, I didn't know better. And I have seen that in enough other people that I think, who knows, you probably can point to some situations for yourself where you said, ah, you know, I think I've made that mistake as well. That being said, I'm not going to make the mistake of going too long. So I'll let you get back to it and hopefully you have a mistake free day. And if not, I hope there were the kind that you can learn from. That being said, go out there and have yourself a great day, a great week, and we will talk to you next. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Hi, this is Rob from Building Better Developers, the Develop-a-Noor Podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we We will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.