Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche discuss how developers can succeed across multiple software methodologies, including Agile, Waterfall, DevOps, and hybrid models. From handling context switching to defining “done,” they share real-world tips on staying productive, documenting wisely, and focusing on value, not just process.
Topics Covered: • Common software methodologies • Context switching between frameworks • Defining “done” in different teams • Being methodology-bilingual • Smart documentation practices • Developer mindset shifts
🔗 Full blog post summary: https://develpreneur.com/software-methodologies-developer-success/
*Follow-us on:*
[email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://X.com/develpreneur * https://www.linkedin.com/company/develpreneur/
#SoftwareMethodologies #AgileDevelopment #DeveloperMindset #BuildingBetterDevelopers #DevOps #SoftwareEngineering #AIInDevelopment
Transcript Text
[Music] All right. Conveniently enough, I hit record. Um, so we don't have much to talk about. This is actually pretty cool. We're going to dive right in. episode last time around two seasons back and we're going to ask AI about it is bridging the gap how developers can thrive admits differing methodologies. Now one of the interesting things is I did not go back and look at all these after we recorded them way back when and actually like look at the titles. So there's some of this stuff I'm like wow did we talk about that? We're going to find out what AI thinks here in just a few moments. We'll do our Let's dive right in. Three. Well, hello and welcome back. We are continuing our season of building better developers, developer with AI. Yes, we're going back through a past season. We're taking those topics thrown out the AI and see what it says. So far, it's actually been really interesting. It's it's been very much in line with a lot of the things we've talked about and the 10 things that it suggests. We have never gotten through all 10 because we have comments on every one of them because that's who we are. More specifically, I am Rob Broadhead, one of the founders of Developer, also the founder of RV Consulting, where we are we are that company that sits down beside you and says, "Let's look at what you've got as far as technology is concerned and see where you want to go with your business and we're going to craft a special recipe and help you build a road map, maybe even help you implement it for your technology so you get a better return on investment through integration, simplification, automation, even innovation. We will find ways to take what you've got. Uh my favorite latest one is take that junk drawer of technologies you've got and turn it into something that's actually useful so that you're not sitting there at the end of the year going where did all of these licenses and all of this money go and instead you're counting all those bags of money that come in because now you have a smooth slick process and you are leveraging technology instead of being you know hemorrhaging technology even. Good thing, bad thing. Good thing was uh took a got to take a week off sort of uh about a week or two ago. Got to spend some time away from home, a little bit different, you know, change of change of scenery and things like that. Had a couple of of days that were partial days essentially and things like that. We're able to do some check out some of the areas around there and some, you know, nice little walks and exercise and good things like that. Bad thing about that is somewhere along the way picked up some sort of crud or something like that. So now I've got that deeper radio voice that hopefully I will not be coughing through this too far. Uh that being said, the other guy the guy on the other end is now apparently on the other end of all of his allergy issues, but we'll see how that goes. Michael, go ahead and introduce yourself. Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of building better developers, also known as developer. I'm also the founder of a company called Envision QA where we work with businesses and understand their problems and help them find a solution. We do that through essentially a QA mindset. We take it walk through the processes of your company through a users's perspective. We essentially do an assessment of everything within your technology stack and determine how you're using your software and if it's working for you. If it's not, we help you customize the solution that fits your needs. Either help you find uh over-the-counter software or build you something custom to work with your systems and hopefully improve your performance and customer satisfaction. Good thing, bad thing? Well, good thing on my side, as Rob mentioned, I am over my allergies. I am past my part of the season and part of that is due to the fact that we have had sunny weather for almost a week. A few rainy spots there but lots of sun so I can finally get over the crud that I have. Uh bad side of that uh I am away from my house this week uh because my daughter is at Bonnaroo which is a Woodstock kind of thing in Tennessee concert. So, I get to dogsit for a week amongst all my other uh business tasks. So, I get a multitask this week. Uh, always a fun thing. Never hurts to have a few pets, at least so I've heard I had kids instead. Moving on. So, the topic we're going to talk about last time around was titled bridging the gap. How developers can thrive amidst differing tech uh methodologies. So we throw that at AI at chatgpt and of course it is very impressed with us. It starts out with that's a great topic very relevant in today's multimemethodology hybrid tech teams. These are some things here where you can see where AI is like as they say overeing the custard a little bit throwing a couple extra big words out there to make it impressing. But let's go into their outline and key talking points. So set the stage. What are differing methodologies? Quick overview of common methodologies. Uh methodologies, agile, scrum, waterfall, conbomb, devops, safe, explain why teams often end up mixing them. Enterprise constraints, legacy systems, client demands, etc. Now, this is one that I think we we really did start with like a very brief definition. We didn't go as broad as they they said there. Um but, you know, it's basically you sort of want to set the table for something like this. This one I don't think we have too much to talk about. So let's move along to the next point. See what they say. This is where the common struggles developers face. Context switching between styles. For example, agile sprint versus waterfall milestone mindset. Misaligned expectations. Definition of done or documentation depth. Communication challenges when processes are not uniform. Friction from leadership or other departments with different cadences. That's four or five episodes right there. I think the first one I'll I'll just dive into the first one. Context switching between styles. We talk about switching your projects uh on a regular basis where you maybe have two or three projects at a time. Uh they may be different technologies, different environments and things like that. And there is that that mental cost of switching from thinking about for example uh JavaScript and putting semicolons at the end of your lines or uh Python where you don't have any and you have to make sure you get your tabs right or Java where you're worried about case sensitive versus maybe DOSs where you're not things like that. Okay, DOSs there's not a lot of people out there but I'm going to throw that out there just because I can. It is, I think, more jarring to do it from a methodology point of view. This is something I don't think we've really talked about it from a the higher level methodology point of view, but I'm going to throw this right at you is like the the thought of it because I'm sure you you've been there as well where we're working a project maybe, you know, one customer it's agile, the other one's waterfall, maybe one's conbon, and this is even amongst agile. Maybe you've got a scrum that's like every two weeks you do a sprint, another one you do every three. Some of you do retrospectives, some of you don't, things like that. So, what are some of your thoughts on the the context switching? So, there are pros and cons to this. Uh, let me start with the pros. So, one of the things that I enjoy about context switching is if you're working on multiple projects, especially in the same language and in the same kind of um business class, you typically can run into burnout where it's like, oh, I'm working on this and I switch gears. I'm still working on kind of the same issue, same problem. Um, one of the things I like about working on multiple projects in different contextes or different languages is it allows me to mentally shift from one mindset to another. Let's me take a break from what I'm working on over here. Lets me get over here and work on this. Now, the negative side to that with switching context is like you said kind of that mental shift. You have to make sure that you go from this language, you go to this language, you got to make sure you got the syntax right. If you're starting on a new project that you haven't worked on the language in a while, that uplift is going to be a little tedious at the beginning. Now, if you're going back and forth between uh languages that you've worked with constantly, it's less of a con contextual shift, so to speak, because you're in it enough that you can go from this, you can go to this, go to this. It's kind of like being bilingual. If you can speak Spanish and English really well, you might be able to speak like French, but if you're not if you took Spanish for four years in college and it's been 10 years, yeah, you might be able to understand it, but you're not going to be able to jump in and start speaking it real well right away. It's kind of the similar kind of context with programming language. It's still a language. So all I can say is make sure that if you are jumping projects and you're dealing with this contextual shift um make sure that you have the tools in place to do it because if you don't not having the right tools in your tool tool belt is going to be a big another kind of downside to multi- switching because you're going to be like oh okay I can use Visual Code. Well Visual Code if you go from like Python to Java oh what libraries do I need? What plugins do I need? you might be better off just downloading like Eclipse or Intelligj to quickly jump into that language. So just some things to think about your thoughts. Uh the tools is really interesting because I do I actually like when I'm in when I'm crossing languages and this is not so much um with a methodology side but when I'm crossing languages a good point. I'd like actually like to stay in like a Visual Studio Studio Code or something like that. So I'm in the same uh the same general context. I sort of know where Windows are and things like that and you know quick keys and stuff like that. There is a b a benefit though of switching them so that there is when you're looking at it there is something visually different. So you're like oh I'm working on project X instead of project Y. Now I'll even do that in the same language. Sometimes if I got two projects of the same language I may work one let's say they're both uh Java. I'll work one in Eclipse and another one I'll work in Intelligj or something like that or Visual Studio. Now, interestingly enough though, this week, well, we've been working on some things. You've broken your local environment because you're using the same environment in the same tool suites. So, that's to me that's kind of a trade-off if you try to stay in like Visual Code because if you do something for one project, you could potentially break yourself in another. Whereas, if you have the two, you you separate the instances, so to speak. Well, this was actually this is not my environment. This is my operating system. This was the this is underlining underlying database. This is where that's a whole different concept where maybe it is better and I've thought about this a lot in the last week that it maybe is better to just run through containers and stuff like do your development there, have your environment up, spin it up, do what you need to and go from there because sometimes you get operating system updates and everything breaks. I'm not going to complain about Brew and Mac, but I just did. It can cause you some issues especially and it can cause you issues when you're crossing languages, you're crossing databases and some other stuff. You'll get libraries that connect, you know, that update you don't want to. And it's not just it's not just Mac and brew. I know Windows that's part of why I left it. I've had too many DL hill is you know situations in my life. Moving along though, this next one, misaligned expectations. For example, the definition of done. Oh my gosh, this is the quintessential discussion in every project somewhere along the way. If it's done right, no pun intended, you talk about it early on. What does done mean? What does it look like? If it's not, then what's going to happen is somewhere along the way there's going to be an argument slashd discussion slash World War III beginning over what does done mean? And usually it is when you cross like business analysts versus project managers versus QA versus developers because they don't always say the same thing. They don't always think the same thing. And then you have the user who doesn't always think the same way. And when you say something is done that needs to be clarified. This is something that we've talked about in various cases over the years. Uh one of them is definitely when you're dealing with a customer, know what done means and make sure you're clear what done means to them. Because you don't want to be in a situation where you say it's done and they don't think it is yet. Or the reverse when you say it's not done but they think it is. So they're like ship it. Put it in front of everybody and you're like no no no no no that is not what that is not kosher. So even especially with methodologies because there's a very different way that we approach things if it's waterfall versus if it's agile. there is that agile is almost always that like that 8020 you know uh paro principle kind of approach of like we'll get there we're mostly done we can clean it up in the next sprint things like that versus waterfall it's like it has to be done code freeze and then it better be solid you better have all your pieces all your ducks in a row thoughts on that boy that's a can of worms cuz interestingly enough. So being having a lot of experience on the testing side of things and doing a lot of user acceptance testing, integration testing, unit testing, from a tester's perspective, the definition done is different than if you're doing like unit testing. Um because unit testing, you're testing a function of code. You're testing something behind the scenes. But where as uh when you're actually writing these tickets, you're creating features for the user. You're creating something within the application for people to use. And the definition of done isn't always visible to the user. Sometimes it could be as simple as you know you something is created behind the scenes, a job runs, something is created in the back end. But these things need to be defined in such a way that it can be tested that you can essentially check off. It's a checklist of things to do. The best thing I can say and I say this all the time with testing is think of a recipe. All the stuff that goes into it is all your ingredients. That's all your code. What comes out of it is that those steps to actually produce the food. So you have the requirements which is kind of that uh here's your uh overview of what it is that you're making. You're making chocolate chip cookies. So you should get cookies. It's your ingredients are essentially this is what needs to go into the code to build it. You know, chocolate chips, sugar, flour, and then the recipe or or the steps to produce it is essentially your checklist. Okay, did this get mixed correctly? Did this go into the oven at the right time? Did it come out burnt or did it come out the right way? That's essentially to me the way you need to tackle definition done or u you know within a ticket. What is it that you're doing? What is the output of what it is we're asking you to do? If that's not defined, as Rob mentions, it's going to get to the tester and they're going to be like, "Well, what did you do?" And the worst part is if it's not defined and the developer does something off task or out of scope and it's not documented in the ticket, you have no idea testing. You're going to go test it and it could be something totally different than what the ticket says. And your food example gives me another, you know, I think of something similar. If you want to talk about what the, you know, think about how argumentative it can be to figure out what done is for a feature, sit around with a bunch of people from different parts of the country and ask them what done means as far as stake is concerned. And you will find not only very different answers, people that very much want it done a certain way. And that's where I think we get into it's almost religious issues arguments when we talk about it from developers to testers to project managers to users and things like that that we can really get caught up in the semantics of that the syntax of it. And so we need to make sure sooner rather than later that we walk through what that is. And that's also so much tied to methodologies. And that is that is where you really have to think through it. you're going to have to shift your mind a little bit to say, "Okay, what do I need to get done to mark this ticket complete or move it on to whatever the next next phase is." Let's go ahead and move on. I said there's a lot of good stuff in this one. So, they get into uh mind shift mindset shift from methodology purist to adaptive professional. Encourage developers to value principles over process. For example, delivering value, team collaboration. Share real world anecdotes where rigid adherence hurt collaboration. Promote being methodology bilingual, understanding how different systems work, even if you don't prefer them. This these three bullet points right here. This is basically the uh agile manifesto like principles over process. There is this goes back to something we brought up. I think even in this specific episode is it comes down to why. Why are you building this application? Why are you solving this problem? What is the solution that you're really trying to get to? Because yes, there is a lot when you talk about a methodology, there's a lot of rules, for lack of a better term, rules or guidelines on how to get there. But the bottom line is you need to get there. It's just like, you know, you can jump in a car and go from one end of a country to another. And there's a lot of different ways you can go and some are going to be better than others and cost more or less and things like that, but the goal is to get to the other end of the country. It's not necessarily that, hey, we turn left here instead of right and things like that. And I think that is something that I I too often I have been in situations where people get caught up in the methodology side of stuff and are not thinking about we still have a we have a goal that is not serving the methodology. It's actually serving our customer. thoughts on that? Yeah. So, it's really funny the principles over practice. You know, what are you building? Why are you building this? It's when you start out on a project or start out on the journey, you kind of have a end goal in mind. You kind of have an idea. But the problem is as you go through the project, either customer expectations change, requirements could potentially change, and you might lose yourself in the weeds versus where you're going. You could get distracted. It it's uh that constant example we throw out is, you know, why is this button purple? Why are you spending hours on a color when the application isn't done? It it it's you know you got to ask yourself is what I'm working on working towards the goal or am I just working basically am I being busy to be busy am I staying on task am I working towards something um we run into that all the time and it that's one of the quicst things it it's almost like you know the the multitask thing it's like you can't really work on multiple multle tasks simultaneously. You can perceptionally wise work on multiple things at the same time, but really you're stopping your focus on one thing to work on another. And then when you shift to that, you're stopping your focus on that. Now, if you say you're multitasking and you shift from this to this and you're still thinking about this, then you're not giving this your its full attention. So, try to make sure that what you're working on is going towards that goal. what you're trying to build and not getting sidetracked in the weeds on something that is important but maybe not important now for the end goal. Yeah, it's just like red tape anywhere. It can be is it you know you can get the process can be what you're serving as opposed to the customer and the the end product. Uh moving along because there's great points there and I don't really have much to add. Uh practical skills developers should build communication. Learn to ask the right questions in different frameworks. Great one. This next one words is going to be a full stop right after this. Documentation agility. How to write just enough without overdoing it. Now, this is this is probably one of the most valuable skills for a developer to have is to figure out how to write enough or actually developer uh business analyst, project manager, scrum master, whoever's anybody that writes tickets, documentation, requirements, how to put the right amount in there so that you are covering the things that need to be covered and you're not wasting people's time with a bunch of extra extra stuff, which actually goes back to the original thing I was saying about AI is where it was like it could have had a much shorter answer that it put a lot of fluff in there because that's part of what it does. And honestly, if you look at a lot of, you know, blogs and stuff like that, there is a lot of fluff in those things as well. People are spending too much time trying to impress people with the, you know, the more than four-letter words that words that they know and all these things and write to a, you know, 12th grade level or whatever it happens to be as opposed to just be concise, get the point across just like I haven't done. I just added a whole lot of fluff right there. It's better off to say make your point, make it clear, and move on. It's that simple. Thoughts on that? The thing I'll add to that is one of the biggest problems with documentation is the multissources where documentation lives. At the beginning of a project, it should live in one place. Be it Dropbox, one folder, whatever the requirements gather gathered, it should go in one place. As the project goes on, this is one thing I I've kind of adopted over the years. Your code document documenting your code needs to be the source of truth. If you're adding Java docs or any type of comment documentation in your project, it should essentially go from the requirements to the code. You should have some way of building that with your code at the end. So you essentially can always look at your code and know that this is the source of truth. If you try to jumble the two and have a maintain a secondary requirements document outside of your code, that's fine. But you have to be very rigid about because if you don't stay on track, your code could go one way and your documentation goes another. But if you keep the documentation in your code, then essentially as you make changes, you should be updating your documentation and then everything's in sync. And that is a perfect segue into a great way to help document your thoughts about this is to send us an email at [email protected]. We appreciate your time. We appreciate you you sitting here and walking through these things with us. I I highly recommend that you do a process. You know, spend a little time with something like this. Take some thoughts, throw them out to one of the AI engines, preferably a couple different AI engines, and see what kind of stuff comes back. Because we are getting into a world where yes, AI can help you be more efficient. It can help help you get stuff done faster, but you also need to be able to recognize AI and some of its fingerprints and some of the things that it does well and the things it doesn't do very good so that you're able to leverage it even better and also maybe not get caught up by somebody that's AI generated something and you think it's good and then you realize that no, it actually isn't. It's going to help you in vetting not only your own work but that of others. This actually is not AI generated. I'm a real person. He's a real person as far as I know. And our intelligence, it may not be that great, but we are definitely not artificial. That being said, I'm going to wrap this one up. Thank you again for your time. Go out there and have yourself a great day, a great week, and we will talk to you next time. Bonus material. Uh let me start with this. I'm going to fly through there. We only got through four. Uh, I'm going to go through the five real quick and then see where you want to throw something in there. Bridging techniques translate across teams. How de developers can become communication bridges. Suggest hybrid practic practices. Share frameworks like Spotify model or dual track agile. Uh, stories from the field. Interview or share a story from a dev who's thrived in a hybrid method environment. That would be a really fun one to try. Highlight successes failure due to inflexibility and methodology use. Actionable takes takeaways. Uh, audit your team's methodology fit. Learn one new method every quarter. Shadow or interview someone on a different team about their process. Suggest one small bridging experience in your next sprint or cycle. So, where do you want to go with that for some bonus material? So, I'll take it this route. Um, one of the things that I've find useful in a lot of bigger companies and corporations I work with, when you have a large team, uh, especially when you're in like two week sprints or you're in long drawn out projects, take the time to do maybe bi-weekly do like a team collab. Spend an hour together as a team. Talk through problems, talk through ideas, brainstorm. Um, maybe throw out, hey, what do you guys think of the direction we're going? Does anyone have any new thoughts or ideas? You can kind of do like an open platform. Uh with that, maybe do lunch and learns like pick a topic and just get together as a team and talk through uh a new technology or a new feature or a new architecture. And lastly, uh hackathons. get your team together and just pick something that's kind of been on the back burner on your team and just sit down and spend like two to three days on it and just throw everything at the wall and see what sticks and what you can come up with as a solution. I think with those I I like it with I I think the more you experience the different methodologies that you've done a project uh you've done multiple project with them especially different sized teams different environments things like that it's going to help you figure out ways to find a best of breed out of those because there are some there are pros and cons to every one of them and there are ways to mix and match things a little bit take some of the strengths of one and maybe adapt them into another. Agile in particular is built to be more like a guideline. It is not a series of rules. So you can make some changes to it. You can start with an agile approach and uh take some of the things that you liked about maybe waterfall or some of the things you like about just a conbon or you know some of these other approaches that are out there and so you can find maybe your a best fit for you. Um, you can also find ways I think to better do certain methodologies because now you've seen how a problem was solved in you know some other one and that may open your mind and you know let you think out of the box to maybe approach this process and approach a little differently with the other methodology. As always, I think the more tools you have, the more arrows that you have in your your quiver, the more tools you have in your toolbox, the more you can realize that, you know, you don't have just a hammer and everything is a nail that there are a lot of different, we'll say, we'll just use the word nuances to get through these uh this problem solving. And it's that's going to be the ways that you find better, newer, uh sometimes groundbreaking ways to get these things done. So, take advantage of that. I mean, it's yes, it can be a challenge, but also uh it can be a it can be a great way to grow because you'll be exposed to a lot more in a shorter period of time. That being said, we're going to wrap this one up. We're coming back. We're going to continue this. We're going to take the the next episode's topic and we're going to throw it out to AI and see what it says. And it's going to say it's brilliant because it always says nice stuff to us. And if it doesn't, then we're going to find we're going to watch that one really close because then obviously it's gone evil on us. And watch out, Skynet is right behind it. As always, you shoot us an email, but you can also hit us up at developer onx. We have a Facebook page. You can go to developer.com. We have got so much stuff out there. Whatever your topic is, whatever your language is, whatever environment is, I can just about guarantee we've got stuff out there that can help you. Whether it's at a beginner level or some specific problems, uh, common problems that are solved in those languages and those environments, including things that are business problems. We have spent a lot of time with some of our uh some of our mentor classes. We've talked about some of the the business problems that out there. We've had several past seasons of developer podcasts where we've talked about things that were common business problems and challenges. And of course the interviews I always go back to those those were those are just a gold mine of information. uh we talked to a lot of excellent uh entrepreneurs and people that are very, you know, top of their field and there's always some great advice that came out of it. So feel free to check that stuff out. As always, you know, let us know if you have any questions. We would love to get your feedback and we will wrap this one up and we will get back to you next time around. Go out there and have yourself a good one. [Music]
Transcript Segments
[Music]
All right. Conveniently enough, I hit
record. Um, so we don't have much to
talk about. This is actually pretty
cool. We're going to dive right in.
episode last time around two seasons
back and we're going to ask AI about it
is bridging the gap how developers can
thrive admits differing methodologies.
Now one of the interesting things is I
did not go back and look at all these
after we recorded them way back when and
actually like look at the titles. So
there's some of this stuff I'm like wow
did we talk about that? We're going to
find out what AI thinks here in just a
few moments. We'll do our Let's dive
right in. Three.
Well, hello and welcome back. We are
continuing our season of building better
developers, developer with AI. Yes,
we're going back through a past season.
We're taking those topics thrown out the
AI and see what it says. So far, it's
actually been really interesting. It's
it's been very much in line with a lot
of the things we've talked about and the
10 things that it suggests. We have
never gotten through all 10 because we
have comments on every one of them
because that's who we are. More
specifically, I am Rob Broadhead, one of
the founders of Developer, also the
founder of RV Consulting, where we are
we are that company that sits down
beside you and says, "Let's look at what
you've got as far as technology is
concerned and see where you want to go
with your business and we're going to
craft a special recipe and help you
build a road map, maybe even help you
implement it for your technology so you
get a better return on investment
through integration, simplification,
automation, even innovation. We will
find ways to take what you've got. Uh my
favorite latest one is take that junk
drawer of technologies you've got and
turn it into something that's actually
useful so that you're not sitting there
at the end of the year going where did
all of these licenses and all of this
money go and instead you're counting all
those bags of money that come in because
now you have a smooth slick process and
you are leveraging technology instead of
being you know hemorrhaging technology
even. Good thing, bad thing. Good thing
was uh took a got to take a week off
sort of uh about a week or two ago. Got
to spend some time away from home, a
little bit different, you know, change
of change of scenery and things like
that. Had a couple of of days that were
partial days essentially and things like
that. We're able to do some check out
some of the areas around there and some,
you know, nice little walks and exercise
and good things like that.
Bad thing about that is somewhere along
the way picked up some sort of crud or
something like that. So now I've got
that deeper radio voice that hopefully I
will not be coughing through this too
far. Uh that being said, the other guy
the guy on the other end is now
apparently on the other end of all of
his allergy issues, but we'll see how
that goes. Michael, go ahead and
introduce yourself. Hey everyone, my
name is Michael Malashsh. I'm one of the
co-founders of building better
developers, also known as developer. I'm
also the founder of a company called
Envision QA where we work with
businesses and understand their problems
and help them find a solution. We do
that through essentially a QA mindset.
We take it walk through the processes of
your company through a users's
perspective. We essentially do an
assessment of everything within your
technology stack and determine how
you're using your software and if it's
working for you. If it's not, we help
you customize the solution that fits
your needs. Either help you find uh
over-the-counter software or build you
something custom to work with your
systems and hopefully improve your
performance and customer satisfaction.
Good thing, bad thing? Well, good thing
on my side, as Rob mentioned, I am over
my allergies. I am past my part of the
season and part of that is due to the
fact that we have had sunny weather for
almost a week. A few rainy spots there
but lots of sun so I can finally get
over the crud that I have. Uh bad side
of that uh I am away from my house this
week uh because my daughter is at
Bonnaroo which is a Woodstock kind of
thing in Tennessee concert. So, I get to
dogsit for a week amongst all my other
uh business tasks. So, I get a multitask
this week.
Uh, always a fun thing. Never hurts to
have a few pets, at least so I've heard
I had kids instead.
Moving on. So, the topic we're going to
talk about last time around was titled
bridging the gap. How developers can
thrive amidst differing tech uh
methodologies. So we throw that at AI at
chatgpt and of course it is very
impressed with us. It starts out with
that's a great topic very relevant in
today's multimemethodology hybrid tech
teams. These are some things here where
you can see where AI is like as they say
overeing the custard a little bit
throwing a couple extra big words out
there to make it impressing. But let's
go
into their outline and key talking
points. So set the stage. What are
differing methodologies? Quick overview
of common methodologies. Uh
methodologies, agile, scrum, waterfall,
conbomb, devops, safe, explain why teams
often end up mixing them. Enterprise
constraints, legacy systems, client
demands, etc. Now, this is one that I
think we we really did start with like a
very brief definition. We didn't go as
broad as they they said there. Um but,
you know, it's basically you sort of
want to set the table for something like
this. This one I don't think we have too
much to talk about. So let's move along
to the next point. See what they say.
This is where the common struggles
developers face. Context switching
between styles. For example, agile
sprint versus waterfall milestone
mindset. Misaligned expectations.
Definition of done or documentation
depth.
Communication challenges when processes
are not uniform. Friction from
leadership or other departments with
different cadences.
That's four or five episodes right
there. I think the first one I'll I'll
just dive into the first one. Context
switching between styles. We talk about
switching your projects uh on a regular
basis where you maybe have two or three
projects at a time. Uh they may be
different technologies, different
environments and things like that. And
there is that that mental cost of
switching from thinking about for
example uh JavaScript and putting
semicolons at the end of your lines or
uh Python where you don't have any and
you have to make sure you get your tabs
right or Java where you're worried about
case sensitive versus maybe DOSs where
you're not things like that. Okay, DOSs
there's not a lot of people out there
but I'm going to throw that out there
just because I can. It is, I think, more
jarring to do it from a methodology
point of view. This is something I don't
think we've really talked about it from
a the higher level methodology point of
view, but I'm going to throw this right
at you is like the the thought of it
because I'm sure you you've been there
as well where we're working a project
maybe, you know, one customer it's
agile, the other one's waterfall, maybe
one's conbon, and this is even amongst
agile. Maybe you've got a scrum that's
like every two weeks you do a sprint,
another one you do every three. Some of
you do retrospectives, some of you
don't, things like that. So, what are
some of your thoughts on the the context
switching?
So, there are pros and cons to this. Uh,
let me start with the pros. So, one of
the things that I enjoy about context
switching is if you're working on
multiple projects, especially in the
same language and in the same kind of um
business class, you typically can run
into burnout where it's like, oh, I'm
working on this and I switch gears. I'm
still working on kind of the same issue,
same problem. Um, one of the things I
like about working on multiple projects
in different contextes or different
languages is it allows me to mentally
shift from one mindset to another. Let's
me take a break from what I'm working on
over here. Lets me get over here and
work on this. Now, the negative side to
that with switching context is like you
said kind of that mental shift. You have
to make sure that you go from this
language, you go to this language, you
got to make sure you got the syntax
right. If you're starting on a new
project that you haven't worked on the
language in a while, that uplift is
going to be a little tedious at the
beginning. Now, if you're going back and
forth between uh languages that you've
worked with constantly, it's less of a
con contextual shift, so to speak,
because you're in it enough that you can
go from this, you can go to this, go to
this. It's kind of like being bilingual.
If you can speak Spanish and English
really well,
you might be able to speak like French,
but if you're not if you took Spanish
for four years in college and it's been
10 years, yeah, you might be able to
understand it, but you're not going to
be able to jump in and start speaking it
real well right away. It's kind of the
similar kind of context with programming
language. It's still a language. So
all I can say is make sure that if you
are jumping projects and you're dealing
with this contextual shift um make sure
that you have the tools in place to do
it because if you don't
not having the right tools in your tool
tool belt is going to be a big another
kind of downside to multi- switching
because you're going to be like oh okay
I can use Visual Code. Well Visual Code
if you go from like Python to Java oh
what libraries do I need? What plugins
do I need? you might be better off just
downloading like Eclipse or Intelligj to
quickly jump into that language. So just
some things to think about your
thoughts. Uh the tools is really
interesting because I do I actually like
when I'm in when I'm crossing languages
and this is not so much um with a
methodology side but when I'm crossing
languages a good point. I'd like
actually like to stay in like a Visual
Studio Studio Code or something like
that. So I'm in the same uh the same
general context. I sort of know where
Windows are and things like that and you
know quick keys and stuff like that.
There is a b a benefit though of
switching them so that there is when
you're looking at it there is something
visually different. So you're like oh
I'm working on project X instead of
project Y. Now I'll even do that in the
same language. Sometimes if I got two
projects of the same language I may work
one let's say they're both uh Java. I'll
work one in Eclipse and another one I'll
work in Intelligj or something like that
or Visual Studio. Now, interestingly
enough though, this week, well, we've
been working on some things. You've
broken your local environment because
you're using the same environment in the
same tool suites. So, that's to me
that's kind of a trade-off if you try to
stay in like Visual Code because if you
do something for one project, you could
potentially break yourself in another.
Whereas, if you have the two, you you
separate the instances, so to speak.
Well, this was actually this is not my
environment. This is my operating
system. This was the this is underlining
underlying database. This is where
that's a whole different concept where
maybe it is better and I've thought
about this a lot in the last week that
it maybe is better to just run through
containers and stuff like do your
development there, have your environment
up, spin it up, do what you need to and
go from there because sometimes you get
operating system updates and everything
breaks. I'm not going to complain about
Brew and Mac, but I just did. It can
cause you some issues especially and it
can cause you issues when you're
crossing languages, you're crossing
databases and some other stuff. You'll
get libraries that connect, you know,
that update you don't want to. And it's
not just it's not just Mac and brew. I
know Windows that's part of why I left
it. I've had too many DL hill is you
know situations in my life. Moving along
though,
this next one, misaligned expectations.
For example, the definition of done. Oh
my gosh, this is the quintessential
discussion in every project somewhere
along the way. If it's done right, no
pun intended, you talk about it early
on. What does done mean? What does it
look like? If it's not, then what's
going to happen is somewhere along the
way there's going to be an argument
slashd discussion slash World War III
beginning over what does done mean? And
usually it is when you cross like
business analysts versus project
managers versus QA versus developers
because they don't always say the same
thing. They don't always think the same
thing. And then you have the user who
doesn't always think the same way. And
when you say something is done
that needs to be clarified. This is
something that we've talked about in
various cases over the years. Uh one of
them is definitely when you're dealing
with a customer, know what done means
and make sure you're clear what done
means to them.
Because you don't want to be in a
situation where you say it's done and
they don't think it is yet. Or the
reverse when you say it's not done but
they think it is. So they're like ship
it. Put it in front of everybody and
you're like no no no no no that is not
what that is not kosher. So even
especially with methodologies because
there's a very different way that we
approach things if it's waterfall versus
if it's agile. there is that agile is
almost always that like that 8020 you
know uh paro principle kind of approach
of like we'll get there we're mostly
done we can clean it up in the next
sprint things like that versus waterfall
it's like it has to be done code freeze
and then it better be solid you better
have all your pieces all your ducks in a
row thoughts on that
boy that's a can of worms cuz
interestingly enough. So being
having a lot of experience on the
testing side of things and doing a lot
of user acceptance testing, integration
testing, unit testing,
from a tester's perspective, the
definition done is different than if
you're doing like unit testing. Um
because unit testing, you're testing a
function of code. You're testing
something behind the scenes. But where
as uh when you're actually writing these
tickets, you're creating features for
the user. You're creating something
within the application for people to
use. And the definition of done isn't
always visible to the user. Sometimes it
could be as simple as you know you
something is created behind the scenes,
a job runs, something is created in the
back end. But these things need to be
defined in such a way that it can be
tested that you can essentially check
off. It's a checklist of things to do.
The best thing I can say and I say this
all the time with testing is think of a
recipe. All the stuff that goes into it
is all your ingredients. That's all your
code. What comes out of it is that those
steps to actually produce the food. So
you have the requirements which is kind
of that uh here's your uh overview of
what it is that you're making. You're
making chocolate chip cookies. So you
should get cookies. It's your
ingredients are essentially this is what
needs to go into the code to build it.
You know, chocolate chips, sugar, flour,
and then the recipe or or the steps to
produce it is essentially your
checklist. Okay, did this get mixed
correctly? Did this go into the oven at
the right time? Did it come out burnt or
did it come out the right way? That's
essentially to me the way you need to
tackle definition done or u you know
within a ticket. What is it that you're
doing? What is the output of what it is
we're asking you to do? If that's not
defined,
as Rob mentions, it's going to get to
the tester and they're going to be like,
"Well, what did you do?" And the worst
part is if it's not defined and the
developer does something off task or out
of scope and it's not documented in the
ticket, you have no idea testing. You're
going to go test it and it could be
something totally different than what
the ticket says.
And your food example gives me another,
you know, I think of something similar.
If you want to talk about what the, you
know, think about how argumentative it
can be to figure out what done is for a
feature,
sit around with a bunch of people from
different parts of the country and ask
them what done means as far as stake is
concerned. And you will find not only
very different answers, people that very
much want it done a certain way. And
that's where I think we get into it's
almost religious issues arguments when
we talk about it from developers to
testers to project managers to users and
things like that that we can really get
caught up in the semantics of that the
syntax of it. And so we need to make
sure sooner rather than later that we
walk through what that is. And that's
also so much tied to methodologies. And
that is that is where you really have to
think through it. you're going to have
to shift your mind a little bit to say,
"Okay, what do I need to get done to
mark this ticket complete or move it on
to whatever the next next phase is."
Let's go ahead and move on. I said
there's a lot of good stuff in this one.
So, they get into uh mind shift mindset
shift from methodology purist to
adaptive professional. Encourage
developers to value principles over
process. For example, delivering value,
team collaboration. Share real world
anecdotes where rigid adherence hurt
collaboration. Promote being methodology
bilingual, understanding how different
systems work, even if you don't prefer
them. This these three bullet points
right here.
This is basically
the uh agile manifesto
like principles over process. There is
this goes back to something we brought
up. I think even in this specific
episode is it comes down to why. Why are
you building this application? Why are
you solving this problem? What is the
solution that you're really trying to
get to? Because yes, there is a lot when
you talk about a methodology, there's a
lot of rules, for lack of a better term,
rules or guidelines on how to get there.
But the bottom line is you need to get
there. It's just like, you know, you can
jump in a car and go from one end of a
country to another. And there's a lot of
different ways you can go and some are
going to be better than others and cost
more or less and things like that, but
the goal is to get to the other end of
the country. It's not necessarily that,
hey, we turn left here instead of right
and things like that. And I think that
is something that I I too often I have
been in situations where people get
caught up in the methodology side of
stuff and are not thinking about we
still have a we have a goal that is not
serving the methodology. It's actually
serving our customer. thoughts on that?
Yeah. So,
it's really funny the principles over
practice. You know, what are you
building? Why are you building this?
It's when you start out on a project or
start out on the journey, you kind of
have a end goal in mind. You kind of
have an idea. But the problem is as you
go through the project,
either customer expectations change,
requirements could potentially change,
and you might lose yourself in the weeds
versus where you're going. You could get
distracted. It it's uh that constant
example we throw out is, you know, why
is this button purple? Why are you
spending hours on a color when the
application isn't done? It it it's you
know
you got to ask yourself is what I'm
working on working towards the goal or
am I just working basically am I being
busy to be busy am I staying on task am
I working towards something um we run
into that all the time and it that's one
of the quicst things it it's almost like
you know the the multitask thing it's
like you can't really work on multiple
multle tasks simultaneously.
You can perceptionally wise work on
multiple things at the same time, but
really you're stopping your focus on one
thing to work on another. And then when
you shift to that, you're stopping your
focus on that. Now, if you say you're
multitasking and you shift from this to
this and you're still thinking about
this, then you're not giving this your
its full attention. So,
try to make sure that what you're
working on is going towards that goal.
what you're trying to build and not
getting sidetracked in the weeds on
something that is important but maybe
not important now for the end goal.
Yeah, it's just like red tape anywhere.
It can be is it you know you can get the
process can be what you're serving as
opposed to the customer and the the end
product. Uh moving along because there's
great points there and I don't really
have much to add. Uh practical skills
developers should build communication.
Learn to ask the right questions in
different frameworks. Great one. This
next one words is going to be a full
stop right after this. Documentation
agility. How to write just enough
without overdoing it. Now, this is
this is probably one of the most
valuable skills for a developer to have
is to figure out how to write enough or
actually developer uh business analyst,
project manager, scrum master, whoever's
anybody that writes tickets,
documentation, requirements,
how to put the right amount in there so
that you are covering the things that
need to be covered and you're not
wasting people's time with a bunch of
extra extra stuff, which actually goes
back to the original thing I was saying
about AI is where it was like it could
have had a much shorter answer that it
put a lot of fluff in there because
that's part of what it does. And
honestly, if you look at a lot of, you
know, blogs and stuff like that, there
is a lot of fluff in those things as
well. People are spending too much time
trying to impress people with the, you
know, the more than four-letter words
that words that they know and all these
things and write to a, you know, 12th
grade level or whatever it happens to be
as opposed to just be concise, get the
point across just like I haven't done. I
just added a whole lot of fluff right
there. It's better off to say make your
point, make it clear, and move on. It's
that simple. Thoughts on that?
The thing I'll add to that is one of the
biggest problems with documentation is
the multissources where documentation
lives. At the beginning of a project, it
should live in one place. Be it Dropbox,
one folder, whatever the requirements
gather gathered, it should go in one
place. As the project goes on, this is
one thing I I've kind of adopted over
the years. Your code document
documenting your code needs to be the
source of truth. If you're adding Java
docs or any type of comment
documentation in your project, it should
essentially go from the requirements to
the code. You should have some way of
building that with your code at the end.
So you essentially can always look at
your code and know that this is the
source of truth. If you try to jumble
the two and have a maintain a secondary
requirements document outside of your
code, that's fine. But you have to be
very rigid about because if you don't
stay on track, your code could go one
way and your documentation goes another.
But if you keep the documentation in
your code, then essentially as you make
changes, you should be updating your
documentation and then everything's in
sync.
And that is a perfect segue into a great
way to help document your thoughts about
this is to send us an email at
We appreciate your time. We appreciate
you you sitting here and walking through
these things with us. I I highly
recommend that you do a process. You
know, spend a little time with something
like this. Take some thoughts, throw
them out to one of the AI engines,
preferably a couple different AI
engines, and see what kind of stuff
comes back. Because we are getting into
a world where yes, AI can help you be
more efficient. It can help help you get
stuff done faster, but you also need to
be able to
recognize AI and some of its
fingerprints and some of the things that
it does well and the things it doesn't
do very good so that you're able to
leverage it even better and also maybe
not get caught up by somebody that's AI
generated something and you think it's
good and then you realize that no, it
actually isn't. It's going to help you
in vetting not only your own work but
that of others.
This actually is not AI generated. I'm a
real person. He's a real person as far
as I know. And our intelligence, it may
not be that great, but we are definitely
not artificial.
That being said, I'm going to wrap this
one up. Thank you again for your time.
Go out there and have yourself a great
day, a great week, and we will talk to
you next time.
Bonus material. Uh let me start with
this. I'm going to fly through there. We
only got through four. Uh, I'm going to
go through the five real quick and then
see where you want to throw something in
there. Bridging techniques translate
across teams. How de developers can
become communication bridges. Suggest
hybrid practic practices. Share
frameworks like Spotify model or dual
track agile. Uh, stories from the field.
Interview or share a story from a dev
who's thrived in a hybrid method
environment. That would be a really fun
one to try. Highlight successes failure
due to inflexibility and methodology
use. Actionable takes takeaways. Uh,
audit your team's methodology fit. Learn
one new method every quarter. Shadow or
interview someone on a different team
about their process. Suggest one small
bridging experience in your next sprint
or cycle. So, where do you want to go
with that for some bonus material? So,
I'll take it this route. Um,
one of the things that I've find useful
in a lot of bigger companies and
corporations I work with, when you have
a large team, uh, especially when you're
in like two week sprints or you're in
long drawn out projects,
take the time to do maybe bi-weekly do
like a team collab. Spend an hour
together as a team. Talk through
problems, talk through ideas,
brainstorm. Um, maybe throw out, hey,
what do you guys think of the direction
we're going? Does anyone have any new
thoughts or ideas? You can kind of do
like an open platform. Uh with that,
maybe do lunch and learns like pick a
topic and just get together as a team
and talk through uh a new technology or
a new feature or a new architecture. And
lastly, uh hackathons. get your team
together and just pick something that's
kind of been on the back burner on your
team and just sit down and spend like
two to three days on it and just throw
everything at the wall and see what
sticks and what you can come up with as
a solution. I think with those I I like
it with I I think the more you
experience the different methodologies
that you've done a project uh you've
done multiple project with them
especially different sized teams
different environments things like that
it's going to help you figure out ways
to find a best of breed out of those
because there are some there are pros
and cons to every one of them and there
are ways to mix and match things a
little bit take some of the strengths of
one and maybe adapt them into another.
Agile in particular is built to be more
like a guideline. It is not a series of
rules. So you can make some changes to
it. You can start with an agile approach
and uh take some of the things that you
liked about maybe waterfall or some of
the things you like about just a conbon
or you know some of these other
approaches that are out there and so you
can find maybe your a best fit for you.
Um, you can also find ways I think to
better do certain methodologies because
now you've seen how a problem was solved
in you know some other one and that may
open your mind and you know let you
think out of the box to maybe approach
this process and approach a little
differently with the other methodology.
As always, I think the more tools you
have, the more arrows that you have in
your your quiver, the more tools you
have in your toolbox, the more you can
realize that, you know, you don't have
just a hammer and everything is a nail
that there are a lot of different, we'll
say, we'll just use the word nuances to
get through these uh this problem
solving. And it's that's going to be the
ways that you find better, newer,
uh sometimes groundbreaking ways to get
these things done. So, take advantage of
that. I mean, it's yes, it can be a
challenge, but also uh it can be a it
can be a great way to grow because
you'll be exposed to a lot more in a
shorter period of time. That being said,
we're going to wrap this one up. We're
coming back. We're going to continue
this. We're going to take the the next
episode's topic and we're going to throw
it out to AI and see what it says. And
it's going to say it's brilliant because
it always says nice stuff to us. And if
it doesn't, then we're going to find
we're going to watch that one really
close because then obviously it's gone
evil on us. And watch out, Skynet is
right behind it.
As always, you shoot us an email, but
you can also hit us up at developer onx.
We have a Facebook page. You can go to
developer.com. We have got so much stuff
out there. Whatever your topic is,
whatever your language is, whatever
environment is, I can just about
guarantee we've got stuff out there that
can help you. Whether it's at a beginner
level or some specific problems, uh,
common problems that are solved in those
languages and those environments,
including things that are business
problems. We have spent a lot of time
with some of our uh some of our mentor
classes. We've talked about some of the
the business problems that out there.
We've had several past seasons of
developer podcasts where we've talked
about things that were common business
problems and challenges. And of course
the interviews I always go back to those
those were those are just a gold mine of
information. uh we talked to a lot of
excellent uh entrepreneurs and people
that are very, you know, top of their
field and there's always some great
advice that came out of it. So feel free
to check that stuff out. As always, you
know, let us know if you have any
questions. We would love to get your
feedback and we will wrap this one up
and we will get back to you next time
around. Go out there and have yourself a
good one.
[Music]