Breaking Things Down for Success- How Developers Can Build Better Habits

Welcome to Building Better Developers, the Developer podcast where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season of building better habits because we are building better developers and we do it one day at a time or something like that. I am Rob Brigham. I'm one of the founders of Developing or Building Better Developers. I am also a founder of RB Consulting where we help you take the vast wasteland of technology that is out there, whether it's technology sprawl or the pain related to it and find ways through simplification, automation and integration to like bring that down into something that is a nice pretty little Farmville village or something like that so that you can be far more effective your business and your customers are happy and everybody wins. Good thing, bad thing. A good thing is why did I, I had like a nice little list. So bad thing is that I made myself a list of like, I was like, oh, here's my good thing and my bad thing and I lost my list. I don't know how I like it's right here in front of me as I'm banging on this and I didn't ah, I hate when I do that. Ah, good thing. Good thing. Good thing. Good thing. Was, I had a night last night. There's one of these and this actually goes a little bit to like our challenge from last week or from last episode at least where, where there's last week or a year ago when you did it is with like doing your to do list and stuff like that as I got to the end of my day and I had my stuff done. I got things done. I was like, okay, the stuff I needed, wanted, desired to get done that day got done and I had an evening that was nice weather out. I was like, hey, I'm going to go. I had like a little training thing I had to do, but I was like, you know what? I'm going to go get like a simple pizza. We got a nice big thing of wine and just like hung out on the deck for a while hanging by the fire pit, just having a good old time. So that was definitely a good thing in the world of challenges. The I think one of the biggest problems, which actually is sort of the bad thing is me picking the automation piece is because I need to go. So I'm failing this, but I'm going to do better this time around. And I'm I've got a couple more days, but it's basically I've got, I've got some ideas that want to automate and I need to spend a little time to do that automation. And part of it, which is sort of good to itself is that I've been doing all these little automations like building out mail filters and some things like that and a couple of little things. But I think that's a challenge. And that's why we do this is so that we can keep it in our mind and not let it fall through the cracks. So something you may want to do, which like I, like I said, I always I've done the to do list challenge for more than seven years. I think probably more than 14 years. I've done that stuff for a long, long time. However, you do these kinds of things and you start to build these habits, but you may want to put on that list working on one of these challenges or when you get to the end of it's like, Hey, I didn't get to this thing yet. I want to make sure I do this because you do want to get those habits built in. And those may be those additional tasks that we've talked about that could end up not really like your main task, but the thing is like, I just need to touch this item or do this thing today. Don't go out there and touch that person over there because you never know what kind of developer and her stuff he's got all over himself. Michael, go ahead and introduce yourself. Hey everyone. My name is Michael Mollash. I'm one of the co-founders of developer Neur building better developers this season, building better habits. I'm also the founder of Envision QA where we are experts at automation. If you are struggling with bad software, no QA, limited QA, or just problems with overall software development, give us a call. Our whole mantra is quality first. We do test driven development and we will help you build those unit tests, those automation tests, selenium tests, mobile testing, whatever you need to make your life better and to improve the quality of your product from development to release. Good things, bad things. Good things. Let's say good thing, good thing, good thing. It's wrapping up. We're recording this right before Halloween, but yeah, I'm a big Halloween guy. So tomorrow I'm so stoked. So we're actually starting the Halloween marathon tonight and we'll finish that tomorrow. So that is a very good thing. I'm just stoked. Bad thing. I decided to try my luck at some horror video games and found out that Silent Hill 2 remake is really creepy. Awesome game, creepy as get out. It's almost as bad as the baby level on Resident Evil 7. So while I love Halloween, I hate scary in some instances. Challenges. So I've been doing really good with the automation stuff. Again, that's kind of my mantra, my company. But as far as the Pomodoro, I'm getting a little bit better at it. I need to remember at night to use a different timer than my phone. Again, I mentioned that last time. If you have those, you know, do not disturb things turned on, which is great. If you're trying to use that to control your timers, your sound might not come on. So just be careful with that. And the other things I've been working on, kitchen sink app, I've been building out some nice UI designs, which are working actually with the automation piece to make them plug in place. If I need a custom design, it will format it to a particular customer's kind of their colors, their branding at a push of a button. So you just answer a few questions, plug it in. Boom, you have a web UI style sheet and some basic screens to get you going. So making some good progress on that. All right. Speaking of progress, let's talk about our habits for this episode. This is something that's big. We've, there are a lot of habits and there's a lot of things that are interrelated that are part of becoming a better developer. Just like in the technology world, things like you need to sort of understand a database to be able to understand middle tier, to be able to understand what you're doing on the front end and where is it best to do that work and those kinds of things. In the world of getting stuff done, of being productive, of making sure that things don't fall through the cracks, there are a lot of skills related to that. And this is where we sort of like got a little bit into a Pandora's box of talking about just a list item. Last time around, we talked about having your list, you go attack your list. This episode, we want to talk about, it's really, it sort of gets into the meta side of that of making the list. But more importantly, it's taking big things and breaking them into smaller things. And doing that in a way, and this is also which is where our habits going to talk, we're going to talk about is basically having a habit of a personal backlog of when you take that big thing and you chip off a small piece and you put it on your to-do list, you take the other chips and you put them in your backlog. You spend a little bit of time breaking that task up, let's say it's going to take you a week that you spend a little bit of time one day and you break it into seven tasks or five tasks every year, you want to define your week. And those are going to be, you know, Monday you do task one, Tuesday, two, three, four, all the way through to Friday. I think here is this also touches on the idea of batching a little bit. So let it just, instead of just like chipping off one piece and say, okay, here's what it is and I'll think about that later. You say, I'm going to look at this a little bit and I'm going to think about what makes sense. What is the logical progression to get this done and then break it down. And now part of this is when do you know it's too big? Now that is itself. Quite an interesting question, but we should, even if we have never estimated anything, and we probably have, let's face it, we, your life, it's estimation. But let's say you haven't really professionally thought about it before. You should at least be able to sit back and go, huh, what is it going to take me to do this task? Now the bonus is it really doesn't matter if you overestimate or underestimate, particularly if you underestimate great, you got it done faster. If you overestimate, then you can always come back and say, okay, I've got to find a stopping point. I'm going to get this up. I'm going to tackle it another day. So yeah, that's not the best solution, but at least it is viable because now you're like, oh, I took a bigger bite off than I can chew. I've got to adjust that. And the way you do these things, typically there's a lot of ways you can approach it. But the nice thing is that we have, when we're talking about our daily lists, which is what our backlog is, our personal backlog is effectively, it is all of those different tasks that we could actually take and put on our to-do list for a given day. Take them out of our backlog, put them on our list, go get them done. Ideally, and we've talked about this, if you ever go get the, if you get the development of a book, all that kind of stuff, we talk about these things about having a backlog, about having that pool of tasks, because we probably should have told you this before we challenged you to do three tasks or five tasks a day, is that when you've got that pool, it makes those tasks really easy because you have things that you've got to do. You have things that have to have some sort of progress made on them. And so you can figure out, looking at your backlog, what are the tasks that would potentially move the ball forward there? Find one that fits and then you put it together. It's almost like a, it's a little bit of a Tetris kind of thing because you probably will have a bigger task and then maybe a couple of smaller tasks or a bigger task and maybe a medium and a small task or things like that. So you're going to look at these and you're going to need to sort of push them together because they're not all going to be the same size. And this is where it gets into, all right, we know that our outer limit, our, our, our biggest constraint is we have to get it done in a day, which we cheat and we say you have to get it done in six hours, which that's just one task. If you only get one task done, you need to break it up. Therefore six hours too big. So now we start looking at, well, what would make sense? You could, if it's just two tasks, you could say, you know, three hours is sort of your limit, but we're talking at least three to five. So now you're down to probably one to two hour tasks. Now it takes a little bit more work to break something up to that level. That is sometimes too granular. If you get into the world of Scrum and Agile and Sprints, that is why there are tasks that are not that small. There are tasks that take a week or more. However, to some extent, those have to be able to be broken down because you work a day at a time. Even if it takes you a week to get it done, you worked on that five different times. So you had five chunks one way or another. So the reality is that there's some level of us stepping in and doing work in these smaller chunks. The bonus to this is this gets back to why your school, your college classes, well, college is different because they hate you, but in regular school and before college, your classes were effectively less than an hour. And if you look at presentations that are complex presentations, they are less than an hour because people can't consume content. They can't get heavy into thought for a long, for past about 45 to 60 minutes on average. Now you'll say, I'm a developer. I can go heads down for eight hours. Yes, you can. But if you don't break that out a little bit, there is a diminishing return. So you would find that if you actually break that up and every so often, just like even if you get up, which is another topic, we'll get into this. If you get up and go like take a five minute walk and come back, you will be more productive having taken those five minutes and just step back for a second. Then you will be if you just stayed heads down the whole time. Now that is not a hard and fast. There are times where it's like, don't pick walk, going for a walk right when you're in the middle of solving a major problem. There is like timing and things like that. However, the nice thing about this is this forces us to have these bite sized chunks, which is healthier for us in the long run. It makes us more productive in the long run. And it is easier to estimate small than it is big. If you want me to estimate how to repair a totaled car and I need to just figure out how to, I don't know, replace a tire that's flat. I can figure out how I can better estimate fixing that flat tire than I can repairing the entire car. Same thing with code. We know that. It's like if I just have to write a little method or a function, I probably have a lot better idea of that versus an entire application. And so this is where we start to build our backlog. And this is going to be one of the habits is that instead of just this is where we take it to the next level. Instead of simply building our list, one of the other things we're going to do is we're going to have a backlog and we're going to use that backlog to feed the list. But we're also going to at times be building, use the building the list piece to help add to our backlog. Now I'm going to gather my backlog of thoughts while Michael continues this because he also has a lot of thoughts on this. Thanks Farro. So I'm actually going to take a step out of software for a minute and kind of hits closer to home. If you're looking to build task lists and you're looking at massive problems for trying to break things down, just think about your grocery list. You know, you have to go shopping, you have to buy food, then you have to prepare your meals for the week. You know, you get dinner, maybe lunches, breakfast. Typically you're not going to go to the grocery store every single day to buy the food you need to prep to prepare your meal for that night, cook it and then prepare it. No what you end up doing is you look ahead. We figure out, okay, what kind of menu do I want for the week? You go to the grocery store, you buy a whole bunch of stuff and then you may do that on Saturday and then Sunday you go, okay, so what are the meals going to be for the week? And then what you need to do is, oh, well, there's a bunch of prep work I need for the week. So what you can do is Sunday, you can do all that prep work, put it in the fridge and then Monday. Oh, we're having tacos. Okay. So you pull out all the stuff that you prep for tacos, put it together, run your recipe, six, 30 minutes to cook. Boom, you got your meal. If you did not do all that prep, then you had to probably go to the grocery store, which took you time to get there, time to shop, time to get back, time to prep, time to cook. And now you're looking at eating at sometime, maybe eight, nine, 10 o'clock at night because you started so late getting your things together. That's kind of what we're talking about by breaking things down. If you're in the software world, you have problems like that. You have to be forward thinking. You have a problem and you have a deadline or you have an idea that a customer wants and they kind of need the timeline of how long is it going to take to get it done. So what you do is you look, you kind of plan a little bit and you take what it is you're trying to accomplish and you figure out, okay, what do I need first? What do I need to gather to be able to do this project? Then you break it down. You do your prep work. That can be your smaller tasks. And then from that prep work, you can then break it down into other tasks that you can do throughout the week, throughout the day to get the tasks done. Now as Rob mentioned, sprints and projects, planning and things like that, it's life. We want to get things done, but we also don't want to be overloaded. We want to follow those tasks. We want to do the Pomodoro technique. We want to ease the stress and get things done. The GTD, I believe is what you've been referring to through the past few podcasts. So what the idea is here is look ahead, look at what it is you need to get done, make the list, kind of plan for it, and then put together a lit, like a master list of that backlog of things that need to be done. And then you pull them in, in the order that makes sense. Again, you don't want to build the screen before you had the backend because you may not have all the, you know, the fields, all the data points identified that you need on that screen. So make sure you do things in the right order, not out of order. So you're not taking more time to get things done. And lastly, because I'm the test guy, if you are building software, don't neglect testing. Look at your projects from the user perspective. So if you kind of have this planned out, what it is that you're going to build, look at it from the user's perspective. As I build it, what am I supposed to get out of it? So then you can actually write the test with the test. So one of your tasks could be, if I do this, how do I test it? And then you essentially can kind of have a corresponding task go with each of those. And by the time you get to the end of the week, you can push a button and know if everything you did during the week works. So that brings us to this challenge. There's a lot of ways that we can do this, but as we've talked through this and thought through what kinds of things we're going to have in our to do list, what I'd like to do for the challenge is have you step into, hopefully you're already doing your daily task list. Maybe you've already finished that, but we're going to do another week of it. And what we're going to do this time is we're going to do our daily task list of three to five items. And what I want you to do is probably, in most cases, there's going to be at least 60, 70% of the tasks are related in some way. So maybe it's your day job or it's the main project you're working on or something like that, certain coding tasks. The thing here is that instead of looking at your week of like, I have to code on, like, let's say you have your day job. I have to code on this application every day. I just, I've got a lot to do. It's going to take me at least a week, maybe more to get this done. So I'm just going to go to work each day. The beginning of the week, your first day, look at your task. And what I want you to do is within doing that, take that things, particularly this is where it's a challenge. Like if you have a whole day, you've got a full six to eight hours of work to do and you're trying to figure it out. Well, the challenge here is break that into a couple of pieces. I mean, it may just be what you get done before lunch and what you get after lunch or something like that. In a way that you can now have that one item of I've got to work on this project to three or five items that I have these things that I'm going to get done today. Now within that, you most likely are going to be chunking out things for the next day. And so what I'm thinking about here is a little combo challenge. Part of it is the meal prep kind of thing like Michael referred to is what you want to do is let's in this first day, and maybe this is one of your tasks on your to do list in your first day is create a little backlog for yourself of the bigger item for each of the next five days or the next, you know, I guess next six days, let's say we're on day one so that when you get to day two, you already have a backlog of the big items. And now as you go through the week, every day as you're putting those other lesser items together, be spend a little bit of time. So the goal is every day for the items that you the you know, if you put if you split stuff up and you have like, say three tasks, I want you to actually create six is I want you to spend enough time to put six together so that every day you have you are building actually on top of your your backlog. And this is an interesting one because I want you to do it just for a week, because at the end of the week, technically, you're going to have like several weeks worth of well, you at least have another week of tasks, I guess, if you do extra ones every day, roughly. But what I want you to do is build the habit so that as we start going forward, one of the goals needs to be when I build my list, there is always going to be something that doesn't make the list that goes into my backlog. Now, at some point, we could look at every time we go, which gets into the idea of like technical debt and things like that is like maybe we have a point where we say every day one of the items I'm going to put on my list is something that's in my backlog. It will not be something new. It will not be something on fire. It will be something that's been sitting in my backlog. So that's the challenge is to build your to do list. Now we've done this for a little bit. We're starting to build a habit. Now we're going to tweak this habit and we're going to build our list for today and also be adding tasks that we can maybe pull from for the future as we start going into our next seven days. So this was going to be a little bit different, but I think it's going to be something and you can put your you can put your backlog in a in a Word document on a spreadsheet on a sheet of paper, you name it. Just ideally put it on a sheet of paper with pencil so you can carry it with you, a little notebook wherever or if you've got like a phone or something that's like a just handy simple list so you can look at it any time and go, do I have something? Oh yeah, I've got something to do. I have some dead time. I'm going to go take something off of my list. What you should put on that list is email info at developer.com and send these guys some sort of feedback. I really don't care if it's good or bad. I have like feedback. I just like to hear what you like, what you don't like. Obviously you like me. You don't like Mike. You don't have to send me that part, but you can. You can always double down. But ideally, what are the topics we've covered? What are the things we've covered that are maybe we've covered too much that we haven't covered enough? What are some things that you would love to hear from us? What are some suggestions you have for us and the greater development or community for building better habits? What are some of the things that you have done? And we will be more than happy to either leave your name anonymous or we can actually give you the fame of being mentioned on a podcast if you want to get to that point. You can also reach us out at developer.com. There's a contact us form. You can leave us comments and follow and rate us on the on YouTube on wherever you get your podcast. Facebook, we've got a page out there. You can get us out on X where you can go to develop a new and you can follow us there. You can send us stuff. You can reach with us, whatever you want to do. All that being said, it's time to wrap this one up. 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 to develop a new 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.