Celebrating Victories

This is Building Better Developers, the Develop-a-Noor 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 are continuing our between season special topics. In this episode, we're going to talk about celebrating victories. We are in that time towards the end of the year where we do, most of us, to some extent, and some cases very deep extents, we do reviews, we do a look back on what did we get done this year and usually with an eye to what are we going to get done next year? What do we want to get done? Even that forward thinking process tends to, I think in a lot of cases, take up most of our time. It's thinking through and planning through what is it that we want to accomplish in the years ahead or maybe even just weeks and then in the next quarter. However, when we do that, when we focus forward, which there's nothing wrong with that for sure. I mean, we need to, we don't want to get bogged down in the past, but in doing so, sometimes we can miss victories. We can fail to celebrate some of the things that have been accomplished. Major accomplishments, more likely than not, we're going to have some sort of celebration because the buildup to in that moment of that big accomplishment typically are telegraphed, I guess we'll say. We know that they're coming. Sometimes we hope they're coming and then they eventually do. We have slips and schedules and timing and resources and everything else, but there is a buildup to that completion, to that victory. As part of that, we are, I think, more likely to celebrate it. We've thought about it. It's been on our calendar for a while, things like that. But that's the bigger kinds of victories. The smaller things that we do, partially because they happen maybe more often or with less work are easy for us to forget. The reason all of this comes up is recently doing a review discussion with somebody, with a customer, looked back at what's been done in the last year. Part of that was really almost like an estimation effort in some sense to look back at what did we do in the last year so we have an idea of what's the burn rate or the velocity that we should expect in the year ahead. Now, there are many other reasons behind that, behind that exercise and lots of information we gleaned from that conversation. One of the things is when you actually list out what you accomplished, and it's not, it may sound, but not like in a slapdash effort. Not spending five minutes and just saying, oh yeah, I did these five things. Really spending a little more time and looking back maybe even at your calendar, your schedules, your meetings, invoices maybe, stuff like that. What did you do in the last year? And I think more often than not, we will be surprised at how much was accomplished. Even in a crazy year like 2020, when you look back, if you look back to even June and especially back to March or January, what was going on? What were you working on? You're going to see that there's actually probably a lot of progress. And that brings us forward to this review time. Maybe it's good to spend a little bit of the time just reveling, I guess, in what you accomplished in the year that is wrapping up. Part of the reason to do that is as a motivational tool basically for the next time around. So if you spend your time and you're doing your due diligence and your research and things like that, and you've got this nice, long, correct, detailed, how do you want to look at it list of what did you do, what did you accomplish in this last year? And especially, this is going to be helpful when you rub that up against what did I not accomplish. You know, if you have your list of items that you wanted to accomplish that you didn't, I think you'll find that while the what I want to accomplish but didn't is probably larger tasks and goals, bigger goals than that, when you look at all the little things that you completed, it adds up to a pretty productive year probably. There's a lot that got done. It may not feel like it because you may look at those big things and say, man, I had five big goals and I only got one of them accomplished and these others, I don't even know if I'll get them done in the year ahead. But then when you look at the other things that you did get done, then maybe it'll help you feel a little bit better about, wow, I am getting a lot done. And there's two benefits out of this that are very important at this juncture for this exercise. One is to recognize that there are a lot of little things that go on that they do suck up your time. They do drain resources, essentially. You need to get those done maybe, or maybe not, but that's part of part two. However, you did get them done. And so while maybe you didn't get the big things done, these little things, more likely than not, actually were either a distraction or something that needed to get done more so than your big ticket items. The other part of this is the, I will call it the dual-edged sword of filling up space with smaller tasks. We talked about that. We've talked about this in many cases with the example of filling a bucket and you start with big rocks and then you can start putting in smaller rocks and then smaller rocks and water because you can still fill up the space between those things. But we do that from a productivity point of view. That's very useful. And if you look at that moving into the year ahead, you may see that there were maybe two big things that you did, but a whole bunch of little things that you did around them that allows you to consider what kind of small things should we address in the year ahead, particularly if any of those are productivity enhancers of some sort or another. If there's some things, some little things you can do here and there that may seem like, I don't know, you won't get a good return on investment, we'll say, then maybe you look twice at it and see that maybe it isn't as costly to do those little things as you think because you can mix them in with all these others and maybe move the ball forward a little faster on some of those big projects. So we've got these things that are tiny that we should celebrate because we did get them done. We should take a look at it and recognize what went into our time, what went into our year. And this isn't to beat ourselves up to say, oh, we didn't focus on these big things, but instead for us to see that there's a lot of little things that go on during the year. So in our year ahead and our planning for the future, we need to keep those in mind. And then, going back to what I sort of hinted at earlier, it's worth taking a look at those because maybe some of those victories that we had, those things we got done really didn't need to get done. Maybe those are some things that we did it because we thought it was needed at the time or because we didn't have the right good direction or planning. And so you said, oh, well, we'll go ahead and do this or these things. And then we find out we don't need them. It's probably more common and I would say justifiable if, for example, you'd use the Agile process on a regular basis. If you use Scrum and Sprint, then that's part of the nature is that you may have things change and requirements may change. And so you want to adapt, which does mean in some cases you could build something that is never used. But it's not like we don't have full waterfall method projects that are also never used. So just because it wasn't used doesn't mean it was a waste of your time. But it can be a learning experience. These things that you did, and this is maybe a deeper review to take a look at, is take a look at what you got done. Build that list out. Stand in awe and amazement at what you got accomplished in the last year because I just about guarantee for everybody it will be more than you initially expected. I think it's the nature of us and the work that we do, particularly in the technology world where there's just so much to do and so much going on and so many changes, it's easy to forget about or get lost in things that we're doing. Now pause there for a second. One other item that I wanted to mention at this. If you look back and you really don't have a list, if you really, you're racking your brain trying to think of what got done, if you don't have resources to go back to look at to say, what did I do? What did I get accomplished? That may be something you want to do in the year ahead. some sort of a work log or tracking tool or something that allows you to keep up with, you don't want this to be a huge time waster or something like that, but just where you can make notes and maybe even be in a little work log or something like that, just take a few minutes and note what was I working on? What did I get done? A lot of places you probably had to crank out some sort of a status report. You can go back through your status reports. If not, maybe you start creating a status report essentially for yourself to be able to track what did you do? What have you been working on? And you may see some things that fell between the cracks that need to be addressed, but you also see that you probably got a lot more done than you, more than you ever thought you did. Now in looking at all of that, so we can, you know, back to that point I was going to say before we drifted off on the, Hey, let's make sure we've got a good list. Take a look at that list with an eye towards those things that were accomplished that weren't needed or useful. And maybe like sort of separate those out essentially. And just looking at those items, at those tasks, it's worth it. And now we're looking more in it, you know, from more of a review point of view is what is it that maybe you could have used to determine that this was not going to be useful? Or another thing that comes up a lot, is it a task that you completed and you probably didn't need to? And if you had, and you could have gotten far enough for what you needed at the time, not completed it out all the way and thus would have lost less time spent on that thing that you ended up not using. Now that's a little bit of a squirrely way to talk about it. But what I'm getting at here is more the 80-20 rule. Are there some things that you just went all out and you completed 100% but really even at the time you didn't need to, and maybe it would have been beneficial to hold back a little bit and spend some of that finishing up time on something else? Because I think those are some good learning experiences for us. Is figuring out, and this goes back to that 80-20 rule, is really figuring out what is needs to be in that 80%. This also falls for a minimally viable product, but what is important in the things that we do and the requirements and the need to haves and nice to haves? And what is something that is not? And along those same lines is where do we have related items or prerequisites where maybe there are certain things that we really need to nail early on because that helps out others while there's other items and facets of our tasks that are not needed. There's just something that we can finish somewhere along the way. A favorite example of mine, although web designers may not like this, is in a web application spending a lot of time getting, for example, responsive related styling and things like that. The key usually is get it working on whatever the primary deployment platform is. In mobile this becomes really, or web I guess, this becomes really challenging because you may have a certain mobile device that most of your people are going to use or the largest majority of your people are going to use, or I guess even the largest subsection of your customers are going to use. Or you may have something where you say, well, we're going to have it for the web and mobile. Well a lot of time can be spent, particularly if you say, well, we're going to have a web application but it needs to be a good user experience, whether it's a phone or a tablet or a smaller tablet or a larger tablet or desktop. There can be a lot of time spent making something look good across however many platforms are that you're dealing with. Or if you're dealing with a web application in general, getting it to work in three or four or five different browsers plus all the different versions. Maybe as you look back, you're going to see some situations where you spent a lot of time, we'll call it finishing in quotes, or really doing those final designs on something only to find out that you didn't need it. So you could have presented something that was essentially functionally there and then moved on to other tasks and actually been saved the work of by the time that you got back around to do that design finalization, you realize that you didn't need it. So this actually becomes another strong argument for the whole 80-20 approach for using the Pareto principle to get enough done and sort of use it as a placeholder where you can say, yes, I have that functionality, it works. There's some cleanup and there's user experience things and stuff like that that may not, and this is not always going to be the case, but they may not be as critical to the solution. So then you can move on to other stuff and hopefully by the time you get to that last 20% that takes so much effort to really clean it up and improve the user experience and all of that, that you have all the pieces in place and you know they're going to be in place so that you know you're not going to have wasted effort. It is a bit of a chicken and egg thing, which comes first with all of these, but I think along with estimation skills and some of the other things that we learn over time, it is very valuable for us, particularly if we're technology people that are working with non-technology people. It is worth it for us to have a good understanding of what matters in a solution and what is, I don't want to say secondary, but what matters primary then what matters after that. Making sure that you get something that works, in quotes, works enough, that minimally viable product again, and then you can work on other stuff. Be an example of understanding that if you're building a parachute, getting a parachute that can be used and saves a person life if they have to be thrown out of an airplane would be primary. You need that first and foremost. Now obviously if it's a parachute that five people out of ten that use it when they hit the ground they break their legs or break a bone or something like that because they do hit pretty hard, okay that's not a good user experience. But if you had the choice of either a parachute that's not quite there that may cause bone breakage and one that would have been a very soft landing but it's not done yet so now you don't have a parachute, you're going to take the broken bone. Or most of us would anyways. And while that's an extreme example, we do run into that. There are definitely situations where projects run out of money or we hit some sort of a wall of where the window of opportunity is and things like that. In looking back at our past successes and victories and celebrating those will not only give us a sense of accomplishment and maybe help raise our spirits, it will also help us in moving forward to see where we can minimize the losses, the failures, the work that was done that ended up not being used. And that all will add up for us to become better developers. We'll be able to do more that matters. And at the end of the day that should be one of our primary goals. If we're going to spend the time doing the work, let's do work that matters as opposed to busy work or stuff that's going to end up getting thrown out. Challenge of the week is exactly what we've talked about. Take a look at what you've done. Put together a little list. Put it on paper, put it electronically because I think writing it down or typing it down will help you a lot. Build a list of what did you accomplish and maybe share it with some people. Maybe make it a challenge and get together with a couple of other people on your team and see who can list the most that the team has done that year. Something like that. And take a look at it and do a little, you know, yay celebration and enjoy it and then see where maybe there's some victories that you can use to lead to further victories in the future. That being said, it's time to get out there and have yourself, especially as we get into the end of the year and holidays and vacations and all kinds of stuff, even more so than normal. 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 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. 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, it'd 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.