Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit one of their most memorable discussions: “Psychopaths, Scenarios, and Tough Coding Challenges.”
From half-baked requirements scribbled on napkins to “just a small change” that rewrites half the app, they dive into the absurd, frustrating, and sometimes funny challenges every developer faces. With humor and real-world insights, they explore how to survive tough coding challenges, cope with the madness, and turn chaos into developer superpowers.
🔑 What you’ll learn in this episode: • Why unclear requirements lead to “psychopath” paths in coding • Common tough coding challenges like nested if statements, gotcha interviews, and vague specs • Developer war stories: missing semicolons, “everything urgent” bosses, and merge nightmares • Coping strategies: rubber duck debugging, snacks & caffeine, and knowing when to step away • How every challenge helps you level up as a developer
👉 Share your own psychopath coding stories in the comments—we’d love to feature them in a future episode!
đź”— Explore more episodes and resources at https://develpreneur.com/tough-coding-challenges/
⸻
0:00 – Intro & catching up 2:00 – Good Thing / Bad Thing segment 6:30 – Revisiting “Psychopaths” scenarios 10:00 – The Psychopath Starter Pack (napkin requirements, legacy code, gotcha interviews) 15:00 – War stories: missing semicolons, urgent bosses, merge madness 22:00 – Coping mechanisms for tough coding challenges 28:00 – Snacks, caffeine, and developer sanity 33:00 – Turning chaos into developer superpowers 38:00 – Debugging skills and learning from mistakes 44:00 – Wrapping up: sharing stories and feedback
Transcript Text
[Music] All right. So somewhere we hit record. Uh maybe right there. This one's psychopaths scenarios and tough coding challenges. Um this will be interesting. Okay, let's see what it says because I'm ready to dive right into it. And so here we're going to go with our typical I'm even going to do it. Hello and welcome back. We are continuing our season where we are doing things with AI. Specifically, we are doing a couple seasons back and we are looking at the titles and we are sitting there going say going through those and saying all right let's just take that title and the the general synopsis the concept of what building better developers are and we are getting some good feedback and then going from there. Uh this episode we are going to I'm not going to share with you yet. I'm going to introduce myself first. I'm like I don't want to spoil it too much what our topic is. Uh the guy that's not spoiling it, his name me is Rob Broadhead. I happen to be a founder of developer. Also a founder, the founder of RB Consulting where we are all about helping you do technology better. I've seen so many things go arry, so many things go off the rails. Uh been a part of projects that somebody else started and then we had to come in and clean up the dumpster fire that was left behind. And so all of that across a long a lot of different industries. We found some great ways to approach whatever your problem is. And it all starts with understanding your business because if if we don't understand your business, we're really not going to understand the problem. So get down sit down. We're going to talk to you about your business. Then we're going to look at your pain points and where we can alleviate them. What are your processes? How we can make them better through simplification, integration, automation, innovation. We're gonna find ways in our toolkit to help you create a a custom recipe that is going to be your technology roadmap and then we can help you execute it or we can just say hey here's your road map enjoy your journey or any sp part part in between because we are here to help you do business better thing bad thing uh this is a fun one because there's like sometimes life dishes out a little bit of a lesson you know things like that um so I I I had a dental thing the other day and I was a few minutes late and they were basically like come back another day and I was not very happy because in the past they have not been very respectful of my time or anybody else. It's one of these places where I've spent large large amounts of time sitting in the waiting room before they ever get around to being like, "Okay, Mr. Broadheads, you can be seen." And as I was fuming, not really fuming, but as I was annoyed by it, we'll say, I started thinking. I was like, "Well, maybe this is a good sign." So, the bad thing was I was late. I lost a bunch of time. I lost probably an hour back and forth traveling. The good thing is I think it was a good sign because I looked a little closer at their stuff and my complaint that had bothered me so much in the past about all the times they've wasted is like now they have changed a lot of their procedures and policies. So, they are doing their best to stay on track. And of course, you know, stuff happens and things get off track, but it's good to see that, you know, businesses have evolved and they've done things better. So, you know, it's one of those that yes, I was a victim of my own uh my own lateness or whatever, but that also means that there's a lot of other people out there that their time has not been wasted. And now I'm done wasting your time. And I'm going to let Michael introduce himself and waste some of your time. Hey everyone, my name is Michael Wash. I'm one of the co-founders of Developer, Building Better Developers. I'm also the owner of Envision QA. We help startups and growing companies improve their software quality through services like test planning, automation, and release support. Why do companies work with us? Because buggy software costs you time, money, and customer trust. We make sure products are reliable before they launch. Help teams move faster and avoid costly mistakes. If you're building something great and want it to run smoothly from day one, visit envisionqa.com and schedule a free consultation under contact us. Good thing, bad thing. So, I'm going to start with the good thing. I have been struggling for four weeks now on this particular uh problem uh at work. And today, all of a sudden, we the light bulbs went off. We figured it out. Uh all was happy and good. Found out that what I had envisioned the solution to be 3 weeks ago was correct. The bad thing was all the steps provided to me on how this piece of software worked and how where I was supposed to plug this in was not the correct place to test. I was given the keys to the to the house, but I was sent to the wrong house. Uh, literally I was in there I'm like doing exactly what it says to do. No, the steps are two places further into the application to actually trigger what it was that I needed to test. When you don't know the software and you're relying on other people to help you, it's really hard, especially when it's a legacy application and there's little documentation to get through some of these problems. Sometimes you just have to bang your head against the wall. But sometimes you do finally get through it. Like today we had a round uh round table meeting, walked through it and they're like, you know, maybe that's not the right place. Why don't you go over here and try this? And sure enough, boom, it worked. And it's like done, checked in. I'm going to lunch. So this episode I actually changed gears a little bit. Uh we started out with uh let me get the original title because I didn't spoil it earlier. Uh the title was psychopaths scenarios and tough coding challenges and I said all right give me an episode topic and then I did something extra this time I did a thing as some people like to say is it said hey would you like me to make that do you want to make this more seriously educational or light-hearted and entertaining and me being me lightigh-hearted and entertaining so this is what we got that's why Michael you just got a second uh up updated did bunch of notes. So, it says, "Perfect, because GPT likes me. I'm sure it never treats you that well, right?" It says, "Let's lean into the fun side of psychopaths coding challenges. Here's a light-hearted and entertaining spin for your development or episode." Fun intro hook. You ever open up a juro jurro a jur ticket and think this was definitely written by a psychopath? Not exactly where we went. Uh, one second because it is there. See, it's a good time to talk about psychopaths. And uh, okay. Open. Ever open a Jurro ticket and think this was definitely written by psychopaths. Welcome to the world of impossible coding challenges, unclear specs, and those gotcha interview puzzles that feel like they were designed by your evil twin. Now, I'm going to start with this. The original psychopaths we talked about actually had nothing to do with this. So, this is going to go down a path, no pun intended, that we actually never went down with this one. So, this is going to be a fun one because when we talked about psychopaths, we're actually talking about testing and uh back the inverse or the opposite of happy path. We talk about hypath. You talk about the paths that you normally go through. And it actually was psychopaths that we as we talked about it were those ones that we have no idea how anybody gets on that path. And yet they do. Similar to almost similar to what Michael's uh description was about his good thing, bad thing. So I'm really looking forward to this one because this is completely different from where we went with it. The psychopath starter pack. Uh this is the segments that it's got. First segment, half a requirement written on a napkin. Legacy code with seven levels of nested if statements. Just a small change that spirals into rewriting half the app. Coding interview question. Write a compiler from scratch on the whiteboard in 30 minutes. Laugh with the audience. Exaggerate the absurdity. Make it relatable. I do want to talk about this a couple of these things just because again we haven't. Uh I want to go to the coding interview question. I think we have I know we have mentioned interviews and how to approach them and things like that. Uh particularly if you go back to the pre-developer world when we had it for recruiters and some some of that content that has flowed into the developer side as well. If you're doing a technical interview these days, there are tools out there that will help you do a technical interview that make sense where it's like, oh, sit down and write some code. Those are the kinds of things you're going to help because you if you're going to try to figure out like if this person could write a compiler from scratch in 30 minutes on a whiteboard, then maybe that is your very very niche thing you need to do. But I don't know that anybody does because if so then they just wrote a compiler in 30 minutes and now they're done and they don't you don't really need to hire them. You need to worry about figuring out how people think when you're on a when you're on the flip side of that when you're interviewing. You need to make sure that you're connecting to the people that you're working with. You're understanding the chemistry that's going to be there or not. And then you're also understanding what how they would like you to think. Does that make sense to you? Are the problems that they're trying to solve the problems that you are good at solving? the the whole like the gotchas and all these kind of there's been so many I'm in too many technical interviews where it's like you know what are the three different versions of this command and the order that you can do to the parameters and it's like dude have you ever heard of Google do you ever especially IDs they autocomplete 90% of the time now so that stuff just seems so not applicable to what you're trying to do um before I toss it back to you seven levels of nest and if statements is actually goes to back something we talked about before. If you're using stat static code analysis tools, then it's going to flag stuff like you have a ridiculously over complex procedure function chunk of code. Fix it. And those are the kinds of things that I think you will thank yourself that you you straighten that stuff out. Yes, the first time through you were probably like just, you know, bull in a china shop trying to get the salt problem solved. But once you do, you need to address that kind of technical debt sooner rather than later because it is going to hurt you for maintainability, scalability, reliability, quality, all of the things that are important with your code. And now I will step off my soap box and let Michael step up on his. >> So it's funny, you know, the seven levels of if statements. A lot of times you run into this situation because of the half baked requirements or half of the requirements written on a napkin because you have partial requirements. And if you're reading the requirements and you have to ask yourself what if this or what if that or I get to this point and it goes this you know which way which path do I go? That's sending you down if then statements. You need to clarify those before you start the work because if you don't, you could write a solution that doesn't solve the problem. You could be solving your interpretation of the requirement, not the requirement itself. Uh it's interesting with that though too. Um so the other thing that was on here, you know, just a small change that spirals into rewriting half the app. If you are not using source control, if you're not using something like GitHub or if you're just using Notepad and you're not using a modern IDE tool that has some code review, code repository um built into it, get it, start using it using these tools as you're working the requirements, you can click a little button and say, "Hey, what have I changed for this uh for this code?" If you see one or two files, a couple of file changes, cool, you're good. If you see 6 or 7 8 9 10 11 files start to build up, you may want to pause and say, "Wait, why am I making all these changes? Why am I going down this rabbit hole?" By not doing that, by not checking that occasionally, you could go so heads down that you have rewritten half the application and not even be aware of it till you get to the point that you check in the code. So doing the code checks as you're writing the code is really good. And then the last little note I'll throw out there is unit tests. Write your unit test to go with this because if you are writing tests to check your code as you're writing it, you're going to find very quickly that if you're writing 20, 30, 50 unit tests, you've written too much code for this requirement. The co the requirement was either halfbaked or not flushed out. So, moving on. It says, "Next one, developer war stories." Uh, share funny nightmare challenge stories like, "We found a bug. It was a semicolon two days later. The spec said user friendly, but no one could define what that meant. Boss said it was urgent, then went on vacation. Invite listeners to submit their own psychopath scenarios for a future episode." Um, let me go with the last one about the boss saying it's urgent. I've one of my favorite war stories um from many years back now. Uh I was working with a group uh also a boutique consulting company matter of fact and we had a customer and was just wearing one of our main developer out or like senior developer out which is all these requests and so finally we sat her down and said hey we need some prioritization we need you know let's talk about what is urgent what is you know nice to have or what do we need to have but it's not like immediately what is nice to have and what is like ah if you can get to and stuff like that. And so we had a nice like we had the the whole team in we had like an hourong conversation stuff like that. She's like cool I get it. Great. And so you know week goes by come in Monday and we have got 14 new issues and every one of them is labeled urgent. It was like you smack in your head because you're like you don't get the point. If everything's urgent then nothing's urgent. You know it's like this is the boy who cried wolf. is the chicken thinking the sky is falling and stuff like that is it's like you have got to have some level of sanity to your prioritization of stuff and I think this is the kind of thing that do these are the kind of things that do get us into these psychopath scenarios that that chat GPD has come up with where you've got you've got competing sometimes competing requirements and they're both you've got to have both of them and it's like Sometime this goes back to some of the things we said before. Sometimes you have to say no. Sometimes you have to say look you cannot do both. You can't you get one or the other. You cannot just say well I want both because you can want it all you want but that's like sometimes time space you know equilibrium the balance of the universe those kinds of things cannot be maintained if you have both. It's just there's certain things that don't go together or there's going to be a lack of resources or all the other reasons that you can have that is why we actually have prioritization and sometimes just like you hear they said you might have to define what user friendly meant. You might have to define what priorities mean which is probably wise every time I see a project book that talks about prioritizing stuff it actually gives examples of priorities and what those kind of priorities look like. So that was mine. Where do you want to go on this one? >> So, I'll take the first one. We found a bug. It was a semicolon two days later. So, I think it was in the last episode we talked about llinters and you know code reviews, code repositories. Oh my god, if you are not using llinters and everyone is committing their code, it's in a different format. You have no idea who's making what changes to your code. And so many times I've worked in many companies and you go through enough of these that eventually the organization finally says, "Hey, we are instilling coding standards. If you do not follow this, you are going to be shamed." And unfortunately, this is one of those where shaming is almost the only way to make them stop if you can't get them to stop. And it is a pain. The problem with this one though, it it's not just the llinters, but sometimes you run into situations where you have very large complex code and if you have too many people in that code making changes at the same time. When you get to the code commits and you have people merging code, code gets missed. And if there are not unit tests wrapped around that code, it is missed. And it will be a day or two or a week later when your testers get in to start testing it. Pray to God it doesn't make it to the customer. But hopefully your testers will catch this. But you're going to find that whoops, a piece of code got missed in the merge or oh I overloaded or overwrote my change on yours. So oh my god, you just got to be very careful when dealing with your code. Uh and and you know Rob mentions this all the time. You need to be using code repository GitHub and and use llinters. Please use llinters because they will be a huge um savior and for your sanity and your code hoping mechanisms for surviving the madness. This one's actually pretty interesting. Humor. If you don't laugh, you'll cry. Or both. Snacks and caffeine. Every bug fix deserves at least one cookie. Rubber duck debugging. Sometimes the duck has better answers than Stack Overflow. And the ship it and run strategy. Just kidding. mostly. Um, we actually had one of the first places I worked, we we would joke about that we are going to skip the testing and pass the savings on to the customer and that was it was very there was way too often because we were doing commercial software. We were we had to like crank it out and sometimes we had to crank it out faster than we wanted to. But uh and we also this was this is a while back so the uh we had QA people there was testing and things like that but it was not to the level that it you know it is today. Um and that was a that was a challenge. I love the idea of rubber duck debugging. Um I have no idea what that means. Uh, but I do think that I'm going to take it in a way of, you know, sometimes it's um ask somebody just random, you know, like or like maybe you've got a family member that's sitting there. It's just like they're not a developer, just like what do you think about this? Uh, it's the same way as like stepping away or, you know, just do a random search. Just do some stuff to get out of the out of the madness and out of what's going on and maybe you'll find a way to solve whatever that problem happens to be. This is, you know, we're talking about the psychopath. We're talking about the craziness. We're talking about the things that are just going off the rails. Sometimes you need to walk away from the train crash for a little bit before you can go back to it and go, "Oh, here's how we need to clean it up." Things like that. Sometimes it's just take a deep breath. Sometimes it is like just all right, I'm going to go and I have been there where it's like, you know what? I'm just going to go to lunch. I am just going to go like hang out at the water cooler for 15 minutes. I just I need to get away because sometimes your sanity is going to get dragged into that, you know, dumpster fire if you don't watch out. How about you? Coping mechanisms, maybe some of your favorite ones. >> Oh, so if you don't laugh, you'll cry or both. Um, so I I kind of want to call out, you know, your um, you know, the ship it and run it strategy. Video games today are a good example of this. So many games are shipped before they're done and they go through a series of patches or what's called, "Hey, let's do a uh pre-release or it's in beta, but hey, we're collecting your money anyway." Microsoft is another good one for this because how many times has Windows come out and it's really not stable for 6 months because hey, we need users to test our software. But I I start there because humor, you know, if you want to sit down and you release software and you sit down and you start to work on it and it's working, it's like great and then all a sudden it crashes, you know, why did it crash? Oh, hey, maybe you're a shopping site and you just found out that your site cannot handle Cyber Monday or Black Friday and you just are down. You're like, oh my god, what am I going to do? So, you're going to cry, but when you get through it, it's like, hey, there was kind of a good thing to that. we were so popular that they took our site down, but next year we need to be better than that, you know. So, so you get through it and you laugh about those. But the fun the last little fun one is the snacks and caffeine. So, I I have been an abuser of caffeine for years. I am down to reducing that uh horribly. Uh not horribly, but I've reduced the horrible abuse of it to something that's more manageable like one cup or one four cups a day tea bag. But the snacks. So my little like I guess treat, I have a jar of Jelly Bellies. And when I solve a particularly difficult problem, I go to that jar. I get a Jelly Belly. Now I You can very easily eat too many of them. But if you go to, hey, when did I solve this? You know, something good, it limits how often you can go to it. you you kind of have to set that bar a little high so you don't basically abuse your treats. >> Uh yes, I've done that in the past. I uh got it when I was working at a company that had we had a a drugstore down the street and people would regularly get a big old bag of various chocolates and stuff like that. So I'd be sitting, you know, there and and so we all started to get them. So whenever you get it, I get like a big old bag. I'd throw half of it in the front desk. I'd be there for people that came by and the rest would be sitting at my desk and next thing I know I'd have a little bucket there and I'd be like, "Oh, I'll try that. I'll get that." I do that around Christmas time every year, too. I'll go get some nice little Christmas mints and have them there. And uh I I probably need to set the bar higher for when I'm going to actually go for a treat on those things. Um turning chaos into superpowers. I do want to do this before we wrap up because it this is I think the important part. Every tough challenge secretly levels you up. Documentation detective. You can now read ancient high hieroglyphics like cobalt. Uh debugging ninja. You can spot a missing bracket from 10 feet away. Interview survivor. Nothing phases you after solving fsbuzz with dynamic programming. I think this is this is the key is we're going to have problems. We're going to have stuff go off the rails. We're going to have dumpster fires. We're going to be we're going to be going off the rails over the cliff while we're still trying to build stuff sometimes. But what doesn't kill you makes you stronger. We're going to go with that one. Um, it does make you better as a developer is that as you go through these things, you're going to figure out what to look for. You're going to know what the problems are. This is honestly, this is why RV Consulting is what it is and why we do what we do and why we are actually pretty good at a lot of the things we do because we have seen some really nasty situations and we've said, you know what, we've seen this before. We usually we know we're basically people are going to hide the skeletons. We know what are some of the problems that you're going to have. And this does vary based on your technology, your line of business, and stuff like that. There are certain things that are just the norms. So, if you're, and you probably know that if you've been doing this for a while, pick your language that you've been in, you know that there are for yourself, there's certain bugs that you're almost always going to do. There's typos or something like that that you're going to miss. Other people, when you're reviewing code, you're going to be like, "Oh, yeah, they missed this and they missed that, and these are the kinds of things to look for." You learn how to look for the the common things. And now granted the the psychopaths can be a little bit different where you're like, "Wow, I have never seen that before." But then the good news is the next time you will have seen that before cuz now you've seen this one. So you can sort of grow your list from uh common mistakes to uncommon mistakes to unique mistakes. But at least when you see them, a lot of times you'll find out that will even if it's unique, it will give you some skills that will help you find something close to that. and the next time you find something unique, you will be able to get it faster because you you've attuned yourself to maybe thinking outside of the box. So, what are some good takeaways for you or some maybe superpower that you see coming out of this? >> So, what number one of course is the debugging? As you learn software and you go through more and more projects and build different more complex systems, you're going to get better at spotting problems. um semicolon if you're using modern IDEs will tell you almost immediately. So hopefully that's not your biggest uh issue that you run into, but there are a lot of hidden things that getting better at writing unit test debugging code uh is huge. So I highly recommend learning to debug your code. Try breaking it. You know, if you haven't broken your code in a while and you're relying on the IDE a lot, uh, best way to test it is to go to like Notepad, go to Vim, write your code, and try to compile it from a command line compiler and see if it works. Chances are you probably forgot something and it broke. But that is one of for a lot of us uh, old fuddy duddies, uh, you know, we didn't have IDs back in the day. We had compilers. So um this is a very good way to become very uh good at catching debugging techniques or at least understanding compile errors uh very quickly. And the last thing I will throw with this is as you learn these things, go out to things like Stack Overflow. Take the problem you just solved, go see if other people are having it and go put your, you know, put your solution out there. One, you're contributing to the community. You're getting your name out there. And two, it's out there. So if you forget maybe 6 months, a year from now, you need to go find that problem again. You may find your comment out there and be like, "Oh yeah, I remember this. This is how I fixed it." I think that's probably one of the most valuable things out of all this is being able to take that and share it with somebody else is have some sort of documentation of it because like I find that that really helps me u absorb and digest what I just went through and give something that is like now it's and it forces you to also like learn from it. So not just be like okay I fix it and I can move on. It's like, "All right, I learned from that. Here's what I learned. Lesson learned, and it's going to be helpful for you, just like any other, you know, code repository and things like that we've talked about is like you're like, "Oh, yes. I've I remember I ran into this and this is what it looked like, and this is how I addressed it." So, if there's something that looks like that, again, you can reuse those skills. One of the things you can reuse is your skill to send an email. I'm going to throw that out there because, as always, I would love for you to send us something [email protected]. would love to hear your feedback, what are your thoughts, positives and negatives. What do you like? What don't you like? What did you like to see us talk about next? Because we do have plenty of stuff coming up. Uh, and we are also running out of time on this episode or this season. I think we got a few more episodes now left. We're still going to break through them, but then we will be into the next season. Who knows what we're going to do then? We don't even know. I think last time we just w we were winging it and then came in and like, "Hey, this is the episode we're this is the season we're going to do." So that is how prepared sometimes we are coming into this. But that's because there's just so much so much information out there. There's so many different ways we can go. As you've seen from this, we have left stuff on the table every single episode of topics that we could talk through. Uh sometimes they've been entire seasons that could come out of some of these topics. So love to hear from you because you are the reason we do it. You can leave us uh feedback, comments, stuff like that on the developer site. U feedback anywhere on any of our articles or the contact us form. You can check out the developer page on Facebook. You can see us at developer actually listen to us I guess or whatever. Read our our thoughts at developer onx and u just reach out wherever you find all the great ways to communicate. We're probably out there somewhere. Uh anywhere that you give podcasts, leave a leave us a note. Also, I'm can't forget to list the uh YouTube channel uh out on YouTube. We have the developer channel and there's tons and tons and tons of stuff out there. I just I'm I'm sometimes shocked at actually often shocked at how much stuff we have out there and it's useful. It's amazing how often I'll go search for something and it's like, oh, we wrote that. So, good stuff to know. Hopefully, it's helpful to you. Let us know how it is and how we can make it better. As always, I just want to say we appreciate so much the time you've given for us for just hanging out with us and uh for becoming a better developer because you becoming a developer is a better developer is going to make others around you and eventually it's going to come back to us and we're going to be dealing with projects that good developers wrote. So, we're not tearing our hair out trying to figure out where the documentation is, stuff like that. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. bonus material. >> So, I want to start by all you listeners and viewers out there, send us your psychopaths. Tell us, you know, some of the challenges, some of the things that drive you crazy or that have gone off the rails. You know, let us know cuz this is one topic I think anyone can have a story about. Uh, just kind of go through the list and, you know, let us know. Um, but with that being said though, you know, psychopaths are not the happy past, but we we kind of diverged from the original topic from before. But psychopaths aren't always just, you know, bad. You know, they could still be happy past, but they could be things that take you off the rails. Again, you know, think like a choose your adventure story. If you get to a point where you c have option A, B, C, or D or multiple choice, chances are requirements aren't right. You're probably off the path. Um or you're going down the wrong path and you need to check yourself, you know, just so just the one biggest takeaway I guess of this is check yourself. Check what you're working on and check it back to the requirements. That's one of the easiest ways to make sure that you stay on track, that you're doing what needs to be done, and that your requirements are going to meet the needs of your uh user. This is why there is a why. This is what we go back to. That is your cornerstone. That is where you go back to like what are we solving? How are we solving it? And using that, I think often is going to give you like your north star as well. you know, something that's just going to say like this is how I get to anchor myself back to sanity to make sure that we're doing what we need to do and that we can, you know, have the confidence to rein in things that go off track or to realize that maybe that psychopath is something that we do have to take care of that somebody came in, thought outside of the box, and we're like, "Oh my gosh, they're not the only ones that they're not the only psychopaths out there." If you ever driven out in the driven on the roads, you know, there's a lot of psychopaths out there. So sometimes those are uh scenarios that you have to address that need to be uh part of you know your testing your exceptions and all the other kinds of stuff that go on there. I will wrap this one up because h we're just cruising right along here but I'm ready to go eat some dinner and stuff like that. So I'm going to wrap this one up. Let you go eat dinner, lunch, breakfast, whatever time of day it or just have a snack. Go have your little, you know, jelly belly because you just solved a problem. Creat yourself. go have like a little snack because you have treated yourself to some good content hopefully that has helped you become a better developer. Uh feel free to feed us with any thoughts that you have because we would love to gorge ourselves on such things and that is obviously I'm ready for dinner because I keep using those all of those little examples. That being said, thank you so much for your time. I appreciate all that you guys have done for you guys being a part of this for you guys giving us your time. As I said earlier, feedback is even more appreciated, but go out there and have yourself a good one, and we will talk to you next time. [Music]
Transcript Segments
[Music]
All right. So somewhere we hit record.
Uh maybe right there. This one's
psychopaths scenarios and tough coding
challenges.
Um
this will be interesting. Okay, let's
see what it says because I'm ready to
dive right into it. And so here we're
going to go with our typical I'm even
going to do it.
Hello and welcome back. We are
continuing our season where we are doing
things with AI. Specifically, we are
doing a couple seasons back and we are
looking at the titles and we are sitting
there going say going through those and
saying all right let's just take that
title and the the general synopsis the
concept of what building better
developers are and we are getting some
good feedback and then going from there.
Uh this episode we are going to I'm not
going to share with you yet. I'm going
to introduce myself first. I'm like I
don't want to spoil it too much what our
topic is. Uh the guy that's not spoiling
it, his name me is Rob Broadhead. I
happen to be a founder of developer.
Also a founder, the founder of RB
Consulting where we are all about
helping you do technology better. I've
seen so many things go arry, so many
things go off the rails. Uh been a part
of projects that somebody else started
and then we had to come in and clean up
the dumpster fire that was left behind.
And so all of that across a long a lot
of different industries. We found some
great ways to approach whatever your
problem is. And it all starts with
understanding your business because if
if we don't understand your business,
we're really not going to understand the
problem. So get down sit down. We're
going to talk to you about your
business. Then we're going to look at
your pain points and where we can
alleviate them. What are your processes?
How we can make them better through
simplification, integration, automation,
innovation. We're gonna find ways in our
toolkit to help you create a a custom
recipe that is going to be your
technology roadmap and then we can help
you execute it or we can just say hey
here's your road map enjoy your journey
or any sp part part in between because
we are here to help you do business
better
thing bad thing uh this is a fun one
because there's like sometimes life
dishes out a little bit of a lesson you
know things like that um so I I I had a
dental thing the other day and I was a
few minutes late and they were basically
like come back another day and I was not
very happy because in the past they have
not been very respectful of my time or
anybody else. It's one of these places
where I've spent large large amounts of
time sitting in the waiting room before
they ever get around to being like,
"Okay, Mr. Broadheads, you can be seen."
And as I was fuming, not really fuming,
but as I was annoyed by it, we'll say, I
started thinking. I was like, "Well,
maybe this is a good sign." So, the bad
thing was I was late. I lost a bunch of
time. I lost probably an hour back and
forth traveling. The good thing is I
think it was a good sign because I
looked a little closer at their stuff
and my complaint that had bothered me so
much in the past about all the times
they've wasted is like now they have
changed a lot of their procedures and
policies. So, they are doing their best
to stay on track. And of course, you
know, stuff happens and things get off
track, but it's good to see that, you
know, businesses have evolved and
they've done things better. So, you
know, it's one of those that yes, I was
a victim of my own uh my own lateness or
whatever, but that also means that
there's a lot of other people out there
that their time has not been wasted. And
now I'm done wasting your time. And I'm
going to let Michael introduce himself
and waste some of your time. Hey
everyone, my name is Michael Wash. I'm
one of the co-founders of Developer,
Building Better Developers. I'm also the
owner of Envision QA. We help startups
and growing companies improve their
software quality through services like
test planning, automation, and release
support. Why do companies work with us?
Because buggy software costs you time,
money, and customer trust. We make sure
products are reliable before they
launch. Help teams move faster and avoid
costly mistakes. If you're building
something great and want it to run
smoothly from day one, visit
envisionqa.com
and schedule a free consultation under
contact us. Good thing, bad thing. So,
I'm going to start with the good thing.
I have been
struggling for four weeks now on this
particular uh problem uh at work. And
today, all of a sudden, we the light
bulbs went off. We figured it out. Uh
all was happy and good. Found out that
what I had envisioned the solution to be
3 weeks ago was correct. The bad thing
was all the steps provided to me on how
this piece of software worked and how
where I was supposed to plug this in was
not the correct place to test.
I was given the keys to the to the
house, but I was sent to the wrong
house. Uh, literally I was in there I'm
like doing exactly what it says to do.
No, the steps are two places further
into the application to actually trigger
what it was that I needed to test.
When you don't know the software and
you're relying on other people to help
you, it's really hard, especially when
it's a legacy application and there's
little documentation to get through some
of these problems. Sometimes you just
have to bang your head against the wall.
But sometimes you do finally get through
it. Like today we had a round uh round
table meeting, walked through it and
they're like, you know, maybe that's not
the right place. Why don't you go over
here and try this? And sure enough,
boom, it worked. And it's like done,
checked in. I'm going to lunch.
So this episode I actually changed gears
a little bit. Uh we started out with uh
let me get the original title because I
didn't spoil it earlier. Uh the title
was psychopaths scenarios and tough
coding challenges and I said all right
give me an episode topic and then I did
something extra this time I did a thing
as some people like to say is it said
hey would you like me to make that do
you want to make this more seriously
educational or light-hearted and
entertaining and me being me
lightigh-hearted and entertaining so
this is what we got that's why Michael
you just got a second uh up updated did
bunch of notes. So, it says, "Perfect,
because GPT likes me. I'm sure it
never treats you that well, right?" It
says, "Let's lean into the fun side of
psychopaths coding challenges. Here's a
light-hearted and entertaining spin for
your development or episode."
Fun intro hook. You ever open up a juro
jurro a jur ticket and think
this was definitely written by a
psychopath?
Not exactly where we went. Uh, one
second because it is there.
See, it's a good time to talk about
psychopaths.
And uh, okay. Open. Ever open a Jurro
ticket and think this was definitely
written by psychopaths. Welcome to the
world of impossible coding challenges,
unclear specs, and those gotcha
interview puzzles that feel like they
were designed by your evil twin. Now,
I'm going to start with this. The
original psychopaths we talked about
actually had nothing to do with this.
So, this is going to go down a path, no
pun intended, that we actually never
went down with this one. So, this is
going to be a fun one because when we
talked about psychopaths, we're actually
talking about testing and uh back the
inverse or the opposite of happy path.
We talk about hypath. You talk about the
paths that you normally go through. And
it actually was psychopaths that we as
we talked about it were those ones that
we have no idea how anybody gets on that
path. And yet they do. Similar to almost
similar to what Michael's uh description
was about his good thing, bad thing. So
I'm really looking forward to this one
because this is completely different
from where we went with it. The
psychopath starter pack. Uh this is the
segments that it's got. First segment,
half a requirement written on a napkin.
Legacy code with seven levels of nested
if statements. Just a small change that
spirals into rewriting half the app.
Coding interview question. Write a
compiler from scratch on the whiteboard
in 30 minutes. Laugh with the audience.
Exaggerate the absurdity. Make it
relatable. I do want to talk about this
a couple of these things just because
again we haven't. Uh I want to go to the
coding interview question.
I think we have I know we have mentioned
interviews and how to approach them and
things like that. Uh particularly if you
go back to the pre-developer world when
we had it for recruiters and some some
of that content that has flowed into the
developer side as well.
If you're doing a technical interview
these days, there are tools out there
that will help you do a technical
interview that make sense where it's
like, oh, sit down and write some code.
Those are the kinds of things you're
going to help because you if you're
going to try to figure out like if this
person could write a compiler from
scratch in 30 minutes on a whiteboard,
then maybe that is your very very niche
thing you need to do. But I don't know
that anybody does because if so then
they just wrote a compiler in 30 minutes
and now they're done and they don't you
don't really need to hire them. You need
to worry about figuring out how people
think when you're on a when you're on
the flip side of that when you're
interviewing. You need to make sure that
you're connecting to the people that
you're working with. You're
understanding the chemistry that's going
to be there or not. And then you're also
understanding what how they would like
you to think. Does that make sense to
you? Are the problems that they're
trying to solve the problems that you
are good at solving? the the whole like
the gotchas and all these kind of
there's been so many I'm in too many
technical interviews where it's like you
know what are the three different
versions of this command and the order
that you can do to the parameters and
it's like dude have you ever heard of
Google do you ever especially IDs they
autocomplete 90% of the time now so that
stuff just seems so not applicable to
what you're trying to do um before I
toss it back to you seven levels of nest
and if statements is actually goes to
back something we talked about before.
If you're using stat static code
analysis tools, then it's going to flag
stuff like you have a ridiculously over
complex procedure function chunk of
code. Fix it. And those are the kinds of
things that I think you will thank
yourself that you you straighten that
stuff out. Yes, the first time through
you were probably like just, you know,
bull in a china shop trying to get the
salt problem solved. But once you do,
you need to address that kind of
technical debt sooner rather than later
because it is going to hurt you for
maintainability,
scalability, reliability, quality, all
of the things that are important with
your code. And now I will step off my
soap box and let Michael step up on his.
>> So it's funny, you know, the seven
levels of if statements. A lot of times
you run into this situation because of
the half baked requirements or half of
the requirements written on a napkin
because you have partial requirements.
And if you're reading the requirements
and you have to ask yourself what if
this or what if that or I get to this
point and it goes this you know which
way which path do I go? That's sending
you down if then statements. You need to
clarify those before you start the work
because if you don't, you could write a
solution that doesn't solve the problem.
You could be solving your interpretation
of the requirement, not the requirement
itself. Uh it's interesting with that
though too. Um so the other thing that
was on here, you know, just a small
change that spirals into rewriting half
the app. If you are not using source
control, if you're not using something
like GitHub or if you're just using
Notepad and you're not using a modern
IDE tool that has some code review, code
repository um built into it, get it,
start using it
using these tools as you're working the
requirements, you can click a little
button and say, "Hey, what have I
changed for this uh for this code?" If
you see one or two files, a couple of
file changes, cool, you're good. If you
see 6 or 7 8 9 10 11 files start to
build up, you may want to pause and say,
"Wait, why am I making all these
changes? Why am I going down this rabbit
hole?" By not doing that, by not
checking that occasionally, you could go
so heads down that you have rewritten
half the application and not even be
aware of it till you get to the point
that you check in the code. So doing the
code checks as you're writing the code
is really good. And then the last little
note I'll throw out there is unit tests.
Write your unit test to go with this
because if you are writing tests to
check your code as you're writing it,
you're going to find very quickly that
if you're writing 20, 30, 50 unit tests,
you've written too much code for this
requirement. The co the requirement was
either halfbaked or not flushed out.
So, moving on. It says, "Next one,
developer war stories." Uh, share funny
nightmare challenge stories like, "We
found a bug. It was a semicolon two days
later. The spec said user friendly, but
no one could define what that meant.
Boss said it was urgent, then went on
vacation. Invite listeners to submit
their own psychopath scenarios for a
future episode." Um, let me go with the
last one about the boss saying it's
urgent. I've one of my favorite war
stories um from many years back now. Uh
I was working with a group uh also a
boutique consulting company matter of
fact and we had a customer and was just
wearing one of our main developer out or
like senior developer out which is all
these requests and so finally we sat her
down and said hey we need some
prioritization we need you know let's
talk about what is urgent what is you
know nice to have or what do we need to
have but it's not like immediately what
is nice to have and what is like ah if
you can get to and stuff like that. And
so we had a nice like we had the the
whole team in we had like an hourong
conversation stuff like that. She's like
cool I get it. Great. And so you know
week goes by come in Monday and we have
got 14 new issues and every one of them
is labeled urgent. It was like you smack
in your head because you're like you
don't get the point. If everything's
urgent then nothing's urgent. You know
it's like this is the boy who cried
wolf. is the chicken thinking the sky is
falling and stuff like that is it's like
you have got to have some level of
sanity to your prioritization of stuff
and I think this is the kind of thing
that do these are the kind of things
that do get us into these psychopath
scenarios that that chat GPD has come up
with where you've got
you've got competing sometimes competing
requirements and they're both you've got
to have both of them and it's like
Sometime this goes back to some of the
things we said before. Sometimes you
have to say no. Sometimes you have to
say look you cannot do both. You can't
you get one or the other. You cannot
just say well I want both because you
can want it all you want but that's like
sometimes time space you know
equilibrium the balance of the universe
those kinds of things cannot be
maintained if you have both. It's just
there's certain things that don't go
together or there's going to be a lack
of resources or all the other reasons
that you can have that is why we
actually have prioritization
and sometimes just like you hear they
said you might have to define what user
friendly meant. You might have to define
what priorities mean which is probably
wise every time I see a project book
that talks about prioritizing stuff it
actually gives examples of priorities
and what those kind of priorities look
like. So that was mine. Where do you
want to go on this one?
>> So, I'll take the first one. We found a
bug. It was a semicolon two days later.
So,
I think it was in the last episode we
talked about llinters and you know code
reviews, code repositories.
Oh my god, if you are not using llinters
and everyone is committing their code,
it's in a different format. You have no
idea who's making what changes to your
code. And so many times I've worked in
many companies and you go through enough
of these that eventually the
organization finally says, "Hey, we are
instilling coding standards. If you do
not follow this, you are going to be
shamed." And unfortunately, this is one
of those where shaming is almost the
only way to make them stop if you can't
get them to stop. And it is a pain. The
problem with this one though, it it's
not just the llinters, but sometimes you
run into situations where you have very
large complex code and if you have too
many people in that code making changes
at the same time. When you get to the
code commits and you have people merging
code, code gets missed. And if there are
not unit tests wrapped around that code,
it is missed. And it will be a day or
two or a week later when your testers
get in to start testing it. Pray to God
it doesn't make it to the customer. But
hopefully your testers will catch this.
But you're going to find that whoops, a
piece of code got missed in the merge or
oh I overloaded or overwrote my change
on yours. So oh my god, you just got to
be very careful when dealing with your
code. Uh and and you know Rob mentions
this all the time. You need to be using
code repository GitHub and and use
llinters. Please use llinters because
they will be a huge um savior and for
your sanity and your code
hoping mechanisms for surviving the
madness. This one's actually pretty
interesting. Humor. If you don't laugh,
you'll cry. Or both. Snacks and
caffeine. Every bug fix deserves at
least one cookie. Rubber duck debugging.
Sometimes the duck has better answers
than Stack Overflow. And the ship it and
run strategy. Just kidding. mostly. Um,
we actually had one of the first places
I worked, we we would joke about that we
are going to skip the testing and pass
the savings on to the customer and that
was it was very there was way too often
because we were doing commercial
software. We were we had to like crank
it out and sometimes we had to crank it
out faster than we wanted to. But uh and
we also this was this is a while back so
the uh we had QA people there was
testing and things like that but it was
not to the level that it you know it is
today. Um and that was a that was a
challenge. I love the idea of rubber
duck debugging. Um I have no idea what
that means. Uh, but I do think that I'm
going to take it in a way of, you know,
sometimes it's um ask somebody just
random, you know, like or like maybe
you've got a family member that's
sitting there. It's just like they're
not a developer, just like what do you
think about this? Uh, it's the same way
as like stepping away or, you know, just
do a random search. Just do some stuff
to get out of the out of the madness and
out of what's going on and maybe you'll
find a way to solve whatever that
problem happens to be. This is, you
know, we're talking about the
psychopath. We're talking about the
craziness. We're talking about the
things that are just going off the
rails. Sometimes you need to walk away
from the train crash for a little bit
before you can go back to it and go,
"Oh, here's how we need to clean it up."
Things like that. Sometimes it's just
take a deep breath. Sometimes it is like
just all right, I'm going to go and I
have been there where it's like, you
know what? I'm just going to go to
lunch. I am just going to go like hang
out at the water cooler for 15 minutes.
I just I need to get away because
sometimes your sanity is going to get
dragged into that, you know, dumpster
fire if you don't watch out. How about
you? Coping mechanisms, maybe some of
your favorite ones.
>> Oh, so if you don't laugh, you'll cry or
both. Um, so I I kind of want to call
out, you know, your um,
you know, the ship it and run it
strategy.
Video games today are a good example of
this. So many games are shipped before
they're done and they go through a
series of patches or what's called,
"Hey, let's do a uh pre-release or it's
in beta, but hey, we're collecting your
money anyway."
Microsoft is another good one for this
because how many times has Windows come
out and it's really not stable for 6
months because hey, we need users to
test our software. But I I start there
because humor, you know, if you want to
sit down and you release software and
you sit down and you start to work on it
and it's working, it's like great and
then all a sudden it crashes, you know,
why did it crash? Oh, hey, maybe you're
a shopping site and you just found out
that your site cannot handle Cyber
Monday or Black Friday and you just are
down. You're like, oh my god, what am I
going to do? So, you're going to cry,
but when you get through it, it's like,
hey, there was kind of a good thing to
that. we were so popular that they took
our site down, but next year we need to
be better than that, you know. So, so
you get through it and you laugh about
those. But the fun the last little fun
one is the snacks and caffeine. So, I I
have been an abuser of caffeine for
years. I am down to reducing that uh
horribly. Uh not horribly, but I've
reduced the horrible abuse of it to
something that's more manageable like
one cup or one four cups a day tea bag.
But the snacks. So my little like I
guess treat, I have a jar of Jelly
Bellies.
And when I solve a particularly
difficult problem, I go to that jar. I
get a Jelly Belly. Now I You can very
easily eat too many of them. But if you
go to, hey, when did I solve this? You
know, something good, it limits how
often you can go to it. you you kind of
have to set that bar a little high so
you don't basically abuse your treats.
>> Uh yes, I've done that in the past. I uh
got it when I was working at a company
that had we had a a drugstore down the
street and people would regularly get a
big old bag of various chocolates and
stuff like that. So I'd be sitting, you
know, there and and so we all started to
get them. So whenever you get it, I get
like a big old bag. I'd throw half of it
in the front desk. I'd be there for
people that came by and the rest would
be sitting at my desk and next thing I
know I'd have a little bucket there and
I'd be like, "Oh, I'll try that. I'll
get that." I do that around Christmas
time every year, too. I'll go get some
nice little Christmas mints and have
them there. And uh I I probably need to
set the bar higher for when I'm going to
actually go for a treat on those things.
Um turning chaos into superpowers. I do
want to do this before we wrap up
because it this is I think the important
part. Every tough challenge secretly
levels you up. Documentation detective.
You can now read ancient high
hieroglyphics like cobalt. Uh debugging
ninja. You can spot a missing bracket
from 10 feet away. Interview survivor.
Nothing phases you after solving fsbuzz
with dynamic programming.
I think this is this is the key is we're
going to have problems. We're going to
have stuff go off the rails. We're going
to have dumpster fires. We're going to
be we're going to be going off the rails
over the cliff while we're still trying
to build stuff sometimes. But what
doesn't kill you makes you stronger.
We're going to go with that one. Um, it
does make you better as a developer is
that as you go through these things,
you're going to figure out what to look
for. You're going to know what the
problems are. This is honestly, this is
why RV Consulting is what it is and why
we do what we do and why we are actually
pretty good at a lot of the things we do
because we have seen some really nasty
situations and we've said, you know
what, we've seen this before. We usually
we know we're basically people are going
to hide the skeletons. We know what are
some of the problems that you're going
to have. And this does vary based on
your technology, your line of business,
and stuff like that. There are certain
things that are just the norms. So, if
you're, and you probably know that if
you've been doing this for a while, pick
your language that you've been in, you
know that there are for yourself,
there's certain bugs that you're almost
always going to do. There's typos or
something like that that you're going to
miss. Other people, when you're
reviewing code, you're going to be like,
"Oh, yeah, they missed this and they
missed that, and these are the kinds of
things to look for." You learn how to
look for the the common things. And now
granted the the psychopaths can be a
little bit different where you're like,
"Wow, I have never seen that before."
But then the good news is the next time
you will have seen that before cuz now
you've seen this one. So you can sort of
grow your list from uh common mistakes
to uncommon mistakes to unique mistakes.
But at least when you see them, a lot of
times you'll find out that will even if
it's unique, it will give you some
skills that will help you find something
close to that. and the next time you
find something unique, you will be able
to get it faster because you you've
attuned yourself to maybe thinking
outside of the box. So, what are some
good takeaways for you or some maybe
superpower that you see coming out of
this?
>> So, what number one of course is the
debugging? As you learn software and you
go through more and more projects and
build different more complex systems,
you're going to get better at spotting
problems. um semicolon if you're using
modern IDEs will tell you almost
immediately. So hopefully that's not
your biggest uh issue that you run into,
but there are a lot of hidden things
that getting better at writing unit test
debugging code uh is huge. So I highly
recommend learning to debug your code.
Try breaking it. You know, if you
haven't broken your code in a while and
you're relying on the IDE a lot, uh,
best way to test it is to go to like
Notepad, go to Vim, write your code, and
try to compile it from a command line
compiler and see if it works. Chances
are you probably forgot something and it
broke. But that is one of for a lot of
us uh, old fuddy duddies, uh, you know,
we didn't have IDs back in the day. We
had compilers. So um this is a very good
way to become very uh good at catching
debugging techniques or at least
understanding compile errors uh very
quickly. And the last thing I will throw
with this is as you learn these things,
go out to things like Stack Overflow.
Take the problem you just solved, go see
if other people are having it and go put
your, you know, put your solution out
there. One, you're contributing to the
community. You're getting your name out
there. And two, it's out there. So if
you forget maybe 6 months, a year from
now, you need to go find that problem
again. You may find your comment out
there and be like, "Oh yeah, I remember
this. This is how I fixed it."
I think that's probably one of the most
valuable things out of all this is being
able to take that and share it with
somebody else is have some sort of
documentation of it because like I find
that that really helps me u absorb and
digest what I just went through and give
something that is like now it's and it
forces you to also like learn from it.
So not just be like okay I fix it and I
can move on. It's like, "All right, I
learned from that. Here's what I
learned. Lesson learned, and it's going
to be helpful for you, just like any
other, you know, code repository and
things like that we've talked about is
like you're like, "Oh, yes. I've I
remember I ran into this and this is
what it looked like, and this is how I
addressed it." So, if there's something
that looks like that, again, you can
reuse those skills.
One of the things you can reuse is your
skill to send an email. I'm going to
throw that out there because, as always,
I would love for you to send us
something [email protected]. would love
to hear your feedback, what are your
thoughts, positives and negatives. What
do you like? What don't you like? What
did you like to see us talk about next?
Because we do have plenty of stuff
coming up. Uh, and we are also running
out of time on this episode or this
season. I think we got a few more
episodes now left. We're still going to
break through them, but then we will be
into the next season. Who knows what
we're going to do then? We don't even
know. I think last time we just w we
were winging it and then came in and
like, "Hey, this is the episode we're
this is the season we're going to do."
So that is how prepared sometimes we are
coming into this. But that's because
there's just so much so much information
out there. There's so many different
ways we can go. As you've seen from
this, we have left stuff on the table
every single episode of topics that we
could talk through. Uh sometimes they've
been entire seasons that could come out
of some of these topics. So love to hear
from you because you are the reason we
do it. You can leave us uh feedback,
comments, stuff like that on the
developer site. U feedback anywhere on
any of our articles or the contact us
form. You can check out the developer
page on Facebook. You can see us at
developer actually listen to us I guess
or whatever. Read our our thoughts at
developer onx and u just reach out
wherever you find all the great ways to
communicate. We're probably out there
somewhere. Uh anywhere that you give
podcasts, leave a leave us a note. Also,
I'm can't forget to list the uh YouTube
channel uh out on YouTube. We have the
developer channel and there's tons and
tons and tons of stuff out there. I just
I'm I'm sometimes shocked at actually
often shocked at how much stuff we have
out there and it's useful. It's amazing
how often I'll go search for something
and it's like, oh, we wrote that. So,
good stuff to know. Hopefully, it's
helpful to you. Let us know how it is
and how we can make it better. As
always, I just want to say we appreciate
so much the time you've given for us for
just hanging out with us and uh for
becoming a better developer because you
becoming a developer is a better
developer is going to make others around
you and eventually it's going to come
back to us and we're going to be dealing
with projects that good developers
wrote. So, we're not tearing our hair
out trying to figure out where the
documentation is, stuff like that. As
always, go out there and have yourself a
great day, a great week, and we will
talk to you next time.
bonus material.
>> So, I want to start by all you listeners
and viewers out there, send us your
psychopaths. Tell us, you know, some of
the challenges, some of the things that
drive you crazy or that have gone off
the rails. You know, let us know cuz
this is one topic I think anyone can
have a story about. Uh, just kind of go
through the list and, you know, let us
know. Um, but with that being said
though, you know, psychopaths
are not the happy past, but we we kind
of diverged from the original topic from
before. But psychopaths aren't always
just, you know, bad. You know, they
could still be happy past, but they
could be things that take you off the
rails. Again, you know, think like a
choose your adventure story. If you get
to a point where you c have option A, B,
C, or D or multiple choice, chances are
requirements aren't right. You're
probably off the path. Um or you're
going down the wrong path and you need
to check yourself, you know, just so
just
the one biggest takeaway I guess of this
is check yourself. Check what you're
working on and check it back to the
requirements. That's one of the easiest
ways to make sure that you stay on
track, that you're doing what needs to
be done, and that your requirements are
going to meet the needs of your uh user.
This is why there is a why. This is what
we go back to. That is your cornerstone.
That is where you go back to like what
are we solving?
How are we solving it? And using that, I
think often is going to give you like
your north star as well. you know,
something that's just going to say like
this is how I get to anchor myself back
to sanity to make sure that we're doing
what we need to do and that we can, you
know, have the confidence to rein in
things that go off track or to realize
that maybe that psychopath is something
that we do have to take care of that
somebody came in, thought outside of the
box, and we're like, "Oh my gosh,
they're not the only ones that they're
not the only psychopaths out there." If
you ever driven out in the driven on the
roads, you know, there's a lot of
psychopaths out there. So sometimes
those are uh scenarios that you have to
address that need to be uh part of you
know your testing your exceptions and
all the other kinds of stuff that go on
there.
I will wrap this one up because h we're
just cruising right along here but I'm
ready to go eat some dinner and stuff
like that. So I'm going to wrap this one
up. Let you go eat dinner, lunch,
breakfast, whatever time of day it or
just have a snack. Go have your little,
you know, jelly belly because you just
solved a problem. Creat yourself. go
have like a little snack because you
have treated yourself to some good
content hopefully that has helped you
become a better developer. Uh feel free
to feed us with any thoughts that you
have because we would love to gorge
ourselves on such things and that is
obviously I'm ready for dinner because I
keep using those all of those little
examples. That being said, thank you so
much for your time. I appreciate all
that you guys have done for you guys
being a part of this for you guys giving
us your time. As I said earlier,
feedback is even more appreciated, but
go out there and have yourself a good
one, and we will talk to you next time.
[Music]