I want you to take a moment while you're listening to this episode. Do me a favor and open your calendar. I want you to look across the last week, maybe the last two weeks and look at the different meetings that you had. Look at each meeting and try to identify what happened during that meeting, what came from that meeting. How did things change in your work or in your relationships? Did you learn something in that meeting that you didn't know before? Did you become closer to someone who you were meeting with? These are the kinds of questions that we should be asking ourselves. And that's what we're talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea. I create the show to help driven developers like you find clarity, perspective, and purpose in your career. We're going to take a break from talking about meetings to talk about software engineering. This is the thing that the meeting support. We should be able to spend the majority of our time as engineers actually engineering. We've talked about test driven development on the show before. If you're not familiar with test driven development, then you probably will become familiar if you spend much time in the industry. The purest form of test driven development is to write some kind of specification that describes how your code should react. There's a variety of test types, but generally speaking, you're looking for some kind of output when you run a particular piece of code. You write the spec, the specification, you run it, and it should fail initially. Then you take some time to write the code necessary to get the test to pass. Once it passes, then you probably want to go back and refactor that code. You'll also probably want to write a few more specifications around the same piece of code to make sure that you're covering edge cases and, for example, erroneous inputs. Once you've refactored using the same process where you're running the tests after every small change to that code, then you can move on to the next test. You'll write a test. It fails. You write the code to make it pass, and the cycle continues. What exactly is the point of test driven development? Why can't we start by writing the code and then write the tests that describe what the code does? In the end, you may end up with very similar outputs. You may end up with a very similar test and very similar code. You might end up with different code and different tests, but ultimately, the output, the features that you end up building are probably going to be similar. What test driven development forces us to do is think about the outcome first. By creating a scoped specific example of what we need as an output, we can then focus on a very narrow piece of the code. This keeps our work highly efficient, but it also protects us against regressions in the future. If we change a piece of code in another part of the code base that causes an error in an unexpected area of the code base, if we have pretty good test coverage, we might catch that error. Now, this episode isn't about test driven development. It's about taking this model of thinking and applying it to our meetings. How can we have more effective meetings? When you looked back at your calendar at the beginning of this episode, did you see meetings that you felt were highly effective? Did you see meetings that maybe you don't remember at all what happened in that meeting? Maybe you have no idea about how to find out what happened in that meeting. We're going to talk about a way to remedy this problem in today's episode. But first, I want to talk about today's sponsor, GitPrime. GitPrime has written a book for you as a developer to identify bad patterns in your team and identify good patterns in your team. This book is 100% free. You can head over to GitPrime.com slash 20 patterns that get git. 2.0 patterns to check it out. I'll give you one of the example patterns. One of the example patterns is the busy body. Someone is on your team that is jumping all over the place in the code. They'll fix a problem on the front end. Then maybe they'll fix a problem with a back end API. Maybe they'll fix a bug in the deployment strategy. Then they jump to improving an internal tool. The interesting thing about the busy body is that they have a lot of knowledge, but unfortunately they aren't building a lot of specialization. Wildlist person's work may be very valuable to the team. This can be really frustrating for an engineer because they never feel a sense of ownership or a sense of expertise. If you want to find out what to do about the busy body and learn about 19 other patterns, go over to gitprime.com slash 20 patterns. That's 20 patterns. Thank you again to GitPrime for sponsoring today's episode of Developer Tea. If you looked at your calendar at the beginning of this episode or if you can remember the meetings that you had this past week and maybe you're looking forward into the meetings for the upcoming week, if you're like most people and if your team works like most teams, those meetings, while they may have an agenda or a assumed output, you probably don't have an explicit output. You probably don't have an explicit way of identifying the purpose of that meeting. You're probably doing that meeting and you may actually appreciate those meetings. They're maybe good that's coming from it, but because you're not really certain about it, you probably have the sense at the end of many of your meetings that it was a waste of time or perhaps you could have done it more efficiently. So how can we solve this problem of having good reasons to have meetings, but not really knowing what those reasons are? Well, let's take this model of test-driven development where we write out a specification and apply it to meetings. Let's think for a moment about something like a unit test. A unit test looks at a class instance and a test of method. If you're unit testing a function, then you're looking at for a given set of inputs, what are the set of outputs for that function? Another type of test is an integration test. With an integration test, you're looking at a process, a series of events, maybe an action taken by a user. For example, you may be testing a route that's getting hit, and then you're looking at all of the things that you want to happen. Because there are side effects that are happening that you can't necessarily represent in a unit test. The integration test is saying, let's figure out what's going on when all of these things come together when they are integrated. So we can apply these same concepts to our meetings. With unit tests, you're looking at specific functions inside of a meeting. For example, let's talk about a one-on-one meeting. One of the functions that you may have inside of a one-on-one meeting is a feedback round. This is a chance for your manager to provide feedback to you and perhaps for you to provide feedback to your manager. What is the functional output of this particular ceremony? The output from feedback could be a couple of things. One, if it's positive feedback, this is an encouraging moment, then the output may actually be something a little bit softer, like you feeling positive about the work that you did. Perhaps the output for negative feedback is some kind of change, some commitment to a particular action to improve in that particular area. Ultimately, if you look at the feedback process as some kind of functional output, then you can shape that feedback process to more efficiently produce that kind of output. We don't want to think about our meetings as simply the outputs of these individual ceremonies like a feedback session. We want to look at them from an integration approach. While it's important to have these individual ceremonies providing the right kinds of output, it's also important to think about all of the side effects of our meetings. Before we get too far into this discussion, I do want to point out that it may sound like this kind of evaluation of a meeting where you turn it into some kind of procedure with specific outputs and side effects that it sounds cold from the outside looking in. But in fact, by taking the time to engineer your meetings so that they have the proper types of side effects and the proper types of output, you're actually doing the opposite. You're actually working on behalf of the human side. It's easy to believe that we're just going to get what we need out of meetings. It's totally acceptable, by the way, to establish that one of the side effects that you care about is closeness, camaraderie, confidence, appreciation, celebration. These are the kinds of things that bring a team together at a personal level. You aren't trying to make meetings more efficient by cutting out all of those softer side effects. In fact, instead, we want to protect those kinds of side effects. We care about them. But if we expect them to just happen without intentionality, then we're probably going to be disappointed on, unfortunately, a regular basis with our meetings. How do you actually go about practicing this? How do you create a test-driven meeting structure? I'm going to encourage you to do two things. You can do this whether you're an individual contributor, a manager, or any other role. Here's what I want you to do. I want you to set alarms on all of those meetings, a five or ten minute alarm, to take a moment before the meeting and write down the outputs and the side effects that you desire from that meeting. The outputs may be something like a set of notes from the meeting. Another example of this may actually be code. You are doing a pair of coding session and the output should be some set of code. Secondly, I want you to write down those side effects. The side effects are going to be things like different types of feelings that you may have coming out of that meeting. You would like for people to feel confident or in the know. The interesting thing is that you can compare these outcomes, these side effects, and the outputs, you can compare them and make sure that they agree. For example, if you want people to be in the know, then perhaps one of your outputs should include notes that they can refer to so that in the future, the information that you wanted them to know, well, they have a reference for it. Here's what I would encourage. I would encourage you that while you're going through this exercise of identifying the side effects as well as the main output that you keep it simple, don't try to go for too many side effects, don't try to go for too many feelings or too many outputs especially because a given meeting, if you have too many focuses, then you're not going to be able to actually accomplish all of those. Instead, keep them simple. Keep them to one or two for each category and zero is okay. If you have no actual outputs, if it's purely for the side effects, that's totally okay as well. Now, the important thing is that you're explicit about this and that you identify this out loud to the group at the beginning of the meeting so that everyone has a common goal, a common outcome that they care about. Here's an important caveat. You don't want to use this tool as a weapon against people. When the meeting goes off course, you don't want to use this as a way of silencing other people. Instead, use this as a way to reflect on the meeting. Once the meeting is complete, reflect back and decide, did you actually have the right outcomes in mind? Did you actually have the right side effects in mind? And if so, did you get those things? Were you able to actually output the things that you cared about, outputting from the meeting? If not, how could you change the meeting to be more effective? This should all be a process of collaboration with the people who are participating in the meeting with you. Ultimately, the entire point of this kind of change in thinking about meetings is to go from using meetings as a goal and instead view them as a process. All processes have some kind of goal attached to them, but they are not in and of themselves a goal. We shouldn't despise meetings because of their lack of effectiveness. And we also shouldn't perpetuate the illusion that simply completing a meeting is productive. Instead, we should use them for what they are, processes to produce some kind of side effect and some kind of output. Thanks so much for listening to today's episode of Developer Tea. Hopefully you can take this information and go forward and try this kind of test-driven meeting approach for yourselves. A huge thank you to today's sponsor, Get Prime. Get Prime has written a book about the 20 patterns of engineering teams. This ebook is incredibly useful and practical. You can probably read through it in a weekend, but then you're going to want to use it as a reference, an ongoing reference to look at your team and compare some of the things that are emerging some of the patterns and behaviors that are emerging from your team to the ones in this ebook. It uses data to inform all of these patterns. Go and check it out. Get Prime.com. That's gitprime.com slash 20 patterns, two zero patterns. Thanks so much for listening to today's episode. This wouldn't be possible without the SPEC network. Go and check it out. SPEC.fm. Tons of awesome content for you as a driven developer as you grow in your career. Thank you to today's producer, Sarah Jackson. My name is Jonathan Cutrell. Until next time, enjoy your tea.