The value of meetings for developers

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. Well, hello and welcome back. We're continuing our season where we're looking at the bright side of things. We're trying to find out if that glass is half full or half empty, and we're going to assume it's half full. We're taking these annoying things that we've done, that we've dealt with, possibly on a daily basis, and look at how they help us become better developers, how they help us sometimes even get through the drudgery of work, even when it's the drudgery itself. This episode, we're going to look at one of those things that I think developers really... If there's a broad brush statement I can make, this is one of those that developers really don't like, and that is meetings. Now, of course, from a developer point of view, a coder, a developer, our scale of productivity what we get done, completing a task, which usually is at the end is basically writing code that works, that tests out and that does what it needs to do. Now, the thing about meetings is that you can't write code. You can, you shouldn't. It's possibly dispersefectful, maybe just a waste of time being in a meeting because you're not going to be mentally focused on what's going on. But for the most part during a meeting, you can't write code. So that thing that we possibly erroneously too often count as our measure of productivity is something that we don't have access to while we're sitting in that meeting. Now, I think the first thing we need to think about, and this is going to lead us to the positives, is that meetings are not necessarily unproductive. They do not necessarily keep us from achieving a goal. And this goes to that whole trope basically that coders, developers are only productive when they're writing code. That's false. I think we've discussed it enough that probably most of you agree at this point and realize the point of view we have is that there are a lot of other things that go on. For example, design. You have to, it helps you immensely to think through what you're doing before you do it. That takes us back to the old adage of measure twice, cut once. While we don't have to, we don't have quite the same cost of the quote there, cut once when we're writing code, we can always change it. We can always rewrite code. That's not as destructive as cutting something, but it's the same concept. We should think about it, walk through it, and it's going to reduce whatever the code is we're writing. That's most likely going to reduce the number of rewrites, the initial bugs, logic flaws, particularly those that maybe don't show up until later. So there's value here. And that is the first positive I want to point to in these meetings. Now this is not all meetings, but particularly the meetings that are related to planning and design for our work. These are critical actually in us being successful, we'll say. You can be productive, you can crank out code, but your overall productivity is going to drop if you're not cranking out good code. If you're building something and you're doing it in a flawed manner, either the logic's off or the design's not correct, there may be gaps in the design. Those kinds of issues can be very costly. And while we may get a product done, to do so successfully is going to be, the odds drop dramatically when you don't spend that time upfront thinking through what it is that you're working on, the problem you're solving, and the, we'll call them nuances, as well as the happy path of your solution. And this is something we've revisited this multiple times, actually with regard to testing in particular, that we have a vision, a direct path from problem to solution, I think a lot that we have in our head, and that's what we more or less code to. Now there may be some variations and some exceptions that we take into account depending on how much design, but there's definitely a narrow road that we, I think, tend to mentally have to go from the problem to the solution that we're creating. And when people get off that path, then that can cause problems. The more time we slow down and think through the problem, the solution, and really the journey from point A to point B, the more likely we are to catch all of those exceptions and outliers, and sometimes it's outright bugs, some of the flaws in our logic. It's easy to have like an almost equivalent of a knee-jerk reaction solution for something. A classic phrase I've heard way too many times from developers will be something like along the lines of, oh, that's simple or that's easy. Well a lot of times it's not. A lot of times we look at it, we initially say, oh yeah, that'll be easy. And then as we get further into it, we realize that there's some things we didn't consider. I think this is part of the almost now I guess infamous inability of developers to estimate the amount of time required to get something done, which is actually one of the nice things about some of the sprint point scoring methods that they're really not based on hours. It's more effort, and then over time we hopefully can figure out what that effort likely relates to as far as hours and being able to schedule things. So these meetings are not, while they do stop us from our, I guess our core competency of writing code, a lot of times they're actually going to help us write code better. So it's proper planning and maybe tuning our mental facilities in a way so that we are going to be most effective when we do sit down and write code. Think about running a race. You can run a race right now. We could all sit down, I guess, but we could all go somewhere on a track and we could run a mile race. Some of us would run very good. Some of us would maybe not even be able to make the mile. But if you spend some time beforehand doing some exercises and getting yourself a little bit in shape, your time spent during that race is going to be better spent. You're going to do better. It's going to be more productive. It's going to be a better result. That's what meetings, these planning meetings in particular, can do for us. Now I recognize that not all meetings are created the same, but, you know, slight sidetrack here, but I do want to say that if you're in meetings a lot that are planning meetings, they are listed as described as planning meetings, and you come out of those without feeling like any planning got done, then you need to give that feedback to whoever's running the meeting. Or if you're running the meeting, you need to talk to the people involved and figure out how to make it productive, how to get to the goal of planning. And I'm not going to go any further onto this sidetrack of properly running meetings. So we'll leave it there for now. So first thing about meetings that is a positive is that they give us the ability to be more effective in the other areas of our day. A stand up in Scrum is maybe a good example because that's really sort of the, I think that's the main thrust of it, is to be able to start the day with a plan and understanding the plans of others so that you can maybe be more productive and even avoid conflicts and showstoppers, you know, blocking issues during that day. So that's first one. The second thing about meetings is that this is another area, like a couple other things we've talked about, where it is a, it's a change. It is a different mental activity for us, which can be refreshing or recharging in and of itself. Much like some things we've talked about before, when you get stuck on a problem, when you have something that's really challenging you, where you find yourself more or less mentally banging your head against the wall, you know, it's a good time. We've mentioned several times that it's good to just take a step away. Sometimes we get too caught up, wound up in trying to solve a problem that we can't really see straight anymore. So when we step away, sometimes that allows us to mentally extract ourselves in a way that we can actually move forward. We can make progress on solving that problem again. The meetings are an opportunity for this as well, much like, you know, just like going for a walk or anything like that and grunt work that we've talked about in a past episode. Since a meeting is a different use of your mind usually, even going from coding to design meeting, it's different. And so sometimes that alone will be helpful in allowing you to like progress on that problem you're trying to solve. Or maybe, as I said, a little bit refreshing. It's not as maybe as mentally tedious and exhausting to sit in a meeting as it is to write code. And even if you're one of the primary actors in the design meeting, it's still different. At least I've found it that way. When I'm sitting there coding, I have a very, I will say singular kind of focus on that thing, whatever it is that I'm coding on. When I get into design meetings, then yes, I may be focused on what it is I'm designing, but there's also that discussion part, that give and take, where I'm allowing other people to provide some input. And so now instead of me just having to do all of the, take all of the steps and going through a thought process, it's a team effort. And so it does take sort of the burden off of me or off of all of the individual members. And it's refreshing in the way that we're now more, we're going to be exposed to the thoughts and the ideas of others. And it allows us to maybe see something from a different perspective, maybe get our mind thinking a little different from its normal course. And that sort of leads us into the third part, the third positive of meetings is that it is, it's a discussion. It is an opportunity for us to communicate and have communicated to us different ways of thought, different approaches to a problem, different views, different perspectives, which sometimes in itself can be incredibly like epiphany level rewarding. Because sometimes you just sit there and you think through something and you're banging your head and banging your head and banging your head. And then somebody comes up with something that's maybe not completely outside of the box, but just for some reason, something you didn't think about. A great example, which I think I've used this before, I'm sure I've mentioned it somewhere along the way, was a situation where we were trying to, basically I was tasked to handle paging on results that were literally millions of records. We were trying to get these millions of records returned to an interface, to a user interface, that in a way that didn't cause the user to sit there for 10 or 15 minutes or an hour. I can't remember what the timeframe was. It was definitely not fast response. And we went around and around and as we got for initially it was just, okay, but then as in, okay, okay, we'll try to figure this out. But then as we had meetings and we started to have discussions about it, there was the concept itself, the premise became part of the discussion. Because as we thought about it, think about it, a million records do not need to be displayed to a person. No human is going to go through, whether you page it or infinite scroll it or whatever you want, they're not going to sit there and go through a million records. We don't have the mental capacity to do so or the time. If you're going to do something like that, it would take you literally, I'm assuming weeks. Even if you're just quickly, in any meaningful fashion, I mean, I guess you could like scroll through them very quickly, but they're not going to get any information from that. So our conversations, our meetings led to questioning the premise and eventually getting back to redefining the problem. Because it turned out the problem was we needed all those rows because we needed to have at the bottom of the page a count of how many rows were returned because the users, that's all they cared about was the count. They actually didn't care about any of the real details at that point. They just wanted the count of records in the table, which is a completely different report, which is a completely different interface. And so that meeting that could have, if we hadn't had those meetings, if we hadn't gone down that road, we could have spent days, weeks, I don't know, months trying to tackle that problem. And instead we were able to, you know, we did waste some time. I think we wasted a couple of weeks on it, but we were able to get to a solution faster and actually a proper solution, a better solution than was initially proposed by having those meetings by spending that time away from trying to code a solution and instead talk about the problem and the solution. So those are actually three pretty weighty values, positives that can come out of meetings. They're not all bad. I think badly run, you know, poorly run or badly run meetings can be very devastating, very damaging. They can cost a lot of time. They can get people frustrated, which means it's not just the time spent in the meeting. It's the time spent afterwards complaining about the meeting that you just had and things like it can reduce morale, which I guess I will throw that in as one more positive. Sometimes meetings can actually improve morale. You think about the epitome of a quick meeting is the team meeting between, you know, in a sports event like you go to like basketball or football or one of these where they've got their breaks between periods, you know, between quarters, halves, whatever, where you have some of these great speeches that coaches have given. That was during a meeting and that was to fire up the team to help them change direction. So meetings can be used from a purely psychological, emotional kind of perspective, can be very valuable. Again, this is you're going to get out what you put into it. So if you go into that meeting not paying attention, not wanting to listen in a bad mood anyways, not wanting to be cheered up or whatever it is, then yeah, it can be lost on. So the moral of this story is, which maybe is this whole season, if you go in with a negative attitude, you're more likely to have a negative result. If you go in with a positive attitude, you're more likely to have a positive result. And that takes us to the challenge of the day, challenge of the week, whatever it happens to be. When you sit down for a meeting, what is your thought process? Do you go into meetings looking at the agenda or having an agenda even if one isn't proposed or sent out beforehand? Having a set of goals from a meeting or do you go into a meeting just trying to figure out how you can continue to be productive during that meeting time? Or those are sort of, I guess, more or less extremes. So you may fall somewhere in between. And this is really for yourself. What is your mental state, your attitude, your approach to meetings, maybe in general, and then maybe there's specific daily standups or weekly status or things like that, demo meetings or things that you have on a regular basis that maybe you have a slightly different mental attitude towards them. And then as part of this challenge, is that, assess yourself, is that attitude, is that approach something that is going to take advantage of a well-run meeting or maybe even help a poorly run meeting get on track? Or is it something that could totally derail a poorly run meeting or totally make it a waste of your time where you could have done the same stuff, maybe more effectively somewhere else? Because maybe, I hate to be judgmental, but maybe it's a time for an attitude change. Maybe your approach, maybe your attitude, adjusting that will help you find that meetings are not the greatest evil man's ever created. And that being said, on such a happy note, we will want to flip the script here a little bit and walk out a little happier. So please 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 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. If you've gotten some value out of this and you'd like to help us 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.