Building Better Habits, Breaking Down Problems

Welcome to Building Better Developers, the Developing 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 continuing our season of Building Better Habits. We're Building Better Developers. We are the Developing Nord podcast. I am Rob Brodhead, one of the founders of all of the four mentioned, also a founder of RB Consulting, where we help you figure out how to take technology and make it your workhorse is it allows you to become better as a company, as a boss or whatever it is you do is doing your business better, is taking technology, leveraging that through simplification, automation, integration, and even research and some of the things we'll do so we can help you figure out where do you need to be not just today to be more productive, but the trends, what are the things that you need to do so that you don't have to come back and hire consultants and teams every year and redo all of this stuff. Instead, you have a roadmap for the future that allows you to put a serious budget to it that doesn't have all kinds of wild estimations. You know where your growth is and you know that your systems are going to be there when you need them and they're going to be, I don't know, reliable and some of those kinds of things that people like to have. As far as habits go, this time around I want to talk about, because I've talked about Pomodoro probably a little bit too much in those, one of the ones that's really been good that I've made some adjustments on which actually goes to one of our most recent prior episodes is the list, is figuring out where my priorities are. And it's really been a challenge because I have a lot of priorities, everything's a priority. I have a big list of things that I have to do, but in doing so I've basically take, I've been able to adjust a little bit with my list habit of looking at that list and taking one item for the couple of things that have to be touched, for the projects that have to be touched, for the customers I have to reach out to, things like that, at least one thing in each of those. So it's a little bit of a different approach from prioritizing stuff as much as it's saying These things are all critical, but I want to make sure that I at least get these things done and it's sort of really refining and pushing to the why. What do I need to do to take a step forward in each of these areas? And so that's helped me quite a bit from the habit side of things. And the good things, bad things, I've come through, like I think maybe a lot of you, I've come from a lull and it was a little bit of a struggle getting through the holidays to make sure that I was like, I was taking advantage of what I need to take advantage of and that is going to get a little bit into our topic today. But it was making sure that I wasn't just sitting there twiddling my thumbs and things like that. And so I was like struggling a little bit because it was hard to start the day when I didn't necessarily know what I had and I had to go look for work to do to some extent. It's not really that I had to look for work to do, I had to figure out what is it that I want to attack next. I had too many options essentially. So a little bit of a challenge. The good news is I made it through there and then as we start into the year, it's like bam, slammed with everything. So I don't have to worry about that. I got so much stuff to do. I'm having to figure out what I can't do today to build my list. It's basically my list is huge and I'm having to just whack away at that to get it down to something that I can get done in a reasonable amount of time. One of the big items on my list today is to pass this over to Michael and let him introduce himself. So I'm going to let him introduce himself while I go check that off my list. Hello, everybody. My name is Michael Melosh. I'm one of the co-founders of Building Better Developers, Developineur. I'm also the founder of Envision QA, where we are your software development and quality assurance partner. We build tailored software to meet the needs of healthcare professionals in small to mid-sized e-commerce businesses. We work with you. We figure out what your business needs and we help identify the systems that you need to have built for you or to customize what you have to work for you so that your software works for you. You aren't working for your software. Good and bad. Good. I'm getting a little more sleep. Like Rob, I'm hacking things off my list. I'm actually kind of getting back on track from the holidays. So things are getting back into more of a grind, a routine. Bad thing. It took me a good portion of the week to get back to that routine. I lost a couple of days of sleep and just trying to get back into normal habits after the holidays. And with that, talking about the habits. So this past week, what I've really been working on a lot is trying to break things down a little bit, which will kind of lead into this episode and also talking about or working on my lists and trying to focus on what needs to be done in the near future to make sure that all the projects I'm working on are on track where they need to be and make sure that we meet those deadlines that are coming up in the next few months. And that really gets to, I think what I want to focus on is there's a couple of ways we can look at the topic this time around. And it could be the idea of leveling out your schedule, your work schedule. Because say we tend to have sort of a feast or famine kind of thing where there's a lot of work that needs to be done and then there's not as much work that needs to be done. And it's sort of the IT norm that you'll have like a regular steady little hum and then the next thing you know, we've got to crank everything out for production release and things going wrong and all this kind of stuff. And so now we're working late nights, we're working through the weekends and we're exhausted. The stuff that really is not helpful in the grand scheme of things. It's not as productive, it's not healthy and finding ways to level it out. But the part of that is really making sure that we can break things down in a way that then we can sprinkle it across the days and the weeks to get to that point. So like Michael said is that there's going to be things that we know are coming up that we need to be, we really, there's going to be a lot of work. So we need to start chipping away at that now versus waiting until it becomes critical and then dealing with it. It's sort of like if you're, it's the death by a thousand cuts kind of thing. It's like if you're sort of addressing stuff as it goes, then everything's a little thing. But if you let too many of them go, then the next thing you know, it's now you're bleeding to death and you're trying to patch all that stuff up at once as opposed to taking the little things as they go. Now this is not firefighting and just being like, okay, I'm just going to fix the thing that's broken right now and everything else is going to be awesome. It is looking at the things that are going to come up that are going to need maintenance, that are going to need to be addressed and making sure that you have plotted out a way to get those things done in a timely manner. And that's really where we're going to get into the habit and the challenge is it is, it's sort of for lack of a better term, it goes to some of the longer term scheduling stuff that we've talked about. We've talked about some habits related to daily scheduling, but within that, I think we also need to look at some of the longer term things because yes, we don't want to spend all day, we don't spend all day every day thinking about what we're going to do six months from now or a year from now or two years from now. But what we do want to do when we're building our list for today is our prioritization should have as part of it the idea of what are the things that I need to get done because I need to be making progress on this versus the things that's like, I really could like, if I don't do this today, it's not going to matter. And it does get into the idea of the thing that if I don't do it today, it's not going to matter that much. So I'm going to push it tomorrow. At some point, it raises a priority that's like, I need to get that done. It's the idea of building habits. A lot of times I've heard that you can miss a day if you're doing a daily habit, but don't miss two days in a row. And that's sort of where we want to get with this. And it's the idea of taking something big and looking at it and breaking it down to how do I get that thing complete? Instead of looking at it as a whole, instead, it's like, how do I break this down? And that's a little bit what we're going to talk about as well. So it's how do I go from this huge honking elephant of a project to breaking it down and realizing that, okay, it's got legs, it's got a trunk, it's got ears, it's got a tail, it's got a midsection. And then looking at those sections and saying, okay, well, how do I tackle the foot? Oh, well, then the foot, maybe there's like a knee and there's a foot and there's toes and legs and stuff. Okay, well, then how do I break that down? That's the kind of stuff we want to do is we want to take, in order to do this, we have to be able to look at the big problem, which may be like in an agile sense, like an epic or something like that. It's like, how do I, for example, how do I build, let's say, billing functionality for my customer, for their app? They've got this huge application and now I get to be, I'm assigned as a developer, billing. Well, and it's like, let's look at what are the pieces, what are included in billing? Now maybe you got something put together where you've got user stories and you've got very specific requirements or families of requirements. So you can now break that down. So for example, billing may be like sending it out, like invoicing, but then it's also receiving payments and then it's applying payments and then it's reconciling those. So maybe those are like four areas right there. So now you've already broken that down a little bit. So if you have to get this billing thing done in six months, well, okay, I've got these four areas. Let's look a little bit deeper into those so we can figure out are they equally the same amount of work? So I need to get like about a month and a half to get to each of them or is there one that's going to take half the time and the others can get done very quickly? And so I basically just rinse and repeat. So I go into like, say, for example, the invoicing piece. So now I've gone into that and I'm like, all right, I need to be able to send invoices out. Well, that's like, okay, well, what do I need to do to be able to send invoices? Well, I need to be able to attach all of the bills or charges that are for that customer for that invoice period. So I need to be able to have some way to enter an invoice period and then have it go, you know, either have a list of customers or just grab all customers. Then for a customer, I need to be able to get all of the charges that are related to them during a timeframe. And then I need to have maybe there's some calculations. So I've got to take all of that and maybe now I've got to add in maybe some interest charges or maybe I need to figure out is there a past due and what does an invoice look like? What am I actually telling them that adds up to this is what you owe and this is what I need you to pay me by whatever the due date is. So now you've broken that into these smaller pieces and you can estimate what it's going to take to each of those. And then now, you know, once you've done that, you can sort of roll that back up and you now have a rough idea. It's going to take X amount of time to do the billing or to do the invoice part of the billing. And then I can move on to, for example, receiving payments. Well, what's involved with that? Do I need to set up an integration with the system because now I'm going to be taking credit card payments? Do I need to have some sort of a system that allows for taking cash in like some sort of POS or something like point of sale system or something along those lines? Do I need to can I take partial payments? Do I need to be able to support payments like for checks? And then if they're checks, do I need to have some way to make sure that those checks have actually been deposited in the bank? Now I've built these pieces out and I can estimate all those and I can roll that up and that is the receiving payment side. And we keep doing that. And so what we'll do is we'll break it down to certain, you know, a few pieces. And ideally, every time you break it down, it's, I don't know, three, five, maybe a half dozen pieces. And then you break that in and break that down and break that down. And eventually you may have to go several layers deep and have hundreds or maybe thousands, heaven forbid, of pieces. Those are all bite-sized chunks that you can figure out what is it going to take to do that. You can roll that stuff back up. And now you know, for example, this is project planning 101, it's going to take me six months of work to do this. And lo and behold, I have a six month deadline. Okay, I need to make sure what work am I getting done each month, each week, each day to keep on my track to keep that thing going to hit that six month goal. So that's part of what we're talking about is how do we do that? And this is where we're going to get into the challenge. But first, I'm going to let Michael give his two cents and then some worth on how we do this. Thanks, Rob. So you laid out at a very good high level from like a project manager, a high level view of breaking the problem down. I want to kind of flip it a little bit and take it over from the developer's perspective as we start taking those pieces and looking at them even further before we actually start working on them. So as you as developers, we essentially take these tickets or take these tasks like Rob broke down. And once you have them at the small pieces, it's time to start working on them. So we create the tickets, we do the sprints and we lay these out. But as developers, a lot of times we get into the habit of, OK, we have a ticket, we jump in and we just start working the problem. The problem may be in the fact that the problem itself isn't broken down enough. The problem hasn't been simplified. So what you might be doing is you might be working on a feature and blowing it out beyond what it needs to be. So what you really need to do and how I want to tackle this is as a developer, as you start to do your work, look at the task you have been given and read through it again. Now, you may have gone through the ceremonies of the high level pointing and all that, but still. Typically, we are busy. Typically, those meetings go quickly and you got to go through very fast and everyone just ask the questions as they can. But sometimes you don't get to that work right away. Sometimes that work doesn't get reviewed or doesn't get started for weeks. And while it was in your mindset at the time you did the pointing, things may have changed by the time you get to that ticket. Things in the system may be different. So it's always a good idea when you sit down to start a problem or a task, read through the whole process again, read through your ticket and make sure that you are tackling one problem, that your focus is on one feature and that that feature or the piece that you're trying to work on isn't really multiple pieces, doesn't need to be broken down further. Because if you get into it and you find out, oh, this needs this, this needs this, your task that may have been agreed to that, hey, this is going to take a couple of days to do may now mean it's going to take a couple of weeks. Now, if you don't do this, if you don't take the time to read through this now, you could be at the end of your sprint and be like, oh, why is this one, two day task taking me two weeks? If you had taken the time day one to reread your ticket, take 15 minutes, hey, even take a half an hour if it's a very complex ticket, read through it, read through it again, and then kind of visualize what it is that you're building. If you get to the point where this task, as you're reading through it, it's like, wait, this doesn't make sense anymore because we made this change. But the ticket says it wants this. Well, that you have a conflict. You need to raise that now before you start the work, because you could be removing or that requirement might have changed. So what is always in our mind that we have to get stuff done. We have to get work done. We have to show that we're productive. Make sure that the work you're doing is the right work, even though it's in a ticket, it doesn't necessarily mean it is the right thing to do. Always review your work before you start your work is kind of going to be my mantra on this one. You want to simplify the problem, but you also want to make sure that you are getting the problem done right, that you are solving the problem in the right way. So again, to break it down further, make sure that when you take your task, read through the task, make sure that it fits within the big picture, also make sure that it is one concise piece of that feature and not multiple pieces. Because if it's multiple pieces, you might need to break it down further and it might need to require more tickets or more features that need to be flushed out. So before, again, before you work, read through your pro read through your requirements, read through your tickets, make sure you understand the problem, make sure that the ticket addresses that problem and make sure that the problem that is being addressed is still relevant to the big picture. So what are your thoughts on that Rob? First, I have to unmute myself. See, it's like making sure you put your task as you're thinking through that. This is, I think this goes back to something that we have talked about before from a coding and documentation point of view is the idea of instead of just writing code is start out with like essentially pseudo code is use some comments that say, I'm solving this problem. And this actually is very near and dear to my heart because I'm spending a lot of time essentially doing some code reviews and refactoring and things like that, where there are these very complex functions and methods and figuring out is there a better way to do this that is more readable, that breaks this down. So it's smaller chunks of work and thus probably easier to, to reuse those chunks of work. And I think that's the way to do is we can take a problem and have a, you know, a main or a primary application, whatever it is we want to think about that we start out where it's just, all it is, is a bunch of comments of in order to solve this problem, I need to do this, I need to do this, I need to do this, I need to do this. And so that may not be the, the be all and end all, but this is where it goes to what Michael's talking about is now you've thought through it a little bit. You're spending some time, dare I say, designing your solution a little bit and saying, this is the approach I'm going to take. And then as you get into each of those steps, you'll probably find, you may find some additional things you're like, oh shoot, I need to break this into two steps, or I forgot that because I have this, that means there's this other step I'm going to have to do. You know, there's things like that, but what it is doing is it's giving us our, sort of like our outline of what it really is, I guess it comes out. It's an outline of what is it going to take to get this thing solved. Now we've broken it into smaller steps. And even with each of those, as we're thinking about it, that may help us break it into other steps. Or the reason we try not want to do this sooner rather than later is it may bring up questions because we'll say, wait a minute, I don't have all the information I need to complete this step. Because now that I'm thinking about it, I don't know how to do that. I'm not sure what that's going to be. So I'm going to have to go, you know, reach back out to a customer or my manager, or I'm going to have to go back and spend some time thinking about this design or whatever it is to be able to actually figure out what needs to be done to complete that task. And in doing so, I think you're going to write smaller, easier to understand, easier to maintain code. It goes to like, there's all kinds of lenders and stuff out there that'll tell you that, you know, there's like these code complexity scores and all this kind of stuff that are in a general sense, they're just trying to simplify stuff. And sometimes it's too much. It's too granular, but sometimes it's not. So it is very much a good rule of thumb to say, okay, I shouldn't have, you know, thousands of line of code in a function. I should be breaking that thing down where possible. And so it should be, it really shouldn't be that much. It should be, there's maybe a series of steps. And if, if that has too many steps, then maybe I can group some of those steps so that it is readable, that it's understandable, it's easier to maintain. It's easier to document. It's easier for somebody else to come behind you and say, Oh, this is what I'm doing, then this is how I'm doing it. Before I give the challenge, I want to throw that back to you, Michael, and see if there's anything that that popped up in your head, anything else to discuss. Yeah. So the other thing base, because of how you laid it out, I like that, which goes back to my test driven development model is when you sit down with a ticket, the best way that this works great for test driven development is start the ticket. Essentially write out the steps on how you would, or how you would essentially test this ticket from the end user. And as you walk through, you start finding out, okay, I get to this step here. I get to this step here. Oh wait, I now have multiple choices on this step. Well, if you are writing a feature, you should not have multiple choices unless that's defined in the ticket. If you get to a step and it's like, Oh, well, I could go here. I could go here. I could go here. I could go here. You need to stop and go ask for direction because you should have a straight path from the user's expectation to the solution. You should not have multiple paths to get there unless it is an if then scenario and that if then should be laid out within the ticket. So if you again, write it out or kind of do it as a test driven approach first, you're going to catch a lot of this. A lot of these, I guess, open ended questions are in tickets where they're not flushed out, they're not well defined, or if the feature has changed as you're going through this process, you'll get to a step and say, wait, the system doesn't do this anymore. So why am I being asked to do this in this ticket? I think that combination of the why, the thinking through it in the why is really going to solve a lot of your problems. It's amazing how those are very simple steps. They are a little bit hard to build the habits to get there, but once you do, they will make a big difference. They will help you stay focused and help you really comes back down to like leveling out stuff. So you're not, you're not going to be surprised as much. You're going to be able to estimate better, going to be able to plan better. And the bumps and bruises that generally come with software development will be smaller and very manageable. So from a habit point of view, this is again, this is one of those very similar to a couple of our sort of a theme we have as we're starting this year, it feels like with a couple of these episodes and building better habits, is it with each item that you're doing on a daily basis, this is your challenge for the next week. When you start building a habit, you're going to be able to do it on a daily basis. So when you start a task, the first thing you do is actually start the task is it's like, look at your to-do list and say, I'm going to focus on this task. So this is what I'm going to do right now. And first thing you do with that is what, you know, we've talked about and probably what does it mean to complete it? Okay. Now I know what it means to complete it. So I know what I need to get there. So walk through, what am I going to do to get that done? It's as simple as like, for example, I want to get my laundry done. Okay. How do I get that done? Well, I need to, first, I need to go to my laundry hamper. But first I have to pick up all my dirty clothes and put it into the hamper. Then I have to take the hamper to the washing place, wherever that happens to be. And then I have to do some number of loads of wash and some number of loads of drying. And then when I'm done, I need to gather all that crap up and I need to fold it, iron it, put it away, whatever it is, depending on what your tasks, how you want to define that. But now what I've done is said, okay, in order to be done with washing, doing my laundry, these are the steps I need to do. And of course, in doing so, you're going to do exactly what I just did is you're going to say, well, first, I just have to get my clothes to the washing place. But as I said, it's like, oh wait, maybe first I need to gather my clothes into some place so I can then take them somewhere. So for example, if I'm going to do a garbage run, first I need to, what are all the garbage cans I need to empty into wherever I'm, you know, the device, the transportation thing that is going to do the garbage run. And then I need to run, dump it all out and come home. Those kinds of things. When you start laying out those steps, I think you'll be amazed at how often you're like, oh yeah, there's another step I need to think about that may have been a pain in the butt had you gotten into doing the process and then had to adjust and add that step versus you thinking about that step from the start. In particular things where it's like, maybe it's like making dinner. Well, if I'm going to slow cook dinner, first I need to prep it and get the slow cooker going because if I wait until five minutes before I'm going to eat dinner, that slow cooker, hence the name slow cooker, is not going to have my food ready for me. So there's things like that that I need to do to plan out my day. And if I think about those steps, it's going to help me. So the advanced thing would be to look at all the steps you need to do to get the things that you have to get done. Let's organize those. But we're going to start simple with your habit. I just want to do a habit of attacking a task and that the first thing I do is I write down how am I going to get to that task? What am I going to do? What are the steps to complete that task? As I'm thinking about this, I think this is going to be really fun for me to do because I don't do it this way, but I'm going to be very anal retentive about it and try to do it in the next week and let's see what this works out for me as far as habits go. So first step for you, send us an email at info develop an order.com and let us know how you're doing. How do you think about these habit building things are working for you? Is this a great use of is this getting you towards being a better developer? We building a better developer by building better habits. And if not, I'm more than welcome to happy to hear from you what would be a better way. If it's just a matter of like, tell Rob to shut up and Michael needs to do everything. Cool, because my schedule just got a lot easier. But don't do that just to make my schedule easier. But whatever it is, we have topics come out. We have new seasons. We are not even close to done. Maybe you're like, oh, sadly so. But no, we're going to be around for a while. We have a lot of things that we can cover. And so we want to hear from you. What is the best thing? What is the best use of your time? What are the best topics for us to cover? Whether they're timely, whether they're more career, you know, span of your career kinds of things, whether it's just how to tie your shoes. I don't know what it may be, but it's the things that you come bring to us and say, this is what I don't think you're giving us enough of. And I'd like to hear more of it because that's what we want to do. We want to give you as much that you want as we possibly can. And if not, we'll fake it because, hey, we got skills. That being said, there's so many ways you can contact us. I'm not even going to waste your time. You can listen to the next episode or you can go to the one before us. Go out there and have yourself a great day, a great week. And we will talk to you next time.