Bridging the Gap - How Developers Can Thrive Amidst Differing Methodologies

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season talking this episode about the developer journey. We are sort of working through various things and maybe milestones that you're going to get along the way with your developer journey. Some of them you only see early, some you only see late, some you see recurring throughout your career. That may be what we have this time because we're going to talk about like butting heads. When are we, you know, when we get in situations when we are not really all on board, where we have like a way we want to go or a way that we're taught and others with us, you know, boss, maybe a customer, stuff like that, are going a different direction and dealing with that and making sure that we are doing what we need to do, that what we're paid to do as well. It's like, you know, to make sure that we're getting the job done, but also that we are, you know, if we need to raise flags up the warning, then we're raising those flags up. I will go ahead and introduce myself first. I'm Rob Broadhead. I'm one of the founders of developer.com. Developing better developers, this podcast, this YouTube channel if you're not, whichever one you're not watching, go ahead and try the other one just because. But on the other side, there are no red flags over there even though he does have a red background. Michael, can you introduce yourself? Hey, everyone. My name is Michael Milosz. I'm one of the co-founders of developer.ner and founder of Envision QA where we help small and mid-sized businesses with code assessments, software assessments and building custom software. So I want to start with this actually is like a nice recent story and it is one of the things that I think we see most often where we struggle. And that is early in our career because we usually have come out of either a certain school or boot camp or maybe there's one company that we worked with and there's a style, there is a culture, there's a way that they get things done. And there's also processes and procedures that we were taught that this is, you know, basically we're trying to, this is the correct way to do software, to build software to solve problems. It may be that they were, that that is the correct way, but it may also be, which most often it is, there are other ways as well. There is not just one way to solve this problem. There are many, many, many different ways. Once you get out into the, we'll call it the real world, you can bump into those pretty darn quickly. Now we will have things we're comfortable with. There are things that will mark us or be trademarks of us because of where we came from. If you think of like big schools and stuff like that where it's like, yeah, people are from this school or almost always like this, or they have this style or they go into this business. One thing that was personal recently that actually reminded me of a past thing was I play this thing called handball, similar short thing, similar racquetball minus a racquet. Hadn't played in a long, long time. And there's a guy that I knew, I've been like long like 20 years, guy that I knew and he didn't recognize me. I recognized him a little bit. He didn't recognize me until I started to play. And then he recognized the style. And it was funny that he mentioned it because I had always, I had a coach that worked with me a bit. And then the people that were in my early years that taught me a lot and I played with a lot all had that style. There is just an approach, a style, a way that all of us play. And so it is to me, I could always pick somebody out of a crowd of handball players that was doing that because I knew that I recognized that style. And then, actually, my one son did, played hockey. And there was one time I was watching him skate early on when he was younger and he skated very different from his brothers. And even though I had coached him and I'd coach them, I recognized another coach he'd had that was a very good coach, that was a very good skater, how his style, my son's style mimicked to some extent that coach's style. And it was because it's like you're taught even in these kinds of things, like football, there is different, you can, especially going to the college, there are, and actually even pros, there are head coach approaches to offense, to defense and stuff like that if you're talking about football. We have the same thing as developers. It does not mean, it's like in football, you can have a running game, you can have a passing game, you may be one of the others, and they can all work. That's the same thing we run into. The first thing I want to say is that Michael mentioned, like, if you go in somewhere and they say, this is the way we do it, that is the right way to do it. Regardless of what your background is, if there are developer standards and processes and procedures, that is how you need to do it. If there's a problem with it, if it's clunky or time consuming or you don't understand it or whatever, feel free, like, ask questions. But one, you may get an answer of, hey, that's how we do it. And you may just have to suck it up and just do it that way. More likely, I don't know, sometimes you'll get, this is why we do it. And Michael touched on this a little bit. It's like, sometimes you are a big enough organization now that, yeah, if you're just yourself doing development, you can do this stuff. You can have this approach all day long. But when you grow into a team of, let's say, 500 developers and you're building stuff that has got mission critical software for different people, it's going to be different. There's a big difference between you building a little app on your machine and you update it right away versus this is something that's got 4 million users and you just update it because you want to do a hot fix on production. There are levels of concern. I don't want to digress too much from the personal headbutting conflicts because sometimes we run into that where it's just like, it's not that clear. Where it's like, we've got this thing to do and we really don't like their approach. Michael and I, I think we worked for a guy that there's like, it seemed like regularly something would come up that almost he did it just to tick us off. He would just like, no, we need to do it this way and would not explain it or very rarely. So it was just sort of like, okay, I guess we got to do it this way. And then we would go grumble, but we would go do it or, you know, some extent. And that's really not the approach. Just don't do what we did. The better approach is to as much as possible, try to understand, come at it as, okay, this is the way you do it. I want to make sure I'm clear on how it is because really it's going to be better almost with the goal of you being able to defend that way of doing it. So that you understand it enough to say that, hey, they do it this way and this is why, because that's going to help you do it better, understand it and make sure that you are addressing the spirit of the law as well as the letter of the law for whatever that process is. But also because at some point you're going to grow, you're going to have other developers going to interact with and they're going to ask questions. And you may be able to, it may be viable to just say, hey, can you go talk to Michael? He knows he'll help you out with that. But it's more helpful, I think, for you and for them to be able to say, oh, this is what I was taught. This is why they do it. This is the reason why. And it's not like drinking the Kool-Aid or anything like that, especially not in this case because it is you saying, hey, you guys have a different approach. I see where it has value. And this, believe it or not, is how we become better developers. This is the same thing as somebody that only knows C Sharp. You got to use C Sharp for everything. It's like, no, there are actually other languages out there. You could use Java to do that or Python, or you could use, I don't know, Ruby, or you name it. It is us expanding our tool chest. So when you have these head-butting moments, I would recommend that instead of butting heads, embrace it as an opportunity to learn, to say, okay, how do you, where does this come from? You can even say, hey, I don't see the value in this. I see where I'm spending too much time on this thing or that thing. Help me understand. And say, where is your focus? Because their focus may be very different. They may not give a rip what your time is that you're spending on it because the result is more valuable than the time spent. Now again, I do a great job getting on my little soap box. So I'm going to get off my soap box for a second and throw this over to you, Michael, because I know you've got a lot of things turning in your head about this and it's very near and dear to your heart as well. Yeah. So I run into butting heads just by every company I work at because like you, we tend to like looking for multiple solutions to a problem. Like you said, you could do something in C Sharp all the time, but that's not necessarily the only tool out there. You can do Java. You can do Python. We always look for the best tools. Now within organizations though, they've already done that. Or if you're working for a more mature company, they've already gone through the trenches. They've gone through the lessons learned, figuring out how to get to where they are, this more established app product, and you're coming into their shop. So you're coming into a shop that's more established. They kind of have some ground rules and they have some coding styles or hopefully they have some coding styles. And so when you come in, if you're unfamiliar with the environment, hopefully they have gone through the process of putting together some software development styles, some coding styles, best practices, and hopefully they have documentation. Now saying that, I know that in almost every organization I go into, I'm the one that writes that documentation because it doesn't exist. So as I go through, I have to learn how this company does what they do so that one, I'm doing my job right. Two, I'm not breaking or not following any of the processes that are in place. A lot of times when you come in, you're not going to know. You're going to butt heads with just about everyone. All I can say is for the first six months at a minimum, always ask, all right, here's the problem as I understand it. This is how I'm going to solve it with X. This doesn't quite fit within what you have. So could someone on the team please walk me through how I can put this square peg into this round hole within your policies and procedures? Now sometimes you can't do that and that's fine. What you then do is you may have a better solution. So you present that to the team, either through like a collab or like stand up and walk through your approach to doing it if it doesn't exist already in the organization because you will run into that. You'll run into situations where you're not just butting heads, you're butting heads with the software, you're butting heads with the framework, not necessarily people, but the actual code itself. Now on the flip side of that, I run into this constantly and I'm not trying to name names, but there are situations where not just as a developer where we come in with our own, I don't want to say baggage, but our own style like Rob said, and we have a particular way of doing things. So for instance, I like Java, I like Maven structures, I like doing controllers for back end APIs, but I like taking an additional layer and actually breaking out the controllers on the endpoint hierarchy. So like if you have object A, B, C, so like kind of if you have a path, you have multiple objects, if you define the packages that way, you can go look at your swagger or your API document and your code mimics it. So it's like quick jump in, figure out where things are. Some organizations don't like that. You have to strictly follow, oh, it must follow this Maven archetype. You must do this. It has to be this. Fine, do that. But if you don't understand it or you have problems with it, talk to your team, talk to people, ask questions, ask for help. Now as I say that, there are situations where you have a job to do, you have timelines, we have sprints, we've got deadlines. You have to get your code done in a timely manner. Now you have to keep in mind, am I doing the minimal amount of work to get the problem done or am I reinventing the wheel to get this problem out the door? Am I writing two lines of code or am I writing a book because I have this cool, fancy framework or this cool way or this plugin to do something that has all this? I throw it in there and why? If I could do it in two lines of code, why did I just write this book? You're going to have to justify that and that's going to cause friction. Or if you're in the Java world, C Sharp world, and you're keeping up with the latest innovations and the latest versions, you could run across something that's new within the framework, which is a part of the actual language that you use that isn't necessarily new. It's not necessarily a new item or new style. It's within the tool set you have. The problem is the rest of your team doesn't know about. So if you start throwing that in, start using it and don't explain it to anyone, you're going to run into situations where you now have one person on the team that knows how to do this code and no one else can support it. You're going to have a lot of friction there because the next person that comes behind it, they're going to be like, what the heck is this? How did they do that? Now they have to spend more time. So basically you've now scoped development time with research time on something, two lines of code versus this cool approach that now may be one line of code, but no one has any understanding of what it's doing. So either you need to reset the software design, software style sheet, or have training sessions. So these are things you have to be careful of. Otherwise you will be bunny heads. You'll be saying the F word quite a bit or putting people on mute, walking away, turning your screen off and just say, I need a minute because there's going to be a lot of times where this happens. I would say at least once a day I run into a situation where I run into a line of code trying to, why did they do that? Or why is this missing? On the flip side of that, make sure you do follow those style sheets because if you don't, you could be leaving things out. You could be following a different paradigm than the project follows. And now you may have like a domain object structure. You've now completely excluded that. So now it becomes a harder task to maintain that project. So now you come in and it works, but it is not structured in a way that anyone can maintain. It has to be refactor. I think that's the thing is that sometimes, actually a lot of times, I think it comes down to, there's not necessarily a right answer. It's just pick one, pick an answer and take that path. Development standards, there's a lot of stuff, right? Like naming standards, there's just gargantuan amounts of documentation on all these various like naming standards and ways you can do it and why you need to do it. And depending on what your background is and every language that seems like has its own little standard and stuff like that. But it's the end of the day, if you're using one that makes sense, that is consistent, and works with that environment, do it. There should not be a case where you are part of a group and that you guys or guys and gals are building something and it looks like it was built by a whole bunch of different people. That and it's, Michael sort of alluded to this, that adds maintenance cost moving forward. You may not think about it, may not hit you, but somewhere down the line, six months from now, you guys have all moved on to different projects and somebody else looks at it. And every time they look at a different method or a different class or a different, it's like it's all over the place. You can't find stuff, you can't assume anything. And sometimes it is, it's like there's this big complicated thing that's done. And it's like, why didn't you use that over there? Now it could be because that didn't exist when you built that big long thing. But that's where reviews and stuff like that should come in as you're advancing, as you are growing your software. It should be stuff like, hey, we have this new approach. And you like say, Michael, Michael just sort of laid out, there's this new thing and we can use this. And this is a great new way to leverage the language to solve this problem. One of the things you're probably going to need to do is go back to everywhere else. You use the old way and convert it to the new way. So it's like you are adding technical debt and there should be some sort of refactoring to say, hey, there is a reason for us to upgrade this and we should do it across the board. If not, then we're going to end up with something. And I see this so many times. It's so frustrating that you can see like what version the code was written on and you can see who wrote it and where they were at at the time. But it's not until after you really understand all the code, you're like, well, this, this thing was done at this point, but this thing right next to it was done six years later and it's done in a completely different style. And you get into this and then you end up with like bloated code and back on my soap box. So don't, don't do it. Like stick to the standards. If you don't have it, make a standard, particularly when you come in. One thing I want to make very clear because this is, I think what we run into because we are all problem solvers. We're all smart at varying levels. And so we all have a little bit of ego and a little bit of pride and all this kind of crap. When we come into a new organization, if you're a brand new, they don't owe you squat explanation. You can ask for it, but they may not give it to you because they may not even know it may be essentially literally above your pay grade. So just be patient, use it as just like sponge, osmosis, soak it up, work with it, try to understand it so that it's really like you want to comply. If you've been doing this for a long time and you come into an organization, same thing. They really don't owe you squat. No, they, if they're going to use you, then you need to understand. And it's not that they owe you. Why is it different from the way you would do it? It is you owe them to understand how they got there. And it may be that they don't know, but as best as possible, you want to try to understand why it was done this way. And if it's like, nobody knows and you can say nobody knows, but you should as much as possible have a good idea of like, this is what we do and this is why we do it. And since you are a senior in this case, there may be things where you say, hey, you do it this way. I've seen it done differently. Maybe we can look at converting it over. Maybe not because sometimes the cost of converting to that better solution is more than it's worth to, you know, more than whatever you're going to get out of that new solution. So try, and this is, I know it's very hard for people to do it, like try to actually work with what exists when you walk into a new environment, project, ecosystem, instead of ripping it all apart, like we've got to do it this way because this is the right way, especially if you're one of those like big six firms that comes in, it's like, we're going to spend billions of dollars. So we're going to rip all your crap out and make it look like we want it to look, give everybody a break and say, Hey, maybe they got something right here and try to work with what they had and carry forward with that instead of trying to enforce your experience in your background. You will be better for it because if you go into this and you learn where you will, if you do this right, you will learn where your stuff, your background, your skills, your approach can actually be improved if not all the time, but at least in certain situation. Close your thoughts. Yeah, I've got a couple and one I will save as a teaser for the after podcast for the video because it's more of a lengthy discussion. As we, as you go through this, you know, like Rob said, you know, they hired you for a reason. They hired you for your skills. You have a certain skill set to avoid a lot of the headbutting. One of the best things I hear this constantly is don't lose, lose the force through the leaves. Make sure that you understand the problem that you're working on. You understand the test that needs to be done and you work within the structure that you are provided, the frameworks, the code styles, whatever, and that you get the job done in the simplest way possible. Don't overcomplicate it. Don't over architect it. And nine out of 10 times you're not going to headbutt, you're going to get the job done faster and your life's going to be a lot easier. Very well said. And so rather than complicate things, we're going to wrap this one up. You can always do very uncomplicated emails and communications to us via developer.com. We have a contact form. You can shoot us something at info at developer.com. You can put comments in the, if you subscribe, you can get it wherever you do your podcasts. You can do it on the YouTube channel, which Michael alluded to. There may be bonus material coming on. Maybe not. Probably will be because we just teased it a minute ago or less. And we will be back next time around. We're going to continue the podcast season. We've got plenty of things to discuss on the developer journey. So I guess you can leave that seat for right now, but make sure you come back to wherever you are. So you catch us for the next episode, cause you really don't want to miss one. You never know what kind of cool stuff you would miss out on. And then your life will be a little less, maybe not that bad, but close enough. That being said, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers to develop a newer 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.