Building Better Developers with AI: Mastering Developer Feedback

Welcome to Building Better Developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we are building better developers with AI. Yes, this time around we are going to go to a past season. We are going through those past topics and we are basically taking them, throwing them into AI and see if that gives us better discussions. Spoiler alert, it is giving us really cool things to talk about every single episode and I am looking forward to continuing to do that. Currently we are using chat GPT and we may switch to another AI engine just for grins or that may be bonus material sometimes. We will see how that goes. We have never gotten through the points but we are going to see if we get there today and probably we will fail again. But before we do that, I am going to introduce myself. I happen to be Rob Brodhead, one of the founders of Developineur, also the founder of RB Consulting where we help you do technology better. If you think of your technology as having like a junk drawer where you have all these applications and services and servers and network things and all that kind of stuff, we sit down with you, we talk to you about your business, figure out how that maps to what you have and what is out there. And then we help you through a technology assessment, we help you figure out a roadmap for the future. We can even help you implement it, depends on where you want to go with it. But essentially we are there to give you a nice little like guiding hand and help you through integration, simplification, automation, innovation, however we need to do it to find that path to get to a simpler, easier, more Zen technology world of your own and then the most ROI on that really expensive investment in most cases. Good thing, bad thing. Good thing, bad thing, this is actually a spoiler alert I didn't talk about in the pre-show or I hinted at it. Good thing is, Harry's that does like shaving stuff has a new razor. I've always liked them as far as their pricing, but their stuff was not where I needed it to be because I'm like, I got this beautiful mug that I got to shave or something like that. So the good news is they got a new razor. They upgraded it and I was like, all right, I'm going to give it a shot. And that razor came in the mail. I'm like, awesome. Good thing. The thing is, is I shaved with a new razor today. And so now I've got like a really nice little cut where I forgot I had a new razor. So be careful with sharp objects, children. Also be careful with my co-host Michael, who is about to introduce himself. Go for it. Hey everyone. My name is Mike Mollosch. I'm also the founder of Envision QA. We help startups and growing companies launch better products faster. That means fewer bugs, smoother customer experiences and less wasted time and money. We take care of the behind the scenes quality work so you can focus on building and scaling your business. You know, let Envision QA help you. Good things and bad things. Good thing is I also have that Harry's razor and I've gotten past your little problem there. But yes, early on had that exact same problem. So good and bad on that. But also a really good thing. We're getting closer to July. It's sunny. Yes, it's hot. But man, just something about the sun being out more and not any of this rain makes you just feel so much happier and less gloomy. Yes. If anybody from Harry's is listening, feel free to like send us. We would love to be sponsors because hey, we're always happy to have advertisements. That one was free. The next one, obviously we more than happy to take some money product, whatever. That was just a side note. Anyways, back to our topic for this time around. We took the prior episode of turning feedback into future success, a guide for developers and we shove that into chat, chat, GPT and it gave us back a series of an episode structure and series of key discussion points. I love the first point. So in the first section, reframing. Now, real quick, though, before you get into that and all our prior ones, though, you've given us how chat GP responded. And I kind of want to keep that going a little bit because as we go to the other AIs, I want us to kind of speak on it. It's true because if we get an AI that says that is the most stupid request I've ever heard, we want to share that this one. When I asked for that, it said, absolutely for your developer podcast episode titled, here's a structure breakdown of topics of discussion. It has gotten away from the like, that's an awesome idea or something, but I think it's realized that we don't care or it is one of our listeners. So I don't want reframing feedback. It's not criticism. It's data point one feedback is a growth tool, not a personal attack. I love that this is like top of the list. And this is actually, I think top of the list. One of the primary things that we've discussed in feedback in general, also code reviews. It also, I'll get you the rest of these first bullets. Professionals seek feedback. Amateurs avoid it. Reframing it as input to iterate and improve like debugging yourself. And then they've got a suggestion, mini segment, the developer who took feedback personally and lost a client. Wow, that would be a cool little segment to do. I don't think I've done that. I don't think I've got anything like that that we've ever done. That would be sort of cool. I like the, with this one, I really liked the idea of like debugging yourself. And this is actually how I feel when I'm doing it. I guess it's a little more than when I go into code reviews and especially when they're the ones that are in person where you actually are like sitting there walking through your code and explaining it and you're getting live feedback, which to me is very different from when you're using tools that allow people to give you feedback. While those are useful, I found that the in person, they tend to be, there's more feedback. I tend to get more useful feedback and it's actually, it tends to like a lot of things go off the rails a little bit. So the feedback will actually a lot of times go beyond just the code that I wrote, but it will also give me insight into other suggestions outside of like just that code review. When you're doing it through a tool, usually it's just in that code. And the debugging yourself, I also see it as improving yourself. If you ever selfless promotion here, but if you ever go back and read our book, that's one of the things we talk about in code reviews. It's a great way to learn. So debugging and code reviews are an awesome way to get feedback and learn things you don't know about the language, the environment, honestly, even the application. There are numerous times that I have walked into projects mid, you're like not in the first sprint and the first couple of sprints when I'm doing code reviews, I end up getting a lot of feedback about what is it that we're actually building. It's all of this stuff that doesn't come on day one that isn't really documented, but a lot of what you don't know is that this is how this works. Or by the way, there's this other feature you've never thought of or been introduced to. And this is not only good for you. This is why I love code reviews because it forces cross training to some extent. That's why even like I've got a developer that is our newest developer, actually not newest and with air quotes, he's literally our newest developer, our most junior developer. And I ask him all the time to do code reviews and he doesn't feel comfortable with them. And if he ever watches this, yes, I'm talking about you. That I asked him to do it and he may not feel comfortable. He's like, well, I don't really know. But it's like, no, there are things you know that are useful. There are pieces of code you've written that are useful to code reviews. And so think of it that way is please think of it as both sides of it. Please think of it as constructive criticism and please promote it as constructive criticism. People trust me. We are developers. We create bugs. We are not perfect. We know every time we run the stinking compiler or build, we will see all kinds of crap. Yeah, and maybe it's just us. Maybe not everybody sees it, but we know we make mistakes. We make typos. I don't know how many times I've seen commits in that are I forgot to commit this one file All of us do it. Go with it and use it as a learning experience. Your thoughts, because I know this is very near and dear to your heart. Yeah, I'm going to try to keep this positive. First and foremost, I will say this. Debugging yourself feedback, anything in general, you have to take a breath, treat it as a safe space or try to make a safe space for feedback and criticism because you may get slammed with nothing but criticism and bad feedback. You need to be able to absorb that, filter out the minutia and get to the key points of the feedback. A lot of times. So one I'll start with, you know, improving yourself with feedback. Asking for feedback all the time is a wonderful thing. But it can also be a negative thing on the people you are reaching out to for feedback. You could get into feedback loops where personally, you know, if you're feeling challenged or you're feeling uncomfortable or insecure of the problem or what you're working on at the time, it is very hard one to ask for feedback and then very to to get the feedback and not continuously ask for more feedback. You get out of that. In control moment and you kind of unfortunately, you lead into or fall into that trap of you. You lose your confidence in what you're doing and you're just stuck on the feedback of others. You know what you're doing. Take the feedback you're getting from others. Take it. Learn from it. If you still need to follow up, follow up, but be conscious of their time and make sure that you are learning the right way. If you're if you get stuck where you think you're going down the trap of I'm not getting what I need. Maybe you're talking to the wrong people. Maybe you're getting the wrong feedback from because you're asking the wrong question of the wrong group. So, again, I want to try to keep this positive, but these are some things that I've run into a lot and just personally are some challenges you run into because you could it could bring you down just because you're talking to the wrong person. If you're talking to the right people and getting the right feedback, then it makes sense. But it's a challenge because you don't necessarily know if the person you're asking your customer could potentially be giving you the right feedback, but you're not hearing it because you're in the wrong mindset. I want to I want to talk about that mindset real quick, though, because I this is a little behind the scenes. Michael and I have worked together as developers for a long stinking time for as young as we are a long time. And I want to say that there are times that we're like an old married couple and that we will have code reviews and we will go back and forth. But I want you to like as one of the things that we have learned that makes it useful is that it's going to come as a shock. But we have bad days and there will be and we also because, you know, particularly through Slack and text and stuff like that, you will misread things. And we are comfortable enough saying, hey, that doesn't seem right or that seems like attacking or I'm not intending to be a jerk. It just come and we will say different words than that. But but because we recognize that we're we're harping on maybe something we don't. And there's also situations where we will talk about something and realize that neither of us have are in the position to make that decision because somebody else needs to do that. And we have to push that off. So I just want to say this like, yes, there it can be stressful, but like own that it can be stressful, own that it could be you could maybe take it wrong or maybe somebody's maybe you're communicating it in a way that is not we'll say nice. And I'm I'm usually the person that's like, screw you with nice, just get it done. But also there is like it has to be you have to do in a way that people receive it. And so I want to like Michael's trying to be nice, but also let's we're going to be real because we like we have lived this. We have had rough times on it. And I just want to throw that out there and sort of throw those extra pieces because I felt like that was a good time. Go ahead. It was. I mean, you know, not throwing salt on the wound, but, you know, we actually had that started that conversation this morning and we had a little chat thread going and it felt like it went off the rails, walked away for a little bit and came back and it's like, okay, we're just misreading it. And but the funny thing is it came around from a code review and testing. Working on a ticket that are trying to test a ticket that was completed, looking at the ticket and well, the developer Rob worked the ticket. I came back in and looked at the ticket and the ticket was a little vague. So trying to dissect and understand what to test and things like that prompted questions and prompted questions outside of essentially his lane. I needed to go a little bit above that to the project owner. And that's where you have to make sure you're talking to the right people. You're understanding the right priorities, but that all came from testing code review. It's like, Hey, I looked at this. I potentially found a gap or I found like, I'm not understanding what you worked on because there's my piece of miscommunication in a ticket. Real quick. I want to add on that is no, that that was through testing. We've been talking about code reviews. Testing is the same thing. So when we're talking code reviews, also consider tests. Same thing. Go ahead. Yep. Nope. Exactly. So because we, I'm more a tester and coder, I wear too many hats and I get stuck in many things. It's like, if I'm in my test mode, I ask things to certain way, but when I'm coding, it's like, Oh, that's out the window. Guy get work done. Guy get out the door. Uh, it's very funny trying to, if you work with me and you work on many projects like this, you'll see that when I'm in this mode, yeah, testing is out the window trying to get things done. But when I'm in the test mode, it's like crap, I forgot about that guy. But code reviews. So I'll real quickly talk about code reviews and then we'll move on to the next one. Code reviews, like Rob mentioned are really good tools. One to catch things that are missed to if your pipelines are built correctly, when you send it up to your pipeline to build one, it will tell you if the project, your code builds that, oops, you haven't pushed up bad code. Most of the time pipelines can break to, did you commit all your code? Your bill could still pass, but you're missing some configurations or something behind the scenes that your tests don't touch. And three, cover reviews are a great way to keep your team trained on what is going on with the code. So many projects I've been on. It has been very, uh, if you're dealing with like larger teams, you could very quickly run into one person is kind of working on front end stuff. One person is working on backend stuff or multiple people, but they're not working on that. They're not switching over. They're not cross-treating enough on the code or the application. That is where code reviews are perfect for this. And sure everyone spends a little bit of time, 15 minutes to a half an hour to paint pan how many code changes are in there. And if you're doing your tickets, right, there shouldn't be that many, that big of a code change if there is your tickets are too big. Um, so a box over, but code reviews are perfect for training, perfect to ensure that your code standards are being followed, that your naming conventions are right. The other thing that code reviews are great for is, Hey, I added this functionality to solve this problem. Oh wait, Hey, this was already solved over here is named something else. Go get this. This helps you decrease code bloat, uh, dead code and duplication of code within your application. Uh, a couple of quick things on that is that means what he just said is. Absolutely spot on. And that means that when you're doing a code review, you need to pay attention to what you're reviewing. I have had too many times where people have reviewed code and then a week later, they're writing essentially the same function. They just code reviewed. And if they did that to me says they probably weren't paying enough attention. Uh, bonus thing is unit testing and regression testing is an awesome way to, um, give yourself feedback without a personal touch because we all can hate the unit tests and then it fails it and stuff like that. And it's not, you know, a person's fault. We don't send it. We don't seem to take those personally as much. So I see that often as a great way, uh, particularly if you incorporate that into your pipelines and things like that, a great way to, uh, build knowledge about the application and ensure that it's, you're not breaking things when you add new code moving along, because we have some pretty cool stuff. I want to hit this next one. Types of feedback developers receive, uh, technical code reviews, architecture decisions, performance improvements, collaborative communication, responsiveness, documentation, or team synergy, uh, client-based feature delivery UX expectations as user experience, timeline management, user feedback, bug reports, usability, pain points, and feature requests tip. Not all feedback is equal. Learn to fig filter signal from noise. Now that section I would love for my teams and this, this is something I build in my teams, I would love for all the teams that I work with to incorporate all of these areas, technical, collaborative, client-based user feedback. Uh, I even include what I would include, uh, professionalism for back, lack of a better term, because I think there is a lot of feedback we can get as developers that will help us be a better developer, but more importantly, be better as a teammate, teammate, better as a, uh, a communicator. And there's a lot of things that we as developers get away with sometimes because we have a firewall between us and the normals or the non-technicals or whatever you want to call them. The people that don't speak our language and part of being a better developer, part of moving from a coder to a developer is being able to translate tech speak for lack of a better term into business speak, whatever your business is. And sometimes that is sometimes that's a challenge because sometimes the business speak is not consistent. There are not every industry is created equal. There is a very big difference. If you're dealing in, uh, law firms versus healthcare versus finance versus, uh, distribution, fulfillment, warehousing, all of these organizations, all of these lines of business have different terminologies. Some are easier than others. And if you want to be a better developer, part of what you need to do is get feedback and this is including clients and users so that you are understanding the business side of what it is that you're doing so that you can communicate to them what the application actually is. And this breaks, this goes down to like the most simple things like labeling your stinking input fields was something that the user understands. And trust me, I have been in long conversations about what the correct label is for a certain text field. And I often consider it to be not time wasted because we need to make sure that we are understanding who our customer is, how to communicate with them and do so in a way that is clear, because when they get in and use it, you want them to be comfortable with it and not saying what the heck are these people trying to make me do. I'll get off my soapbox and now allow Michael to step onto his. Yeah. So types of, you know, types of feedback, you know, technical collaborative, we've kind of touched on a lot of these and we deal with a lot of these. I'll tell you right now, my biggest fear is dealing with customers. For years, years, I've always worked behind the scenes. There's been a salesperson, a marketing person, a manager. I'm behind all that. I'm the coder, depending upon where you're at, you could be in the same situation. I will tell you right now, you've been in the same situation. I will tell you right now, you better rip that bandaid off because you need to get better at communicating at all levels. I will say this, the first job I first real software job I had after college, I had a code go out the door and the feedback I got for multiple, uh, you know, early releases or beta sites for the software was, Hey, everything's working great. We go live first big client software breaks. It's July 3rd. You'll run into these situations. You get a lot of negative feedback. You're this doesn't work. I immediately went from behind the scenes to customer facing. Customer is always right to a point because you need one, depending on where you're at in your job, your customer is your boss. So your boss may be wrong, but he cuts your paycheck. So you need to make sure that what is wrong is clearly understood and defined. So you get the right feedback so that you can correct the problem and move on. Um, don't want to be that horse too far dead, but always understand the situate. Your situation will constantly change in software. You could think you're always a coder or developer. You're always doing this. No, you at some point in your career will be thrown into every level of the company of the software. So you better get used to a lot of negative feedback, especially if you somehow skipped working in customer support or software support before becoming a developer, you need to get on the phones and talk to your customers. Because you will find out very quickly that that little button you did does not work the way you think it does. Your customers hate it. Do something else, but unless you learn from your customers, this is a great learning tool. You get the feedback on how things work. What it is that you're doing, how it's being interpreted is the best way to improve your product and to improve yourself and grow as a developer. I will add that the, the reason that RB consulting is what it is, is because when you do think, when you actually listen to your customers and the, what their pain points are, the customer meetings are always so much better than what we do to ourselves. We beat ourselves up for all of the little bugs and all that kind of stuff. But if you're listening and delivering what the customer actually wants to fix 99 times out of a hundred that they're like, wow, this is way more than I want it, but it's because this goes back to our, why focus on why you are building it, don't do it because it's cool technology. Don't do it because it's a cool algorithm or it's like a new thing. Do it because it is serving your customer. And I guarantee you, your customer meetings will be great. If you short circuit that, if you're trying to like, you know, learn some technology and if you weren't straight with them from the start, if you aren't like laying stuff out and giving them a, here's where we're going to go and communicating, you're going to have problems. Now that being said, I want to move on because I do want to, like, I want to add this little bonus thing, not a bonus, but this other point before we move on. Um, the next one it has how to process feedback constructively, and we don't have a lot of time, so I, we're not going to get too deep in this, but bullet point don't react, review, digest, reflect, ask clarifying questions without becoming defensive, separate the feedback from how it was delivered, look for patterns. If two to three people say the same thing, it's a flag. Now I want to jump real quick and then I'm going to throw it to Michael. So he has a time to speak and then it's my time because I get to close it up. I'm just kidding. Um, don't react, review, digest, reflect. That is the hardest thing for us to do. We get something and we want to like, bam, like boom, right away attack it. Because one of it is because we're developers want to get it done, get it out of the way, move on, move on, move on. Trust me. People hate me for this. Haters going to hate. That's just the way it is. Um, but it, we have to accept that is realize that we move through stuff too fast and we need to sit back at Tekken, particularly with feedback constructively. More so than anything, it's like, where do I fix this? What? There is a problem. Somebody has noted something. They may be high. They may be wrong. I don't care. There is still some sort of fix, whether it's a communication or an actual go change, whatever it is. And this goes to the next one. Ask clarifying questions without becoming defensive. I think this is the number one skill that we can all get better at. And I don't even care if you're a developer or not, because asking quire clarifying questions, we have to know that like this goes back to go to loser, think, go to philosophy, to psychology and stuff like that. Realize who we are as humans. We typically are going to ask a clarifying question in a manner, in a context that is probably defensive. We're probably going to state it in a way that is making us look good. And the other person, like an idiot, because they shouldn't have pointed out our bug, that's not a bug. This goes back to what I talked about. Michael and I earlier, we have worked with each other long enough. And although it's not always the safe space because Michael will punch me sometimes, I'm just kidding, but we know that we are allowed to say, Hey, I didn't hear that. I don't think I heard that right. I was offended by that. I was hurt by that. Um, I wasn't, I didn't mean to be a jerk by that. Those things, we have those sensitivities out there. And I will also add, it's not just us. Our team knows that. Yeah. Sometimes we get a little heated about stuff, but they also realize and have mentioned it's like, we do it without the egos leading. Yeah. It'll come off that way, but we're usually very apologetic about it. And that's the key. If you can learn to clarify without being defensive, that helps so much because it's basically, I hear you. I need more information. And sometimes it's that simple. And sometimes it's frustratingly that simple because they say it's broken. Okay. Tell me more about what is, what is broken? How did you, what did you do? How did you expect it to act? Sometimes something as neutral as that is the way for you to move forward because it's basically, it's like, look, I need more information because you do. And it doesn't hurt. So let's go ahead and do that. And then that can be done in a neutral way. You've been nodding all along and I'm sure it's not because you agree with me. So what are your thoughts on this one? Uh, it's funny about that, but one of the biggest things I've heard in a lot of the, uh, like co-star classes and business classes I took to relaunch the business is stop and listen to your customer. If you are doing all the talking, you are not getting the validation, the clarification that you need, the right feedback you need to solve the problem. Take the time, stop, listen. And it may even be, you need to just go out and take a walk around the block for a minute, walk away from the problem. If you get heated, you get very emotional about what you're doing. We all do. We're passionate about what we do. You wouldn't be doing this if you're not, but we can't let that passion turn into an obsession of I'm always right. The customer is always wrong or whoever's speaking and ensure that you do take the time to listen, get the right feedback that you need and offer the correct feedback when things are wrong, be courageous enough. And it's not easy to speak up when you're being talked down to, or when the feedback you're getting may seem too critical, too hard and say, Hey, let's back it up a minute. Let's make sure we're focusing on the problem that we're not. Injecting egos into this, like Rob mentioned, and just let's solve the problem, you know, we're here to fix. We're here to solve a problem. We're here to create some great software and to improve everyone's life. Let's not detract from that. Let's not tear people down. Let's not beat things up. Let's keep it positive and get that feedback and move on. A hundred percent agree. I will throw a little bonus thing out there. There was, and I'm going to name names. There was a guy that I worked with that I, he said a throw away phrase one time that really sticks with me because I think it's very important for us to think about. His name is Greg Imany. And he said, you know, this is a meeting that whoever talks the least will win. And I think we need to think of that, particularly when you are in requirements gathering, when you are architecting and getting feedback. You win if you say the least amount of words, basically, if you can sit there and say, and then what, or, and then what, or what happens next, or how does that work? Just leading questions. And I know people will think you're a jerk because all you're doing is asking questions, but you're not, you are doing everything you can to draw that information out. If you can think about that, it is not about showing off your skills, showing off your knowledge, showing off that you've got a degree or you've got a certification or blah, blah, blah, the stuff that we sometimes fall back on. And instead of falling back on, this is how we can help you. That is where you're going to win. That's you're going to win your customer, you're going to win your project because you're going to get that, uh, that safe space for them to gripe about everything they want to gripe about. Sometimes it's going to hurt because they're going to say your, your code sucks. This breaks. This is, you know, but own it. Like I have, I've got a customer that I loved working with him. I think we finally are past working with him. And one of the things was there were times where he'd be like, this is not what I expected from you. And I'm like, I agree. And I'm going to fix it or I'm going to discount it or whatever it's going to be. Because it's like, yeah, we, we, we missed it. You know, we didn't get it right. We didn't understand it. We're not going to blame you for not communicating. Sometimes it's our fault for not asking the right questions. For example, this is why every time we ask, send us an email at info at developer in order.com so that we cannot fail you as our customers. And we can make sure that we are doing things that are useful to you, that we're providing you content that are our context, our approach, all of those things. They are all open, especially Michael. I know I'm perfect. I know Michael needs a lot of help. Just kidding. Um, Any feedback you give, whether it's positive or negative, it helps us a lot. This is what this actually, what this episode is about is we embrace even negative feedback because that tells us where we have made mistakes, where we've screwed up. I want to hear from you guys. If you have suggestions for us to improve for future topics, all of that info at developer in order.com is a great way from email. You can also reach out to us. We've got all kinds of places on developer in order.com. You can give us feedback wherever you listen to podcasts, whatever your catcher is, you can leave us feedback. Positive, negative, great. YouTube, the developer in our channel. We are on X at developer in order and out on Facebook. We also have a developer in order page. So you name it. We're out there. If you name it and we're not, let us know. And we'll go get out there because that's just where we want to be. We want to be where you are continuing to provide content as always. Thank you so much for your time. I know this is a little bit, a little bit long. Sorry about that, but please forgive us and we will try to do better next time. Love you guys. Have a great day, a great week, and we will talk to you. Thank you for listening to building better developers, the developer podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts, we are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.