Building Better Developers

Summary

Transcript Text

Welcome to Building Better Developers, the Developer 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 because we are building better developers. You on the other end are developers that we are building better ones of you. We are helping you help yourself become better, whether you're actually a developer or not, because there are a lot of developer related things that we found are very useful. Even if you're not by title or trade a developer, technology is everywhere. And there's a lot of these tools and things we discussed that are going to help you do a better job essentially of making technology your friend and finding a way to use it. This episode, we're actually going to talk about one of those things. A little spoiler alert is we're going to get into the world of agile a little bit or agile, depending on which side of the ocean you live on. And that is coming up soon. But first, I need to introduce myself. I am Rob Brodhead. I'm one of the founders of Developineur, also a founder of RB Consulting, where we help you just sort of like this is instead of just building better developers, it's more like building better businesses. We help you leverage technology, take what you've got and take what's out there and find a good mix of that so that you become more efficient at what you're doing through integration, automation, simplification. We find ways to take that sprawl of technology and turn it into something that is a nice, pretty little thing that helps you drive your machine faster, cleaner, better than a regular tune up. On the world in this world of challenges that we have put together, I'm going to throw it because I keep coming back to it. I love the Pomodoro thing doing just a little bit. One thing that Michael has talked about is the struggle of keeping them small and actually doing 25 minutes stop and move on. And one of the things I've played around with a little bit is having like a long and a short Pomodoro. So I've had some where I'll just say, you know what, I'm essentially going to do effectively like two back to back because in a 25 minutes, it actually works really well, goes back to old school, school blocks of where you had basically 50 minutes and then 10 minutes before you went to your next class. And I've tried that a little bit. I want to say that has worked out actually really well. It is sometimes a little bit of a stretch to get that 50 minutes before somebody interrupts me. But when I do, it's actually been very productive. Another one of the things is gone back to the building a brand. I have gone back to that several times, working on the brand, working in my business instead of on my business. And I've found a lot of little tweaks. It's actually sort of a downside because a lot of it is generating a to do list for myself because I'm like, oh, I got to do this, got to do that, got to do this, got to do that. But it is getting me at least back into it and getting me to refresh myself on some of the things that are that are out there. Another one that's on the to do list has been really interesting. And the other one, as I said, as I really struggle because I have daily to do list, but I have sort of expanded that out a little bit because I'm trying to think of that, you know, those two or three things I want to do every day. I'm also instead of doing my daily list is causing me to go back and look at other items that I've got on, like my general backlog of stuff to do and things like that, or just revisit. In some cases, I'll look at things and go, you know what? I haven't thought about this in a while. For example, I had not really looked at my Amazon server allotment of stuff and a little bit of something that got me in there reminded me that I hadn't really reviewed stuff in a while. I started looking in there and I'm probably going to save myself, I don't know, not a lot, not a ton, but at least 10 or 20 bucks a month, maybe more than that on servers. Plus, I actually will have more servers for less money. So there's like some bonuses there because I was looking at, so I was looking at licensing and making sure, like I do for other businesses, making sure that I'm making the best use of the licenses and the technology that I have. So it's a little bit of drinking from your own cup kind of thing or, you know, practicing what you preach. Good things, bad things. Good thing was I took a whole weekend off, basically. I got to hang out, went to a different city, did a whole lot of different stuff, just fun time, fun times, fun times. The bad side of that is I was exhausted by the time I got to the end of the weekend. I was actually looking forward to going back to work this week because I needed a break from having too much fun last weekend. Now, I did not have that with Michael, so he's going to share his story around all of this. Go ahead and introduce yourself. Hey, everyone. My name is Michael Milosz. I'm one of the co-founders and developer. Also, I am the founder of Envision QA, where we help businesses build software, customize and tailor to their needs. If you're struggling with your current software stack or you don't have a software stack, you don't know where to begin, give us a call. We'll help you figure out what it is you need and build a solution that works for you. Good and bad. Let's see. Good. We're getting closer to Christmas. I'm getting back into that holiday mood. Starting to watch the feel-good Christmas Hallmark movies. Kind of putting me back in that good kind of mindset for the holiday. Bad, which will go into kind of our challenges. I was doing really good with the Pomodoro technique and kind of staying on track, small little iterations and following a plan of things to do. Until I worked on building this little server idea I had for a project I'm working on. And what was probably a really decent estimate of about a day's work to build any type of server from scratch when you're definitely building hardware machines, not cloud-based machines. There's always that little intricacies you run into. And this one kind of went from, okay, it's almost there to next thing I know, I'm 24 hours in, just spent 16 hours straight plowing my way through to hit a brick wall that basically we had to pivot. We hit something that just, the solution was not going to work at all for what we wanted. So we had to pivot. Downside was the fact that I spent 16 hours straight literally glued to my machine because it's like every time I turn up, I almost got, look at the clock, that's four hours later. All right. I think I'll get, nope. So bad habit, good habit. Go back to that list. Go back to taking the Pomodoro and say, take, when you do get to your breaks, also take a moment. Maybe if you're on multiple Pomodoros of the same issue, set a goal or a check, kind of a sanity check after four of these, should I continue or do I need to pivot? So that's kind of where I'm at for our challenges. Beyond that, everything else is going good. Typically I'm following the Pomodoro really well. I've actually been really cranking it with automating things. So I'm keeping track of what I'm doing because I'm building servers and we typically have to replicate. So everything I have I'm taking, and I'm just converting it to a script so I can run on the next machine. Or now that I'm back in the cloud-based world, we'll just take snapshots as we go and be able to spin things up quickly. So keeping that in mind, that'll save my sanity, hopefully going forward. And it will save yours if you keep track of what you do and see if you can automate it. Now this actually leads us into the word, using that word pivot leads us into the world of agile, which is one of the things that is a strength of the agile approach. Now, the interesting thing about this and why I felt like this was a good building better developers, building better habits kind of thing is one, I think a lot of people don't know what agile really means is that they have all of these like, they say it's pair programming or it's sprints or something like that. And agile is actually meta to that or predates that to some extent. I guess it doesn't even predate it. It got merged somewhere and they are a little bit different. However, this does touch on things like the, which is part of the challenge, we're going to touch on things that are really more in the scrum world and some of the ceremonies and things like that that go on because we're going to talk about building better habits. Now I want to start with reiterating there's four main things, more four main values that are what the agile manifesto puts together. And if you ever want to look at it, agile manifesto.org it's out there, it's been there forever. It's very easy to read. And it's very actually insightful as a developer. It's one of those things like we've talked about the four hour work week and some other things out there that we revisit on a regular basis. And I think the agile manifesto is one as a developer, you should because it's going to help you, I think often be a check of like, am I doing this? One of those kinds of things. Am I doing this? Am I doing it right? Now the four values are, they said that, you know, they've sort of the preamble is, hey, we're a bunch of developers. We've built a lot of systems and this is what we've learned. And these are the four individuals and interactions over processes and tools. As far as these are the things that we have come to value. So individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Now that last one is a perfect example of what Michael just ran into is that there's sometimes, particularly when we get into the software development world, if you're in the waterfall world, sometimes you're sort of stuck. It's like, you've got to plow through, you've got to get this thing done because there are downstream issues that you have to worry about because you built in the requirements. It's there. Everybody's counting on it. All of that kind of stuff in this agile world. There are some things that, yes, there are requirements that are sort of, they're loosely required, you know, tied to this thing. So he can look at it and he can say, you know what, this is taking more time than we needed to. It's more complicated than we needed to. It's not what we need or whatever it is. And he can change. And that's exactly what agile is about is it's not necessarily about, hey, we've got this plan. We've got to execute. We've got to do all this stuff. We can change on a regular basis. We are, you know, it's, I used it several times when we talked, when we were going through some of the lectures about it. It's a difference between laying out a yardstick versus having, like, let's say little six inch rulers and using that to get to your point because the yardstick, once you lay it down, you're going from point A to point B. That's it. Your path is covered. But if you've got these little six inches, you know, six inch rulers that you're doing along the way, you're like, Hey, I'm going to go here for a while. Oh, maybe I'm going to go here. Oh, I'm going to go here. You may go off in a completely different direction than you originally planned on it because the world is ever changing. As they say, there's always things that come up. Your customers may change your focus. The budget for a project may disappear. The goal, the scope of a project could change dramatically. And I've seen that on numerous projects. And that's why you do sprints is you, you sort of go in, you plan somewhat. I mean, you're planning like a sprint or two or three or four ahead, maybe. But generally speaking, you know, you're still saying, staying loose and flexible and how you approach things. And I want to put that in. And I think that actually fits with sort of the daily, for example, the daily to-do list that we talk about is that, yes, we've talked about having like your career roadmap, which is obviously going to span many, many, many years, going to spend decades versus we talk about annual goals and quarterly goals and monthly goals and things like that. But when you get down to that daily, that does allow you on a given day to pivot. It is in a sense, it's an agile way to look at things. And we'll talk about that a little bit more as we get into the habit side of this and the challenge side of it. But now I want to sort of throw this over to Michael and get some of your feedback and your thoughts along this and where you want to go in the, this agile discussion because we're agile like that. Yeah, it's funny. Like your yardstick versus rulers. It's a really good analogy. And when you were saying that what popped into my head initially was not necessarily software, but the bridge collapse in Baltimore. So you had a direct path from A to B. Well, if something fails and it collapses, what do you do? You know, you can't really pivot because you have this one path. But if you have multiple paths to get to somewhere, if one's blocked, you can go somewhere else to get there. So that was just a funny analogy because we watched so much of that collapse when that happened. And that sticks with me a lot, especially with the agile process, because even though like I ran into that situation where I was stuck for hours, it was one of those though, where at the end of the day, it wasn't a critical failure. We could pivot, we could move on, we could do something else to still keep the ball moving. You know, as we work with ceremonies and try to work to our daily routines, especially with teams, everyone kind of has a different process or different ceremonies as to how they work with agile. And you and I have talked about this many different times because we kind of have different approaches to this. And it's kind of funny because at the end of the day, we're still trying to do the same thing, but you're fighting, like especially corporate, you're fighting that too many meetings mindset sometimes where it's like, do we really need a meeting to talk about in the agile sense? Yes, because the ceremonies are designed in such a way that we keep that ball moving, we keep the process moving. If anyone's got any blockers, we work through those issues and we can pivot, we can move forward. And then you get away from that kind of waterfall approach that Rob mentioned where you have to plan everything out first. And then, you know, this is our path. We can't deviate. We have to get there. But life changes, you know, it's like, I don't know if anyone's still on Windows 10, you're probably getting pop-ups constantly telling you that, Hey, Windows 10 isn't going to be supported anymore. You need to upgrade. Well, oh, your machine isn't supported. Now you need to go buy a new machine. These are things that can help be planned for and avoided with like agile. You just plan things out, but you plan them out in a way that puts working over, you know, kind of like you said, like planning out all the documentation first, you kind of get a idea of what it is and you start writing it, start building it out. Although there's times I'll push back on that. Like if we're starting a project, sometimes you do have to do a little bit of waterfall, but you're going to have to get enough information from a customer sometimes to figure out what they want. Now, granted, sometimes their ideas change and you'll pivot a lot on that. That's where agile comes in. But sometimes certain things do require a little more planning upfront. So it's a little more waterfall ish in the requirements phase. But once you get to the development and the start putting things together, that's where agile comes in. That's where you start really using that ruler versus the yardstick approach to get things from point A to point B faster. And I guess what I was kind of curious because you mentioned the customers versus contract kind of the third value that you mentioned there. What are some examples of that? Because I have not really touched upon that too much with the agile experiences that I've worked with. So that is one that I think is, it tends to be more of, I guess, in a, as a development manager or things like that. But really the customer collaboration over contract negotiation is for lack of better terms, it's nickel and diming on either side of it. So what happens is, is that we can get into situations and it's really, if you've been in a larger organization or if you are in a larger organization where there are things like change requests and things like that, they go on. And even if you're in a small organization or if you've got a side hustle or something like that, there is in any given contract, there is going to be potential for change requests somewhere along the way. There's a scope change or something along those lines. Now the thing is, and this actually gets into the whole idea of like fixed bid projects versus hourly and some things like that that are a whole different soapbox that I can get on and lecture about and wax poetic about. But it really comes down to working with your customer to give them, to get to a win-win situation. It is working with them to give them something that is valuable to them as opposed to getting into a fight over a dollar or a dollar amount even. Because it's the kind of stuff where it's like, yes, you want this thing that's going to cost $10,000. And instead of getting into them saying, well, we could probably afford $9,000. And you're like, no, how about 95? Instead of getting into the contract negotiation and spending all of that time trying to agree on what you're building, you could spend that time building the thing. A good example is I dealt with somebody that was not, there was like a slow pay situation going on and they're like, well, I'm just not going to, you know, I'm not going to work for the customer because they're not paying. So I'm not going to do the work. And it's like, well, all you're doing is just pushing, kicking stuff down the road. You're actually hurting yourself as well as them, because now you're not doing the work. And so now you're going to have to come back. You're going to have to ramp back up. And now the customer is not going to be happy because they're not getting what was promised. And so, you know, instead of addressing the problem in that case, they ended up saying, well, I'm just going to pull back. And it's, it's a negotiation strategy, but it's, I mean, maybe not a good one. You might agree or disagree with that. But instead of going to the customer and saying, look, you know, you're not paying on time. I'm delivering on time. We need to work on that. And then figuring that out. And instead of, you know, beating them over the head, like a good example, a lot of times in that case is like, if you don't pay me by this day, then we're, we're going to stop work completely, or we're going to shut down all the servers or whatever it happens to be. And instead of getting into these like, you know, us versus them mentality, the customer collaboration is when you're like, look, we're all working to get this thing done. And if you're not, if you come into a project and you're doing it for the money, you're just doing it. Cause like, I see dollar signs and I just want to get paid. Then don't do it. You're not ever, you will never be a better developer. If you do that, I guarantee you because you're not doing it to be a developer, doing it to the, you know, to earn some money. If you want to do that, that's fine. But, you know, listen to us, keep listening to us because maybe you'll sometimes see the light, but don't think that that is ever going to make you a better developer. It's going to make you maybe a better negotiator or salesman or something like that. But it's not about development at that point. The contract negotiation is all sales and that kind of stuff. Customer collaboration is where you're sitting there with them and saying, Hey, you have a problem. We want to solve it. And there's always a budget. There's always a reality there. There's like, there's a certain level of how well you can solve that problem. And so it's working with them to figure out, okay, maybe we can't, we can't solve it a hundred percent, but maybe we can get you 80% there. Or maybe we can't give you the core solution that you think you want, but you're going to find out that the Kia, no offense to either of these cars or manufacturers or anything like it, but maybe like you just need the Kia solution because you don't need the, all that other crap. And there's a lot of that. This goes back to again, something I can preach on for days because people will end up buying software and spending money on stuff they really don't need. They don't, they never use it. And so they have all these features and all these things that they're not using. Why spend extra money to get there? Why get stuck into contract negotiations and wasting time over things that you really aren't going to use anyways. And this goes to, this is on both sides of it. It is as a developer working with the customer and as a customer, hopefully working with the developers to realize that you guys are on the same page and, or you guys have the same goals. You have the same desires. We should all want, if you're being a better, if you're here, you're building better developers. You do, you want to build software that people use. And so it's not as much about the bucks that are involved. And I think most of us would take a successful project at 10% less of what we could have earned as opposed to a failure of a project where we earned an extra 20% bonus somewhere along the way. That's those. And I'm very happy that you asked that because I do think that's one that as developers, we don't think about it in those terms as often because we'll get in and argue with our boss or the other teammates or things like that about, well, this has to be this color. That has to, we have to use this standard or we have to use this, you know, this data value or whatever it is, we have all these little nitpicky things. So while this is talking about it at a customer level, I think we often get lost in the details as well. And it's like everybody's argument is fine. You're better off just picking one and moving forward than you are spending time arguing. So one, did that answer your questions and then thoughts on that? Yeah, that answered my question, but it gave me a follow-up question for you. So not to detract too much from the agile conversation, but within that contract negotiation or kind of working with the customer, kind of like arbitration, things like that to keep things moving forward, because we always do want to provide better services to make things better. At the end of the day, we want to provide them something that is better than what they have, even if it's just cleaner code. But within the contract negotiations, not necessarily as you're going on about pay, but at the beginning. So as you're in that research phase, that deep dive into the requirements and flushing out what they need, how do you avoid getting into the trap of what they have versus what they need to kind of get that happy medium within the conversations? You know, kind of for a odd comparison is where, oh, I want this button up here and I want it to be purple. It doesn't matter. You just need a button that works. How, what is your suggestion to our listeners and viewers to kind of avoid that early on, not necessarily later, but at the beginning so that you kind of can still provide the benefit, but maybe not at a higher cost that you wouldn't initially want. This really does come down to, it really, it's, I think you win and lose this actually at the beginning of a project, at the initial phases, because what you, what you want to do with now, if it's a customer you've worked with, it's different, but somewhere along the way, there is an initial, the start to the relationship. And if while you're building up that in that initial phase of building that relationship and figuring out how you're going to interact with the customer, if you build trust and help them understand that there are things that they need to bring to the table and there are things that you bring to the table and for them to trust you where you're in your lane and you trust them when they're in their lane, then I think it does help those things. So for example, let's say you're going along and they're saying, there's, there's a couple of ways to approach that, where you, you show them something. Let's say you're, you've got some mock-ups for this solution that you're going to build for them and they're, you're in the negotiation phase, essentially. They're trying to figure out what do they want, what don't they want. And this is a good example, because at this point, what they want and what they don't want should not come down to a purple button. It's, there's certain functionality they need. There's a problem they need solved. So this goes back to our favorite, what is the why? Why are they actually doing this? And so if they bring up something like that and say, Hey, this needs to have a purple button there. Now you could say, now you could say, you fool, you are not paying attention to what you need to be paying attention to. That will probably not win you a contract or nice guy of the year award or gal of the year award or anything else like that. But what you can do is, which a lot of times you can start with the positive approach where you just say, okay, what is the, a lot of times, and this is a great one. What is the business reason for that? What is the business logic behind that? Why does that need to be purple? Why does it need to be there? Cause there could be a legitimate reason. There could be something where they're like, we've got a person that is colorblind and can only see purple or something like that. Or, or if, you know, it could be something weird, like the sun shines at that spot at a certain time of the day. And if it's not purple, then we can't just random stuff. But if you don't know their business and you don't like they do, then they may be able to bring you something. But I think it's, it's often frame that as a, what is the, what is the business reasoning behind that? Because if it's just, they say, and sometimes they'll say, well, there is no reason. I just like the color purple and I want a button there. Then you can go to, well, what is the benefit to you of that being purple and being there versus it being pink and over on the other side of the screen or something like that. And if they ask, you know, if they just say, well, I'm the customer and I want to do it. Then you say, well, I understand that, but I'm trying to be a good consultant or I'm trying to be a good vendor for this solution. And when you, maybe that you say that, that actually adds a cost potentially. It adds a cost or it's something else we have to check, or it's something that's going to be, makes this more complicated than it needs to be. And so we just want to ensure that you really are stepping into this knowing that you are adding a complexity to this solution. And we don't, I don't, you know, I don't have to see why. I just want to make sure that you understand that you've done it. So whatever your reasoning is, if you don't want to explain it, that's fine. But if you do explain it to me, then maybe I can help you with alternate solutions or help design this better in other areas, because I'll find out for example, that you love purple buttons. Okay, cool. I'm going to make buttons purple wherever I want you to click on them. And I'm going to make them green because you hate green wherever I don't want you to click on buttons or something like that. I mean, there's, there are things that we can do based on even the most, for lack of a better term, irrational likes and dislikes of a customer is we can use that and we can leverage that and make a custom solution for them. And so this goes back to, this is a customer collaboration instead of you don't need that or something that is very much like now you've got a brick wall and you guys are having to argue you're you're on the opposite side of the customer, you're coming alongside them and you put your arm around me like, that's a pretty cool button. What is the value of having it there or something along those lines? And so now you're working on the collaboration side and you're you're working to build their trust and help understand that you want them to you want them to be happy. You want them to be satisfied with what comes out, but you also are guarding their core idea of there's a problem to be solved, and they're spending money. And so we want to make sure that you are spending money wisely as much as we can. Does that make sense? Does that answer your question as well? Yeah, you actually answered it in a very agile way. I love that. It was a great solution. And I really liked how you turn it around to how is that you know, what is the value of this to you? Yes, I don't need to fully understand it, but you just need to understand the cost. That was huge. Or to me, that's one of the big takeaways from that along with the collaboration, because we do want to be there to provide a solution that the customer wants, but in a reasonable and cost effective way. Now, if they want to pay for it, and that's absolutely what they want, you put it in there, you just do have to make sure that you communicate the cost and complexity to the customer, because they don't understand software, or in most cases, your customer is not a developer. So when we do talk to them, it can't be in tech speak, it has to be in common language that they can understand. And that also isn't talking down to them so that when you are communicating, it makes sense to both parties. And you can, for like a better sense collaborate on the solution versus hammer and nail. And that is really where agile comes in is that you, you know, part of that too, is we don't have to make the decision on that button right now, if we're in the beginning of a project, we don't have to make that decision. We can, you can basically just say, we're going to leave, fine, cool, we'll leave it there, no problems. And then you can always come back later down the road, and then fight that battle if it even needs to be fought. And maybe that screen never exists, and maybe that button never exists, and maybe that customer gets fired and somebody else gets hired. I mean, there's all kinds of different things that could go on that will change it. And so that's where the agile side is, is like, we don't have to nail, we don't have to die on a hill at the beginning of a project, we can say sure, and we can go with the flow until we need until we're further, far enough along. And then we've got something that is much more concrete to fight over as opposed to some sort of just like, you know, vague ideas that we have of how this thing will look. Now, the challenge side of this, because I think you're, you know, a lot of you are like, wow, this is about, you know, big things and stuff like that. The challenge I have for you is, does go back to the daily tasks kind of thing, is I want you to, at the beginning of a week, take a look at, you know, build a few tasks up. So essentially, like tomorrow, what are you going to do in the next seven days? What are you going to accomplish in the next seven days? And I want you each day to, and you can pick, you know, one big goal or two or three big goals or something like that, but in each day, you're going to make progress towards these things. So not something you can get done in one day. Let's think of something a little bit bigger that you want to do. It may be one of the other challenges we are. And then put that on a list. And actually, what I'd like you to do is start with, I'm going to do this at, you know, a certain time, certain window block every day, and see how many days you can do that. Is it more difficult to figure out that time and schedule that thing out and do it at the same time every day, or is it easier for you to adjust when you do it? And now this is hopefully going to get you into that mindset of things that I think for developers, we often are like, this is what I feel. This is what I thought. This is how I have to go. Instead, this is going to help us break that habit or that mindset and realize that, hey, it doesn't have to actually flow the way we originally did it. It can go in a different direction. It can evolve. It can change because that's where you're going to become a better developer and have some really good habits about getting used to being agile, changing, being more light on your feet in a professional sense. That being said, you are not allowed to be agile at all. You need to go directly to your email and send us something at info at developandure.com. Let us know how things are going. What do you like? What don't you like? Let us know how your challenges are going. That is actually very interesting to us, and especially if there's any insights or habits or anything like that that you are building, that you're finding that this is something that particularly if it's something that we've helped you build this habit because of the challenge when maybe you were challenged by it before. For example, the Pomodoro thing and some of the things that we've learned as we've gone through these challenges as well. You can also leave us comments wherever you're seeing this, whether it's out on YouTube, on the Develop and Nour channel. You can go wherever you're at, get your podcast. There's a way to leave feedback and all that kind of good stuff. We really rank us however you want to, but give us a five or one or whatever the review is, but it's really more about the content we want to hear from you. Also, we've got a form out on developandure.com, so you can get us there. They're at developandure on X if you want to send something out that way or if you just want to follow us. That being said, we have got to follow ourselves onto the next episode. 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, the Develop and Nour 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.