Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche explore one of the biggest traps in software development: solving the wrong problems.
Learn how to identify root causes, avoid quick fixes, and build solutions that actually matter. From MVP planning to AI-assisted insights, we’ll show you how to stop wasting time and start delivering real value in your software projects.
🔑 Key Topics Covered: • The illusion of progress in software development • MVP strategy: building what matters • Listening vs. assuming in client discovery • Band-aid fixes vs. systemic solutions • Premature optimization pitfalls • How AI can help developers solve smarter
📘 Mentioned: • Upstream by Dan Heath • Agile retrospectives and sprint backlogs
🎯 Whether you’re a solo dev or leading a product team, this episode will change the way you approach problem-solving.
Check it out: https://develpreneur.com/solving-problems-in-software-projects/
00:00 - Pre-show 02:45 - Podcast 06:10 - Bonus
Transcript Text
[Music] Just to let you guys know, this is actually a follow-up from the prior one. I'm still sitting here. I'm still working on eating. So, I'm sorry if this is not going to be the best uh video. But the important thing is Michael's gonna sp talk a lot this time because I'm going to be back munching my food trying to get myself properly uh the right amount of nutrients into my system so I don't just keel over halfway through the the podcast because podcasting is so physically strenuous like that. This episode um I think I talked about last time solving problems without solving the problem. This is gonna be another one that's gonna be pretty fun. Looks like it loves uh rule of 10. So, we've got another 10 items. We're gonna see how this goes. We will talk about it. Oops. I got to scroll back up here and we're going to go three, two, well, hello and welcome back. We are continuing our season of developer, building better developers with AI. Yes, we're going to use AI this time because everybody else is using it. No, we're not going to send like, you know, killer Terminator robots to your house, but we are going to terminate all of your fears about develop becoming a better developer. Uh, this episode we're actually going to throw out to AI what would be a good way to talk about solving problems without solving the problem. We're going to see what happens. But first, I want to introduce myself. I am Rob Broadhead, one of the founders of Developer, also a founder of RB Consulting, where we work with our customers to understand their business, help craft a special recipe that's just for them, their business, how they specially work. This could be you. What is your specific problem? I know you know each industry's got its family of problems, but each business has got its own little niche, its own way of approaching it. And that is required in order to find the best solution of best way to use your technology whether that is through simplification, integration, automation or innovation. How do you take that big expensive investment that you have and turn it into something that is a real good return on investment? That's what we do. We sit down with you and help you figure out the best way forward. Use a technology assessment and then move into a road map so that you can plot out your course and execute on that. Good thing, bad thing. Uh, good thing, bad thing. Boy, this has been it's been a a week of that. So, good thing. Finally got through uh more or less. Uh, we close on a a house that has been in the works for a while tomorrow. So, we've gotten through lots of stuff. There's been all kinds of things that have gone on. This uh housing shift journey kind of thing started months ago. We're not like moving moving into this right away. So, we are not done yet. We're going to continue to move on and I'm sure have some struggles, but at least we're getting closer. So, I'm going to say that's a good thing. A bad thing is I hate to say it, but it's finally starting to get hot out. It was like I it's it's June and we've had great weather and it's finally starting to get hot enough that I'm like, "Ah, it's too hot." It's like I have to turn the air on and stuff like that. So that's the bad thing. But a good thing for you guys is now you get to listen to Michael while he introduces himself. Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of Developer, building better developers. I'm also the founder of Envision QA where we are a software company that essentially helps customers helps businesses with their software problems. It can be anything from custom software. It can be from store-bought software. But if you are struggling with technology and your business to get your make your customers happy or essentially just getting through the day with your technology working so you can get the work done. Give us a call. We will walk through the trenches with you to understand all the problems and all your processes within your company. and then we will help devise a process and a program to get you to the end of your journey to improve all these caveats, all these problems that you're having. So either you will have a better customer experience with your application or you're just going to have a better experience going into work. You'll be happy to work in your business, not hate working in your business and just, you know, hey, let someone else do it. Good thing. Good thing this time. So bad things, you know, weather's been bad, all that crap all the last few episodes. We got our lawnmower back that I broke couple weeks ago. The weather's been warmer, as Rob mentioned, but it's been comfortable enough that we've actually been able to sit outside, enjoy the weather, and my wife got the little 10ft pool up and we were able to jump in that. It was actually not too cold. We were able to get in that and enjoy that. And we were actually able to get out to the riverhouse and actually had decent weather for a day, but we actually had decent weather out at the river. So, we are almost past this rainy season and it is sunny skies for a while. Maybe warm, but it's still sunny. It's not cold, rainy, drabby, or snow. Yeah, if you start hitting snow in June, we're in trouble. This episode we are diving into we're asking AI as we are in each of these going back two seasons back we're taking the topic and we're asking AI about it. So this time the topic is solving problems without solving the problem. Now as always AI loves us and thinks we're really smart and nice. So it says it's a clever and thoughtprovoking topic. Well let's see how well AI was clever and thoughtprovoking. So, first first recommendation, the illusion of progress. Just writing code doesn't mean you're solving the real problem. Devs often solve symptoms, not root causes. Entrepreneurs sometimes launch features that no one needs. Message progress isn't about activity, it's about accuracy. Oh my gosh, this is another one that just like bam, right in the kisser. This is something we talk about way too often about being productive versus being busy. We talk about the why. This goes back to what we talked about last time, the why. Why are you doing this? Features that nobody cares about. Bells and whistles. It's about doing stuff, adding features, building functionality that helps people solve the problem or problems better, faster. Don't make them stick around. Now, if you're, you know, if you're in the marketing world and you want people to stick on your site and stuff like that, that's cool. Make it fun. But the problem you're solving there is that people want to go away from your site. So, solve that problem properly. Don't find ways to stumble across that across that. I love that one so much. I'm not going to talk the whole episode, but I am going to go ahead and toss it over to you because I know you have things to say as well. Yeah. from the marketing side. It's kind of like handing out those uh $10 Starbucks cards to get people to go look at your site, not fixing the problem on your site. It's like here, we'll pay you to come look at our site, not actually fix the site to make you stay or want to come to us. Oh my god. I mean, it's that that's probably the best example. It's like, are you busy or are you getting stuff done? Are you solving the problem at hand? We've talked about this a lot. We've actually talked about this on some projects we've been on. It gets back to what is the MVP? What is the end goal? What is it that the customer needs to complete the project? Now, if you get the project done and you have time left, that's when you add all the bells and whistles. Do not add the bells and whistles at the beginning. Get the MVP done, then work on the extra features. That is well before we go on I I have to say that is so hard. We get into the the heady times of starting a new project and we have all these visions and all this stuff we can do and it seems like the world is our oyster and we can do whatever we want and the reality smacks us down and says no you don't have that much time. You don't have that kind of resources and all the other things that are the constraints that can slow us down. So just find a way to like it's sort of like balancing out that roller coaster of you know all the excitement and we've got all this energy and then you get towards the end and it's like I just want this project done it's a death march and stuff like that. Finding ways to balance that out actually that is part of what I think agile does the scrum approach in particular but I don't want to get too far into that. So, next one. I I'll touch on that briefly though because with agile though, the the cool part with agile is this roller coaster Rob's talking about. You may have that like high energy at the beginning. It's like, oh, we got all these ideas. You get to a certain point though when you're doing the retrospective, throw things out like, hey, did we complete enough of this? Is there something we still need to add? Because maybe one of those fun features can be added now. Well, we're still not at the MVP, but because we're in that moment, is it something that can be done now for less time and money versus later? Yeah, there's always that uh looking for opportunities. You find an opportunity to sneak something in. And it goes back to the idea of having like a a backlog, we'll call it, because that's what they do in sprints, of ideas and features that especially if it's a it's not a big one, throw those things on the backlog. And then if you've got a like a lull or you get a little bonus time or something like that, then go ahead and and implement that into it. Diagnosing the wrong problem. Here's a quote from Einstein of all people. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem. Dev off devs often fix what's broken on the surface, not what's causing the break. Encourage asking what problem are we actually solving for whom? Why? Now, this this is a pet peeve I have with testers and QA and users at times when it's like this is broke. This doesn't work. Like, okay, you've told me absolutely nothing. Give me something I can work with. Uh the best is when somebody will sit there and there a lot of tools do this. They'll sit there, they will walk through it and say, "Here's what I did. Here's where I got to. This is what I expected. This is what I saw." That gives us a perfect idea of this is what they expected. This is what this should do and it's doing something different. And that's the key. And it's not just the it's doing something different. This goes back to what we've talked about. Coders are going to just say, "Okay, I'm just going to make it do something different." All right? It's like for example, if your logic doesn't, you know, when you enter these three values in and your logic doesn't give you the right answer, you just hardcode it to say when those three values come in, output the answer that you know it's supposed to be. Doesn't really help. It's sort of like showing your work when you were in school. It's great that you can come up with an answer, but it's also not necessarily, you know, going to be consistent enough. So figure out what you're actually what is the actual problem and go solve that so you're not constantly having to play whack-a-ole changing all of the things to you know address the the symptoms and not the actual problem. Thoughts on that one? Yeah. So that's so there was a book we went to uh GE uh global leadership conference a couple years ago and um I forget the guy I found the book uh yeah Dan Heath was talking at the GLS and he was talking about upstream solving problems before they happen and that is one of the biggest keys to being a developer not a coder. It is not just putting out the fire but understanding what is causing the fire. What is the overlaying problem that needs to be fixed to fix the things that are happening downstream? And that whole idea once you get into that mind shift where it's like you start asking yourself well what is the underlining cause? Why are we seeing all these problems? Once you start addressing, okay, not fixing the problems, but where is this coming from? Is this a systemic problem with the software itself or is this a systemic problem with the foundation or the overall um process of how we built the application? Is there something in the overall logic or uh code that fundamentally is wrong that is causing everything else downstream? If we go fix this one thing, we suddenly free up 40 hours of bug fixes because the problem is fixed, not fixing the symptoms. Yeah. And that's um again that's one of the areas that I think is why software projects can can really uh have an appearance of being worse than they are. Um because sometimes it's a it's actually a very small bug. It's a simple fix, but because it doesn't actually get addressed, there's like these band-aids. The band-aids keep falling off and now it looks like it's a it's a complete train wreck when it's really not that bad. So, it it will behoove you. It will help you immensely. spend that little bit extra time, diagnose a problem, and try to fix it the first time because I guarantee you all of my customers I've dealt with over the years, there is I don't think a single one that says, "I would rather have it fixed right away than to say, you know what, give it the right amount of time, think through it, verify it, and move forward." It is way too frustrating for all of us when we try to blow through a solution and then end up having to come back and, you know, correct the solution. Basically, this throws right in to the next one, which is band-aid fixes and systemic sol versus systemic solutions, which is the example of like increasing timeouts instead of fixing latency issues. Adding more features instead of addressing poor onboarding. Entrepreneurs often throw features at churn when the root problem is unmet expectations. I will I don't want to get too far into this one could boy this could go for days but I will mention that this was specifically a project that went off the rails very long ago. I've talked about it before and the whole idea was that the the guy that was running the project basically they were running out of money. They didn't have the funding to finish it. And so he figured out what he needed to do is just get more money. And so what he did is he said, "Well, there's all these features we're going to add." and he thought it's like, well, we'll just add all these features and there'll be another bucket of money, you know, a bag of money and then we're going to be fine. Well, what ended up happening is there all these features and now there's all this other stuff and they took time as well because he didn't really think through it. They took more time than he bid he, you know, budgeted for and now he's in a deeper hole than he was beforehand. So, you know, look for the systemic side. This is again the developer side of it versus the coder side of it. This is a fun one. Lack of context equals misguided solutions. Without understanding the user journey, business model or tech limitations, devs can overengineer or underdel. Real problem solving requires full stack awareness, not just code. I cannot preach enough on the this is why we ask the questions. This is why we sit down. We say, "Okay, well, what about the requirement? What about this situation? How about that? Tell me more about The more you can get a conversation out of your customer about what they're doing, what they need, the more you're going to have all kinds of little hidden Easter eggs that come out and like, "Oh yeah, there's this thing that we do occasionally." Or, "Oh, yeah, there's this report that we need." Or, "Oh, yeah, there's this requirement that we have that I forgot about that, you know, or they won't even think about it. They'll just be like, "Oh, well, we do ABC, B, C, and D." And you're like, "Whoa, whoa, whoa, whoa, whoa. I never heard about this C thing before." for go back to that C between B and D and let's explore that. Spend some time really getting to know the problem and the users and what is it? You know, what are you really solving? Not just like what's the problem, but like how is that being solved? What actually becomes a good solution? Thoughts on that? It looks like you have plenty. Oh yeah. Uh, so the downside to this, if you don't take the time to listen, if you take the time to ask these questions, but you don't take the time to listen to the customer. I've done this. Almost any business person has done this. It's like, oh, I understand what you're saying. Here's how I will solve it. No. Sit down, talk through the problem, make the customer do the talking. Avoid yes or no questions. encourage more exploration into what it is you're discussing. As Rob said, you could get into a situation where they talk about A, B, and C, and you've never even heard of C. Well, C could be the critical lynch pin to hold the whole thing together. If you miss that, you could get to the very end and find out that you do not have an MVP. You don't even have a product that the customer can use because you missed a core piece of the application. So, I've heard this in many business things. I I've learned this through experience. Sit down, encourage the customer to talk through the problems, prompt them when needed, and then shut up. The best part of that, actually, the best part is then shut up because that's I think what we needed is don't don't start solving the problem before you've heard the whole problem. More importantly, do not ask don't ask binary questions. Don't say, you know, something that's a yes or a no. I have I have gotten so many times that I have had to I've tried to get it to that where it's like just tell me can this ever occur or can you ensure guarantee that this situation never happens? I don't know how many times I've had a customer say, "Yes, that situation will never ever ever occur in our business." And then three weeks later, they're like, "You've got to cover this. This happens all the time. That stuff just drives me nuts." And that's why I've gotten away from it. I'm just like, "Tell me how your work your your stuff goes. Tell me about some of these process. Let's talk about some of your customers because then I'll start getting real answers and not just the like, okay, I'm going to answer this question for them. Moving on, the build trap. Building a product or feature doesn't mean it's solving a problem. Encourage hypothesis-driven development, MVPs that test assumptions, saying no or not yet to features requests that don't align with goals. This is really an interesting one because we actually tend to fall on the other side of this a little bit more. We've talked more about the idea of where you're you never get across the finish line because you're trying to perfect it. you're trying to add like this old feature or this old tweak or what about this and what about that. This is more the we'll ship it and consider it done and then at least now we're we've got customers which you don't want customers when you ship them crap because then they're just going to wear you out. So this is just because we have a feature or we have the product doesn't mean it's actually doing anything useful. So this goes back to really context and things like that. It's like, are you solving the right problem? Are you solving in a way that's actually useful to your users, or is it just take them too long? Is it too annoying and too other stuff for them to actually make use of it? Thoughts on that one? So, I'm going to just throw a small thought out on this one. We see this all the time. If you are dealing with games as a service like Diablo, Path of Exile, the game software gets released, it's like, hey, it's done. But then you have these seasons or these uh things that go on over time and the game from today versus 6 months from now it's a totally different game. You basically have been sold on hey we think the software is good enough to sell it to you but we're still going to work on getting it to the end product at some point. you know, not calling out a Microsoft who uses its develop or its users to be their testers because let's face it, anytime a Microsoft operating system comes out, it's really not done or stable 6 to9 months till after it's released. There are so many bug patches next, you know, there there's just problems with software. Be careful with that. Make sure that what you are delivering is a solution, not something that you have to constantly keep patching, delivering. If you go back to the early days before the internet, when you actually sold software, the software had to go on physical media, had to be shipped and delivered, and that was it. That was all. There was really no such thing as a patch unless you actually had a customer call you and you had to ship them floppy discs. But in today's environment, it is way too easy to say it's good enough to ship and then get stuck in cycles of actually improving the product to get it to where it really should have been when it shipped. Now, this is I don't want to say that's separate from an MVP. There's a difference from having a minimally viable product and selling it to your customers and saying, "Hey, we are this is version one. we we are solving this problem and all we're going to do is we're going to solve that problem and solve it well because then what you're doing is you're selling them on that problem that solution you're saying we're solving it cool and they're going to say and it needs to that's the minimal viable minimum viable product part of it is to say it solves it it's sufficient they are now happier people than they were otherwise then you can come out with version two and say all right now we're going to find a better way to you know to solve that problem better way to skin that hat, but that's not the same as we're just going to throw it out there and you know, minimum viable product is for your users. It's not for you to just be like, "Okay, we're done. We want to at least get something out there and generate revenue." And I know I know that is difficult with uh when you're in a public company or when you've got, you know, customers breathing down your neck or investors or things like that, it can get difficult very quickly. Moving on. Premature optimization example. Spending days optimizing performance when the product doesn't yet have users. Solving future problems wastes time. Ask is this a problem we're solving right now? This I have had fights about because and on some serious number of occasions because it's yes that is important. No, that is not important right now. We are not there yet. If you're sitting there worrying about the colors and the font on your application and you don't even have all of the pages done yet, you don't even have any of the key features done yet, then you are you're cart before the horse. You are not where you need to be. That does not mean that you don't want to think about those things. That does not mean that you will not be necessarily frustrated down the road when you're like, gosh, it would have been nice if we had known what all of these pieces were, you know, what these fonts and colors were before we built all these screens. That could have made it nicer, but the thing is is that you didn't even know those screens were going to exist back then. So, you probably would have spent a lot of time doing something that you really didn't need to do. And that that is a really big developer piece is understanding when to actually execute on some of these tasks because there's a lot of stuff if you look at building applications a lot of things that go on in building software and there is essentially a time and a place for each of these and it's easy to get sort of focused a little bit too much focused on like well we need to do this thing right now and not stepping back and going wait a minute no we actually don't and this goes back to something we've talked about earlier is like spending too much time up front and not spending enough time towards the end. Now you're at the end and you have all these things you have to have but you wasted your time on stuff that you don't actually have that you don't need to have. It's like you know it'd be one of those things where it's like you're jettisoning things. you're you're spending too many resource too much of your money early on and now when you have to actually buy like I don't know food and clothing and and somewhere to you know a house well you already blew all your money out there and yeah you've got like a nice toy or something like that but you don't have food and clothing. It's the same kind of thing. It's just it's resource management and it's making sure that you make sure that you're doing the right thing at the right time and not getting caught in those little rabbit trails. Your thoughts? Yeah, we have both been in many, not us all the time together, but we have all been in situations where you may be trying to solve a problem and in the process of solving the problem, you're trying to be a little more forward thinking. For instance, if you are like working with databases or working with message cues, you may come to a point where it's like, well, we need to do load testing or we need to make sure that we can handle the load of these interactions, these integrations, integrated systems we have. There is a point within the life cycle of an application that yes, it is time to do that. At the beginning, no. Until you actually have enough of the systems in place where you can actually see how it works, it is not efficient at it. It's not worth your time or resources to spend the time testing that before you get there because you might get there and that integrated system may completely change. You may find a different solution. So especially in the early stages of a project, especially if you're like thinking, oh, we may look at this or we want to use this or we tried to use this. Don't get too involved in the testing, the load testing or feature set till you get to the point that it is fully integrated within the application. Yes, you want testing. Yes, you want to make sure it works, but don't go too far. Just make sure you got the basics and move on. I'll take this to another thing that's a like an easy analogy or an easy example is spending too much time on the design of a page and the layout of the the labels and the in the fields and things like that when you're, you know, when you're early on when you're just putting that thing up because there's a lot of times that some of those fields will disappear. Uh some of the labels will change anyways. uh maybe that whole screen or page will go away at some point. There are a lot of things that can happen where you end up and it's it is a little bit of a crapshoot. There's going to be times where you're like, "Ah, it would have been nice if we had spent more time on this early on." But your goal is to not waste your time on things that end up not being part of it. You don't want the stuff that ends up on the cutting room floor to be stuff that you spent a lot of time on. You don't want to be like at the end of like you've created this big movie and you spent 90% of your budget on a she a scene that now you were not even going to use, you know, something like that. That's sort of where you can go with some of these. You can get way too lost in the the weeds and not realize that some of these things you don't really have a firm enough it's not firm enough yet where you're going to go to really spend that time on it. Now, I I want to add on to that though because there are some benefits to some pre-planning. So, at the be not in the middle, but at the beginning of the project, throw everything at the wall. Literally, like any idea, get it out there. Whiteboard, brainstorm as much as you can, but then as Rob mentioned, get it to the point where you whittle down to what you need for the MVP and then cut the fat. But try to spend enough time at the beginning to maybe a day or two, but have enough people talk about the idea so that you cover as much as you can to then cut it down to what you actually need. Because if you don't do that, you might literally miss a key feature that you need that you get to the end and you're like, "Oh crap, I now need to build this really quickly or we're not delivering." And this goes to the I'll throw the other ones out real quick and then do a little wrap thought here as it wrap up. So problem solving as an exploration not execution. Uh when solutions create new problems. We say that all the time. Start with the outcome not the output and redefining success. Now I've got a couple items that we'll probably cover in the bonus we do in the uh after the the audio wraps up when we have the post show video. But the the thing that we sort of a theme that has come through a lot of these is spending the right amount of time on things is don't rush it. Don't jump in and just be like, "Okay, I'm like checking stuff off." That's really more of a coder kind of thing to do. Developers are going to say, "You know what? This is not a science. This is there's definitely an art to this." And sometimes it takes a little time for things to bake in, for the right creative juices to start flowing, things like that. So you spend your time like take a step back, give the tasks that you need to do the the amount of time that they need to get them done. Don't try to rush your way through it. Don't try to cram, you know, a square peg into a round hole. Allow things to go the path they need to. Yes, you're going to have to push sometimes. Yes, there's going to be stress. Yes, there's going to be times you're going to like do more than you want, you know, spend more time on something than you want to, but make sure that you're not often spending less time than you needed to. I think that is where we end up, you know, kicking ourselves way too often for doing so. Also, don't kick yourself for not sending us an email. Shoot me an email at [email protected] and let us know your thoughts. What are what are some of the things that you've run into? You know, whether you listen to this a couple seasons ago or whether you're listening to it now and you're like, "Oh, this AI thing really has got some great ideas." I I should look back. It probably has better ideas than we have. Although, we are we are like lining up. So, I'm feeling pretty good about it. That being said, I'm not going to poke you for any other stuff. You know where to see us. You know where to leave us feedback and all that goodness. Whether it's at developer on YouTube channel or podcast, wherever you get podcast. Also, if you find it somewhere that you get podcast and we're not there, let us know. We want to make sure we're there. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. Bonus material. All right. So, go back through those last three topics. Let's see. I think I want to do the last one. So, problem solving as an exploration, not execution. Great developers and entrepreneurs explore problems deeply before attempting solutions. When solutions create new problems, tech debt, complexity, brittle systems, all can stem from solutions that weren't fully thought through. Gosh, I'm really gonna want to come back to that. Start with the outcome, not the output. What result are we trying to achieve? Should come before what are we building. Oh, I like that one. Redefining success. Success isn't just solving a problem. It's solving the right problem in the right way. Sometimes the best solution is doing nothing. reframing the problem, killing a feature, saying we don't need to build this. That oh my god, the one I want. This is something that goes back to the heart of the RB consulting side way back when I said sometimes, yes, we build techn technical solutions. Sometimes we talk to people and the best solution is a pencil and a piece of paper. Sometimes there are processes that are so broken, it's like you need to define your processes first. Uh sometimes it is like I don't know how often this there's been things where it's like you know there's a feature that gets added on and suddenly it slows the whole thing down and it makes everybody hate the application. It's like just kill the feature sometimes. It's like you know what the best thing we can do with that is not take it on because that's not our wheelhouse that turns us into something we're not. And there are so many products and applications out there that did that. They did something nice and then they like, "Oh, we got to grow." And they add some features and next thing they know, they've grown into somewhere they don't need to grow into. God, that last statement you just said there. I mean, that's literally how I went from Malash Consulting to Envision QA because I was literally solving problems for everybody for anything, which got me in trouble because it's like, well, really, you don't need that solution or and and at the end of the day, you got to pay the bills. So, you're going to do what the customer wants. But unfortunately, in the software world, this is kind of a key difference between business and software development. The customer is always right until they're wrong. Because in the software development side, something they want may not be the right solution for what the problem is. You have to stand your ground and tell them this is not a good idea. This will break things. This is wrong. It is hard to do because as a business owner, you want to please your customer and unfortunately the please your customer and the customer is always right mindset leads to bad things. I it it's not always right. Um you do need to listen, you do need to support them and you know make them happy, but at the end of the day you want to make sure that what you deliver is right, not something that is just complacent and wrong. That's the thing is a good if you're building software you're essentially a consultant of sorts. You are helping people solve a problem and if they can't properly contextualize the problem if they're not addressing the problem right if they don't see what the problem actually is sometimes you're going to have to step in a little bit and say well no here's actually what you're doing. Now that doesn't mean that you're lecturing them or you're you know telling them you know better because I mean in some cases I guess it technically yes it is but it's because you're you're listening to their problem you're understanding what it is and you're saying oh you have you know you being the customer maybe they have done something that we have just listed you shouldn't do things for example like they started solving a problem before they really thought through what the problem is. So sometimes that's what we need to do is be that like you know that that voice that slows them down a little bit and says wait a minute think about this is that really the problem you need to solve or is there's this other thing that if we take that away or we solve that problem then this other problem goes away and so there is you know definitely complexity and layers of of those. I have a great example of this. So, I had a friend slash um acquaintance that I had years ago that came to me because he knew I wrote software and he wanted me to build him this website and he wanted it to be full ecommerce, all this stuff. And I kept telling him, look, all you need is a Spotify account, get some product, see if people will buy your product before you spend all invest all this time in a solution. The problem was he was like, "Nope, I want the solution and I will get the product once I'm ready." He spent so much time on the website on what he wanted for infrastructure. He had almost no money left when we got to the end for the product. He had barely anything left for building what he wanted to for a company. And I told him from the beginning, it's like, dude, let's go the cheap route, the Tim Ferrris route. Like, let's do AB. Let's throw up a website. Let's just say, hey, will people buy from you? Throw a couple t-shirts up. Throw something up and see if it will work. But he was out of money before he got to that point. And I had been telling him all along, stop. No, no, no. I mean, I could have quit, but I had to pay the bills, too. I mean it it's one of those catch 22s where it's like you do the best you can for your customer but at the end of the day you are at the service of your customer. Yeah. You do what you can but there's a point where and honestly there are situations where that customer may know better than us where we're like we really think we know it and they're like no we really know this really understand this problem this industry or something like that. And so you're like, "Okay, I've given you my thoughts. They, you know, are outweighed by yours and yours opin your opinions." And so sometimes you have to move on. And I you don't have to. I guess you can always say, like Michael said, you could say, "Well, I'm not going to do it." But that's usually not the best way. Your better bet is say, "Okay, if you're going to do this, then I'm going to do my best to help you get to that solution." because you already have in your mind then some warning flags or something like that where you're like, "Well, here's where things could go wrong." So, you can help them maybe mitigate some of those risks uh as part of being that that steady adviser as you move forward. That being said, it is time for us to wrap this one up. Thank you so much for your time, for hanging out, for putting up with me as I've been trying to like get some food in my system so I don't starve to death. Luckily, I have not. I'm still here. Lucky for me anyways. maybe not for you. We will return next episode. We are going to continue moving through these AI questions. This is pretty cool so far. So, I think this is going to be a real fun season. As always, go out there and have yourself a great one. We will talk to you next time. [Music]
Transcript Segments
[Music]
Just to let you guys know, this is
actually a follow-up from the prior one.
I'm still sitting here. I'm still
working on eating. So, I'm sorry if this
is not going to be the best uh video.
But the important thing is Michael's
gonna sp talk a lot this time because
I'm going to be back munching my food
trying to get myself properly uh the
right amount of nutrients into my system
so I don't just keel over halfway
through the the podcast because
podcasting is so physically strenuous
like
that. This episode um I think I talked
about last time solving problems without
solving the problem.
This is gonna be another one that's
gonna be pretty fun. Looks like it loves
uh rule of 10. So, we've got another 10
items. We're gonna see how this goes. We
will talk about it. Oops. I got to
scroll back up
here and we're going to go three,
two, well, hello and welcome back. We
are continuing our season of developer,
building better developers with AI. Yes,
we're going to use AI this time because
everybody else is using it. No, we're
not going to send like, you know, killer
Terminator robots to your house, but we
are going to terminate all of your fears
about develop becoming a better
developer. Uh, this episode we're
actually going to throw out to AI what
would be a good way to talk about
solving problems without solving the
problem. We're going to see what
happens. But first, I want to introduce
myself. I am Rob Broadhead, one of the
founders of Developer, also a founder of
RB Consulting, where we work with our
customers to understand their business,
help craft a special recipe that's just
for them, their business, how they
specially work. This could be you. What
is your specific problem? I know you
know each industry's got its family of
problems, but each business has got its
own little niche, its own way of
approaching it. And that is required in
order to find the best solution of best
way to use your technology whether that
is through simplification, integration,
automation or innovation. How do you
take that big expensive investment that
you have and turn it into something that
is a real good return on investment?
That's what we do. We sit down with you
and help you figure out the best way
forward. Use a technology assessment and
then move into a road map so that you
can plot out your course and execute on
that. Good thing, bad thing. Uh, good
thing, bad thing. Boy, this has been
it's been a a week of that. So, good
thing. Finally got through uh more or
less. Uh, we close on a a house that has
been in the works for a while tomorrow.
So, we've gotten through lots of stuff.
There's been all kinds of things that
have gone on. This uh housing shift
journey kind of thing started months
ago.
We're not like moving moving into this
right away.
So, we are not done yet. We're going to
continue to move on and I'm sure have
some struggles, but at least we're
getting closer. So, I'm going to say
that's a good thing. A bad thing
is I hate to say it, but it's finally
starting to get hot out. It was like I
it's it's June and we've had great
weather and it's finally starting to get
hot enough that I'm like, "Ah, it's too
hot." It's like I have to turn the air
on and stuff like that. So that's the
bad thing. But a good thing for you guys
is now you get to listen to Michael
while he introduces
himself. Hey everyone, my name is
Michael Malashsh. I'm one of the
co-founders of Developer, building
better developers. I'm also the founder
of Envision QA where we are a software
company that essentially helps customers
helps businesses with their software
problems. It can be anything from custom
software. It can be from store-bought
software. But if you are struggling with
technology and your business to get your
make your customers happy or essentially
just getting through the day with your
technology working so you can get the
work done. Give us a call. We will walk
through the trenches with you to
understand all the problems and all your
processes within your company. and then
we will help devise a process and a
program to get you to the end of your
journey to improve all these caveats,
all these problems that you're having.
So either you will have a better
customer experience with your
application or you're just going to have
a better experience going into work.
You'll be happy to work in your
business, not hate working in your
business and just, you know, hey, let
someone else do it. Good thing. Good
thing this time. So bad things, you
know, weather's been bad, all that crap
all the last few episodes. We got our
lawnmower back that I broke couple weeks
ago. The weather's been warmer, as Rob
mentioned, but it's been comfortable
enough that we've actually been able to
sit outside, enjoy the weather, and my
wife got the little 10ft pool up and we
were able to jump in that. It was
actually not too cold. We were able to
get in that and enjoy that. And we were
actually able to get out to the
riverhouse and actually had decent
weather for a day, but we actually had
decent weather out at the river. So, we
are almost past this rainy season and it
is sunny skies for a while. Maybe warm,
but it's still sunny. It's not cold,
rainy, drabby, or snow.
Yeah, if you start hitting snow in June,
we're in trouble. This episode we are
diving into we're asking AI as we are in
each of these going back two seasons
back we're taking the topic and we're
asking AI about it. So this time the
topic is solving problems without
solving the problem. Now as always AI
loves us and thinks we're really smart
and nice. So it says it's a clever and
thoughtprovoking topic. Well let's see
how well AI was clever and
thoughtprovoking. So, first first
recommendation, the illusion of
progress. Just writing code doesn't mean
you're solving the real problem. Devs
often solve symptoms, not root causes.
Entrepreneurs sometimes launch features
that no one needs. Message progress
isn't about activity, it's about
accuracy. Oh my gosh, this is another
one that just like bam, right in the
kisser.
This is something we talk about way too
often about being productive versus
being busy. We talk about the why. This
goes back to what we talked about last
time, the why. Why are you doing this?
Features that nobody cares
about. Bells and whistles. It's about
doing stuff, adding features, building
functionality that helps people solve
the problem or problems better, faster.
Don't make them stick around. Now, if
you're, you know, if you're in the
marketing world and you want people to
stick on your site and stuff like that,
that's cool. Make it fun. But the
problem you're solving there is that
people want to go away from your site.
So, solve that problem
properly. Don't find ways to stumble
across that across that. I love that one
so much. I'm not going to talk the whole
episode, but I am going to go ahead and
toss it over to you because I know you
have things to say as well. Yeah. from
the marketing side. It's kind of like
handing out those uh $10 Starbucks cards
to get people to go look at your site,
not fixing the problem on your site.
It's like here, we'll pay you to come
look at our site, not actually fix the
site to make you stay or want to come to
us. Oh my god. I mean, it's that that's
probably the best example. It's like,
are you busy or are you getting stuff
done? Are you solving the problem at
hand? We've talked about this a lot.
We've actually talked about this on some
projects we've been on. It gets back to
what is the MVP? What is the end goal?
What is it that the customer needs to
complete the project? Now, if you get
the project done and you have time left,
that's when you add all the bells and
whistles. Do not add the bells and
whistles at the beginning. Get the MVP
done, then work on the extra features.
That is well before we go on I I have to
say that is so hard. We get into the the
heady times of starting a new project
and we have all these visions and all
this stuff we can do and it seems like
the world is our oyster and we can do
whatever we want and the reality smacks
us down and says no you don't have that
much time. You don't have that kind of
resources and all the other things that
are the constraints that can slow us
down.
So just find a way to like it's sort of
like balancing out that roller coaster
of you know all the excitement and we've
got all this energy and then you get
towards the end and it's like I just
want this project done it's a death
march and stuff like that. Finding ways
to balance that
out actually that is part of what I
think agile does the scrum approach in
particular but I don't want to get too
far into that. So, next one. I I'll
touch on that briefly though because
with agile though, the the cool part
with agile is this roller coaster Rob's
talking
about. You may have that like high
energy at the beginning. It's like, oh,
we got all these ideas. You get to a
certain point though when you're doing
the retrospective, throw things out
like, hey, did we complete enough of
this? Is there something we still need
to add? Because maybe one of those fun
features can be added now.
Well, we're still not at the MVP, but
because we're in that moment, is it
something that can be done now for less
time and money versus later?
Yeah, there's always that uh looking for
opportunities. You find an opportunity
to sneak something in. And it goes back
to the idea of having like a a backlog,
we'll call it, because that's what they
do in sprints, of ideas and features
that especially if it's a it's not a big
one, throw those things on the backlog.
And then if you've got a like a lull or
you get a little bonus time or something
like that, then go ahead and and
implement that into it. Diagnosing the
wrong problem. Here's a quote from
Einstein of all people. If I had an hour
to solve a problem, I'd spend 55 minutes
thinking about the problem. Dev off devs
often fix what's broken on the surface,
not what's causing the break. Encourage
asking what problem are we actually
solving for whom? Why? Now, this this is
a pet peeve I have with testers and QA
and users at times when it's like this
is broke. This doesn't work. Like, okay,
you've told me absolutely nothing. Give
me something I can work with. Uh the
best is when somebody will sit there and
there a lot of tools do this. They'll
sit there, they will walk through it and
say, "Here's what I did. Here's where I
got to. This is what I expected. This is
what I saw." That gives us a perfect
idea of this is what they expected. This
is what this should do and it's doing
something different. And that's the key.
And it's not just the it's doing
something different. This goes back to
what we've talked about. Coders are
going to just say, "Okay, I'm just going
to make it do something different." All
right? It's like for example, if your
logic doesn't, you know, when you enter
these three values in and your logic
doesn't give you the right answer, you
just hardcode it to say when those three
values come in, output the answer that
you know it's supposed to be. Doesn't
really help. It's sort of like showing
your work when you were in school. It's
great that you can come up with an
answer, but it's also not necessarily,
you know, going to be consistent enough.
So figure out what you're actually what
is the actual problem and go solve that
so you're not constantly having to play
whack-a-ole changing all of the things
to you know address the the symptoms and
not the actual problem. Thoughts on that
one? Yeah. So that's so there was a book
we went to uh GE uh global leadership
conference a couple years ago and um I
forget the guy I found the book uh yeah
Dan Heath was talking at the GLS and he
was talking about upstream solving
problems before they happen and that is
one of the
biggest keys to being a developer not a
coder. It is not just putting out the
fire but understanding what is causing
the fire. What is the overlaying problem
that needs to be fixed to fix the things
that are happening
downstream? And that whole idea once you
get into that mind shift where it's like
you start asking yourself well what is
the underlining cause? Why are we seeing
all these
problems? Once you start addressing,
okay, not fixing the problems, but where
is this coming from? Is this a systemic
problem with the software itself or is
this a systemic problem with
the foundation or the overall
um process of how we built the
application? Is there something in the
overall logic or uh code that
fundamentally is wrong that is causing
everything else downstream? If we go fix
this one thing, we suddenly free up 40
hours of bug fixes because the problem
is fixed, not fixing the symptoms.
Yeah. And that's
um again that's one of the areas that I
think is why software projects can can
really
uh have an appearance of being worse
than they are. Um because sometimes it's
a it's actually a very small bug. It's a
simple fix, but because it doesn't
actually get addressed, there's like
these
band-aids. The band-aids keep falling
off and now it looks like it's a it's a
complete train wreck when it's really
not that bad. So, it it will behoove
you. It will help you immensely. spend
that little bit extra time, diagnose a
problem, and try to fix it the first
time because I guarantee you all of my
customers I've dealt with over the
years, there is I don't think a single
one that says, "I would rather have it
fixed right away than to say, you know
what, give it the right amount of time,
think through it, verify it, and move
forward." It is way too frustrating for
all of us when we try to blow through a
solution and then end up having to come
back and, you know, correct the
solution. Basically, this throws right
in to the next one, which is band-aid
fixes and systemic sol versus systemic
solutions, which is the example of like
increasing timeouts instead of fixing
latency issues. Adding more features
instead of addressing poor onboarding.
Entrepreneurs often throw features at
churn when the root problem is unmet
expectations. I will I don't want to get
too far into this one could boy this
could go for days but I will mention
that this was specifically a project
that went off the rails very long ago.
I've talked about it before and the
whole idea was that the the guy that was
running the project basically they were
running out of money. They didn't have
the funding to finish it. And so he
figured out what he needed to do is just
get more money. And so what he did is he
said, "Well, there's all these features
we're going to add." and he thought it's
like, well, we'll just add all these
features and there'll be another bucket
of money, you know, a bag of money and
then we're going to be fine. Well, what
ended up happening is there all these
features and now there's all this other
stuff and they took time as well because
he didn't really think through it. They
took more time than he bid he, you know,
budgeted for and now he's in a deeper
hole than he was beforehand. So, you
know, look for the systemic side. This
is again the developer side of it versus
the coder side of it. This is a fun one.
Lack of context equals misguided
solutions. Without understanding the
user journey, business model or tech
limitations, devs can overengineer or
underdel. Real problem solving requires
full stack awareness, not just code. I
cannot preach enough on the this is why
we ask the questions. This is why we sit
down. We say, "Okay, well, what about
the requirement? What about this
situation? How about that? Tell me more
about The more you can get a
conversation out of your customer about
what they're doing, what they need, the
more you're going to have all kinds of
little hidden Easter eggs that come out
and like, "Oh yeah, there's this thing
that we do occasionally." Or, "Oh, yeah,
there's this report that we need." Or,
"Oh, yeah, there's this requirement that
we have that I forgot about that, you
know, or they won't even think about it.
They'll just be like, "Oh, well, we do
ABC, B, C, and D." And you're like,
"Whoa, whoa, whoa, whoa, whoa. I never
heard about this C thing before." for go
back to that C between B and D and let's
explore that. Spend some time really
getting to know the problem and the
users and what is it? You know, what are
you really solving? Not just like what's
the problem, but like how is that being
solved? What actually becomes a good
solution? Thoughts on that? It looks
like you have plenty. Oh yeah. Uh, so
the downside to this, if you don't take
the time to listen, if you take the time
to ask these questions, but you don't
take the time to listen to the
customer. I've done this. Almost any
business person has done this. It's
like, oh, I understand what you're
saying. Here's how I will solve it.
No. Sit down, talk through the problem,
make the customer do the talking. Avoid
yes or no questions.
encourage more exploration into what it
is you're discussing. As Rob said, you
could get into a situation where they
talk about A, B, and C, and you've never
even heard of C. Well, C could be the
critical lynch pin to hold the whole
thing together. If you miss that, you
could get to the very end and find out
that you do not have an MVP. You don't
even have a product that the customer
can use because you missed a core piece
of the application.
So, I've heard this in many business
things. I I've learned this through
experience. Sit down, encourage the
customer to talk through the problems,
prompt them when needed, and then shut
up.
The best part of
that, actually, the best part is then
shut up because that's I think what we
needed is don't don't start solving the
problem before you've heard the whole
problem. More importantly, do not
ask don't ask binary questions. Don't
say, you know, something that's a yes or
a no. I have I have gotten so many times
that I have had to I've tried to get it
to that where it's like just tell me can
this ever occur or can you ensure
guarantee that this situation never
happens? I don't know how many times
I've had a customer say, "Yes, that
situation will never ever ever occur in
our business." And then three weeks
later, they're like, "You've got to
cover this. This happens all the
time. That stuff just drives me nuts."
And that's why I've gotten away from it.
I'm just like, "Tell me how your work
your your stuff goes. Tell me about some
of these process. Let's talk about some
of your customers because then I'll
start getting real answers and not just
the like, okay, I'm going to answer this
question for them.
Moving on, the build trap. Building a
product or feature doesn't mean it's
solving a problem. Encourage
hypothesis-driven development, MVPs that
test assumptions, saying no or not yet
to features requests that don't align
with
goals. This
is really an interesting one because we
actually tend to fall on the other side
of this a little bit more. We've talked
more about the idea of where
you're you never get across the finish
line because you're trying to perfect
it. you're trying to add like this old
feature or this old tweak or what about
this and what about that. This is more
the we'll ship it and consider it done
and then at least now we're we've got
customers which you don't want customers
when you ship them crap because then
they're just going to wear you out. So
this
is just because we have a feature or we
have the
product doesn't mean it's actually doing
anything useful. So this goes back to
really context and things like that.
It's like, are you solving the right
problem? Are you solving in a way that's
actually useful to your users, or is it
just take them too long? Is it too
annoying and too other stuff for them to
actually make use of it? Thoughts on
that one? So, I'm going to just throw a
small thought out on this one. We see
this all the time. If you are dealing
with games as a service like Diablo,
Path of Exile, the game software gets
released, it's like, hey, it's done. But
then you have these seasons or these uh
things that go on over time and the game
from today versus 6 months from now it's
a totally different game. You basically
have been sold on hey we think the
software is good enough to sell it to
you but we're still going to work on
getting it to the end product at some
point. you know, not calling out a
Microsoft who uses its develop or its
users to be their testers because let's
face it, anytime a Microsoft operating
system comes out, it's really not done
or stable 6 to9 months till after it's
released. There are so many bug patches
next, you know, there there's just
problems with
software. Be careful with that. Make
sure that what you are delivering is a
solution, not something that you have to
constantly keep patching, delivering. If
you go back to the early days before the
internet, when you actually sold
software, the software had to go on
physical media, had to be shipped and
delivered, and that was it. That was
all. There was really no such thing as a
patch unless you actually had a customer
call you and you had to ship them floppy
discs. But in
today's environment, it is way too easy
to say it's good enough to ship and then
get stuck in cycles of actually
improving the product to get it to where
it really should have been when it
shipped. Now, this is I don't want to
say that's separate from an MVP. There's
a difference from having a minimally
viable product and selling it to your
customers and saying, "Hey, we are this
is version one. we we are solving this
problem and all we're going to do is
we're going to solve that problem and
solve it well because then what you're
doing is you're selling them on that
problem that solution you're saying
we're solving it cool and they're going
to say and it needs to that's the
minimal viable minimum viable product
part of it is to say it solves it it's
sufficient they are now happier people
than they were otherwise then you can
come out with version two and say all
right now we're going to find a better
way to you know to solve that problem
better way to skin that
hat, but that's not the same as we're
just going to throw it out there and you
know, minimum viable product is for your
users. It's not for you to just be like,
"Okay, we're done. We want to at least
get something out there and generate
revenue." And I know I know that is
difficult with uh when you're in a
public company or when you've got, you
know, customers breathing down your neck
or investors or things like that, it can
get difficult very quickly. Moving
on. Premature optimization example.
Spending days optimizing performance
when the product doesn't yet have users.
Solving future problems wastes time. Ask
is this a problem we're solving right
now? This I have had fights
about because and on some serious number
of occasions because it's yes that is
important. No, that is not important
right now. We are not there yet. If
you're sitting there worrying about the
colors and the font on your
application and you don't even have all
of the pages done yet, you don't even
have any of the key features done yet,
then you are you're cart before the
horse. You are not where you need to be.
That does not mean that you don't want
to think about those things. That does
not mean that you will not be
necessarily frustrated down the road
when you're like, gosh, it would have
been nice if we had known what all of
these pieces were, you know, what these
fonts and colors were before we built
all these screens. That could have made
it nicer, but the thing is is that you
didn't even know those screens were
going to exist back then. So, you
probably would have spent a lot of time
doing something that you really didn't
need to do. And that that is a really
big developer piece is understanding
when to actually execute on some of
these tasks because there's a lot of
stuff if you look at building
applications a lot of things that go on
in building software and there is
essentially a time and a place for each
of these and it's easy to get sort of
focused a little bit too much focused on
like well we need to do this thing right
now and not stepping back and going wait
a minute no we actually don't and this
goes back to something we've talked
about earlier is like spending too much
time up front and not spending enough
time towards the end. Now you're at the
end and you have all these things you
have to have but you wasted your time on
stuff that you don't actually have that
you don't need to have. It's like you
know it'd be one of those things where
it's like you're jettisoning things.
you're you're spending too many resource
too much of your money early on and now
when you have to actually buy like I
don't know food and clothing and and
somewhere to you know a house well you
already blew all your money out there
and yeah you've got like a nice toy or
something like that but you don't have
food and clothing. It's the same kind of
thing. It's just it's resource
management and it's making sure that you
make sure that you're doing the right
thing at the right time and not getting
caught in those little rabbit trails.
Your thoughts?
Yeah, we have both been in many, not us
all the time together, but we have all
been in situations
where you may be trying to solve a
problem and in the process of solving
the problem, you're trying to be a
little more forward thinking. For
instance, if you are like working with
databases or working with message cues,
you may come to a point where it's like,
well, we need to do load testing or we
need to make sure that we can handle the
load of these interactions, these
integrations, integrated systems we
have. There is a point within the life
cycle of an application that yes, it is
time to do that. At the beginning, no.
Until you actually have enough of the
systems in place where you can actually
see how it
works, it is not efficient at it. It's
not worth your time or resources to
spend the time testing that before you
get there because you might get there
and that integrated system may
completely change. You may find a
different solution. So especially in the
early stages of a project, especially if
you're like thinking, oh, we may look at
this or we want to use this or we tried
to use this. Don't get too involved in
the testing, the load testing
or feature set till you get to the point
that it is fully integrated within the
application. Yes, you want testing. Yes,
you want to make sure it works, but
don't go too far. Just make sure you got
the basics and move on.
I'll take this to another thing that's a
like an easy analogy or an easy
example is spending too much time on the
design of a page and the layout of the
the labels and the in the fields and
things like
that when you're, you know, when you're
early on when you're just putting that
thing up because there's a lot of times
that some of those fields will
disappear. Uh some of the labels will
change anyways. uh maybe that whole
screen or page will go away at some
point. There are a lot of things that
can happen where you end up and it's it
is a little bit of a crapshoot. There's
going to be times where you're like,
"Ah, it would have been nice if we had
spent more time on this early on." But
your goal is
to not waste your time on things that
end up not being part of it. You don't
want the stuff that ends up on the
cutting room floor to be stuff that you
spent a lot of time on. You don't want
to be like at the end of like you've
created this big movie and you spent 90%
of your budget on a she a scene that now
you were not even going to use, you
know, something like that. That's sort
of where you can go with some of these.
You can get way too lost in the the
weeds and not realize that some of these
things you don't really have a firm
enough it's not firm enough yet where
you're going to go to really spend that
time on it. Now, I I want to add on to
that though because there are some
benefits to some
pre-planning. So, at the be not in the
middle, but at the beginning of the
project, throw everything at the wall.
Literally, like any idea, get it out
there. Whiteboard, brainstorm as much as
you can, but then as Rob mentioned, get
it to the point where you whittle down
to what you need for the MVP and then
cut the fat. But try to spend enough
time at the beginning to maybe a day or
two, but have enough people talk about
the idea so that you cover as much as
you can to then cut it down to what you
actually need. Because if you don't do
that, you might literally miss a key
feature that you need that you get to
the end and you're like, "Oh crap, I now
need to build this really quickly or
we're not delivering."
And this goes to the I'll throw the
other ones out real quick and then do a
little wrap thought here as it wrap up.
So problem solving as an exploration not
execution. Uh when solutions create new
problems. We say that all the time.
Start with the outcome not the output
and redefining success. Now I've got a
couple items that we'll probably cover
in the bonus we do in the uh after the
the audio wraps up when we have the post
show video.
But the the thing that we sort of a
theme that has come through a lot of
these
is spending the right amount of time on
things is don't rush it. Don't jump in
and just be like, "Okay, I'm like
checking stuff off." That's really more
of a coder kind of thing to do.
Developers are going to say, "You know
what? This is not a science. This is
there's definitely an art to this." And
sometimes it takes a little time for
things to bake in, for the
right creative juices to start flowing,
things like that. So you spend your time
like take a step
back, give the tasks that you need to do
the the amount of time that they need to
get them done. Don't try to rush your
way through it. Don't try to cram, you
know, a square peg into a round hole.
Allow things to go the path they need
to. Yes, you're going to have to push
sometimes. Yes, there's going to be
stress. Yes, there's going to be times
you're going to like do more than you
want, you know, spend more time on
something than you want to,
but make sure that you're not often
spending less time than you needed to. I
think that is where we end up, you know,
kicking ourselves way too often for
doing so. Also, don't kick yourself for
not sending us an email. Shoot me an
email at [email protected] and let us
know your thoughts. What are what are
some of the things that you've run into?
You know, whether you listen to this a
couple seasons ago or whether you're
listening to it now and you're like,
"Oh, this AI thing really has got some
great ideas." I I should look back. It
probably has better ideas than we have.
Although, we are we are like lining up.
So, I'm feeling pretty good about
it. That being said, I'm not going to
poke you for any other stuff. You know
where to see us. You know where to leave
us feedback and all that goodness.
Whether it's at developer on YouTube
channel or podcast, wherever you get
podcast. Also, if you find it somewhere
that you get podcast and we're not
there, let us know. We want to make sure
we're there. As always, go out there and
have yourself a great day, a great week,
and we will talk to you next
time. Bonus material.
All right. So, go back through those
last three topics. Let's see. I think I
want to do the last one. So, problem
solving as an exploration, not
execution. Great developers and
entrepreneurs explore problems deeply
before attempting solutions. When
solutions create new problems, tech
debt, complexity, brittle systems, all
can stem from solutions that weren't
fully thought through. Gosh, I'm really
gonna want to come back to that. Start
with the outcome, not the output. What
result are we trying to achieve? Should
come before what are we building.
Oh, I like that one. Redefining success.
Success isn't just solving a problem.
It's solving the right problem in the
right way. Sometimes the best solution
is doing nothing. reframing the problem,
killing a feature, saying we don't need
to build this. That oh my god, the one I
want. This is something that goes back
to the heart of the RB consulting side
way back when I said sometimes, yes, we
build techn technical solutions.
Sometimes we talk to people and the best
solution is a pencil and a piece of
paper. Sometimes there are processes
that are so broken, it's like you need
to define your processes first. Uh
sometimes it is like I don't know how
often this there's been things where
it's like you know there's a feature
that gets added on and suddenly it slows
the whole thing down and it makes
everybody hate the application. It's
like just kill the feature sometimes.
It's like you know what the best thing
we can do with that is not take it on
because that's not our wheelhouse that
turns us into something we're not. And
there are so many products and
applications out there that did that.
They did something nice and then they
like, "Oh, we got to grow." And they add
some features and next thing they know,
they've grown into somewhere they don't
need to grow into. God, that last
statement you just said there. I mean,
that's literally how I went from Malash
Consulting to Envision QA because I was
literally solving problems for everybody
for
anything, which got me in trouble
because it's like, well, really, you
don't need that solution or and and at
the end of the day, you got to pay the
bills. So, you're going to do what the
customer wants. But unfortunately, in
the software world, this is kind of a
key difference between business and
software development.
The customer is always right until
they're wrong. Because in the software
development side, something they
want may not be the right solution for
what the problem is. You have to stand
your ground and tell them this is not a
good idea. This will break things. This
is wrong.
It is hard to do because as a business
owner, you want to please your customer
and unfortunately the please your
customer and the customer is always
right mindset leads to bad things. I it
it's not always right. Um you do need to
listen, you do need to support them and
you know make them happy, but at the end
of the day you want to make sure that
what you deliver is right, not something
that is just complacent and wrong.
That's the thing is a good if you're
building software you're essentially a
consultant of sorts. You are helping
people solve a problem and if they can't
properly contextualize the problem if
they're not addressing the problem right
if they don't see what the problem
actually is sometimes you're going to
have to step in a little bit and say
well no here's actually what you're
doing. Now that doesn't mean that you're
lecturing them or you're you know
telling them you know better because I
mean in some cases I guess it
technically yes it is but it's because
you're you're listening to their problem
you're understanding what it is and
you're saying oh you have you know you
being the customer maybe they have done
something that we have just listed you
shouldn't do things for example like
they started solving a problem before
they really thought through what the
problem is. So sometimes that's what we
need to do is be that like you know
that that voice that slows them down a
little bit and says wait a minute think
about this is that really the problem
you need to solve or is there's this
other thing that if we take that away or
we solve that problem then this other
problem goes away and so there is you
know definitely complexity and layers of
of those. I have a great example of
this. So, I had a friend slash um
acquaintance that I had years ago that
came to me because he knew I wrote
software and he wanted me to build him
this website and he wanted it to be full
ecommerce, all this stuff. And I kept
telling him, look, all you need is a
Spotify account, get some product, see
if people will buy your product before
you spend all invest all this time in a
solution. The problem was he was like,
"Nope, I want the solution and I will
get the product once I'm ready." He
spent so much time on the website on
what he wanted for infrastructure. He
had almost no money left when we got to
the end for the product. He had barely
anything left
for building what he wanted to for a
company. And I told him from the
beginning, it's like, dude, let's go the
cheap
route, the Tim Ferrris route. Like,
let's do AB. Let's throw up a website.
Let's just say, hey, will people buy
from you? Throw a couple t-shirts up.
Throw something up and see if it will
work. But he was out of money before he
got to that point. And I had been
telling him all along, stop. No, no, no.
I mean, I could have quit, but I had to
pay the bills, too. I mean it it's one
of those catch 22s where it's like you
do the best you can for your customer
but at the end of the day you are at the
service of your
customer. Yeah. You do what you can but
there's a point where and honestly there
are situations where that customer may
know better than us where we're like we
really think we know it and they're like
no we really know this really understand
this problem this industry or something
like that. And so you're like, "Okay,
I've given you my
thoughts. They, you know, are outweighed
by yours and yours opin your opinions."
And so sometimes you have to move on.
And I you don't have to. I guess you can
always say, like Michael said, you could
say, "Well, I'm not going to do it."
But that's usually not the best way.
Your better bet is say, "Okay, if you're
going to do this, then I'm going to do
my best to help you get to that
solution." because you already have in
your mind then
some warning flags or something like
that where you're like, "Well, here's
where things could go wrong." So, you
can help them maybe mitigate some of
those risks uh as part of being that
that steady adviser as you move
forward. That being said, it is time for
us to wrap this one up. Thank you so
much for your time, for hanging out, for
putting up with me as I've been trying
to like get some food in my system so I
don't starve to death. Luckily, I have
not. I'm still here. Lucky for me
anyways. maybe not for you. We will
return next episode. We are going to
continue moving through these AI
questions. This is pretty cool so far.
So, I think this is going to be a real
fun season. As always, go out there and
have yourself a great one. We will talk
to you next time.
[Music]