Unpacking 'Psychopath' Scenarios and Tough Coding Challenge

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we are going through the developer journey. We are Building Better Developers. We are Developer Noir. I am Rob Broadhead. I am one of the founders of Develop Noir. And in keeping with our standards now in the last few episodes, we talked about a little good and bad, good thing, bad thing, and then throw a little extra introduction to it. I'll do the introduction first because I got to think about my good and bad. I was going to reverse it and then I lost it. I am also the founder of RB Consulting, where we integrate, simplify and automate and find ways for you to find the best way to leverage your technology investment, whether it's people, whether it's languages or applications or whatever it happens to be. Good thing, bad thing. Good thing, this is actually a fun one. So good thing is I managed to go to a store that for people around here, it's a place called McKays and they just take back old. It's like it's a used store, a used store, used media store. It's not just bookstore, they do video games and a whole bunch of crap. And I had just boxes of stuff that was sitting around basically because I've just had kids move out. And we took it there and got a bunch of credit, introduced the kids to it. So now they know that they can take their old crap there. They can get new stuff, which they did, they're new to them. They can go get like books and stuff like that. So that was a good thing. Bad thing is I don't want to get political, but I watched the debate last night and it was the most ridiculously bad thing ever. It's just like it wasn't a total waste of time, but it was definitely like you could do better. Like to everybody, everybody involved, you could do better. You could be more entertaining. You could do a lot of stuff better. But that's sort of the way things go these days. Somebody that also, maybe cannot do anything better is sitting on the other side of the screen for me. Michael, go ahead and introduce yourself. Hey, everyone. My name is Michael Milosz. I'm one of the co-founders of Developmenter. I'm also the founder of Envision QA, where we build software tailored to meet the unique needs of healthcare professionals and small to mid-sized e-commerce businesses. You know, whether you're a healthcare provider or an e-commerce entrepreneur, partnering with Envision QA means unlocking your software's full potential. Experience the confidence of knowing your software meets the highest quality and compliance standards while driving success in your industry. Good and bad. Let me start with the good. So, I guess the good news, I missed the debate. I missed all that chaos. Getting back on track this week because on the bad side, life happened. Some health issues hit the family last week and we were down for quite a few days and unfortunately had some very bad experiences with the general healthcare system of our local general hospitals. Can only strive for better. And with that, I'll pass it back to you. Maybe there'll be another one we'll do, building better hospitals. That'll be like the next thing to get into. Today, we're going to talk about how do you get better? Well, one of the things is it's a little bit of like you get better because you just do it. It's like the more you do it, the more you get better. I want to talk about this thing that we've come up with a new term and actually it's because we're in a conversation with a client and we're just going to call that client Melissa. And. Melissa came up with an idea. We're talking about the happy path and we were talking about the things that aren't the happy path. And she interjected and said, Oh, the psychopaths. And I was like, that is so on point to what we often run into that we're going to use that. So she's like, you know, just make sure I was like, can I mention your name? And even if it's like, you know, in quotes and everything. And so we were able to do that. And so we're stealing that for now. So we will use psychopaths for quite a while because I just find that very apropos when we're talking about everything, not everything, but a lot of the things that are not the happy path, particularly the things that tend to bite us in the buttocks as Forrest Gump's likes to say. Those things that are like outside of the norm, the outliers, the things that are just rare, but it's like, those are the ones that always get us. And I want to talk about getting into that because there are probably like two situations that we run into where those are very, very difficult. There are others where they can be. It's a challenge, but the ones that are most difficult are where there is where we're talking about like a brand new application, brand new solution. So it doesn't exist except in the person's head. And usually this is an entrepreneur or visionary type person. And so the whole like rubber meets the road is not really in their wheelhouse either. And so you have to find a way to take that vision and ground it into, you know, bring it down to earth and then start looking at all of the warts that could possibly come out of it. Similar to that, maybe, although it's a little easier is when it's an existing system and it's somebody just does it. You think of it as like almost like muscle memory. So you're trying to figure out where are the things that they just know how to do, but they're not going to think about it. It's like if you, if you ask them, they can give it to you. They're like, yeah, this is what you do. This is how it works. The problem is you have to know what to ask. So as you get into these things early on, when you're starting out in your career, you're probably going to find that there are, you're going to like almost out of the gate, be able to come up with some things that are how can this fail and the common things everybody, right away, we'll find things like what you look at, you know, is it a maximum value? Is it a minimum value? Sometimes people right away figure out what if there is no value and it's like, okay, cool. As you get a little further on, you will bump into the off by one error. So you'll very quickly say it's not just the maximum error. It's the maximum value plus one and minus one, the minimum value plus one and minus one, because there's a big difference between less than and equals or less than and greater than and you will get bit by it at some point, whether it's design issue or whether it's just typos or all sorts of things. And of course, there's the whole equals as opposed to less than or as opposed to greater than, which usually is going to come more around your copy paste and stuff like that. But it's like fine. Like it really does get into almost a statistical analysis of like fine, like a middle, absolute middle of the road, something on the first quartile and the third quartile, both ends and right on the cusp of both ends. And then is it a, you know, does the value exist at all? What if it, and then you start getting into things like, well, what if they try to find a way to put a value that doesn't exist? One of the things like a good example you'll run into probably at some point is where somebody's typing a number and it should just be a number, but they decide to put a comma for their thousands or a point for their thousand separator or something like that. If you don't have a, you know, depending on how you have stuff set up, that might sneak through. And the next thing you know, you're like, what the heck is this? Or they put a, you know, a currency sign, a dollar sign or something like that on the front of it. And you just want a number. So now you've got to figure that kind of crap out and don't even get me started on like date formats and phone number formats and things like that. And especially you have to, in a lot of these cases, you're going to start thinking through things where there are varying forms of it because you're going to assume certain things. Like for example, there was a point where people assume that all years you really only cared about the last two numbers. And then they found out that when you got to about 1999 to 2000, you did care about all four numbers. And so there was, you know, those things happen. Now you're asking, you may say, okay, great. You've thrown out a lot of things. You may even know what a lot of these are. So how is it that we figure out how we know what we don't know? And this is where it does go back to as we've talked about before. A lot of it is asking questions, but a lot of it is sitting down and saying, okay, here's your process. And I think the easiest way to do it is find your best way to take the happy path, whatever that path is, and then disassemble it into the steps that are involved. And then that allows you with every step that's involved to apply what you know to each of those steps, which is basically what happens if the inputs are incorrect? What happens if the outputs come out wrong? What happens if the step gets skipped? What happens if this step is going on and another step triggers? Those kinds of things, that kind of line of thinking is what's going to get you into those kinds of questions and to help you get those psychopaths, which are truly some of the nastiest things if you try to do like real time processing and it's parallel and you get into race conditions and things like that. That the first time, and that is not like, this is not about like, you know, I'm a black guy, white guy, that kind of race. This is like running really fast race and both people, both things finish at the exact same time. Then who's the winner? You can't have a tie. So what happens? There are things like that that you will run into or even like maybe you can't have a tie and then you do and it's called a deadlock or something along those lines. These are the things that you will run into when you start breaking down those steps and applying that. How can it go wrong in the most really in like the most granular way? It's like, because then it's limited. Now you're not having to think about entire systems of issues. Now you're going to those specific things and you're basically saying here's, you know, whatever your, your ability is to guess or to, you know, assume that these are the things that can go wrong. Maybe there's four tie items or 10, but the important thing is that now you can take all those apply those to each step and you don't have to figure out the whole system of exploding stuff when things go wrong. You can go to that specific thing and say, okay, this thing, what are essentially what are all the possible states? And then from there you can rework your way through it because at the end of the day, we're basically almost always dealing with a state machine of some sort or another. And so if you can nail down the states, then you can nail down the process itself and figure out where it can go wrong, or at least what you need to do if it gets to a state that it potentially shouldn't be. And now this is also a near and dear to the heart of anybody that's in testing because this is the, this is the other side of it. It's like, okay, you're telling me this is a requirement. I need to think of all the ways it can go wrong so I can test it and verify that it's going to work in all of the situations. The last thing before I throw it over to Michael is just the biggest thing that you will save yourself headaches from is to not assume. If you assume things will be a certain way, you will find out that they won't and you have problems. It's things that never, never happen like outliers, like you have a huge server and it runs out of disk space. And suddenly your web application that doesn't even know what disk space is effectively doesn't run because somebody can clean up the log files or something along those lines. So don't assume, sit there and really try to think like, where can you possibly be assuming things so you can figure out where you can ask the right questions. And now I'll toss it over to Mike. Wow, that was a lot. So I don't want to get on my soapbox too much because I could so go way too far in many directions. One of the things Rob touched on so many good points and what I'm going to bring to this conversation is staying on this topic, but from an example perspective. So in my 25 plus years, 30 years of working in this industry, I have worked through the journey of here's a ticket, go write a task, you go build it, you test it as a developer. Hey, what I did work, but I didn't test the whole system. Things break down the road. You don't think to test other things. You only work on what you work on. As you move into your middle career, it's like, oh, I'm going to start asking more questions. Like Rob said, you're going to look at those, you know, off by one errors. You're going to look at what type of data you need in your system, those deadlocks, things of that nature. And as you move further along in your career, or if you're like me and you like to jump and wear many hats or just do too many startups and you just wear every hat, you come to find out that from a project owner's perspective, a business manager or a tester's perspective, you look at things different. You look at the systems, you look at the stories, you look at these requirements in a totally different way. So like Rob gave so many great examples. I'm going to walk you through a couple of scenarios here. So first of all, from a tester's perspective, we take a ticket. We take a requirement, for instance, login. Happy path. User should be able to enter in a valid username and password and log into the system. Perfect. Simple. Negative path. User enters in an invalid username and password and they shouldn't be able to log in. It's still a happy path, but it's a negative use case. Some of the weird cases could be if you don't have the right logic in the background, what happens if you throw in a SQL command in the username or in the password? You now get a SQL injection error because you have something weird in the background and now suddenly your database is deleted and things go wrong. So from a tester, from just a user story looking at the requirements, you have to assume that what you're giving is wrong. If you're a tester, we have to always assume things are wrong. But as a developer, when we're handed a ticket for the first time, if we're doing Agile correctly, if we're going through our sprints correctly, we're going to walk through the requirements of the ticket, walk through what the ticket or what the requirement is supposed to be. How does it impact the system as a whole? What are the acceptance criteria? What are the things that we can kind of let slide in this particular ticket? Because some work precedes other work. So you are going to potentially write bugs or feature or future feature conditions or features in new code that aren't necessarily turned on yet or maybe feature incomplete. So you have there will be things that won't work. But the thing is, in the ticket, in what we're looking for, we should know what we're doing. So when we look at these tickets and we talk through these tickets, you should always be asking yourself, are there any questions that are not there? For instance, log in screen. Well, what happens? So I just give you those two scenarios. You know, happy path log in negative case, still happy path user logs in with invalid credentials is kicked out. But nowhere in those requirements specifies, hey, what happens if I get bad data or weird data or a sequel command? If you leave out things like that, it's not going to get good. You potentially could leave yourself open for problems or the features not going to work as expected. So we have to ask ourselves, looking at a requirement for, for instance, just a screen, like I said, the login screen. So you have two fields. You have a username and password. Well, from a web perspective or even an application perspective, are they alphanumeric? Do they allow special characters? Do any input fields? These are things you should ask. Is it numeric only? Can I allow sequel? Should I look for specific commands? Do I need to mask the data? You know, is this data being stored into a database? Do I need to set a max length, a minimum length? Do I have to add specific criteria? Oh, I need uppercase letters, lowercase letters. I need numbers. I need special characters. It has to be a minimum of a certain length. And if it's not, and they try to log in or they try to create this information, what do we communicate to the user that they've done wrong other than, oh, hey, you can't log in or, oh, hey, you can't create a password. What do you tell the user? So you have to also think about the error handling behind the scenes as well as what is displayed to the user. So a simple login page. Hey, build me a login page to allow users to log in. Sure, sounds easy, but there are so many layers to impact with that that this is just one example of how to kind of peel back the onion when you're dealing with these type of situations. Now, a recent one we both were looking at is we were trying to walk through the requirements with a customer and we started running across things that we started realizing were muscle memory. These were things that the users were doing that they weren't thinking about. So to them, it just worked as it's supposed to, but they weren't communicating to us what it is that they were doing and what it was that they were expecting from the system or that the system should do. So when we go to code this or work in a similar solution without this, things are going to break. People may not get paid, customers may not get their products on time. So you always have to look at the little pieces. You may have the high level, big roadmap, sitemap, whatever, but you need to pick at it. You need to literally get into those nitty gritty details. And at the end of the day, if you think from a tester's perspective, look at the use cases, the user stories for that given ticket. And if you can write every single user story, you can write those tests first, then write the code, and then next time you go to make a change to this, if you break one of those user stories, you'll know immediately the code will never make it out the door. And then you go back and you have to fix it before inducing a bug to the end user. We don't want to be like that one company that took Microsoft down all across the world. So again, these are those psychopaths, those paths that you may not always look at with your stories. You have to get to those details. You have to talk to the customers. And sometimes you literally just have to sit there and watch what the end user does. It may be boring as heck, but watch what they do. They may do what they say they do. Great. Record that. If they don't do what they say they do, stop them and find out why, or just pay attention and see what use case they just introduced that has not been communicated. And finally, the other thing you want to look at when you're watching that is, are your end users or is the prospective customer doing things outside of the system that again, is that muscle memory or a process they've introduced to work with their current systems because their systems don't do it. So they have built a system on top of a system that you have to kind of unpack and figure out what that psychopath is to put those requirements into a ticket to make sure that your functionality, that software that you're building meets the customer's demands. That is, that last part is probably the best is you can say, tell me, and you're going to get something. If you say, show me, you will get something different a lot, particularly if you're dealing with an existing system with a, call them a power user or a user that has been on this for a long time, because as Michael said, a lot of times they'll have their own systems. I've been at places where they've got these huge systems and they'll tell you that they use them for everything. And you sit down and two seconds into it, you realize that they've got Post-it notes or they've got extra little spreadsheets. They've got all this stuff. It's like, well, what is that? Oh, I use that so I can get this thing. And it's the kind of stuff you're like, well, wait a minute, you said you only use the system. Then what happens if that's not there? Well, that never happens because I always sit down at my desk and my Post-it note is always there. It's those kinds of things that you need to, you need to find a way to get to it. And sometimes you're not told it because people want to tell you the right way to do it, which is not the real way that they do it. And that's where show me is so much more value sitting down. And this is, I think, lost a lot when we have so many remote engagements and stuff like that. And I was very frustrated in one not too long ago where it was third and fourth hand information as opposed to just being able to get boots on the ground and watch somebody do it and how they use the application and how they use the system and be able to actually say, okay, what's actually going on? Because in this case, it's one of those you get to a point where you say, okay, well, how does this get used? And they say, they use it like this. I think it's like, well, wait a minute. You think if you don't know, then we need to go who can say definitively what the answer is. Now, in a very similar vein, you can say definitively what you think about us and what your suggestions are for us by sending us an email at info at developer.com. You can contact us out on developer.com on our contact form. You can put comments wherever you see us, whether it's out on YouTube and the development or channel, whether it's out on whatever your favorite podcasting tool is or your actually podcast listening devices, all of that stuff, wherever it is, leave us comments, send us comments, smoke signals, we really don't care. However you get it to us, we want to hear from you. We want that kind of feedback because it helps us help you. Help us be better, building better developer podcasters so we can help you build better developers, essentially that kind of thing. We are not done though, we are continuing this season. We have tripped at the 800 mark apparently in a number of episodes, which is in itself sort of mind boggling, thinking back to like when it went to like double digits, it was like, wow, I made it to 10. And now we're quite a bit away from that. So we're just marching along. We will come back with more on the developer journey next time around. Until then, get out there and have yourself a great day, a great week. We will talk to you next time.