Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche explore how developer feedback helps sharpen your skills, improve code quality, and boost team collaboration. Learn how AI tools like ChatGPT reshape developer conversations and uncover new ways to grow through constructive feedback, code reviews, and clear communication.
🔗 Read full summary: https://develpreneur.com/developer-feedback/
More Episodes: 🔗 https://youtube.com/playlist?list=PLxXUHr7mZ-jGw-fKv4BvUT4uhj27m5bKA&si=cPhAqJSQn6KQ8Q0P
Follow Us: 🔗 Website: https://develpreneur.com/ 🔗 LinkedIn: https://www.linkedin.com/company/develpreneur/ 🔗 Facebook: https://facebook.com/Develpreneur 🔗 X: https://x.com/develpreneur Email: [email protected]
Transcript Text
[Music] We just hit record after all that crap we said that cannot be recorded. Now it can't be. Uh I'm gonna turn a light on because that's the way I go. Doesn't do much, but depending on how long this goes, how the light go. Let me get my shuffle myself up. There we go. Look at I've got my little If I do this, you got a weirder lighting situation than I do. I have it on my left and as the sun goes down I just get darker on this side. But all right, that's clear. It's all fuzzy. I got like all windows here. So it's, you know, I get pretty and it's all like white and and gray. So it all like reflects in here now. So it is what it is. Although now I look like I got like a black eye. I should like I just like sit like this the whole time. You get sucker punch in hockey again? Yeah. be a good excuse, but no, I do have what you can't see. Oh, no, it's over here. Yeah, you can go. That's my good thing, bad thing. Um, I'll I'll share that later. I don't want to spoil. Um, no, I have not gotten sucker punched in hockey. Actually, I've had more sucker punch damage done in handball in the last six months than I have hockey. I don't think I've been smacked in hockey near as much, but I've run into partners and a big partner twice now and it's both times I was like, "Ow, that hurt." It's funny. You seem to get hurt more in handball than I ever did playing raetball. Oh, that's cuz handball is a real sport. Wacket balls raetballs for like wusses. So, should play me sometime. We'll see how that goes. The guy that I keep running into is a handball player from uh he's been doing it for like 30 years now. And the reason he's a handball player, he was a converted raetball player. And there's this old guy. Sorry folks, I'm just gonna share stories. There's this old guy, his name's Dick Fitch. Actually, he's passed away many years ago, but he was at the time he was like, I think he was in his 80s, maybe late 70s, small little wiry guy. And uh he would just pick on this this buddy of mine that was a he was a raetball player. and he had no idea who Dick was. But Dick would just be like, you know, you could never survive a handball match. You could never survive. And he would just do that over and over and over again. And eventually my buddy was like, "All right, I'll play." And he got smoked. A year later he was still getting smoked by Dick. It was like, you know, he was an old guy, but he was crafty. He knew how to play the game. And, you know, since then, we have had a we've had a, you know, stalwart. This guy's been playing handball solidly for, you know, 30 years now. And he converted from raet ball. He still talks smack to raetball players. He'll occasionally play, but he converted over and he's like, "Nope, it's a it's a whole different game. I'm never going back." So, I used to play a long time ago, but then I got into raetball and I liked raetball more for some reason. Yeah, tried raetball a couple times and was never never as big a fan. And no, I'm not doing pickle ball yet. Although gosh, there was I went by a place that was called like I think it was I think it was like a big honking building. I think it's like pickle ball world was on the side of the building. It like tons and tons of courts here. So apparently that's the thing to do. I've tried it. Uh our local brewery actually has two pickle ball courts, a volleyball court, and botchi ball. And Oh wow. Let's just say we played pickle ball for 10 minutes and we went to botchi ball. Yeah. Pickle balls work. That's like it's not so much work, but it's I don't know. Maybe it's just I'm not used to the pedals, but the pedals are more ping pong pedals to me. And I'm not used to like a solid pedal. Like if it was like a tennis racket or something like that, it maybe. But it's just weird. I don't know. You got to get used to it, I guess. But botchi ball is still a lot of fun to me. Yep. All right, folks. Sorry for that. Actually, I'm not This is bonus. This is bonus material. You get to see behind the scenes. And now I got to check my clock to see where the heck. Wow, we are way into this. Although this started before the recording, so we're okay. All right, we're continuing our AI journey. And this one I am going to do, what did I just do? I asked it um turning feedback into future success, a guide for developers. So, uh this should be a fun one. Uh it's got like it's got more topics than we're going to actually get to. Yeah, it's got seven of them. I'm sure we're not going to get that far. So, we are going to dive right into this. Let me reduce this. Let me probably need to start tweaking it to give you like the top five, top like after you get the list, but tweak it and say, "Hey, all right, now give me like the top four." We don't get through like two or three. I just like having extra that's bonus material for all of these people that are spending extra time listening to us talk about botchi ball, handball, and all of those kinds of useless things. All the other stuff that we bring to the table. Um, what was I going to say? Okay, I was going to sing our praises, but I'm not going to because that's just selfs serving and I'm not going to do that right now. I'm going to go one I'm going to go I can't even start with a three, a two, one. 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're going through those past topics and we're basically taking them, throwing them into AI and see if that gives us better discussions. Spoiler alert, it has given us really cool things to talk about every single episode and I'm looking forward to continuing to do that. Uh, currently we're using chat GPT. We may switch to another AI engine just for grins or that may be bonus material sometimes. We'll see how that goes. Uh, we've never gotten through the points, but we're going to see if we get there today and probably we'll fail again. But before we do that, I'm going to introduce myself. I happen to be Rob Broadhead, one of the founders of Developer, 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've got 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 road map 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 thus making 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. Uh, good thing is, uh, 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 like that. I didn't like the shave. So, the good news is they got a new razor. Uh, 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." Bad thing is is I shaved with a new razor today and so now I got like a really nice little cut where I forgot I had a new razor. So be careful with sharp 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 Michael Malash. I'm one of the co-founders of developer building better developers. 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. Well, good thing is I also have that hairy uh 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. Um, we're getting closer to July. It's sunny. It, 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. Uh, yes. Um, 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. Uh that one was free. The next one obviously we more than happy to take some money product whatever. Uh 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 shoved that into chatb chat GPT and it gave us back a series of uh 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 we get into that, in all our prior ones though, you've given us how chat DP 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. That'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 ner podcast episode titled here's a structure breakdown of topics and 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 item one 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 uh 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 um wow that would be a cool little segment to do I don't think I've done that. Um I don't think I've got anything like that that we've ever done. That would be sort of cool. Um I like the with this one. I really like the idea of like debugging yourself. And this is actually how I feel when I'm doing and it's I guess it's a little more than that when I go into code reviews and especially when they're the ones that are uh 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. Um while those are useful I found that the inperson they tend to be um there's more feedback. I tend to get more useful feedback and it's actually uh 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 um you know 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 when we 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 testing 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 um mid you 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 you know isn't really documented, but it's 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 it forces crossraining 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. Um that I I asked him to do it and he may not feel comfort. 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 uh 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 that Yeah. And maybe it's just us. Maybe not everybody sees us, but we know we make mistakes. We make typos. I don't know how many times I've seen commits in and 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. Uh 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, 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 two uh 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. Um, I want to I want to like talk about that mindset real quick, though, because I this is like 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 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 you know 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 you know attacking or I'm not intending to be a jerk it just come and we will say different words than that, but but I cuz 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 it's 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 you know maybe you're uh 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 it in a way that people receive it and so I I want us like Michael's trying to be nice but also let's you know 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 cuz I felt like that was a good time. Go ahead. It was and I mean and you know not throwing salt on the wound but you know we actually had a start of 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 it 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 or trying to test a ticket that was completed looking at the ticket and well the developer Rob uh worked the ticket. I came back in 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 and that's where you have to make sure you're talking to the right people, you're understanding the right priorities. But that 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 might be some miscommunication in a ticket." The top real quick, I want to add on that is note 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 the certain way, but when I'm coding, it's like, oh, that's out the window. Got to get work done. Got to get it 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. Fix that. But code reviews. So I'll I'll real quickly talk about code reviews and then we'll move on to the next point. Code reviews, like Rob mentioned, are really good tools. One, to catch things that are missed. Two, 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. Two, did you commit all your code? Your build could still pass, but you're missing some configurations or something behind the scenes that your tests don't touch. And three, code 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 they're not switching over. They're not crossraining enough on the code or the application. That is where code reviews are perfect for this. Ensure everyone spends a little bit of time, 15 minutes to a half an hour depending upon 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 bucks 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. It's 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 quick things on that is that means what he just said is absolutely spoton. 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 test and then it fails it and stuff like that and it's not you know a person's fault. We don't seem to 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 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, that's 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 and 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 would 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 team me 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 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 health care 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 with 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 soap box and I'll 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. Uh, 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 better rip that band-aid 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 customerf facing. Customer is always right to a point because you need one depending upon 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 that situ your situation will constantly change in software. You could think you're always a coder or a 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'll 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 wanted." 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. 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'm we're not gonna get too deep in this, but bullet point one, 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 obviously 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 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 like code 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 qu clarifying questions. We have to know that like this goes back to go to loser think, go to philos 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 why 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 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 ego's 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 it? 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? Well, it 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 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 is 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 bit. 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. 100% agree. Uh I will throw a little bonus thing out there. There was a and I'm going to name names. Uh there was a guy that I worked with that I he said a throwaway phrase one time that really sticks with me because I think it's very important for us to think about. Uh his name is Greg Immany 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 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, "You're your code sucks. This breaks. This is, you know, but own it." Like I have I've got a customer that I've 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 infoddevelopur.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, 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 [email protected] is a great way from email. You can also reach out to us. We've got all kinds of places on developer.com. You can give us feedback wherever you listen to podcasts. Whatever your catcher is, you can leave us feedback. positive, negative, great. Uh YouTube, the developer channel. We are on xdevelopure and out on Facebook. We also have a developure 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 has gone a little bit 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 next time. Bonus material. Sorry for you YouTube people because you get even more. You've been hanging out for a long time and yet we're still here. Oh, wait. Scratch that. I want to go ahead and uh the bullet points, right? The other ones. Let's see. What do we have? We had three more bullet points. Wow, we got nowhere on this. Um, actually, we those are really good. So, I'm going to fly through these and I'm going to give you one to throw on. So, you may take notes fast. Turning feedback into growth. Identify what you what you control and make a small action plan. Example, you got feedback about confusing APIs. Improve docs. Add examples. Refactor. Convert feedback into learning sprints. Refine your skills or workflow. Wow, that's a neat one. Build public change logs for side projects. Show you, listen, and act. feedback loops and side hustles. Early users are your free QA team. Embrace that. And every piece of user feedback is a chance to increase value and reduce churn. Use NPS surveys or interviews to proactively pull insights. Quote, "Side hustles don't fall fail from lack of code. They fail from ignoring feedback." Wow, that's a good one. Uh giving feedback as a developer. Be kind, specific, and actionable. Use I notice or I'd suggest instead of this sucks. Give feedback in the spirit of improvement, not ego. This builds trust, better teams, and great clients. Discussion prompt. What's the best piece of feedback you ever received that changed your dev journey? Creating feedback. Creating a feedback culture for yourself. Regularly use for impact. Ask for input. What's one thing I could improve? Use introspective and solo project or retrospective and solo projects or journaling for feedback. I need to learn how to read better. Small text. My bad. Normalize feedback in your collaborations, especially for side hustles and freelance clients. Call to action for listeners. Challenge: Ask one colleague, client, or user for feedback this week. Write down what you learned. Share your most painful but powerful feedback story with #de dev feedback win. I guess we should start looking at that. Tease next episode from good to great leveling up your dev workflow. Oh, I should probably tease that, but I'm not going to. So, your thoughts on these? That was a lot. So, I'll take one uh early one that you threw out there. Uh your early te your early users are your testers. Be careful with that. Don't be a Windows here. Let's push our software out and for six months use our users as our testers to fix bugs or Path of Exile 2. I'm calling you out. Don't go pre-BA or whatever. Yeah, I guess they're in beta or whatever it is. Uh, early access. Don't go early access and then expect a million users to join your site and guess what? You're in early access. No, you're live. You need to understand if you do rely on your customers or your users as your testers, you better pay attention because suddenly your application may not be this application that you're building anymore. It may have drastically changed. Be very careful with that. an early unnamed project that I was part of. Um, we used to kid that we skipped the savings and pass skip the testing and pass the savings on to you. Um, and that was uh, you know, cuz we did we cranked some stuff through and we also we're built on top of a product that also did that very often and so we would refer to them as doing the same things that we were we had like 250 tickets open with their software and they knew it. They hated hearing from us because we tested their stuff more than they did. Um, I will go with I'm gonna share this one as a bonus because I think it is it probably says more about me than it does anybody else, but that's okay. I think this is something as developers we can learn from. Ear feedback that really touched me, I guess, in a and not necessarily in a good way. early on when I was very young because this is yesterday. I'm still very young. Um I was working with a guy and he lit he was very brutal, we'll say, and you can you can gauge this, but he said, "You know, I thought you were an I thought you were, you know, you didn't know what you're you were just over the top and just being a jerk about stuff." And then I realized you knew what you were talking about. Now that's in many cases and pardon my French obviously but uh in many cases that was very could be considered very harsh but what I took it as which is how it was attended because this guy I respected him and his feedback was you have a lot to say and sometimes you don't say it the right way or in his case I'm sugar coating it he probably said never do you say it the right way you come off in a way and part of it was because I was a young kid and I knew a lot of stuff and I would just jump right into a conversation and people didn't expect that. So I could say well that's everybody else and part of me did and that's why I went back and got a degree and some a higher degree and stuff like that. But there was another part of it was how I submitted that information, how I carried myself when I said it. And it is something that has stuck with me through my life. And it's honestly I'll just like throw it open. It's like that's still who I am is like you may note because I have a bit of a I have a personality that sometimes precedes everything and my mouth is right there with it. And so sometimes it's a little bit much for people. And Michael's smiling cuz he has been a victim of this where he's like, "You said this and I felt like you were beating up on me." I'm like, "I really didn't mean to. I was trying to be the nice guy. Didn't come across that way." That kind of feedback. It can sometimes be hard to hear, but it can be very, very valuable. So this goes back to like it I'm going to use different words, but ruminate on it. Think about it. Sometimes in the heat of battle when you're going through and like cranking through tickets and codes and you're in the middle of like a death march, it is very difficult. But I this is why I love retrospectives and I think you should do the same. Spend a little time listening to the feedback that you got. Yeah, you're not necessarily going to respond perfectly in the moment, but later on it's going to sink in and you're going to make some adjustments. Hopefully, you're going to make some adjustments and you're going to be a better developer the next time around. I say that as a great way to close this episode because we've gone so long. I thank you so much for your time. We will be back. We are continuing to do more with AI, but obviously that doesn't shut us up fast enough. Thank you so much. Have a great day. All of the great places to contact us, go do it. Talk to you next time. [Music]
Transcript Segments
[Music]
We just hit record after all that crap
we said that cannot be recorded. Now it
can't be.
Uh I'm gonna turn a light on because
that's the way I go.
Doesn't do much, but depending on how
long this goes, how the light go. Let me
get my shuffle myself up.
There we go. Look at I've got my little
If I do this, you got a weirder lighting
situation than I do. I have it on my
left and as the sun goes down I just get
darker on this side. But all right,
that's clear. It's all fuzzy. I got like
all windows here. So it's, you know, I
get pretty and it's all like white and
and gray. So it all like reflects in
here now. So it is what it is. Although
now I look like I got like a black eye.
I should like I just like sit like this
the whole time. You get sucker punch in
hockey again? Yeah.
be a good excuse, but no, I do have what
you can't see. Oh, no, it's over here.
Yeah, you can go. That's my good thing,
bad thing. Um, I'll I'll share that
later. I don't want to spoil.
Um,
no, I have not gotten sucker punched in
hockey. Actually, I've had more sucker
punch damage done in handball in the
last six months than I have hockey. I
don't think I've been smacked in hockey
near as much, but I've run into partners
and a big partner twice now and it's
both times I was like, "Ow, that hurt."
It's funny. You seem to get hurt more in
handball than I ever did playing
raetball. Oh, that's cuz handball is a
real sport. Wacket balls raetballs for
like wusses. So,
should play me sometime. We'll see how
that goes. The guy that I keep running
into is a handball player from uh he's
been doing it for like 30 years now. And
the reason he's a handball player, he
was a converted raetball player. And
there's this old guy. Sorry folks, I'm
just gonna share stories. There's this
old guy, his name's Dick Fitch.
Actually, he's passed away many years
ago, but he was at the time he was like,
I think he was in his 80s, maybe late
70s,
small little wiry guy. And uh he would
just pick on this this buddy of mine
that was a he was a raetball player. and
he had no idea who Dick was. But Dick
would just be like, you know, you could
never survive a handball match. You
could never survive. And he would just
do that over and over and over again.
And eventually my buddy was like, "All
right, I'll play." And he got smoked. A
year later he was still getting smoked
by Dick. It was like, you know, he was
an old guy, but he was crafty. He knew
how to play the game. And, you know,
since then,
we have had a we've had a, you know,
stalwart. This guy's been playing
handball solidly for, you know, 30 years
now. And he converted from raet ball. He
still talks smack to raetball players.
He'll occasionally play, but he
converted over and he's like, "Nope,
it's a it's a whole different game. I'm
never going back." So,
I used to play a long time ago, but then
I got into raetball and I liked raetball
more for some reason. Yeah, tried
raetball a couple times and was never
never as big a fan.
And no, I'm not doing pickle ball yet.
Although gosh, there was I went by a
place that was called like I think it
was I think it was like a big honking
building. I think it's like pickle ball
world was on the side of the building.
It like tons and tons of courts here. So
apparently that's the thing to do. I've
tried it. Uh our local brewery actually
has two pickle ball courts, a volleyball
court, and botchi ball. And Oh wow.
Let's just say we played pickle ball for
10 minutes and we went to botchi ball.
Yeah. Pickle balls work. That's like
it's not so much work, but it's I don't
know. Maybe it's just I'm not used to
the pedals, but the pedals are more ping
pong pedals to me. And
I'm not used to like a solid pedal. Like
if it was like a tennis racket or
something like that, it maybe. But it's
just weird. I don't know. You got to get
used to it, I guess. But botchi ball is
still a lot of fun to me. Yep. All
right, folks. Sorry for that. Actually,
I'm not This is bonus. This is bonus
material. You get to see behind the
scenes. And now I got to check my clock
to see where the heck. Wow, we are way
into this. Although this started before
the recording, so we're okay. All right,
we're continuing our AI journey. And
this one I am going to do,
what did I just do? I asked it um
turning feedback into future success, a
guide for developers. So, uh this should
be a fun one. Uh it's got like it's got
more topics than we're going to actually
get to. Yeah, it's got seven of them.
I'm sure we're not going to get that
far. So, we are going to dive right into
this. Let me reduce this. Let me
probably need to start tweaking it to
give you like the top five, top like
after you get the list, but tweak it and
say, "Hey, all right, now give me like
the top four." We don't get through like
two or three. I just like having extra
that's bonus material for all of these
people that are spending extra time
listening to us talk about botchi ball,
handball, and all of those kinds of
useless things. All the other stuff that
we bring to the table. Um,
what was I going to say? Okay, I was
going to sing our praises, but I'm not
going to because that's just selfs
serving and I'm not going to do that
right now. I'm going to go one I'm going
to go I can't even start with a three, a
two, one. 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're going through those
past topics and we're basically taking
them, throwing them into AI and see if
that gives us better discussions.
Spoiler alert, it has given us really
cool things to talk about every single
episode and I'm looking forward to
continuing to do that. Uh, currently
we're using chat GPT. We may switch to
another AI engine just for grins or that
may be bonus material sometimes. We'll
see how that goes. Uh, we've never
gotten through the points, but we're
going to see if we get there today and
probably we'll fail again. But before we
do that, I'm going to introduce myself.
I happen to be Rob Broadhead, one of the
founders of Developer, 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've got 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 road map 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 thus making
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. Uh, good thing is, uh, 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 like that. I didn't like
the shave. So, the good news is they got
a new razor. Uh, 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."
Bad thing is is I shaved with a new
razor today and so now I got like a
really nice little cut where I forgot I
had a new razor. So be careful with
sharp 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 Michael Malash.
I'm one of the co-founders of developer
building better developers. 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.
Well, good thing is I also have that
hairy uh 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. Um,
we're getting closer to July. It's
sunny. It, 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.
Uh, yes. Um, 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. Uh that one was free.
The next one obviously we more than
happy to take some money product
whatever. Uh 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 shoved that
into chatb chat GPT and it gave us back
a series of uh 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 we get into that, in all
our prior ones though, you've given us
how chat DP 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. That'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 ner
podcast episode titled here's a
structure breakdown of topics and
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
item one 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 uh 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 um wow that would be a cool
little segment to do I don't think I've
done that. Um I don't think I've got
anything like that that we've ever done.
That would be sort of cool. Um I like
the with this one. I really like the
idea of like debugging yourself. And
this is actually how I feel when I'm
doing and it's I guess it's a little
more than that when I go into code
reviews and especially when they're the
ones that are uh 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. Um while those are useful I
found that the inperson they tend to be
um there's more feedback. I tend to get
more useful feedback and it's actually
uh 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 um you
know 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 when
we 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 testing 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 um mid
you 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
you know isn't really documented, but
it's 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 it
forces crossraining 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. Um
that I I asked him to do it and he may
not feel comfort. 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 uh 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 that Yeah.
And maybe it's just us. Maybe not
everybody sees us, but we know we make
mistakes. We make typos. I don't know
how many times I've seen commits in and
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.
Uh 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, 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 two uh 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. Um, I want to I want to like
talk about that mindset real quick,
though, because I this is like 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 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 you know 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 you know
attacking or I'm not intending to be a
jerk it just come and we will say
different words than that, but but I cuz
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 it's 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 you know maybe you're uh
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 it in a way
that people receive it and so I I want
us like Michael's trying to be nice but
also let's you know 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 cuz I felt like
that was a good time. Go ahead.
It was and I mean and you know not
throwing salt on the wound but you know
we actually had a start of 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 it 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 or trying to
test a ticket that was completed looking
at the ticket and well the developer Rob
uh worked the ticket. I came back in
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 and that's
where you have to make sure you're
talking to the right people, you're
understanding the right priorities. But
that 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 might be
some miscommunication in a ticket."
The top real quick, I want to add on
that is note 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 the certain way, but when I'm
coding, it's like, oh, that's out the
window. Got to get work done. Got to get
it 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. Fix that.
But code reviews. So I'll I'll real
quickly talk about code reviews and then
we'll move on to the next point. Code
reviews, like Rob mentioned, are really
good tools. One, to catch things that
are missed. Two, 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.
Two,
did you commit all your code?
Your build could still pass, but you're
missing some configurations or something
behind the scenes that your tests don't
touch.
And three, code 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 they're not
switching over. They're not crossraining
enough on the code or the application.
That is where code reviews are perfect
for this.
Ensure everyone spends a little bit of
time, 15 minutes to a half an hour
depending upon 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
bucks 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. It's 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 quick things on that is
that means what he just said is
absolutely spoton. 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 test and then it fails it and
stuff like that and it's not you know a
person's fault. We don't seem to 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 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, that's 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 and 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 would 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 team me 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 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 health care 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 with 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 soap box and I'll 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. Uh, 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 better rip that band-aid 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 customerf facing.
Customer is always right to a point
because you need one depending upon
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 that situ
your situation will constantly change in
software. You could think you're always
a coder or a 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'll 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
wanted." 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. 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'm
we're not gonna get too deep in this,
but bullet point one, 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
obviously 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
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 like code 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 qu
clarifying questions. We have to know
that like this goes back to go to loser
think, go to philos 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 why 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 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 ego's 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 it? 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? Well, it 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 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 is
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 bit. 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.
100% agree. Uh I will throw a little
bonus thing out there. There was a and
I'm going to name names. Uh there was a
guy that I worked with that I he said a
throwaway phrase one time that really
sticks with me because I think it's very
important for us to think about. Uh his
name is Greg Immany 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 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, "You're
your code sucks. This breaks. This is,
you know, but own it." Like I have I've
got a customer that I've 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
infoddevelopur.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, 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 [email protected] is a great
way from email. You can also reach out
to us. We've got all kinds of places on
developer.com. You can give us feedback
wherever you listen to podcasts.
Whatever your catcher is, you can leave
us feedback. positive, negative, great.
Uh YouTube, the developer channel. We
are on xdevelopure
and out on Facebook. We also have a
developure 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 has
gone a little bit 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 next time.
Bonus material. Sorry for you YouTube
people because you get even more.
You've been hanging out for a long time
and yet we're still here.
Oh, wait.
Scratch that. I want to go ahead and uh
the bullet points, right? The other
ones. Let's see. What do we have? We had
three more bullet points. Wow, we got
nowhere on this. Um, actually, we those
are really good. So, I'm going to fly
through these and I'm going to give you
one to throw on. So, you may take notes
fast. Turning feedback into growth.
Identify what you what you control and
make a small action plan. Example, you
got feedback about confusing APIs.
Improve docs. Add examples. Refactor.
Convert feedback into learning sprints.
Refine your skills or workflow. Wow,
that's a neat one. Build public change
logs for side projects. Show you,
listen, and act. feedback loops and side
hustles. Early users are your free QA
team. Embrace that. And every piece of
user feedback is a chance to increase
value and reduce churn. Use NPS surveys
or interviews to proactively pull
insights. Quote, "Side hustles don't
fall fail from lack of code. They fail
from ignoring feedback." Wow, that's a
good one. Uh giving feedback as a
developer. Be kind, specific, and
actionable. Use I notice or I'd suggest
instead of this sucks. Give feedback in
the spirit of improvement, not ego. This
builds trust, better teams, and great
clients. Discussion prompt. What's the
best piece of feedback you ever received
that changed your dev journey? Creating
feedback. Creating a feedback culture
for yourself. Regularly use for impact.
Ask for input. What's one thing I could
improve? Use introspective and solo
project or retrospective and solo
projects or journaling for feedback. I
need to learn how to read better. Small
text. My bad. Normalize feedback in your
collaborations, especially for side
hustles and freelance clients. Call to
action for listeners. Challenge: Ask one
colleague, client, or user for feedback
this week. Write down what you learned.
Share your most painful but powerful
feedback story with #de dev feedback
win. I guess we should start looking at
that. Tease next episode from good to
great leveling up your dev workflow. Oh,
I should probably tease that, but I'm
not going to. So, your thoughts on
these? That was a lot. So, I'll take one
uh early one that you threw out there.
Uh your early te your early users are
your testers. Be careful with that.
Don't be a Windows here. Let's push our
software out and for six months use our
users as our testers to fix bugs or Path
of Exile 2. I'm calling you out. Don't
go pre-BA
or whatever. Yeah, I guess they're in
beta or whatever it is. Uh, early
access. Don't go early access and then
expect a million users to join your site
and guess what? You're in early access.
No, you're live.
You need to understand if you do rely on
your customers or your users as your
testers, you better pay attention
because suddenly your application may
not be this application that you're
building anymore. It may have
drastically changed.
Be very careful with that. an early
unnamed project that I was part of. Um,
we used to kid that we skipped the
savings and pass skip the testing and
pass the savings on to you. Um, and that
was uh, you know, cuz we did we cranked
some stuff through and we also we're
built on top of a product that also did
that very often and so we would refer to
them as doing the same things that we
were we had like 250 tickets open with
their software and they knew it. They
hated hearing from us because we tested
their stuff more than they did. Um,
I will go with I'm gonna share this one
as a bonus because I think it is
it probably says more about me than it
does anybody else, but that's okay. I
think this is something as developers we
can learn from. Ear feedback that really
touched me, I guess, in a and not
necessarily in a good way. early on when
I was very young because this is
yesterday. I'm still very young. Um I
was working with a guy and he lit he was
very brutal, we'll say, and you can you
can gauge this, but he said, "You know,
I thought you were an I thought
you were, you know, you didn't know what
you're you were just over the top and
just being a jerk about stuff." And then
I realized you knew what you were
talking about.
Now that's in many cases and pardon my
French obviously but uh in many cases
that was very could be considered very
harsh but what I took it as which is how
it was attended because this guy I
respected him and his feedback was you
have a lot to say
and sometimes you don't say it the right
way or in his case I'm sugar coating it
he probably said never do you say it the
right way you come off in a way and part
of it was because I was a young kid and
I knew a lot of stuff and I would just
jump right into a conversation and
people didn't expect that. So I could
say well that's everybody else and part
of me did and that's why I went back and
got a degree and some a higher degree
and stuff like that. But there was
another part of it was how I submitted
that information, how I carried myself
when I said it. And it is something that
has stuck with me through my life. And
it's honestly
I'll just like throw it open. It's like
that's still who I am is like you may
note because I have a bit of a I have a
personality that sometimes precedes
everything and my mouth is right there
with it. And so sometimes it's a little
bit much for people. And Michael's
smiling cuz he has been a victim of this
where he's like, "You said this and I
felt like you were beating up on me."
I'm like, "I really didn't mean to. I
was trying to be the nice guy. Didn't
come across that way." That kind of
feedback.
It can sometimes be hard to hear, but it
can be very, very valuable. So this goes
back to like it I'm going to use
different words, but ruminate on it.
Think about it. Sometimes in the heat of
battle when you're going through and
like cranking through tickets and codes
and you're in the middle of like a death
march, it is very difficult. But I this
is why I love retrospectives and I think
you should do the same. Spend a little
time listening to the feedback that you
got. Yeah, you're not necessarily going
to respond perfectly in the moment, but
later on it's going to sink in and
you're going to make some adjustments.
Hopefully, you're going to make some
adjustments and you're going to be a
better developer the next time around. I
say that as a great way to close this
episode because we've gone so long. I
thank you so much for your time. We will
be back. We are continuing to do more
with AI, but obviously that doesn't shut
us up fast enough. Thank you so much.
Have a great day. All of the great
places to contact us, go do it. Talk to
you next time.
[Music]