Looking at the Bright Side of Things

This is Building Better Developers, the Develop-a-newer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We're continuing our season where we're looking at the bright side of things. We're going to look at the glass being half full, not half empty. This episode, we're going to look at niche needs. These are maybe also known as outliers, as headaches and things that just sort of annoy you go. These are definitely up there, I think, because it's especially during that testing time of an application and system and just about anything you run into, it seems like that happy path, that common typical approach that's used to get through the application, it works pretty well. We don't have any issues with it and things move smoothly and quickly. And then the outliers come. Then the niche things come. These special uses or these special cases or these things that are not the mainstream, but maybe they need to be considered anyways. Maybe they fall under the umbrella, the scope of whatever it is we're doing. Or in some cases, these are the crux of what we're doing. There are those that have said that the riches are in the niches. A lot of these products, that's what we're doing. We're actually finding these outliers and these special cases that are underserved or not served through other means and addressing that. That may be within a product in itself, or it may be a feature or functionality that we provide that is a distinguishing feature. Maybe it is a huge market boost for us to provide for that outlier or that less common situation. But that being said, and that is leading us into, spoiler alert, that's leading us into some of the positives, but getting to this is usually getting those outliers, getting those less common cases addressed can be a headache at times. Usually, it's not so much, I've found at least, it's not so much the solution itself as it is catching it beforehand. So testing and things like that, those are the things that you need to do in order to make sure that these cases exist or are covered properly. Sometimes it gets hit in the requirements and the design. Somebody's thought through it enough and said, oh yeah, there's this case to worry about. But a lot of times we end up missing those things. Sometimes it's obvious. I've been in applications where they're simple, we'll call them outliers, they're niche cases that have to be addressed that are as obvious as being able to have the application work on the weekends instead of during the weekdays when there's maybe a different situation that they're working with. Maybe in the office hours from nine to five and instead they're working on a Saturday afternoon and the application or the solution still needs to work, but maybe it doesn't. Maybe we did something that precluded that. Maybe we assume, and it could happen anywhere. So it could be that we assume that any day that you're doing work is a business day for purposes of calculations that need to be made. And if it's Saturday or Sunday or holiday, those kinds of times it may not be. It could be after hours, so it's not technically a business day. There's things like that that you have to worry about. Or just things that send you a reminder, let's say 24 hours later, assuming that you're doing the work you're doing during business hours. Well, what happens if you do it at two in the morning and then you get a reminder at two in the morning the next day? They may not be very useful. So these can be annoying. They can be a challenge. But the number one upside, I think, is the one that I've already brought up. And it goes back to that idea of niches being where we can go and differentiate our product. And think about that. That is almost across the board what is going to be the differentiator in a lot of products. If you go to pick anything, let's say a simple CRM, Simple Customer Relationship Management Tool. You can go search for that and let's say Cloud Platform or Software as a Service. You'll find tons, tons of them. Or bug tracking or project management tools or things like that. And you can find sites that will compare features or you can go to those sites and compare the features. And typically what you'll find is a bulk of stuff that is shared across all of those products that are the common uses, the common features that you need for that solution. And then if you look, you'll realize that there are these additional features probably that each application has. They've got a couple extra things they do. And when you look at it, especially if you really examine it, you'll probably find that those are features that are not used as commonly. It may be something like in customer relationship, maybe it's something where you have a customer it treats, you know, not everybody is a customer. Some people are customers and maybe some are vendors. Maybe it is a contact management app where you have organizations as well as people, which maybe isn't as common a thing. It is, but I'm stretching a little there because I'm just trying to think of outlier type things. In a business like invoicing system, then you may have things that are less common like the ability to take a PO or to provide a quote or although it's common enough, maybe a distinguishing factor is being able to do electronic transfer of funds or electronic payments. Those kinds of things are depending on how you look at it. Sometimes these are very big niches, but sometimes they could be very small. You could have a CRM app that has a piece that is very much focused towards, let's say the legal industry or let's say pharmaceutical industry or you name it or youth sports and things like that that are, they're not going to have the general audience, but those may be features that make that the product that people that live in that niche need. That's the one that they want. That's part of why we go through RFPs and processes like that is to basically define our niche and then find who can fit it the best. One of the things you get is you have the ability with a niche or an outlier is you have an ability to specifically address that market, however big or small it is. Another thing that's a positive and this, I think you'll find this thread running through several of the positives. It basically comes down to you can look at things as challenges that make you stronger or challenges that weaken you. This would be looking at this as a challenge that strengthens you. When you have to deal with outliers, when you have to take that, we'll call it your general purpose solution and adapt it to additional parameters or constraints to cover outliers, to handle niches and lesser used situations or less visited situations, it forces you to build a more resilient, almost by definition, a more resilient solution. You have to actually think through it and extend that general solution to cover some more cases, cover other situations. Whenever you do that, in my experience, it seems like when you get out of the core functionality, it gets more difficult. Very much this goes back in my mind to the Pareto principle, the 80-20 rule. That first 80% of getting 80% there is 20% of the effort, but the next 20% is 80% of your effort. That's where these things come in usually. You're not going to run into, in most cases, in that first 80%, you're not going to see niches, you're not going to deal with outliers, you're not going to deal with special cases and one-offs and all of these other things. But once you start pushing into those, once you start to look at those things, then you're getting into that more difficult area. This is really part of becoming a better developer. There are a lot of developers out there. There are coders that can get you that 80% more or less. Maybe they can't get all the way there, but a ton that can get pretty close, especially Once you get into that three, five, seven years of experience, you've probably been through enough that you can get your way through 80% if it's, you know, there's assumptions here that it's tools you know and things like that. But generally speaking, you can get there. This is where it sort of distinguishes a coder from a developer to me, is when you are a, and it does, as I've said before, it goes back to your problem-solving skills, your ability to actually to address more complex problems. Those live in the niches. Those live in that final 20%. And so this is an opportunity when someone comes to you with one of these situations. It's an opportunity for you to practice at a higher level. It's game time. It's time for you to put those skills to a test. Much like a professional athlete, if they're to practice or if they're playing with their buddies at home or something like that, it's very different from doing the same thing when they do it with other professionals. It's different if you have Peyton Manning going out and throwing ball with his kids or when he played professionally going out there and playing a game. And that's sort of what we're at. We can do, especially as we go further in our career, we can do that 80% moderately easily. There's still effort and all that kind of stuff. I don't want to downplay the value of doing that. But I think our bigger challenge is the things that are going to force us to grow more, help us to grow more, are those outliers, are those niches, that last 20%. Getting to get that last little bit done is usually going to help us get better at attention to details, at really working through the formulas and the functions and the processes and the logic of our solution in a way that truly pushes it to cover whatever situation is out there. It falls sort of into the same thing when we talked about testing and how it forces us fixing the bugs and getting others to test our applications, forces us to build a more actually just a better solution in general. It's probably going to be more resilient, more reliable, more scalable, maybe easier to maintain. The niches and the outliers do the same thing for us. They force us to get out of our comfort zone in a sense and tackle these problems that they're tougher, the harder problems, moving from the beginner crosswords to the advanced crosswords. That's the kind of work that we're doing. That actually leads to another positive. That is we'll look at it at entertainment value. Think about somebody that does crosswords every day. Maybe they can do the beginner crosswords. They do those occasionally maybe, but they're really quick. They're really easy. Then they also do, I don't know if they still have New York Times, still has it, or one of those where they use some of these classic, more difficult, more complex crossword puzzles. They're people that that's what they thrive on. They want to do the harder work. I think most of us, if we want to be a better developer, then I think there's a part of us that enjoys that harder work. It definitely gets us out of a rut. It gives us something that's a little different to tackle. A challenge means that it's something that can help us remember that we have skills, that we are bringing value to the table, that we're not just plugging out code or something simple like that. That we have a greater value than simply just writing out source code. That in itself, it's a dual-edged sword as a lot of times challenges and such are. It can be more exhausting. It can be more frustrating, but it's also more rewarding. When you have a bigger challenge that you have overcome, you're going to feel better about it than a simple challenge. Stealing candy from a baby is something that we look at as something that's very effortless. Although I think if you've ever tried to take candy from a baby, you know that it's maybe a little more challenging than some people think. But stealing candy from, I don't know, the rock from TV or something like that, or Arnold Schwarzenegger or something like that, that may be more difficult. That would be something to brag about versus something to maybe be ashamed of. It helps to have these challenges, these niches, these outliers, these things that push us to go beyond what can be almost a knee-jerk solution as we get further into our careers. We're going to see situations where we look at it, we've seen it several times before, and we can spout out a solution almost without thinking. But these niches, these special cases, are the things that will sometimes force us to reevaluate what we're doing, reevaluate our, call it our general solution, and even make changes so that we can take into account these other special cases. Challenge of the week. What is the last niche or outlier problem you had to solve? Take a look back at it. Think back a little bit. What did you run into? What did you get out of it? I'm assuming that you solved it. Do you think that maybe you learned something from it? That maybe you, at least when you got done, were a little happier to give yourself a pat on the back for a job well done? While you were in it, while you were solving it, did you have that positive attitude that this is going to be, this is neat, this is fun, this is a cool challenge? Or was it something where maybe your attitude was more negative that you're just like, I can't take this, this is ridiculous, this is slowing me down or something like that? And if you had the negative attitude, maybe next time, try the positive attitude and see how that works for you. I think you'll be pleasantly surprised. And that being said, I hope that you're pleasantly surprised as you move forward from this episode and have yourself a great day, a great week, and we'll talk to you next time. Thank you for listening to Building Better Developers, the Developer Noor podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoor.com. Just a step forward a day is still progress. So let's keep moving forward together. One more thing before you go, the Developer Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.