The Difference Between an Answer and a Solution

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are having a special topic discussion this time. We're going to talk about one of the things that was sort of implied, but we never really got too deep into it. There were a couple of interviews in the past. We've talked about, particularly about product creation and sometimes services, but usually it's products. And it's how do we create a product that serves our customers, which comes down to requirements. And it also comes down to how do we provide a solution instead of just answer a question. And that is really what I want to focus on in this episode, is the difference between having an answer and having a solution. Now as an example, just to get us started, let's think about balancing your checkbook. If somebody comes to you and says, hey, I need to balance my checkbook, maybe that's all they give you. Your answer could be, okay, get pencil, get paper, enter in all of your entries, and then your bank statement is. That is an answer. And it is technically a solution, but not really. Because what they want to do, what is implied, is they want to be able to do that and do it in a way that takes a minimal amount of time, that is easy, and ideally that is fine. Now that's not always going to be part of it, but when you are looking for a solution, when you are out there asking somebody to help you out, to give you an answer, to give you, you don't want just an answer, you really want a solution. And that is going to be hidden no matter who you are, that's going to be sort of built into that request, is things like I want it to be quick and easy and it may be fun or enjoyable. And there may be some other things, but in general, that's what we want. We don't want something where they say that's going to be, here's what you can do, but it's going to be very painful, it's going to be very difficult, it's going to be very time consuming. None of us want that. I don't think, I can't think of anything anywhere that we would ask for where the best solution would be the most expensive, the most painful, the slowest approach, all of that kind of stuff, all of the negatives. That's not what you want. There are certain positives that are universal. Thus, when somebody is posing a question, when somebody has a problem that they want us to solve, they don't just want the first answer that comes into our head. And this actually is where this topic came from was I had a question that was, hey, how do you put together requirements? How do you create a requirements document? It got me thinking about it, and this will probably be a two-parter type of a topic that we'll get into more about requirements and proposals and how those things work, I think, in our next episode where we do a special topic episode. This one, I do want to really just focus on the, there's a difference between an answer and a solution. Now, yes, every answer is technically a solution, but definitely every solution is not only an answer, it is a good answer. Unless it's a bad solution, in which case it's really just an answer. And I don't want to talk in circles, so sort of moving forward into this is the idea of when somebody comes to you, in particular in technology, and they say, I need this done, I need a website, or I need a CRM, or I need a way to do e-commerce. Whatever the problem is that is proposed to you, whether you are an employee, contractor, consultant, whatever it is, they don't just want you to give them just any solution. They don't just want you to say the first thing that comes to your head, the top of your mind, and just say, boom, this is what it is. So for example, a website, you may say, if that's all I give you, is you may be thinking maybe already in your head you had this picture of like maybe a little homepage about us, contact me, something like that. The most basic, simple thing. You probably didn't even have images in your head necessarily. I mean, anything specific, definitely not anything I'm expecting that was like, wow, that's an incredible website is going to be what anybody says. And there are probably millions of websites out there that are exactly like what we just had in our head. It's super vanilla. They've got like maybe a nice little color scheme, one nice little picture, business name, contact us, a little bit of content. And to me, that's most of the websites that were built in the 90s and maybe even the early turn of the century, 2000s up until maybe in the last five or 10 years. And you would know that if you saw it. You would look at it and you say, this is a aging website. You may have a spin on it and say, oh, that's a retro looking website. But it's really, and unless you're going for retro, your customer is, then that's not a good thing. Yes, that is an answer. That's a website. 100%. Yep. Hey, you have pages on the web that people can get to. That's not what they really ask for. And this is where we become better as an entrepreneur, as a developer. We don't just give an answer. Now, we may have an initial answer of, sure, I can build you a website. However, we do need to go that next step. We need to talk to them about, okay, what is it that is in your head when you say you want me to build you a website? This is, regardless of whether it's something as simple as a website or something as complex as a business automation back end ERP type of solution. And it's whether you're building it or whether they need some help in buying one. They're finding a solution for that. And this is where we add value as a technology professional, as an experienced developer or architect or solution engineer or whatever your title happens to be. This is where we add the value that is, as they say, this is why we get paid the big bucks. This is why they want us. Yes, there are a lot of people out there who can't write code and stuff like that. But unless you have a project or a customer that's like, I just need the code written, they want more. They expect more. And if all you give them is the code, is all you do is just like code a simple solution and move on, then don't expect them to come back. Don't expect them to go, wow, I'm impressed. Which you're supposed to do. And this is really, honestly, whether they ask for it or not. You want to give them more than just an answer. You want to give them a solution. You want to give them something that doesn't just very simply solve that problem, but instead solves that problem in a way that actually improves their life. If somebody's got a problem and you give them a solution and it really doesn't impact their life in a positive way, they still spend essentially the same amount of time dealing with them. It's the same amount of stress. It's the same amount of same quality, same potential for errors. All you're doing is you're shifting from one thing to another. It's sort of like if you're going from point A to B and you've got a car that gets you there and somebody and you're like, I need to get, I need a different solution or I need a solution. And the solution is essentially a car that maybe it looks different, but it's more or less, it's same gas mileage, same cost of ownership, all that kind of stuff. Then you're not really doing much for them. It's like if you have a job. If you go from job A to job B and your next job, that job B, you work the same hours, you get the same pay, the coworkers are roughly the same as far as no amount of drama, stress, friendliness, whatever it is. Across the board, it's basically the same job. It's just now you're working for a different company. Then why did you change in the first place? What was the purpose in that? And that's really what we need to think about when we're solving a problem for a customer or our employer or whoever it happens to be is that they're not just wanting an answer. They want a good answer. So we sometimes, that means we're going to have to follow up with more questions. Now, we may understand and have some things that right away we can put because of our experience into the mix and say, well, yeah, you want a website, but I bet you want a website that reflects your brand. I bet you want a website that is eye catching. I bet you want a website that allows you to rank properly and be SEO friendly, that maybe it is easy to maintain, that you have one that your customers will want to come back to. Those are all things that we could sort of throw into the mix right away. They may not ask for that, but those are things that we should be thinking of because we have experience in building these things. We should look at what did we build in the past? What questions were answered in the past for our customers that we think may apply to this customer even though they haven't asked them? So this is where we come up with all kinds of default, we'll say default features. It's things like, okay, if you want a website that your customers are coming to and they're going to be able to check on orders, there's things like, okay, how do you register? We need to, we should have some sort of registration. We have some sort of login. We should have a logout. We have ability to change passwords. We may need the ability to have our users linked in some way so that they could all be under a corporate umbrella. We need to have a way to link to our invoicing system or something like that so that we can show the state of orders or what their invoices were, what's been paid. We may need to connect to a payment processor and so on and so on and so on. There are features that somebody will, and maybe they will even have it in their mind, but that when they ask us for something, because of our experience, there's things that we know should be a part of that solution. And that's what they're counting on us for. If we just give them verbatim a solution to what their question is, then we're missing out. We're missing an opportunity to make it better for them. We're missing an opportunity to add value. Yes, they're paying us to write code, but they're really paying us to solve problems and give them a solution. If you want, think about art where we go back to the why that we've talked about so many times and we've had episodes talking just about that. It's not really about that problem as much as it's about the why. Why do I need that problem solved? And with that, how do I need it solved so that it does improve my life or my ability to deliver to my customers? Or other key business reasons to do it? There is almost zero companies out there that want to have a technical solution just because they want to provide jobs for coders. That almost never exists. There is almost always, probably 99.9999% of the time, a business reason for the question that they ask or the request that they put out there. Our goal is to take our answer and adjust it, massage it, change it so that it is the best solution we can come up for for their request. Not simply answer the question, actually provide a solution. If you want the mathematical approach to this, it would be the show your work kind of thing that you get when you're in college to a certain point. Early on, yeah, it's like memorization. So two plus two answers four. That's all you need to show. But if you need to show how you arrived at the velocity of a cannonball that got shot out of a cannon in a certain, you know, in a 10 mile per hour headwind from what was sitting on the moon or something like that with a different gravitational pull, and your answer is, I have no idea if this is the answer, but if your answer is like five or whatever it happens to be, that doesn't help. Your physics or mechanics professor or whoever they are, they're going to want you to show your work, to walk through. How did you get to that? Because that's, in that case, really the solution. The answer is often a byproduct almost of the solution. The solution is what matters. Because with the right solution, we should be able to plug in whichever variables there are in the question and be able to ask that question over and over and over again, and the solution will present the right answer, the correct answer over and over and over again. So you can write code where it's, every time they put, like let's say it's a calculator that just adds. And so every time they have two numbers that they put in, you could have like an F and you say, okay, if the first number, if either number is a one, then if the next number is a one, kick back two. If the next number is a two, kick back three. And you can make it very complicated. Your code could just be honestly an infinite almost if statement that just says, well, if they give me this, this is the answer. It's not actually solving it. It's just saying, here's the answer. And yes, maybe in some cases that would be suitable, but in most cases, it's not. Because what happens when there is a query, when the parameters are some things you haven't considered before. Okay, yes, you add another if statement, but how often can you do that? That's always going to be slower because that means that now I can't just go to this thing and have it give me the answer. I have to go to it, see if the answer already exists. And if it does, I can grab the answer. If it doesn't, then I have to go back to my coder and have them write code. If you want a quick way to get to a job that they can never fire you, maybe that would be it. It's just write some really insanely bad logic that allows you to get the right answer all the time, but never really solves the problem. And we wouldn't want that. It's not like, we don't want a recipe for a meal that essentially is call this phone number and or pay to get your food delivered. That's not the solution to I want to make this meal. That's the solution to I just need the meal right now. But if you say I want to make the meal, that means you need every recipe and it needs to be able to be something that if you follow it correctly, it will generate the meal, the food that you want. That's what we have to remember. So this also means it's not about our technology. It may be a request. It may be somebody that says because they think it's useful or something like that. I need a Java app that does this. Okay, maybe they do. And that should be one of your questions is why does it need to be a Java application? And they may have valid reasons like, well, we only have Java developers and they need to be able to look at it, maintain it or something like that. But it may also be that, well, I wrote about this Java thing in a magazine and I understand that that's what you have to use to solve this problem, which most likely is incorrect. In which case you may say, hey, yes, you can do that. But maybe we have a different solution. Likewise, if somebody's asking for a solution and you only know Java, but it happens to be something that it would be better to do that solution in .NET, then it is on you at some point to know that and to offer that and say, hey, we do Java, but I happen to know that this would be better off if you did it in .NET. Something like that. It's not about our technology. We need to take our technology out of the equation. Now, I know this is very difficult because sometimes it's, hey, if we don't do it in this technology or this family of technologies, then we aren't going to be able to provide a solution. But it's better for them to go find somebody that can do it, that technology that can get that better solution than it is for you to do it halfway. And now we perpetuate the whole, you know, projects just don't work. They fail. They're not what we're expecting. They don't live up to expectations. Set the expectations where you can, but also realize that there are expectations as soon as somebody asks the question. They want a solution. So spend the time understanding the question enough that you are giving them not an answer, but a solution. That means often go back to them and say, okay, here's what your question is, but let me understand your question better. Let me understand why you're asking this question. Let me understand who will look at the answer. Who cares about the answer? How often do they look at the answer? How often is the question going to be adjusted and you want it to be treated as the same question and so on and so on? There's all these little details or nuances about solving a problem, about defining a problem in general, and then of course about the solution. Because you could have an identical problem in detail, but the solution could be varied from asker, requester to requester because they might have a slightly different purpose. For example, like a great example of this is a customer relationship management CRM type of solution. Generally speaking, a CRM is going to be, I want to be able to track, I want to be able to know how to have information to contact my customers or potential customers. I want to be able to have some sort of history of our conversations and a few other things like that. But then your solution could be very generic to that problem. But if you've got a customer that has specifically requested that, you're going to want to understand more because it may be that they are, like for example, let's say they're a law firm. The customer details about somebody that's using a lawyer is very different if they are a doctor. And it's very different if they're ordering widgets or they're ordering candles off of a website. Those CRMs, the details that you care about for your customer are different in those different lines of business. And so that's part of what we want to do is we want to make sure that we're clear on what is your line of business. And we may know to some extent so we can make suggestions. So for example, if we've had a CRM app that we've built for using the law firm example, that we've built for half dozen other law firms, then when they say, hey, we need somebody to be able to track our customers, then you can say, hey, this is what we think is important for you to know about your customer. And they may add some additional stuff. That's why our experience matters is that we can solve the problem the first time and spend time figuring it out. But then we go to solve it for somebody else, we're going to see a different perspective. We're going to see some, we're going to learn stuff. We're going to see new things about that problem, new opportunities in that solution. And then we go to a third and a fourth and a fifth, we're going to keep adding to that. So the more we've done this, the better we're going to be able to talk to the next person about their problem and offer to them facets of the solution that may make their life much easier. That needs to be our goal. When we are going out there and whether we're trying to get a project, whether we're trying to make our boss happy, whether we have a customer that we are working with, whatever it is, when they ask a question, we need to focus on providing a solution, not just giving them an answer. Yes, quick answer sometimes is useful to say, yeah, we can do that and this is roughly what it's going to look like. Go back and spend some time thinking about it. Don't just rip it off and be like, hey, here it is, here's your answer. Step back and it may be to just give them a ballpark or something like, yeah, we can give you an answer, but it should almost always be, here's an answer. However, that's just an answer. Let me think about that a little bit more and give you a better answer. Something approaching a solution as opposed to just an answer. When you do that, you're going to be better. You're going to be a better value to your employer or to your customers and you're lifting the, basically like lifting all boats in that case. Everybody's going to be doing better in that because now we're starting to get into that habit of, hey, let's give us a solution instead of just an answer. Don't rest on the, as soon as they ask for something technical, then they should be just happy that they get a technical answer at all. They still want a solution and we should be focusing on and moving towards providing them that solution. That's how you're going to see your career advance. That's how you're going to see your customers want to come back and refer to other customers and all of those things that lead to success and is part of, for whatever your reason why, that's part of what is becoming a better developer. I think I've spent enough time on this, but I am going to come back next time on our special topics. I'm going to spend more time talking about proposals versus requirements and how we dig into those a little bit more because I think it's a useful thing that particularly if you're new, newer in this technology world and this solution to providing world, I think there's some things that it's, there's some helpful hints and tips that we can hit. But until then, we're just going to put this to rest for a while. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Please allow me to take 30 seconds of your time to talk about one of the things we're really excited about for 2024. We are going to bring back our masterminds and you can check out technologymastermind2024.com or you can check out our mastermind at develop-a-nor.com. We're going to get our groups together. We've got applications open today. There is an early bird discount. So jump in there, take a look at what we've got and make 2024 your best year yet.