Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche explore how developers and teams can improve collaboration in software development to boost productivity, reduce tech debt, and deliver better software.
We dive into AI-backed insights on what true efficiency means—from solo developers to teams of 10+. Learn how to overcome common bottlenecks, improve your code review process, avoid testing paralysis, and implement Agile practices that actually work.
💡 Topics Covered: • Defining real efficiency beyond speed • Tips for solo developers to collaborate with tools and future selves • Small team collaboration with Agile, standups, and shared environments • Code review SLAs, requirement clarification, and CI/CD pipelines • Avoiding burnout, rework, and context switching
🎯 Whether you’re freelancing, managing a dev team, or leading engineering operations, these proven strategies will help you build better collaboration habits and workflows.
🔔 Subscribe for more developer-focused content every week!
📌 Visit the blog recap: https://develpreneur.com/improving-team-collaboration-in-software-development/
#SoftwareDevelopment #TeamCollaboration #AgileDevelopment #DeveloperProductivity #DevOps #SoloDeveloper #BuildingBetterDevelopers
Transcript Text
[Music] that and get this like lined up a little bit like that. Head straight there. Let's see there. Center myself a little bit. Boom. All right. Yeah, all you guys are catching all this behind the scenes stuff. Isn't this a This is how we pull off such an incredible podcast is a lot of like aligning ourselves with cameras and stuff like that because we don't have, you know, makeup people and all that kind of stuff to do all of this. We just got to figure it out just like we're going to do with this episode. We're going to jump into this one. Maximizing efficiency in software development, individual, small, and large teams. This uh be interested to see what it has to say for this one. Let's see. Uh, interesting enough, it didn't start with like that's an incredible topic. So, maybe it's getting bored. We'll see what happens with this one. See how it goes. But we're going to dive right in. Three, two, one. Well, hello and welcome back. We are building better developers. We are developer. We are with AI this season. We're taking a prior season. We're going through the topics and we're basically just kicking those topics into AI and we're discussing what it tells us would have been great things to talk about. Sometimes we get exactly what we talked about. Sometimes we get stuff that is out there. But guess what? We talk about it this time around. So, we're going to see what happens this time around. First, I'm going to introduce myself. I am Rob Broadhead, one of the founders of Developer, also the founder of RB Consulting, where we help you do technology better. We sit down with you. We learn what your business is. What's your secret sauce? What are your, you know, your pros and cons? What are your good things, your bad things, the positives? What are the challenges and the pain points? What kind of technologies do you have? And then we take our knowledge of technology and business and look at ways to allow you to help you to guide you to do it better. Whether it's through simplification, automation, integration, innovation, we sit down and find you a way to go forward. work. Start with the technology assessment. Figure out where you're at, where are we starting our journey, get a road map, where are we going to go and how are we going to get there. That's our road map. And then we're going to either point you to the places you can go to execute it yourself or we're going to work with you to execute on that road map as well. Good thing, bad thing, good thing, bad thing, bad thing. Couple weeks ago, wife gets a call out of the blue, son got into a car accident and it was one of these where it was like, okay, uh, what's going on? What's happened? Things like that. The good thing is nothing happened to him. This is a combo. Cuz there's a bad thing. It was a hit and run. The good thing is the first thing that my wife said, Natalie comes in and says, "You know what? Take a picture of all of the cars including their license plate." So my son gets out of his car within the first, I don't know, 30 seconds, 60 seconds, starts snapping pictures and he gets the picture of the license of the person that is driving away. So they get caught and they are going to, you know, it's hit and run and uh they're going to their insurance is going to cover all this stuff. So good thing, bad thing, good thing, bad thing. There's a couple of those in there. Sometimes it's nice to have somebody that can like think on the, you know, during a a season or a session of of stress and be like, "Hey, take a picture of the bad guys before they get away." Don't have to take a picture of the bad guy on the other side because he's on video. If you've never checked us out on the developer channel on YouTube, go for it. But first, Michael is going to introduce his bad self. Hey everyone, my name is Michael Malash. I'm one of the co-founders of building better developers, also known as developer. I'm also the founder of Envision QA where we help companies unlock their software potential through a comprehensive software quality assurance assessment review and test services. We help you discover how assessing all the areas of your software development teams from sales to QA can ensure customer satisfaction and improve the software quality right from the initial conversation with your users. We don't just do that. We also help with assessments. We help through you actually walk through your applications, do a full assessment of your software stack and understand your processes and procedures within your company to make sure that the you have the right software working for you, not you working for your software. Good thing, bad thing this time. Uh it's kind of one and the same. Um, I am a bit of a gadget geek and a project I'm on, I we had to go buy a new uh printer for them uh to print labels for this particular project we're on. I've never worked with this before, but it is a new gadget. So, I'm like really looking to get my hands on it. Um, but the bad side is I have to figure out how this works under a deadline. So, that's kind of the good and bad. I'm going to have a lot of fun with this, but it's going to be a little stressing in the process. But, you know, hey, that's what gadget geeks are all about. You know, if it's not a Raspberry Pi, it's a phone. You know, if you like gadgets, you know what I'm saying? So, this episode we're going to talk about, we're going to spit out to AI and see what it spits back at us. Maximizing efficiency in software development, individual, small, and large teams. Now, one of the things I'm noticing as we're going through this is that there was probably some AI involved in creating the topics that we the names of the topics that we did back in the day. So, it's really interesting because it's almost like back when you used to tell uh Alexa to act something to Google and then Google would ask it back and forth and the next thing you know they're getting into a an AI war. Well, this is maybe what we're going to get into. Now, this this topic, we threw it in there. And interestingly enough, it didn't get all friendly and like, you know, rosy cheicked and sunshine and rainbows. It just got right into it. It's like, you know what? Okay, this is what we're going to do. We're going to talk about how developers and teams of all sizes can improve efficiency, blah blah blah. Let's get into its points that it recommends. The first thing is define efficiency in context. what efficiency really means in software development. Not just speed, but value delivered per effort. Avoiding rework, tech debt, and burnout. Efficiency is not the same as rushing or cutting corners. Now, we didn't actually define efficiency, I don't think, at the time. We have definitely talked about some of these topics along the way, but I think this is probably the this is like the the nut of it basically that I think I'd like us to talk about a little bit is efficiency where you're avoiding rework, tech debt, and burnout. So, it's it's really a couple of different very big areas. It's rework. So it's doing the solving the problem correctly, not having to go not having bugs, not having to go back and change the requirements or get clarity on the requirements or anything like that, but getting the product the the problem solved the first time, for lack of a better term. Now, tech debt is the kind of it's like not only getting it solved, but getting it solved in a way that you're not saying, "All right, we're just getting it done right now, but we know there's some other things that we want to do." It's actually getting it solved essentially the right way the first time. And then burnout is yes it's you know burnout of your resources of your developers but I also think of it in this ska this a little bit more of like without going through all the resources you need to not making your developers have to you know stay up 24 hours straight not having to you know not pay people or uh you know cut your budget or all these other things. So it's really you know time quality and resources. This is really looking at efficiency in all of those areas. And so I'm going to throw this out to you and let you talk to any one of those to get us started on this. Sure. I was trying to pull up the uh podcast episode to see some of the highlights we did. Um, interestingly enough, a lot of the things we talked about, and I I'll touch on this, is the main point of this episode before was to really talk about efficiency of your team, like individual developers, small teams, large teams, how they work together, how to make them work efficiently together. And interestingly enough, a lot of it was, you know, um talking about like code committing, you know, is everyone keeping track of their code? How are people communicating? But the main thing is, you know, define efficiency and the the contracts within your team. These are those points, right? Commit code regularly, commit your code, create re uh reproducible builds like we were working on today. create containers that you can share with your teammates so that you don't you have a smaller time for bringing new team members up to speed. You know, it it's all about efficiency. You want your teams to work faster. You want them to work better and you want them to basically be working and not have be constantly blocked, hitting roadblocks uh and kind of arguing amongst themselves across technology. You want to make sure things run smoothly and efficiently. Now they move right and I think we're going to talk into some of these as I'm I'm looking at some of the other things. So they break it this yeah you these results come back they're going to break it into a couple areas. So first they talk about working solo. So the independent developer so this is being efficient as a soloreneur solo developer. So the challenge is wearing many hats you know dev QA ops support. Uh there's not you don't have any feedback loops. It's it's just you in your head. Uh and they have some efficiency tips. use opinionated frameworks, which I've never heard that phrase before, which is pretty interesting. Uh, for example, Rails Next.js to reduce decisions. So, I like that because some of these uh a lot of times we talk about the the negatives of a framework being too restrictive, too constraint, having too many constraints that you have to solve the problem this way. But the bonus of that is that you don't have to think about do I do it this way, do I do it that way? Uh, one of the things that I've I just was playing around with like building a new little application the other day and I wanted to do it in Python because I was like, "All right, I want to do it in Python because I had a couple things set up for it already." But then it was like, "Do I do Django? Do I do Flask?" And there's things like that. I like, "Okay, which way do I go?" And then what do I do for the front end? Do I do just like straight HTML? Do I do React? Do I do, you know, do I maybe instead say, "Well, I'm going to do like Django on the front end, but I'm have a node on the back end for an API." There's there's a lot of different ways you can go with these things. And that's going to take you time if you're going to sit there and think about it. So these these tools that are much more like this is the way will help you get there faster. Now automate everything possible. This is we talk about this all the time, but as a single person, as a single developer, um I find this a really big challenge is that you you just you don't feel like you have the time or at least I don't feel like I have the time to step back and go automate it until I've done it several times. I'm like, I am wasting time on this. So instead of spending, you know, five minutes now and then five minutes tomorrow and five minutes the next day, I'm going to go ahead and spend 15 minutes right now and just take care of it for the way out. But you have to, you know, it's one of those that you I think you're a little biased in your calculations of what kind of time are you spending and what kind of time are you going to save yourself. It always helps to have that second set of eyes. Uh set time box goals with clear deliverables. that is so crucial especially as an independent especially as a side hustler and then uh use journaling tools like obsidian or notion to track progress. So I think also other tools out there like you know your trellos your asas your jeras all of those things those kinds of things are I think just as critical for a single developer as they are for a team. So covered a lot of ground there where do you want to tackle uh efficiency for the solo developer? So efficiency for the solo developer. Uh one thing I don't think you really touched on but it's kind of we talked about many times is uh make sure you have good uh like code commit. Make sure you keep your the quality of your code clean. you know, make sure you that you have good um code commit uh documentation uh that you keep track like you said using Jer things like that to make sure that what you're working on is tracked that you have snapshots of what you're doing so you can roll back and then automate automate automate automate. Get that continuous integration pipeline going as fast as you can because the less time you have to spend maintaining your pipelines, getting your builds out there, the more time you can focus on getting the work done and keep moving forward on features. The other thing is even as a solo developer, it may still be worthwhile to build those containers for your development environment so that you can drop something and build it right back up very quickly versus oops, I broke my database. I have to spend 3 days rebuilding my database on my machine. Whereas if you had a container for that, all you would have to do is drop the container and bring it back up. So starting a project or starting out as a solo developer, you might not think of these things, but these are things that if you can kind of plan ahead, what am I going to need for what I'm working on? What does this project need? And you kind of lay out the things that you can automate or structure in such a way that you have minimal downtime. Yeah. I and I think that the that is I was I was taken back to a project I did years and years ago where I was I was the only developer. It was uh it was as a consultant. It was for a company but basically rebuilding an existing application and it was uh I was given the time and the the bandwidth to you quote do it right. And it was really comforting to have a broad range of unit tests and automation so that when I would go through I didn't at that point it was a it was a locally developed application. It was old Tomcad application and stuff like that. But the nice thing was that I would do you know build I had and it was automated scripts that could build it run all the unit tests and make sure that it you know everything tested out and then it would actually like you know deploy it out and then hit all the pages. So you would get your initial, you know, cash hit. And it was a great way for me to be able to save time because instead of me having to, you would do that like if I was going to go to lunch or if I was going to go take a break for a few minutes or something like that, then I could kick that off. I could have all that stuff run and I could do the testing in the background while I was doing something else. So having those automations helped a lot. Uh, another thing is containers. I think when you're doing a solo project, especially one that you will probably get pulled away from, it is very very helpful to have containers for that, to have everything built into it. Particularly, there's going to be things like data. I don't know how often that I've had um issues where I've got a database that I was working on years, you know, a year ago and I forget where was I at. Uh maybe some of the data has aged out and things like that. So having a a fresh build process and things like that you can do and the documentation around it is really valuable because you don't want to be cussing at yourself six months ago. You're like man I wish I'd really documented this piece. There's a lot there but let's move on to the uh small teams as they say there's two to 10 developers. So strengths, fast communication, tight feedback loops, um resource the challenges or resour resource limitations, informal processes can cause confusion as the team grows. Uh efficiency tips, daily standups, but keep them short and focused. Shared development environments to reduce setup friction. Adopt lightweight agile or conbon boards. Invest early in testing and CI/CD to avoid scaling pain. Leverage pairing or mob programming strategically for knowledge sharing or onboarding. I'm going to take that last one is I think that that is uh as someone who has been in a lot of different development environments and particularly in the last 10 years or so done a lot of you know siloed it's just me even if I've got a you I may have Slack and and other people around but I'm in a in a room by myself effectively doing coding it is very different from being in uh the bullpin setup or some of those kinds of things where you've got people around you you can lean back at any second and say Hey, I'm running into this problem. And I think the people that that embrace the technology that we have out there like Slack and things like that, message boards to be able to quickly throw something out to the team and have them respond back and say, "Oh yeah, I ran into that thing and you know, this is how I solved it." Or, "Hey, let me help you out with that." Or, "Hey, let's jump on a call real quick and let's see if we can walk through it." The getting lost in your own head and getting stuck in your own mindset of how you're solving a problem is probably one of the biggest challenges that we have. Uh honestly, it's one of the things I've liked about AI in the last 6 months is because I will throw something out at AI. It'll give me a completely different direction. Sometimes it's useless. Sometimes it's very useful, but at least gets me off of the track. You know, we get on this track like, "Okay, this is this is a bug. This is the problem. This is how I fix it." and then we realize that it's not the bug or it's not the problem or it's not how we fix it, but we're stuck in that track already. Other people can help us out in a nice nice size team, you know, two to 10, it's actually really good because you've got somebody available, but you're not going to be overwhelmed by the team. That's my two cents. Your thoughts? So, I'm going to take the one you always talk about. I'm going to go with agile. So for small teams 2 to 10 and even larger teams but agile as Rob has preached for many many years is a great way to manage teams and ensure that everyone is on the same page with the project. It also helps avoid duplication of work where you don't have two people in a silo working on the exact same thing at the exact same time. The other thing that this really helps that I like about the agile approach is it also helps share information across teams. I could be working on one thing and say, "Hey, I ran into this problem, but this is how I solved it." And someone else could chime in and say, "Oh, hey, can you get with me after this standup?" Because that is exactly what I'm running into. How did you solve it? And it it it is a great way to kind of break down your projects into smaller sprints and really take small chunks out of the code instead of trying that big waterfall approach where you try to do everything at once. This is also very good for testing of the application because hopefully you have a tester on your team, but if you don't, the other thing that you can kind of work through is someone's got to be testing the code. be it the manager, the project manager, there's UAT as you are going through these sprints, you can work talk to these people and understand that hey in my standup I'm running into this. I'm doing this but the other person can say hey wait that's not quite what we need for the requirements or how is that going to work for the user. So it's very good for collaboration. It keeps everyone on the same page and it keeps your project from going too far off track. It can still go off track, but at least you go off track together instead of in a silo. Yeah, we all go over the edge of the cliff at the same time. That's so not really comforting. Anyways, let's move along. Uh the next one I want to I'm going to skip the the large teams uh mostly just for lack because of time because the next one I talked about is common bottlenecks and bottlenecks and solutions for all sizes of teams. So it has a nice little four bullet points. So, one, and these I think you probably all will be able to relate to in some way. Slow code reviews. Use review SLAs's and rotate reviewers. Unclear requirements. Always start with a 15minute clarification huddle. Testing paralysis. Use test pyramids. Prioritize integration tests that catch regressions and context text switching. Batch work. Blockout focus time hours. So, I'm going to let throw this one right back to you is where where do you want to go with that? sort of your favorite that every size team seems to struggle with. So it's very interesting. Uh all teams I think wow those bullet points it testing paralysis seems to be the biggest one for me. It it's like especially early on with projects cuz you don't have something there. you're still building the foundation for what you need to test. It really relies on the developers to test their code, but they're too busy trying to get the foundation in place to get something stood up that they can physically see and physically test. So, a lot of times early on, either testing is really good or it's really lax. And then when you get into the more midsection of the development uh of the project, you run into problems where there's not enough testing, things break, you make one code change here, break something here. Um, so that test paralysis is really something that kind of is personal where you you really need to be testing your code from the beginning. As you get something stood up, as your teams get something a little more sustainable, you can actually stand up that server or you can actually run the application on a desktop. At that point, you need to start having regression testing or at least user acceptance testing. And then once you start deploying to a QA server, you need to start having uh that more refined regression testing or smoke testing of that system. I am going to I think I want to talk about the blocking out focus time hours. Um because even with small teams, I've seen this particularly in agile. This can be a problem because you have your daily standup. Um sometimes you'll have a lot of breakout meetings and stuff like that. you'll have a meeting here, a meeting there, and the next thing you know, you've you've ended up essentially breaking up your day by a bunch of meetings and you're not able to get focused time to get stuff done. This really becomes an issue with sprints when you're getting to the end of a sprint and you've got that mad dash, as Michael sort of implied it, where you're like getting all your code committed, but then QA is doing all this testing and there's this frenzy of testing and there's a frenzy of feedback that comes at it and so the developers are trying to like scramble to get all their bugs fixed and everything just goes haywire for a couple of days and it's hard to keep moving forward through that. Now, that's not, you know, obviously it's the end of a sprint, so it's not every part of a sprint, but I think there definitely should be some times, whether it's waterfall, whether it's agile, however you approach it. And no matter the size of your team, that you have some hours that are just like, we're going to go get work done. Now, it may be that you're, you know, the lead of a team and you've got to deal with a lot of other teams and you've got to go be busy all the time. That's fine. Make sure that if you do so, you're not dragging your developers into everything. make sure that you can, you know, that's part of what your job is is to deflect from them so that they can go get their job done. You're going to go, you know, listen to all the people you need to listen to, get the stuff, communicate it back to them, and do that in a way that is efficient instead of them having to sit there with you. Now, you can do stuff, and this is something we've done. You can do death by recordings is you can record everything and tell people, "Here you go. Let's go to it. Uh, go listen to the recording and you can grab whatever you want." Don't do that to your teams, particularly if you're like a, you know, a lead and you've got developers, things like that. Should distill that out. Give them the bullet points that they need to know and then move on. Don't make them sit through that for a while. A pro note is if you have to sit through it, kick the speed up to like 1.5 or two, however fast you can do stuff, and you can always pause as you go through that. Trust me, it makes very long recordings a lot faster to go through, and it will allow you to like jump through to stuff. You can also use AI. A lot of times it will give you summaries and synopsis and you can take those and maybe go figure out where in the recording if you need to actually get specifics. Uh but also it allows you to get an outline a lot of times. So there are a lot of ways there are a lot of things that as a team grows that are small but then they become very big very quickly because you add more people and so the little problems become bigger as you go. And so I think that's something you have to watch out for and it's one of the things that it talks about as far as principles of scale. But we're not going to get into that because we are bumping up against our time. It's like, you know, ready for a commercial break or something like that. So we've got to wrap this one up. We will come back next episode and we are going to continue this because we're getting a lot out of this as well. I hope you guys are. As always, shoot us an info at developure email. You can send us an email at infodelvelopeneur.com. I'm sorry I mixed all that up. didn't come out quite right. It was one of those like word scrambles. Send us an email. Let us know what your thoughts are. What are some of your recommendations? What are some things that you'd like to see us talk about? Uh maybe some things that we want to throw at AI as we get further into this future episodes, future seasons. Uh if you want to if if you're an interviewer and you want to talk to us or if you know somebody you would like us to interview, we are open to that as well because hey, we're agile just like that. Just just because we can be. That being said, I want to just 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. So, let's see. Bonus stuff. Oh, it even has bonus content ideas. So, I'm going to get that. Actually, I have two ideas that I didn't get to in the podcast. Cool. one which started coming to mind when we were talking about larger teams and it totally went out the door as he went through those four bullet points is crossrain your team. Make sure that you cycle your developers on different features of your program. If you just have one person working on database and one person working on UI, if that UI person quits, who's going to support your UI? Just make sure you're always rotating your developers across different features. Even if they're not skilled in UI and they're better at backend, still put them in UI. Give them smaller tasks or give them a larger task, but give them more time to work on the task and maybe pair programming with the other developer. That is very crucial to make sure that your team is healthy and you have the coverage in case someone wants to go on vacation. Um, also it makes sure that everyone on the team can support customer issues or bugs that come in. So you're not relying on one person to always be that firefighting person and have them burn out. Second thing was code reviews. I've been in many, many projects and code reviews can be very contentious. They can be ignored. People just go in and just click done. They don't even review it. You have other people that go in it with such a fine tooth uh pen that people are so frustrated by the time they get the reviews from this person um that it's like go away. Uh but a lot of times and then you have those that are in the middle where they give very good feedback. They give very detailed um advice like oh hey maybe this is outside of our framework or this is not quite the architecture we want to use. Um, other things could be simply, hey, you're not following the code standards for naming conventions. Make sure that you're following this or you're missing this comment. Or something even more critical. It could be, hey, I don't think this loop is working the way you think it is. You might have a infinite loop or you might want to switch the logic that's not quite right. These are benefits of doing code reviews. Code review is not just hey someone just give me a green check mark on my code saying hey it looks great move on. Code reviews are there one for review so your other teammates know what's changing in the code so if they don't touch that section of code for 6 months they're at least aware of what's going on. Two you catch general uh typos or just logic issues that might just be missed uh just because you're quickly going through it. It may work for your solution for your problem but may break something else just something you don't think about or didn't even know about. And then lastly, uh if you are the uh coder, take the code reviews with a grain of salt. Submit your code, walk away. Do not look at that code review for a day at least or at least a couple hours. If you watch those code reviews as they come in and the comments, you might get frustrated and just get angry. That's not the point of this. And if your reviewers are giving you that type of feedback, you need to come together as a team and say, "Hey, code reviews are a safe space. This is to work through the problems and make sure the code is right, not how badly can I make myself look better than you because I found a problem in your code." Yeah, there's code reviews are I've seen them done. Well, there's a a wide range of ways they are accomplished. They are done. and they're addressed. They are a great way for cross trainining. I will I want to I guess sort of piggyback off the crossraining idea. This is something that a lot of times we we put people on certain tickets and a particular certain task because they're good at it. That's their area and that is the, you know, a sense the most efficient way to get there. Put the person that that's their strength on it so they can get it done. The problem is what happens if there are too many uh things of tasks of that nature that have to be done because now they become a backlog or what happens if they leave or they're hit by a bus or you know there's a lot of different things that can go on that can change the the balance of the team and the team that you started out with where everybody had the right amount of work to do and all that kind of stuff. it was do going well and now suddenly the balance changes and things go off the rails. I think I like to relate it back to I'll go to a sport like a nice little sports analogy way back in the day. One of these things that we did as a hockey team is early in the year you'd make sure that people played different positions. You would play them in roles that they wouldn't normally have gotten because maybe they're not that good or maybe they're really good and they wouldn't normally have to do it. And it could cost you like early in the se there could be games that you they were close they needed to be or that you lost that you could have won. But fast forward to the end of a season and now you've got a everybody has come up. You've got people that can cover for each other. And so if you have an injury, if you have somebody gets sick, if you have somebody's just tired, you can last longer. You now have a team and not just a bunch of individuals. And it makes a world of difference. And that is included in solving problems because if you've got your database guy always does database and your front-end guy always does front end and your designer always does design and you know your JavaScript person always does JavaScript, you're going to have an imbalance. You're not going to be able to have the idea of like all hands on deck, everybody just jump in and start grabbing tickets and get stuff done because people aren't going to be able to. And this is a hard lesson to learn sometimes because there's stuff that people will grab things, you know, they'll work on things that yes, they're going to do it a little faster than somebody else, but somebody else could do it. And so maybe somebody else should do it so that you're expanding that knowledge that you do have a team that you're developing, bringing everybody up instead of just letting everybody get better within their specific silo. Uh before we jump out, I do want to go ahead. I teased that they have this. One of the other things was principles at scale was one of the things that AI threw at us and I just want to go through these because you know real quick because there are some good ones. Feedback loops shorten them code customer production any kind of feedback loop the sooner you can get the message the information back the better. Automation we talk about this build pipelines that scale with you. Whatever it is, however you do it, make sure that as you get further along that you are still not having to spend too much time doing your builds and you know getting doing to anything that's not writing code, verifying code, knowledge sharing, wikis, code comments, brown bags, we talked about this is same thing as a crossing. Make sure that as many people on the teams as possible know as much as they can about what's going on. Yes, it is sometimes timeconuming. Yes, it is sometimes very frustrating, but it will pay off in the long run. I promise you measurable improvement. This is something that is really a struggle for a lot of teams particularly smaller ones is using like dorometrics or delivery KPIs or something like that. Have some way to measure what you're doing. Now it is very difficult. I know that there are u you know you could use points and velocities and things like that that that happen a lot in agile and those things are you know squishy as you start out and as you get further along in a team you can at least evaluate those uh estimation I think from a developer point of view is one of the most important things to do is make your developers estimate everything they stink and do and then hold them to it and by hold them to it I mean just when they get done say how did that work out for you help them to understand what their particular estimation style is, whether they need to take their estimate and multiply it by 10 or whether they, you know, overestimate, which no developer ever does. Um, you that's going to help everybody get better because you're going to be more realistic about what you can cover and how fast you can cover that. That being said, we are I'm done covering this. This is as far as I can cover it. We can't cover anymore. So, we are going to call it an episode. Call it a night as it were. We will be back. We are just getting started in the season. Uh loving this so far. We'll see. AI has like gotten a little cooler towards us this time. So, we'll see how it goes as we go into the uh the remaining episodes and uh we'll just see where we go from there. We may break it up with a couple of uh interviews along the way as well. We're still looking at that. Uh definitely some fun ones that are out there. We'll see how it goes. As always, love to hear your feedback. Any way that you hear us, whether it's wherever you're listening to podcasts, if you're out there on YouTube, which you're watching us right now, you're probably on YouTube, leave us a comment, leave us some feedback. You can, you know, thumbs up, rate us, whatever it is. But really, it's the comments that we really want to have. We want to have that feedback. What do you like? What don't you like? Help us out. Help us help you, all of us build a better podcast for building better developers. Go out there and have yourself a good one. And we will talk to you next time. [Music]
Transcript Segments
[Music]
that and get this like lined up a little
bit
like that.
Head straight
there.
Let's see there. Center myself a little
bit. Boom. All right. Yeah, all you guys
are catching all this behind the scenes
stuff. Isn't this a This is how we pull
off such an incredible podcast is a lot
of like aligning ourselves with cameras
and stuff like that because we don't
have, you know, makeup people and all
that kind of stuff to do all of this. We
just got to figure it out just like
we're going to do with this episode.
We're going to jump into this one.
Maximizing efficiency in software
development, individual, small, and
large teams. This uh be interested to
see what it has to say for this one.
Let's see.
Uh, interesting enough, it didn't start
with like that's an incredible topic.
So, maybe it's getting bored. We'll see
what happens with this one. See how it
goes. But we're going to dive right in.
Three, two, one. Well, hello and welcome
back. We are building better developers.
We are developer. We are with AI this
season. We're taking a prior season.
We're going through the topics and we're
basically just kicking those topics into
AI and we're discussing what it tells us
would have been great things to talk
about. Sometimes we get exactly what we
talked about. Sometimes we get stuff
that is out there. But guess what? We
talk about it this time around. So,
we're going to see what happens this
time around. First, I'm going to
introduce myself. I am Rob Broadhead,
one of the founders of Developer, also
the founder of RB Consulting, where we
help you do technology better. We sit
down with you. We learn what your
business is. What's your secret sauce?
What are your, you know, your pros and
cons? What are your good things, your
bad things, the positives? What are the
challenges and the pain points? What
kind of technologies do you have? And
then we take our knowledge of technology
and business and look at ways to allow
you to help you to guide you to do it
better. Whether it's through
simplification, automation, integration,
innovation, we sit down and find you a
way to go forward. work. Start with the
technology assessment. Figure out where
you're at, where are we starting our
journey, get a road map, where are we
going to go and how are we going to get
there. That's our road map. And then
we're going to either point you to the
places you can go to execute it yourself
or we're going to work with you to
execute on that road map as well. Good
thing, bad thing,
good thing, bad thing, bad thing. Couple
weeks ago, wife gets a call out of the
blue, son got into a car accident and it
was one of these where it was like,
okay, uh, what's going on? What's
happened? Things like that. The good
thing is nothing happened to him. This
is a combo. Cuz there's a bad thing. It
was a hit and run. The good thing is the
first thing that my wife said, Natalie
comes in and says, "You know what? Take
a picture of all of the cars including
their license plate." So my son gets out
of his car within the first, I don't
know, 30 seconds, 60 seconds, starts
snapping pictures and he gets the
picture of the license of the person
that is driving away. So they get caught
and they are going to, you know, it's
hit and run and uh they're going to
their insurance is going to cover all
this stuff. So good thing, bad thing,
good thing, bad thing. There's a couple
of those in there. Sometimes it's nice
to have somebody that can like think on
the, you know, during a a season or a
session of of stress and be like, "Hey,
take a picture of the bad guys before
they get away."
Don't have to take a picture of the bad
guy on the other side because he's on
video. If you've never checked us out on
the developer channel on YouTube, go for
it. But first, Michael is going to
introduce his bad self. Hey everyone, my
name is Michael Malash. I'm one of the
co-founders of building better
developers, also known as developer. I'm
also the founder of Envision QA where we
help companies unlock their software
potential through a comprehensive
software quality assurance assessment
review and test services. We help you
discover how assessing all the areas of
your software development teams from
sales to QA can ensure customer
satisfaction and improve the software
quality right from the initial
conversation with your users. We don't
just do that. We also help with
assessments. We help through you
actually walk through your applications,
do a full assessment of your software
stack and understand your processes and
procedures within your company to make
sure that the you have the right
software working for you, not you
working for your software. Good thing,
bad thing this time. Uh it's kind of one
and the same. Um, I am a bit of a gadget
geek and a project I'm on, I we had to
go buy a new uh printer for them uh to
print labels for this particular project
we're on. I've never worked with this
before, but it is a new gadget. So, I'm
like really looking to get my hands on
it. Um, but the bad side is I have to
figure out how this works under a
deadline. So, that's kind of the good
and bad. I'm going to have a lot of fun
with this, but it's going to be a little
stressing in the process. But, you know,
hey, that's what gadget geeks are all
about. You know, if it's not a Raspberry
Pi, it's a phone. You know, if you like
gadgets, you know what I'm saying?
So, this episode we're going to talk
about, we're going to spit out to AI and
see what it spits back at us. Maximizing
efficiency in software development,
individual, small, and large teams. Now,
one of the things I'm noticing as we're
going through this is that there was
probably some AI involved in creating
the topics that we the names of the
topics that we did back in the day. So,
it's really interesting because it's
almost like back when you used to tell
uh Alexa to act something to Google and
then Google would ask it back and forth
and the next thing you know they're
getting into a an AI war. Well, this is
maybe what we're going to get into. Now,
this this topic, we threw it in there.
And interestingly enough, it didn't get
all friendly and like, you know, rosy
cheicked and sunshine and rainbows. It
just got right into it. It's like, you
know what? Okay, this is what we're
going to do. We're going to talk about
how developers and teams of all sizes
can improve efficiency, blah blah blah.
Let's get into its points that it
recommends.
The first thing is define efficiency in
context. what efficiency really means in
software development. Not just speed,
but value delivered per effort. Avoiding
rework, tech debt, and burnout.
Efficiency is not the same as rushing or
cutting corners. Now, we didn't actually
define efficiency, I don't think, at the
time. We have definitely talked about
some of these topics along the way, but
I think this is probably the this is
like the the nut of it basically that I
think I'd like us to talk about a little
bit is efficiency where you're avoiding
rework, tech debt, and burnout. So, it's
it's really a couple of different very
big areas. It's rework. So it's doing
the solving the problem correctly, not
having to go not having bugs, not having
to go back and change the requirements
or get clarity on the requirements or
anything like that, but getting the
product the the problem solved the first
time, for lack of a better term. Now,
tech debt is the kind of it's like not
only getting it solved, but getting it
solved in a way that you're not saying,
"All right, we're just getting it done
right now, but we know there's some
other things that we want to do." It's
actually getting it solved essentially
the right way the first time. And then
burnout
is
yes it's you know burnout of your
resources of your developers but I also
think of it in this ska this a little
bit more of like without going through
all the resources you need to not making
your developers have to you know stay up
24 hours straight not having to you know
not pay people or uh you know cut your
budget or all these other things. So
it's really you know time quality and
resources. This is really looking at
efficiency in all of those areas. And so
I'm going to throw this out to you and
let you talk to any one of those to get
us started on this.
Sure. I was trying to pull up the uh
podcast episode to see some of the
highlights we did. Um, interestingly
enough, a lot of the things we talked
about, and I I'll touch on this, is
the main point of this episode before
was to really talk about efficiency of
your team, like individual developers,
small teams, large teams, how they work
together, how to make them work
efficiently together. And interestingly
enough, a lot of it was, you know, um
talking about like code committing, you
know, is everyone keeping track of their
code? How are people communicating? But
the main thing is, you know, define
efficiency and the the contracts within
your team. These are those points,
right? Commit code regularly, commit
your code, create re uh reproducible
builds like we were working on today.
create containers that you can share
with your teammates so that you don't
you have a smaller time for bringing new
team members up to speed. You know, it
it's all about efficiency. You want your
teams to work faster. You want them to
work better and you want them to
basically be working and not have be
constantly blocked, hitting roadblocks
uh and kind of arguing amongst
themselves across technology. You want
to make sure things run smoothly and
efficiently.
Now they move right and I think we're
going to talk into some of these as I'm
I'm looking at some of the other things.
So they break it this yeah you these
results come back they're going to break
it into a couple areas. So first they
talk about working solo. So the
independent developer so this is being
efficient as a soloreneur solo
developer. So the challenge is wearing
many hats you know dev QA ops support.
Uh there's not you don't have any
feedback loops. It's it's just you in
your head. Uh and they have some
efficiency tips. use opinionated
frameworks, which I've never heard that
phrase before, which is pretty
interesting. Uh, for example, Rails
Next.js to reduce decisions. So,
I like that because some of these uh a
lot of times we talk about the the
negatives of a framework being too
restrictive, too constraint, having too
many constraints that you have to solve
the problem this way. But the bonus of
that is that you don't have to think
about do I do it this way, do I do it
that way? Uh, one of the things that
I've I just was playing around with like
building a new little application the
other day and I wanted to do it in
Python because I was like, "All right, I
want to do it in Python because I had a
couple things set up for it already."
But then it was like, "Do I do Django?
Do I do Flask?" And there's things like
that. I like, "Okay, which way do I go?"
And then what do I do for the front end?
Do I do just like straight HTML? Do I do
React? Do I do, you know, do I maybe
instead say, "Well, I'm going to do like
Django on the front end, but I'm have a
node on the back end for an API."
There's there's a lot of different ways
you can go with these things. And that's
going to take you time if you're going
to sit there and think about it. So
these these tools that are much more
like this is the way will help you get
there faster. Now automate everything
possible. This is we talk about this all
the time, but as a single person, as a
single developer, um I find this a
really big challenge is that you
you just you don't feel like you have
the time or at least I don't feel like I
have the time to step back and go
automate it until I've done it several
times. I'm like, I am wasting time on
this. So instead of spending, you know,
five minutes now and then five minutes
tomorrow and five minutes the next day,
I'm going to go ahead and spend 15
minutes right now and just take care of
it for the way out. But you have to, you
know, it's one of those that you I think
you're a little biased in your
calculations of what kind of time are
you spending and what kind of time are
you going to save yourself. It always
helps to have that second set of eyes.
Uh set time box goals with clear
deliverables. that is so crucial
especially as an independent especially
as a side hustler and then uh use
journaling tools like obsidian or notion
to track progress. So I think also other
tools out there like you know your
trellos your asas your jeras all of
those things those kinds of things are I
think just as critical for a single
developer as they are for a team. So
covered a lot of ground there where do
you want to tackle uh efficiency for the
solo developer? So efficiency for the
solo developer. Uh one thing I don't
think you really touched on but it's
kind of we talked about many times is uh
make sure you have good uh like code
commit. Make sure you keep your the
quality of your code clean. you know,
make sure you that you have good um code
commit uh documentation
uh that you keep track like you said
using Jer things like that to make sure
that what you're working on is tracked
that you have snapshots of what you're
doing so you can roll back and then
automate automate automate automate. Get
that continuous integration pipeline
going as fast as you can because the
less time you have to spend maintaining
your pipelines, getting your builds out
there, the more time you can focus on
getting the work done and keep moving
forward on features. The other thing is
even as a solo developer, it may still
be worthwhile to build those containers
for your development environment so that
you can drop something and build it
right back up very quickly versus oops,
I broke my database. I have to spend 3
days rebuilding my database on my
machine. Whereas if you had a container
for that, all you would have to do is
drop the container and bring it back up.
So starting a project or starting out as
a solo developer, you might not think of
these things, but these are things that
if you can kind of plan ahead, what am I
going to need for what I'm working on?
What does this project need? And you
kind of lay out the things that you can
automate or structure in such a way that
you have minimal downtime.
Yeah. I and I think that the
that is I was I was taken back to a
project I did years and years ago where
I was I was the only developer. It was
uh it was as a consultant. It was for a
company but basically rebuilding an
existing application and it was uh I was
given the time and the the bandwidth to
you quote do it right. And it was really
comforting to have a broad range of unit
tests and automation so that when I
would go through I didn't at that point
it was a it was a locally developed
application. It was old Tomcad
application and stuff like that. But the
nice thing was that I would do you know
build I had and it was automated scripts
that could build it run all the unit
tests and make sure that it you know
everything tested out and then it would
actually like you know deploy it out and
then hit all the pages. So you would get
your initial, you know, cash hit. And it
was a great way for me to be able to
save time because instead of me having
to, you would do that like if I was
going to go to lunch or if I was going
to go take a break for a few minutes or
something like that, then I could kick
that off. I could have all that stuff
run and I could do the testing in the
background while I was doing something
else. So having those automations helped
a lot. Uh, another thing is containers.
I think when you're doing a solo
project, especially one that you will
probably get pulled away from, it is
very very helpful to have containers for
that, to have everything built into it.
Particularly, there's going to be things
like data. I don't know how often that
I've had um issues where I've got a
database that I was working on years,
you know, a year ago and I forget where
was I at. Uh maybe some of the data has
aged out and things like that. So having
a a fresh build process and things like
that you can do and the documentation
around it is really valuable because you
don't want to be cussing at yourself six
months ago. You're like man I wish I'd
really documented this piece. There's a
lot there but let's move on to the uh
small teams as they say there's two to
10 developers. So strengths, fast
communication, tight feedback loops, um
resource the challenges or resour
resource limitations, informal processes
can cause confusion as the team grows.
Uh efficiency tips, daily standups, but
keep them short and focused. Shared
development environments to reduce setup
friction. Adopt lightweight agile or
conbon boards. Invest early in testing
and CI/CD to avoid scaling pain.
Leverage pairing or mob programming
strategically for knowledge sharing or
onboarding. I'm going to take that last
one is I think that that is uh as
someone who has been in a lot of
different development environments and
particularly in the last 10 years or so
done a lot of you know siloed it's just
me even if I've got a you I may have
Slack and and other people around but
I'm in a in a room by myself effectively
doing coding it is very different from
being in uh the bullpin setup or some of
those kinds of things where you've got
people around you you can lean back at
any second and say Hey, I'm running into
this problem. And I think the people
that that embrace the technology that we
have out there like Slack and things
like that, message boards to be able to
quickly throw something out to the team
and have them respond back and say, "Oh
yeah, I ran into that thing and you
know, this is how I solved it." Or,
"Hey, let me help you out with that."
Or, "Hey, let's jump on a call real
quick and let's see if we can walk
through it."
The getting lost in your own head and
getting stuck in your own mindset of how
you're solving a problem is probably one
of the biggest challenges that we have.
Uh honestly, it's one of the things I've
liked about AI in the last 6 months is
because I will throw something out at
AI. It'll give me a completely different
direction. Sometimes it's useless.
Sometimes it's very useful, but at least
gets me off of the track. You know, we
get on this track like, "Okay, this is
this is a bug. This is the problem. This
is how I fix it." and then we realize
that it's not the bug or it's not the
problem or it's not how we fix it, but
we're stuck in that track already. Other
people can help us out in a nice nice
size team, you know, two to 10, it's
actually really good because you've got
somebody available, but you're not going
to be overwhelmed by the team. That's my
two cents. Your thoughts? So, I'm going
to take the one you always talk about.
I'm going to go with agile.
So for small teams 2 to 10 and even
larger teams but agile as Rob has
preached for many many years is
a great way to manage teams and ensure
that everyone is on the same page with
the project. It also helps avoid
duplication of work
where you don't have two people in a
silo working on the exact same thing at
the exact same time. The other thing
that this really helps that I like about
the agile approach is it also helps
share information across teams. I could
be working on one thing and say, "Hey, I
ran into this problem, but this is how I
solved it." And someone else could chime
in and say, "Oh, hey, can you get with
me after this standup?" Because that is
exactly what I'm running into. How did
you solve it? And it it it is a great
way to kind of break down your projects
into smaller sprints and really take
small chunks out of the code instead of
trying that big waterfall approach where
you try to do everything at once. This
is also very good for testing of the
application because hopefully you have a
tester on your team, but if you don't,
the other thing that you can kind of
work through is someone's got to be
testing the code. be it the manager, the
project manager, there's UAT as you are
going through these sprints, you can
work talk to these people and understand
that hey in my standup I'm running into
this. I'm doing this but the other
person can say hey wait that's not quite
what we need for the requirements or how
is that going to work for the user. So
it's very good for collaboration. It
keeps everyone on the same page and it
keeps your project from going too far
off track. It can still go off track,
but at least you go off track together
instead of in a silo. Yeah, we all go
over the edge of the cliff at the same
time. That's so not really comforting.
Anyways, let's move along. Uh the next
one I want to I'm going to skip the the
large teams uh mostly just for lack
because of time because the next one I
talked about is common bottlenecks and
bottlenecks and solutions for all sizes
of teams. So it has a nice little four
bullet points. So, one, and these I
think you probably all will be able to
relate to in some way. Slow code
reviews. Use review SLAs's and rotate
reviewers. Unclear requirements. Always
start with a 15minute clarification
huddle. Testing paralysis. Use test
pyramids. Prioritize integration tests
that catch regressions and context text
switching. Batch work. Blockout focus
time hours. So, I'm going to let throw
this one right back to you is where
where do you want to go with that? sort
of your favorite that every size team
seems to struggle with. So
it's very interesting. Uh all teams I
think
wow those bullet points it testing
paralysis seems to be the biggest one
for me. It it's like especially early on
with projects cuz you don't have
something there. you're still building
the foundation for what you need to
test. It really relies on the developers
to test their code, but they're too busy
trying to get the foundation in place to
get something stood up that they can
physically see and physically test. So,
a lot of times early on, either testing
is really good or it's really lax. And
then when you get into the more
midsection of the development uh of the
project, you run into problems where
there's not enough testing, things
break, you make one code change here,
break something here. Um, so that test
paralysis is really something that
kind of is personal where you you really
need to be testing your code from the
beginning. As you get something stood
up, as your teams get something a little
more sustainable, you can actually stand
up that server or you can actually run
the application on a desktop. At that
point, you need to start having
regression testing or at least user
acceptance testing. And then once you
start deploying to a QA server, you need
to start having uh that more refined
regression testing or smoke testing of
that system.
I am going to I think I want to talk
about the blocking out focus time hours.
Um because even with small teams, I've
seen this particularly in agile. This
can be a problem because you have your
daily standup. Um sometimes you'll have
a lot of breakout meetings and stuff
like that. you'll have a meeting here, a
meeting there, and the next thing you
know, you've you've ended up essentially
breaking up your day by a bunch of
meetings and you're not able to get
focused time to get stuff done. This
really becomes an issue with sprints
when you're getting to the end of a
sprint and you've got that mad dash, as
Michael sort of implied it, where you're
like getting all your code committed,
but then QA is doing all this testing
and there's this frenzy of testing and
there's a frenzy of feedback that comes
at it and so the developers are trying
to like scramble to get all their bugs
fixed and everything just goes haywire
for a couple of days and it's hard to
keep moving forward through that. Now,
that's not, you know, obviously it's the
end of a sprint, so it's not every part
of a sprint, but I think there
definitely should be some times, whether
it's waterfall, whether it's agile,
however you approach it. And no matter
the size of your team, that you have
some hours that are just like, we're
going to go get work done. Now, it may
be that you're, you know, the lead of a
team and you've got to deal with a lot
of other teams and you've got to go be
busy all the time. That's fine. Make
sure that if you do so, you're not
dragging your developers into
everything. make sure that you can, you
know, that's part of what your job is is
to deflect from them so that they can go
get their job done. You're going to go,
you know, listen to all the people you
need to listen to, get the stuff,
communicate it back to them, and do that
in a way that is efficient instead of
them having to sit there with you. Now,
you can do stuff, and this is something
we've done. You can do death by
recordings is you can record everything
and tell people, "Here you go. Let's go
to it. Uh, go listen to the recording
and you can grab whatever you want."
Don't do that to your teams,
particularly if you're like a, you know,
a lead and you've got developers, things
like that. Should distill that out. Give
them the bullet points that they need to
know and then move on. Don't make them
sit through that for a while.
A pro note is if you have to sit through
it, kick the speed up to like 1.5 or
two, however fast you can do stuff, and
you can always pause as you go through
that. Trust me, it makes very long
recordings a lot faster to go through,
and it will allow you to like jump
through to stuff. You can also use AI. A
lot of times it will give you summaries
and synopsis and you can take those and
maybe go figure out where in the
recording if you need to actually get
specifics. Uh but also it allows you to
get an outline a lot of times. So there
are a lot of ways there are a lot of
things that as a team grows that are
small but then they become very big very
quickly because you add more people and
so the little problems become bigger as
you go. And so I think that's something
you have to watch out for and it's one
of the things that it talks about as far
as principles of scale. But we're not
going to get into that because we are
bumping up against our time. It's like,
you know, ready for a commercial break
or something like that. So we've got to
wrap this one up. We will come back next
episode and we are going to continue
this because we're getting a lot out of
this as well. I hope you guys are. As
always, shoot us an info at developure
email. You can send us an email at
infodelvelopeneur.com.
I'm sorry I mixed all that up. didn't
come out quite right. It was one of
those like word scrambles.
Send us an email. Let us know what your
thoughts are. What are some of your
recommendations? What are some things
that you'd like to see us talk about? Uh
maybe some things that we want to throw
at AI as we get further into this future
episodes, future seasons. Uh if you want
to if if you're an interviewer and you
want to talk to us or if you know
somebody you would like us to interview,
we are open to that as well because hey,
we're agile just like that. Just just
because we can be. That being said, I
want to just 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.
So, let's see. Bonus stuff. Oh, it even
has bonus content ideas. So, I'm going
to get that. Actually, I have two ideas
that I didn't get to in the podcast.
Cool.
one which started coming to mind when we
were talking about larger teams and it
totally went out the door as he went
through those four bullet points is
crossrain your team. Make sure that you
cycle your developers on different
features of your program. If you just
have one person working on database and
one person working on UI, if that UI
person quits, who's going to support
your UI?
Just make sure you're always rotating
your developers across different
features. Even if they're not skilled in
UI and they're better at backend, still
put them in UI. Give them smaller tasks
or give them a larger task, but give
them more time to work on the task and
maybe pair programming with the other
developer. That is very crucial to make
sure that your team is healthy and you
have the coverage in case someone wants
to go on vacation. Um, also it makes
sure that everyone on the team can
support customer issues or bugs that
come in. So you're not relying on one
person to always be that firefighting
person and have them burn out. Second
thing was code reviews.
I've been in many, many projects and
code reviews can be very contentious.
They can be ignored. People just go in
and just click done. They don't even
review it. You have other people that go
in it with such a fine tooth uh pen that
people are so frustrated by the time
they get the reviews from this person um
that it's like go away. Uh but a lot of
times
and then you have those that are in the
middle where they give very good
feedback. They give very detailed um
advice like oh hey maybe this is outside
of our framework or this is not quite
the architecture we want to use. Um,
other things could be simply, hey,
you're not following the code standards
for naming conventions. Make sure that
you're following this or you're missing
this comment. Or something even more
critical. It could be, hey, I don't
think this loop is working the way you
think it is. You might have a infinite
loop or you might want to switch the
logic that's not quite right. These are
benefits of doing code reviews. Code
review is not just hey someone just give
me a green check mark on my code saying
hey it looks great move on. Code reviews
are there one for review so your other
teammates know what's changing in the
code so if they don't touch that section
of code for 6 months they're at least
aware of what's going on. Two you catch
general uh typos or just logic issues
that might just be missed uh just
because you're quickly going through it.
It may work for your solution for your
problem but may break something else
just something you don't think about or
didn't even know about. And then lastly,
uh if you are the
uh coder,
take the code reviews with a grain of
salt. Submit your code, walk away. Do
not look at that code review for a day
at least or at least a couple hours. If
you watch those code reviews as they
come in and the comments, you might get
frustrated and just get angry. That's
not the point of this. And if your
reviewers are giving you that type of
feedback, you need to come together as a
team and say, "Hey, code reviews are a
safe space. This is to work through the
problems and make sure the code is
right, not how badly can I make myself
look better than you because I found a
problem in your code."
Yeah, there's code reviews are I've seen
them done. Well, there's a a wide range
of ways they are accomplished. They are
done. and they're addressed. They are a
great way for cross trainining. I will I
want to I guess sort of piggyback off
the crossraining idea.
This is something that a lot of times we
we put people on certain tickets and a
particular certain task because they're
good at it. That's their area and that
is the, you know, a sense the most
efficient way to get there. Put the
person that that's their strength on it
so they can get it done. The problem is
what happens if there are too many uh
things of tasks of that nature that have
to be done because now they become a
backlog or what happens if they leave or
they're hit by a bus or you know there's
a lot of different things that can go on
that can change the the balance of the
team and the team that you started out
with where everybody had the right
amount of work to do and all that kind
of stuff. it was do going well and now
suddenly the balance changes and things
go off the rails. I think I like to
relate it back to I'll go to a sport
like a nice little sports analogy way
back in the day.
One of these things that we did as a
hockey team is early in the year you'd
make sure that people played different
positions. You would play them in roles
that they wouldn't normally have gotten
because maybe they're not that good or
maybe they're really good and they
wouldn't normally have to do it. And it
could cost you like early in the se
there could be games that you they were
close they needed to be or that you lost
that you could have won. But fast
forward to the end of a season and now
you've got a everybody has come up.
You've got people that can cover for
each other. And so if you have an
injury, if you have somebody gets sick,
if you have somebody's just tired, you
can last longer. You now have a team and
not just a bunch of individuals. And it
makes a world of difference. And that is
included in solving problems because if
you've got your database guy always does
database and your front-end guy always
does front end and your designer always
does design and you know your JavaScript
person always does JavaScript, you're
going to have an imbalance. You're not
going to be able to have the idea of
like all hands on deck, everybody just
jump in and start grabbing tickets and
get stuff done because people aren't
going to be able to. And this is a hard
lesson to learn sometimes because
there's stuff that people will grab
things, you know, they'll work on things
that yes, they're going to do it a
little faster than somebody else, but
somebody else could do it. And so maybe
somebody else should do it so that
you're expanding that knowledge that you
do have a team that you're developing,
bringing everybody up instead of just
letting everybody get better within
their specific silo. Uh before we jump
out, I do want to go ahead. I teased
that they have this. One of the other
things was principles at scale was one
of the things that AI threw at us and I
just want to go through these because
you know real quick because there are
some good ones. Feedback loops shorten
them code customer production
any kind of feedback loop the sooner you
can get the message the information back
the better. Automation we talk about
this build pipelines that scale with
you. Whatever it is, however you do it,
make sure that as you get further along
that you are still not having to spend
too much time doing your builds and you
know getting doing to anything that's
not writing code, verifying code,
knowledge sharing, wikis, code comments,
brown bags, we talked about this is same
thing as a crossing. Make sure that as
many people on the teams as possible
know as much as they can about what's
going on. Yes, it is sometimes
timeconuming. Yes, it is sometimes very
frustrating, but it will pay off in the
long run. I promise you measurable
improvement. This is something that is
really a struggle for a lot of teams
particularly smaller ones is using like
dorometrics or delivery KPIs or
something like that. Have some way to
measure what you're doing. Now it is
very difficult. I know that there are u
you know you could use points and
velocities and things like that that
that happen a lot in agile and those
things are you know squishy as you start
out and as you get further along in a
team you can at least evaluate those uh
estimation I think from a developer
point of view is one of the most
important things to do is make your
developers estimate everything they
stink and do and then hold them to it
and by hold them to it I mean just when
they get done say how did that work out
for you help them to understand what
their particular estimation
style is, whether they need to take
their estimate and multiply it by 10 or
whether they, you know, overestimate,
which no developer ever does. Um, you
that's going to help everybody get
better because you're going to be more
realistic about what you can cover and
how fast you can cover that. That being
said, we are I'm done covering this.
This is as far as I can cover it. We
can't cover anymore. So, we are going to
call it an episode. Call it a night as
it were. We will be back. We are just
getting started in the season. Uh loving
this so far. We'll see. AI has like
gotten a little cooler towards us this
time. So, we'll see how it goes as we go
into the uh the remaining episodes and
uh we'll just see where we go from
there. We may break it up with a couple
of uh interviews along the way as well.
We're still looking at that. Uh
definitely some fun ones that are out
there. We'll see how it goes. As always,
love to hear your feedback. Any way that
you hear us, whether it's wherever
you're listening to podcasts, if you're
out there on YouTube, which you're
watching us right now, you're probably
on YouTube, leave us a comment, leave us
some feedback. You can, you know, thumbs
up, rate us, whatever it is. But really,
it's the comments that we really want to
have. We want to have that feedback.
What do you like? What don't you like?
Help us out. Help us help you, all of us
build a better podcast for building
better developers. Go out there and have
yourself a good one. And we will talk to
you next time.
[Music]