Conquering Tough Coding Challenges: Proven Strategies Every Developer Needs

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we are 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 through those and saying, all right, let's just take that title. The general synopsis, the concept of what Building Better Developers are, and we are getting some good feedback and then going from there. This episode, we are going to, I'm not going to share with you yet. I'm going to introduce myself first. I don't want to spoil it too much what our topic is. The guy that's not spoiling it, his name is Rob Broadhead. I happen to be a founder of Develop and 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 awry. So many things go off the rails. 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 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 we don't understand your business, we're really not going to understand the problem. So 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 going to find ways in our toolkit to help you create a custom recipe that is going to be your technology roadmap and then we can help you execute it or we can just say, Here's your roadmap. Enjoy your journey or any smart part in between, because we are here to help you do business better. Good thing, bad thing. This is a fun one because there's like sometimes life dishes out a little bit of a lesson, things like that. So I had a dental thing the other day and I was a few minutes late and they're basically like, come back another day. I was not very happy because in the past they have not been very respectful of my time or anybody else. That'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. Broadhead, you can be seen. And as I was viewing, not really viewing, 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. Yes, I was a victim of my own, 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. I'm going to let Michael introduce himself and waste some of your time. Hey, everyone. My name is Michael Blasch. I'm one of the co-founders of developer NUR, 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 problem at work. And today, all of a sudden, the light bulbs went off. We figured it out. All was happy and good. Found out that what I had envisioned the solution to be three weeks ago was correct. The bad thing was all the steps provided to me on how this piece of software worked and where I was supposed to plug this in was not the correct place to test. I was given the keys to the house, but I was sent to the wrong house. Literally, I was in there. Am I 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 roundtable 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. We started out with, let me get the original title because I didn't spoil it earlier. 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, you want to make this more serious educational? Or lighthearted and entertaining and me being me, lighthearted and entertaining. So this is what we got. That's why Michael, you just got a second, updated bunch of notes. So it says, perfect. Because Jeff 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 lighthearted and entertaining span for your development or episode. So an intro hook, you ever open up a Jiro, a Jiro ticket and think. This was definitely written by a psychopath. Not exactly where we went. Uh, one second, because it is there. Say it's a good time to talk about psychopaths. And, uh, okay. Oh, but ever open a Jiro ticket and think this was definitely written by psychopath. 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, by the inverse or the opposite of the happy path, we talk about hypey path. 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 some of the almost similar to what Michael's description was about his good thing, bad thing. So I'm really looking forward to this one, cause 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. Have a requirement written on a napkin. Legacy code was seven levels of nested if statements, just the 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 it, some things like that. Uh, particularly if you go back to the redevelopment or 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 makes sense where it's like, Oh, sit down and write some code. Those are the kinds of things you're going to have. Cause you, if you're going to try to figure out like, how do you 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 on. 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. You're going to be able to do that. 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 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 the parameters. And it's like, dude, have you ever heard of Google? Do you ever, especially IDEs, they auto complete the command. So that stuff just seems so not applicable to what you're trying to do. Before I toss it back to you, seven levels of nested if statements is actually goes to back something we talked about before. If you're using static 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 kind of the things that you're going to have to do. 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, pulling a China shot, 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 a main till it pain ability, scalability, reliability, quality, all of the things that are important with your code. And now I will step off my soapbox 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 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. It's interesting with that though, too. 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 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, for this code? If you see one or two files, a couple of file changes, cool. You're good. If you see six or seven, eight, nine, 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 written 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, right? Your unit tests 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, the requirement was either half-baked 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 semi-colon two days later. The specs 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, I got 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 of 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, if you can get to it, stuff like that. And so we had a nice site. We had the whole team in, we like an hour long 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. This 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 kinds of things that do get us into these psycho past scenarios that, that chat GPD has come up with where you've got, you've got competing, sometimes competing requirements and they're both urgent, you've got to have both of them. And it's like, sometimes 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 where 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 kinds of priorities look like. So that was mine. Where do you want to go on this one? So I'll take the first one. I found a bug. It was a semi-colon two days later. So I think it was in the last episode. We talked about linters and yeah, code reviews, code repositories. Oh my God. If you are not using linters 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 grouped 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's not just the linters, 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 into sort of 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, oops, a piece of code got missed in the merger. Oh, I overloaded or overwrote my change on yours. So, Oh my God, you just gotta 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, get up and use linters, please use linters because it will be a huge, um, Savior and for your sanity and your code. Open mechanisms for surviving the madness. This one's actually pretty interesting. Here, if you don't laugh, you'll cry or both snacks and caffeine. Every bug fixed 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 cause 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 was 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 is today. Uh, 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. It's 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 to 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 psychopaths, 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 let'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, 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 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 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 does Windows come out and it's really not stable for six months because Hey, we need users to test our software. But 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 of a sudden it crashes. Like, 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, right. 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 this, but the fun, the last little fun one is the snacks and caffeine. So I am 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. The tree, 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 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, uh, drug store down the street and people would regularly get a big old bag of various chocolates and stuff like that. So I'd be sitting there and so we all started to get them. So whenever you get it, I get like a big old bag, throw half of it in the front desk, it'd be there for people that came by and the rest would be sitting at my desk. The next thing I know I'd have a little bucket there and I'd be like, Oh, I'll try that. Oh, I 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 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 fizz buzz 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 skeleton. 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 codes, you're going to be like, oh yeah, they missed this and they missed that. And these are the kinds of things 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. Cause now you've seen this one. So you can sort of grow your list from a 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. Number one, of course, is the debugging. If 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, semi-colon, if you're using modern IDEs, we'll 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 them, 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 for a lot of us, uh, old funny duds. Uh, you know, we didn't have IDEs 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'll 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 six 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 don't remember this. This is how I fixed it. I think that's probably one of the most valuable things of all. And this is being able to take that and share it with somebody else's have some sort of documentation of it, because like, I find that that really helps me, um, absorb and digest what I just went through and give something that is like now it's in a force is you also like learn from it and not just be like, okay, I fixed 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 as 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 info at developinora.com. We'd love to hear your feedback. What are your thoughts? Positives and negatives. What do you like, but don't you like, what did you like to see us talk about next? Because we do have plenty of stuff coming up. And we are also running out of time on this episode or this season. I think we've got a few more episodes now. Last we're still going to crank 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 want, we were winging it and then came in and like, Hey, this is the episode we're going to, 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. So many different ways we can go. As you've seen from this, we have left stuff on the table, every single episode, topics that we could talk through. 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 feedback, comments, stuff like that on the developer site, 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 or actually listen to us, I guess, or whatever, read our, our thoughts at developer on X and just reach out wherever you find all the great ways to communicate. We're probably out there somewhere anywhere that you get podcasts. Leave, leave us a note. Also, I can't forget to list the YouTube channel on YouTube. We have the developer channel and there's tons and tons and tons of stuff out there. I just, 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, we appreciate so much the time you've given for us for just hanging out with us and 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 off, trying to make it better. We're not tearing our hair off, 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.