Detailed Notes
Welcome back to our podcast series, where this season, we are talking about the developer journey, focusing on Bridging the Gap: How Developers Can Thrive Amidst Differing Methodologies and growing together within development teams. Various milestones mark the path of a developer; some are encountered early, some later, and some recurring. One common challenge is dealing with situations where team members, bosses, or clients may have different directions or methods than what you’re accustomed to. How do you ensure you get the job done while raising necessary concerns? Let’s explore this dynamic.
Read more: https://develpreneur.com/bridging-the-gap-how-developers-can-thrive-amidst-differing-methodologies
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources
* Learn From CoWorkers : Interview with Douglas Squirrel (https://develpreneur.com/learn-from-coworkers-interview-with-douglas-squirrel/)
* Rock Bottom Can Be a Starting Line (https://develpreneur.com/rock-bottom-can-be-a-starting-line/)
* Invest In Your Team – They Will Want To Stay (https://develpreneur.com/invest-in-your-team-they-will-want-to-stay/)
Transcript Text
[Music] welcome back we are talking about our latest episode this is going to be episode four right I think we're doing episode four for the podcast for Season 22 um still a little crazy in my mind that like this has been going on that long uh this episode I think we want to talk about well this is where and I'll bring it up in the podcast as well we got a request from Timothy in ashkash Wisconsin and he said hey why can't you guys talk a little bit about the situations that we all run into where I'm going to try to do it in a nicer language a little bit but it's like where we have disagreements with people uh that are maybe our boss maybe a customer uh maybe it's co-workers and particularly if it's uh like a design or foundational issue or something like that is like how do we work with that and how do we particularly if we are really convinced that they're taking the wrong direction what do we what do we do and how do we handle it so I think that would be a fun little fun I thinking other FWS too but a fun little word thing that we topic we can do for this episode uh I think you're on board with you have anything you wanted to add to it or does that sound like a good good way to go yeah so the way you kind of described that I kind of like that and especially thinking of the developer Journey for those of you coming out of like boot camps out of college out of self-taught you have been or learning a certain way of doing things a certain way for a while now now when you get into a career or get into a more professional environment especially with larger uh coding shops with lots of developers you're going to run into a lot of times where you butt heads or an organization does things one way that you have never seen before so now you've got to jump in and figure out how to do that even if it's not necessarily the right way it is the way that basically you're being told to do it and just before we jump in it it reminds me of that book liftoff where Elon Musk went through launching SpaceX they were quick to get things done like quick to innovate you know that startup mentality but then once the company was established they started having to implement all these policies and procedures for safety and that and basically they became NASA so you went from this very fast-paced growing learning developing to oh I now meet organizations it's now time to grow up and now I get kind of put into this box uh yeah there's there's a lot of good stuff in there too and about in sometimes about the why so 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 uh maybe you know Milestones that you're going to get along the way with your developer Journey some of them uh you 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 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 customer stuff like that are going a different direction and and dealing with that and making sure that we are you know 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 develop or.com develop or building better developers this podcast uh 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 MOS I'm one of the co-founders of developer ner and founder of Envision QA where we help small and midsize businesses with code assessments software assessments and building custom software so I want to start with is this actually is like a nice a recent story and it 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 uh either a certain school or Boot Camp or maybe there's one company we worked with and there's a style there is a 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 taught 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's not just one way to solve this problems there's 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 you know Mark us or or be trademarks of us because of where we came from if you think of like uh big schools and stuff like that where it's like yeah people are from this school are almost always like this or they have this style or they go into this business something that was personal recently that actually remind me of of a pass thing was I play this thing called handball similar short thing similar to racket ball minus a racket I hadn't played in a long long time and there's a guy that I knew 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 because I had always I was 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 a style a way that all of us play and so it is to me I I could always pick somebody out of a crowd of handball players that was doing that because I knew that I recognized that style similarly 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 coached 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 coaches style and it was because it's like you're taught even in these kind of things like football there is different you can especially if you go into the college there are and actually even Pros there are head coach you know approaches to offense to defense and stuff like that if you're if you're talking about football we have the same thing as developers it does not mean it's like in football you could have a running game you could 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 Developers 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 timec 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 oh not more like sometimes you'll get this is why we do it and Michael touched on this a little bit is like sometimes you are a big enough organization now that yeah you 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 a team of let's say 500 developers and you're building stuff that is 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 you know there's like there are levels of concern I don't want to digress Too Much from the the personal like 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 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 be 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 a able to may be viable to just say hey can you go go talk to Michael he knows he'll 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 it is 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 developed ERS this is the same thing as like somebody that only knows C and like you got to use C 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 headbutting 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 and you can you can even say hey I'm not 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 it's say you know where 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 all my little soap box so I'm going to like 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 are it's very near and dear to your heart as well yeah so I run into budding heads just about every company I work at because like you we tend to like looking for multiple solutions to a problem you know like you said you know you could WR do something in C SHP all the time but that's not necessarily the only tool out there you can do Java you can do python so we always look for the best tools now within organizations though they've already done that or if you're if you're working for a more mature company they've already gone through the trenches they've gone through the lessons learn 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 cells 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 bite 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 pro here's the problem as I understand it this is how I'm going to solve it with X now 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 to like a collab or like standup 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 buding heads you're buding heads with the software your buy 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 uh 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 backend apis but I like taking an additional layer and actually breaking out the controllers on the endpoint uh hierarchy so like if you have object a b c so like kind of if you have a path and you 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 AR Ty 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 looks 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 or if you're in the Java World C 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 you know language that you use that isn't necessarily new like uh 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 and then you're going to have a lot of friction there because the next person that comes behind it they're gonna be like what the heck is this you know how did they do that and now they have to spend more time so basically you've now scoped creete 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 stylesheet or have training sessions so these are things you have to be careful of otherwise you will be bunny ass you will be saying that yeah for quite a bit or you know putting people on mute walking away turning your screen off and just say I need a minut because there's going to be a lot of times where this happens you know 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 stylesheets 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 it's it works but it is not structured in a way that anyone can maintain it has to be refactored 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 like development standards there's a lot of stuff right like you know naming standards there's just gargantuan amounts of documentation out all these various like naming standards and ways you can do it and why you need to do it and depending on what your your background is and every Lang it seems like has its own little you know standard and stuff like that but it's the end of the day if you're using one that makes sense that is consistent consistent and works with that environment do it it's there should not be a case where you you are part of a group and that you guys are 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 alluded 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 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 techn 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 so 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 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 of 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 now 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 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 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 try to actually work with what exists when you walk into a new environment project ecosystem instead of ripping it all apart like we got to do it this way because this is the right way especially if you're one of those like big six sperms 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 and carry forward with that instead of trying to you know 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 closing thoughts yeah I've got a couple and one I will save is a a teaser for the uh after podcast for the video uh because it's more of a lengthy discussion but as we as you go through this you know like Rob said you know they're 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 uh 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 working on you understand the task 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 over complicate 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 very uncomplicated emails and Communications to us via developer.com we have a contact form you can shoot us something at info@ developer.com you can put comments in the uh if you subscribe you can get it wherever you do your podcast 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 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 because you really don't want to miss one you never know what kind of cool stuff you would miss out on and then your 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 all right bonus time all right bonus use case what if you are a developer coming into a shop that has had to reset their development staff so the standards they had in place for all this existing code no one understands it anymore no one knows it it's essentially a blank box but they want you to conform to what's there okay this is where okay so they don't they don't even they want you to conform what exists but they can't tell you what exists effectively right so for instance a a situation went through a couple years ago where I was brought in on into one company only to find out that 90% of the development team left we had one guy that knew everything and the one guy had no coding standards and so coming into that I had to essentially figure out one what was there how it was put together what standards were there and kind of put something together to kind of bring everyone together on the same page but if you're someone who has not been through this how would you navigate that type of situation um I think it's the same thing is that it's what you do is you go with what you know what what you have if they've got and this is actually even if they do know what they've gotten it's just very minimalistic sometimes it is they have very they really they have a very immature software model of some sort you know they're they're down there basically they they're slinging code and there's no standards to it what you can do is start working toward standards figure out what they have and sometimes there are standards that are Unwritten because they have certain Styles and coding groups and approaches that they do that it's like oh you guys don't realize it but this is the style you have these are standards that you use already and so part of that is documenting that making that part of things moving forward a lot of times it's going to be stuff like implementing or talking somebody into implementing certain things like code reviews and things like that where you start making sure that particularly an organization that is very dispersed and they're just doing their own thing is now talking a little bit and thinking about the rest of the team and not just them and their Silo and whatever problem they're solving and then like everything I find the best way is I always refer to as like the cancerous approach where you just like a little bit here a little bit there a little bit here a little bit there and you just you start growing out you don't want to and I've seen this where people come in and they're like okay we've got this big complicated like full thing that we learned at whatever company we were at before and this is how we're going to do it and there's three developers there and their heads explode because they say no this like it's too much instead it really is a journey in that point where it's like okay let's start with what we've got and I have been in situation it's like okay let's start with we're going to have this thing called Version Control and we're going to actually store our code and we're going to be able to have access to it and we're going to have this thing called a test server and we're not going to just go play on our production server anymore we're going to have something where we can actually test stuff you know there's there's so many levels and items that go into mature software development that if you're not there I think it is it's one of those like just pick one pick something and depending on the team and what they're doing and what the solutions are is find something that is going to it's really where you start looking for the biggest bang for the buck early on and say okay you know you guys don't do this so let's fix that first you know like one of them may be everybody's doing hot fixes on the production server and then everything's on fire all the time because somebody typos it and it blows this up and it blows that then you're like okay the first thing we're going to do is we're going to shut off access to that server and we're going to have a we're going to have a structured promotion of code into the production environment we're going to actually have like a release cycle or something like that and I'm just making these things up because every organiz ation is a little different in what they hit but I see that as the best way is you start simple or simple based on where they're at because if you can start moving it in the right direction and give them some hints or some steps or something like that sometimes it's just little as documentation and things like that is to just get people moving in the right direction then start chunking your way through it because you're not going to eat the elephant in one bite you need to really work toward and it's just working towards it it's also sometimes there are going to be things that you normally would do with an organization that you don't with this one because it doesn't fit them or there's something about them that they're they can't get their head around it or it doesn't really fit their model or whatever it is it's like really there is no such thing as one siiz fits-all so this is where if you really are going to be a better developer and really contribute to the organization as you look at where can this organization and these people improve and where's going to give them the biggest bang for their buck and then you eventually you can get to smaller and smaller payoffs but you you start with the things just like this is something that we can do and this is going to give us value exactly and the only thing I would like to touch on to that is you you laid out a whole lot of information which is great and if you didn't catch it all rewind and listen to it again because he touched on a lot of good points but the key one is start small the second key is remove access from things that people shouldn't have access to nine out of 10 times that will fix 90% of your problems um and then the other thing that you didn't really touch on that I've experienced is get your environment stable Ive walked into some houses and found out that the production server is crashing every other hour and no one has any clue what's going on in fact a lot of people on the team didn't even know it was happening only two people the manager and the senior Dev even knew it was going on so instead of communicating the problem to the team we were all in this Silo doing work and basically the sky is falling so if you run into those types of situations again start small like Rob said but immediately look at the pain points what is causing the biggest problem right now how can I eliminate that or can I fix that first get things stable walk into it documentation is key writing test cases if you don't have a test environment remove access restrict access look at your data structure and then look at policies and procedures and processes you know these are all things good things to follow wherever you go even if you're new you could be in a company and shift teams and the team that you're on was stable now the team you're on is not okay what can you take from Team a to Team B but team a and Team B may also have different styles of doing things there may not be a corporate style it could be a team style so figure that out as well and the other thing is you know we all get frustrated we all have a little bit of it and ego take a step back if things are getting heated you know hit mute turn your camera off walk away for a little bit calm down then come back refresh and revisit the problem that is excellent and if it happens to be that we are your problem I'm going to give you a solution right now because we're going to wrap this one up we will be back next time around if we're your problem you don't have to actually come back but I know we're not really so test that theory out come see us next time around we're going to continue going into our developer Journey as always just like Tim from Oshkosh feel free to shoot us a you know a comment or a question or anything like that we'd love to add those and and address those as we go through this journey hope you continue your have a great day and a great week and we will talk to you next episode [Music]
Transcript Segments
[Music]
welcome back we are talking about our
latest episode this is going to be
episode four right I think we're doing
episode four for the podcast for Season
22 um still a little crazy in my mind
that like this has been going on that
long uh this episode I think we want to
talk about well this is where and I'll
bring it up in the podcast as well we
got a request from Timothy in ashkash
Wisconsin and he said hey why can't you
guys talk a little bit about the
situations that we all run into
where I'm going to try to do it in a
nicer language a little bit but it's
like where we have disagreements with
people uh that are maybe our boss maybe
a customer uh maybe it's co-workers and
particularly if it's uh like a design or
foundational issue or something like
that is like how do we work with that
and how do
we particularly if we are really
convinced that they're taking the wrong
direction what do we what do we do and
how do we handle it so I think that
would be a fun little fun I thinking
other FWS too but a fun little word
thing that we topic we can do for this
episode uh I think you're on board with
you have anything you wanted to add to
it or does that sound like a good good
way to go yeah so the way you kind of
described that I kind of like that and
especially thinking of the developer
Journey for those of you coming out of
like boot camps out of college out of
self-taught you have been or learning a
certain way of doing things a certain
way for a while now now when you get
into a career or get into a more
professional environment especially with
larger uh coding shops with lots of
developers you're going to run into a
lot of times where you butt heads or an
organization does things one way that
you have never seen before so now you've
got to jump in and figure out how to do
that even if it's not necessarily the
right way it is the way that basically
you're being told to do it and just
before we jump in it it reminds me of
that book liftoff where Elon Musk went
through launching SpaceX they were quick
to get things done like quick to
innovate you know that startup mentality
but then once the company was
established they started having to
implement all these policies and
procedures for safety and that and
basically they became NASA so you went
from this very fast-paced growing
learning developing to oh I now meet
organizations it's now time to grow up
and now I get kind of put into this
box uh yeah there's there's a lot of
good stuff in there too and about in
sometimes about the
why so 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 uh maybe you know Milestones
that you're going to get along the way
with your developer Journey some of them
uh you 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 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
customer stuff like that are going a
different direction and and dealing with
that and making sure that we are you
know 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 develop
or.com develop or building better
developers this podcast uh 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
MOS I'm one of the co-founders of
developer ner and founder of Envision QA
where we help small and midsize
businesses with code assessments
software assessments and building custom
software so I want to start with is this
actually is like a nice a recent story
and it 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 uh
either a certain school or Boot Camp or
maybe there's one company we worked with
and there's a style there is a 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 taught 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's not just one
way to solve this problems there's 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 you know Mark us or or be
trademarks of us because of where we
came from if you think of like uh big
schools and stuff like that where it's
like yeah people are from this school
are almost always like this or they have
this style or they go into this business
something that was personal recently
that actually remind me of of a pass
thing was I play this thing called
handball similar short thing similar to
racket ball minus a racket I hadn't
played in a long long time and there's a
guy that I knew 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
because I had always I was 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 a style a way that all of us
play and so it is to me I I could always
pick somebody out of a crowd of handball
players that was doing that because I
knew that I recognized that style
similarly 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 coached 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 coaches style and it
was because it's like you're taught even
in these kind of things like football
there is different you can especially if
you go into the college there are and
actually even Pros there are head coach
you know approaches to offense to
defense and stuff like that if you're if
you're talking about football we have
the same thing as
developers it does not mean it's like in
football you could have a running game
you could 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 Developers 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 timec 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 oh not more like
sometimes you'll get this is why we do
it and Michael touched on this a little
bit is like sometimes you are a big
enough organization now that yeah you 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 a team of let's say 500
developers and you're building stuff
that is 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 you know there's like there
are levels of
concern I don't want to digress Too Much
from the the personal like 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
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 be 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 a able to may be viable to just
say hey can you go go talk to Michael he
knows he'll 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
it is 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 developed ERS this is the same
thing as like somebody that only knows C
and like you got to use C 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 headbutting 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 and you can you can even
say hey I'm not 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 it's say you know where 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 all my little
soap box so I'm going to like 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 are it's very
near and dear to your heart as
well yeah so I run into budding heads
just about every company I work at
because like you we tend to like looking
for multiple solutions to a problem you
know like you said you know you could WR
do something in C SHP all the time but
that's not necessarily the only tool out
there you can do Java you can do python
so we always look for the best tools
now within organizations though they've
already done that or if you're if you're
working for a more mature company
they've already gone through the
trenches they've gone through the
lessons learn 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 cells 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 bite 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 pro
here's the problem as I understand it
this is how I'm going to solve it with X
now 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 to like a collab or like
standup 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 buding heads
you're buding heads with the software
your buy 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 uh 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 backend apis but I
like taking an additional layer and
actually breaking out the controllers on
the endpoint uh hierarchy so like if you
have object a b c so like kind of if you
have a path and you 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 AR Ty 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 looks 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 or if you're in the
Java World C 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
you know language that you use that
isn't necessarily new like uh 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 and
then you're going to have a lot of
friction there because the next person
that comes behind it they're gonna be
like what the heck is this you know how
did they do that and now they have to
spend more time so basically you've now
scoped creete 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 stylesheet or have
training sessions so these are things
you have to be careful of otherwise you
will be bunny ass you will be saying
that yeah for quite a bit or you know
putting people on mute walking away
turning your screen off and just say I
need a minut because there's going to be
a lot of times where this happens you
know 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 stylesheets
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 it's
it works but it is not structured in a
way that anyone can maintain it has to
be
refactored 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 like development standards there's
a lot of stuff right like you know
naming standards
there's just gargantuan amounts of
documentation out all these various like
naming standards and ways you can do it
and why you need to do it and depending
on what your your background is and
every Lang it seems like has its own
little you know standard and stuff like
that but it's the end of the day if
you're using one that makes sense that
is consistent consistent and works with
that
environment do it it's there should not
be a case where you you are part of a
group and that you guys are 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 alluded 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 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 techn 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 so 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
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 of 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 now 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 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 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 try to
actually work with what exists when you
walk into a new environment project
ecosystem instead of ripping it all
apart like we got to do it this way
because this is the right way especially
if you're one of those like big six
sperms 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 and carry forward with that
instead of trying to you know 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 closing
thoughts yeah I've got a couple and one
I will save is a a teaser for the uh
after podcast for the video uh because
it's more of a lengthy discussion but as
we as you go through this you know like
Rob said you know they're 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 uh 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 working on you understand the
task 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 over
complicate 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 very
uncomplicated emails and Communications
to us via developer.com we have a
contact form you can shoot us something
at info@ developer.com you can put
comments in the uh if you subscribe you
can get it wherever you do your podcast
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 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 because you really don't
want to miss one you never know what
kind of cool stuff you would miss out on
and then your 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 all right bonus time all right
bonus use case what if you are a
developer coming into a shop that has
had to reset their development staff so
the standards they had in place for all
this existing code no one understands it
anymore no one knows it it's essentially
a blank box but they want you to conform
to what's
there
okay this is where okay so they don't
they don't even they want you to conform
what exists but they can't tell you what
exists effectively right so for
instance a a situation went through a
couple years ago where I was brought in
on into one company only to find out
that 90% of the development team
left we had one guy that knew everything
and the one guy had no coding
standards and so coming into that I had
to essentially figure out one what was
there how it was put together what
standards were there and kind of put
something together to kind of bring
everyone together on the same page but
if you're someone who has not been
through this how would you navigate that
type of
situation um I think it's the same thing
is that it's what you do is you go with
what you know what what you have if
they've got and this is actually even if
they do know what they've gotten it's
just very minimalistic sometimes it is
they have very they really they have a
very immature software model of some
sort you know they're they're down there
basically they they're slinging code and
there's no standards to it what you can
do is start working toward standards
figure out what they have and sometimes
there are standards that are Unwritten
because they have certain Styles and
coding groups and approaches that they
do that it's like oh you guys don't
realize it but this is the style you
have these are standards that you use
already and so part of that is
documenting that making that part of
things moving forward a lot of times
it's going to be stuff like implementing
or talking somebody into implementing
certain things like code reviews and
things like that where you start making
sure that particularly an organization
that is very dispersed and they're just
doing their own thing is now talking a
little bit and thinking about the rest
of the team and not just them and their
Silo and whatever problem they're
solving and then like everything I find
the best way is I always refer to as
like the cancerous approach where you
just like a little bit here a little bit
there a little bit here a little bit
there and you just you start growing out
you don't want to and I've seen this
where people come in and they're like
okay we've got this big complicated like
full thing that we learned at whatever
company we were at before and this is
how we're going to do it and there's
three developers there and their heads
explode because they say no this like
it's too
much
instead it really is a journey in that
point where it's like okay let's start
with what we've got and I have been in
situation it's like okay let's start
with we're going to have this thing
called Version Control and we're going
to actually store our code and we're
going to be able to have access to it
and we're going to have this thing
called a test server and we're not going
to just go play on our production server
anymore we're going to have something
where we can actually test stuff you
know there's there's so many levels and
items that go into mature software
development that if you're not there I
think it is it's one of those like just
pick one pick something and depending on
the team and what they're doing and what
the solutions are is find something that
is going to it's really where you start
looking for the biggest bang for the
buck early on and say okay you know you
guys don't do this so let's fix that
first you know like one of them may be
everybody's doing hot fixes on the
production server and then everything's
on fire all the time because somebody
typos it and it blows this up and it
blows that then you're like okay the
first thing we're going to do is we're
going to shut off access to that server
and we're going to have a we're going to
have a structured promotion of code into
the production environment we're going
to actually have like a release cycle or
something like that and I'm just making
these things up because every organiz
ation is a little different in what they
hit but I see that as the best way is
you start
simple or simple based on where they're
at because if you can start moving it in
the right direction and give them some
hints or some steps or something like
that sometimes it's just little as
documentation and things like that is to
just get people moving in the right
direction then start chunking your way
through it because you're not going to
eat the elephant in one bite you need to
really work toward and it's just working
towards it it's also sometimes there are
going to be things that you normally
would do with an organization that you
don't with this one because it doesn't
fit them or there's something about them
that they're they can't get their head
around it or it doesn't really fit their
model or whatever it is it's like really
there is no such thing as one siiz
fits-all so this is where if you really
are going to be a better developer and
really contribute to the organization as
you look at where can this organization
and these people
improve and where's going to give them
the biggest bang for their buck and then
you eventually you can get to smaller
and smaller payoffs but you you start
with the things just like this is
something that we can do and this is
going to give us
value exactly and the only thing I would
like to touch on to that is you you laid
out a whole lot of information which is
great and if you didn't catch it all
rewind and listen to it again because he
touched on a lot of good points but the
key one is start small the second key is
remove access from things that people
shouldn't have access
to nine out of 10 times that will fix
90% of your problems um and then the
other thing that you didn't really touch
on that I've experienced is get your
environment stable Ive walked into some
houses and found out that the production
server is crashing every other hour and
no one has any clue what's going on in
fact a lot of people on the team didn't
even know it was happening only two
people the manager and the senior Dev
even knew it was going on so instead of
communicating the problem to the team we
were all in this Silo doing work and
basically the sky is falling so if you
run into those types of situations again
start small like Rob said but
immediately look at the pain points what
is causing the biggest problem right now
how can I eliminate that or can I fix
that first get things stable walk into
it documentation is key writing test
cases if you don't have a test
environment remove access restrict
access look at your data structure and
then look at policies and procedures and
processes you know these are all things
good things to follow wherever you go
even if you're new you could be in a
company and shift teams and the team
that you're on was stable now the team
you're on is not okay what can you take
from Team a to Team B but team a and
Team B may also have different styles of
doing things there may not be a
corporate style it could be a team style
so figure that out as well and the other
thing is you know we all get frustrated
we all have a little bit of it and ego
take a step back if things are getting
heated you know hit mute turn your
camera off walk away for a little bit
calm
down then come back refresh and revisit
the problem
that is excellent and if it happens to
be that we are your problem I'm going to
give you a solution right now because
we're going to wrap this one up we will
be back next time around if we're your
problem you don't have to actually come
back but I know we're not really so test
that theory out come see us next time
around we're going to continue going
into our developer Journey as always
just like Tim from Oshkosh feel free to
shoot us a you know a comment or a
question or anything like that we'd love
to add those and and address those as we
go through this journey hope you
continue your have a great day and a
great week and we will talk to you next
episode
[Music]