In today's episode, we talk about how much of our behavior is shaped by the invisible assumptions we make about our constraints, abilities, and context.
In today's episode, we talk about how much of our behavior is shaped by the invisible assumptions we make about our constraints, abilities, and context.
With over 91 million episodes, Listen Notes is my new favorite way to find podcasts. Whether I'm researching an author or trying to find something in a niche topic, Listen Notes has the search engine to make it happen. Search for almost anything, for free, right now! Head over to ListenNotes.com
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
We talked a lot about invisible things on the show. Very recently we've talked about it, but we've also talked about it in the past. Of course, the show has been around for six years now, so we've probably talked about everything that you can imagine talking about that's relevant to software engineering. But today I want to bring up this idea of invisibility as it relates to the shape of our work. My name is Jonathan Cutrell, listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And before we get started today, I want you to take a moment and stop whatever you're doing if you can. Most of us can. Most of us are working from home right now. And I just want you to focus for that moment on nothing but whatever is around you. This is a little bit of a meditation exercise. And the reasoning here is there's so much going on. And I can be yet another voice in your life telling you that you have to take time. You have to slow down and look around you and appreciate whatever it is that's in front of you. Otherwise, you can put this podcast on 2X or 3X. I'm a pretty slow talker. So 3X is not unreachable. And just speed through life. Speed through this podcast. Speed through whatever the next thing is that you have to do. But sometimes it makes sense to slow way down. And this doesn't mean that you have to slow down the work that you're doing. It doesn't mean that you have to slow down and be sluggish. This is not a call to be lazy. But instead to focus. There's a huge difference between focus and laziness. So I want you to focus on everything that you can that's around you. Try to turn up what is normally turned down. This is a trick that I like to use whenever I'm trying to kind of re-center and get back to the present moment. I imagine that there's a volume knob. And you can imagine this in as much detail as you want. I imagine mine like those big thick knobs on a receiver, an audio receiver. So there's this volume knob. And when I sit down to do this focusing exercise, I like to turn that knob up. And when that happens, not only does the volume go up, I hear everything around me. I'm focusing on every small sound. Not trying to dissect it, but just kind of listening and hearing everything. And then everything around me, the definition is also turned up. So a lot of the time we're focused in on only one thing. Or we're so preoccupied with a thought that the world around us kind of disappears. Speaking of invisible things, the world around us becomes invisible. Even the people around us, right, our most important relationships, we can turn that dial all the way down to where we're kind of muting those people. Sometimes even ignoring the most important people in our lives. So I want you to practice turning that dial all the way up. Right, being totally present in the moment. And what happens is that's going to drown out. It's not going to leave space for the preoccupation that so easily happens right now. It's not going to leave space for you to think about what's on the news. It's not going to leave space for you to think about what's happening in two weeks from now. Or what happens two weeks ago. Turning this knob all the way up is going to only leave enough space for you to process the high definition present reality around you. All right, so we're done with our meditation session today. I want to talk with you about the invisible shape of our work. The invisible shape of our work. And I'm going to do this through a story. Right, this is a fictional story, but hopefully it will drive home the point. Imagine that we have our main character, Jane. Jane has decided that she's going to build a startup and she's the technical co-founder. She starts by creating the kind of MVP that she has in her mind. She teams up with a non-technical co-founder, kind of a sales background person. And in a short couple of months, they have a launched MVP product. And this product does well at first. The sales engine is started up with the other co-founder. And they continue to build new features. These features have to roll out quickly. So sometimes there's a few corners cut, but overall Jane is pretty happy with the way that she's built the technical side of things. And her co-founder is happy with the way that the product works. Everything seems perfectly fine. And so this train keeps on going. They continue to build new features. Jane being the sole developer on the team. Until they get to a breaking point. When they realize that they're gaining enough customers, there's enough demand. They're starting to need to scale. And Jane doesn't really have the experience scaling beyond this very simple. This very simple application development that she has done in the past. She has a lot of vision for how it might happen, but she doesn't have the expertise when money is on the line. So Jane and her co-founder say, well, it's time to hire our first developer. So they go out and they hire a developer after an exhaustive search. Of course, throughout this whole time, Jane has continued adding new features. But of course, because of the job search, Jane hasn't had a lot of time to pay attention to the quality of the code base as much as she used to. So the most recent commits have been a little bit lower quality, not as much documentation, but still overall the product is reliable. So the new developer comes in. And this developer is kind of an intermediate level developer. Looking to grow into that lead developer role, but not quite there yet. And so Jane is doing some mentoring. And what's immediately apparent is that this engineer that's come onto the team doesn't totally understand the product. Now, there's no fault of this engineer. The product is brand new. They've never seen the code base before. But on top of that, and this is the critical factor, Jane was only one person. There was no review of the code as Jane was developing it. And this is a very common thing. There's a huge amount of technical property that Jane has been solely responsible for. And now the process of knowledge sharing begins. And all of the kind of cohesive mental models that Jane may have had in her head when she built the software to begin with, were unchecked. They didn't have any any backdrop to go against. It all made sense to Jane probably continues to make sense to Jane. But unfortunately our new developer doesn't make sense to them yet. Okay, so what do we do? Well, we start to talk about the parts that don't make sense. And as the new developer gets tasks handed to them, they start developing features. Maybe they do some pairing with Jane. Jane realizes the parts that are a little bit more confusing, but also this new engineer starts to pick up on some of the style that Jane has. And in fact, can even emulate some of that style. So now there's a little bit of kind of shared brain space. Jane style has become this new engineer style and vice versa. They are truly collaborating and building code together. I realize we haven't given the co-founder and the new developer names. We will call the new developer Brian. So Brian, he is no longer the new developer anymore. Now he's just a member of the team, but there's still some differences between Jane's and Brian's way of thinking. And because there's so much code that really doesn't need to be changed, but isn't necessarily something that Brian would have committed to the code base himself. Oh, there's some differences there. And there's still a gap and the test coverage isn't perfect. So we start to see bugs popping up in the system sometimes even in production. I know it's unfathomable that we would ever have bugs in production, but it happens. It happens to everybody. So we end up with bugs in production. And now our customers are giving us feedback. Our co-founder is sending that feedback to Jane and asking what's going wrong. Putting some stress on Jane about whether Brian was as good of a developer as they thought. And then Brian is getting stressed out because he is frustrated that Jane's code is, you know, esoteric in these particular areas, but they don't have time to fix it. And now it's time to hire a new developer because they have more demand and it's time to build new features. So they need to be able to maintain this code base and need to assimilate a new developer. And they're already experiencing some issues when the new developer signs on. We'll call the co-founder Stephanie and we'll call this next developer. We have Brian, we have Jane, and then the third developer on the team will call him Danny. Danny joins and Danny has a little more DevOps experience. So Danny comes in and he's going to try to build a DevOps pipeline, but that's going to require some refactoring. And as Danny joins on Danny, Jane and Brian, they all meet. They want to develop some best practices. We want to create some rules, some guidelines, a way of controlling this system so that we don't have terrible events happening. We've had a few close calls, luckily nothing that's taken the business out, but it's important for us to protect things. So they set out to do that. How do these best practices get developed? How did they come about? How did they get solidified? That's what we're going to talk about in the next part of this episode. Right after we talk about today's sponsor, listen notes. Listen notes is a brand new sponsor to Developer Tea, but it's going to become one of my favorite tools on the internet. And that's because it is a perfect search engine for 91 over 91 million episodes of podcasts, all kinds of podcasts. Podcasts you've never heard of, but certainly podcasts you have heard of like this one. This search engine is incredibly detailed, lots of metadata to search through, but here's the killer feature that I want to talk about today. It's called Listen Later. You've probably heard of other things like this where you have paper, you know, the pen kind of read it later, bookmark, all of these things that you've probably used, or at least committed to using, but then didn't ever actually go and read all the things that you've been using. But here's the way this one works. This is really a genius way to listen to podcasts later. So you can go through browse through all of the various episodes that you might want to listen to. You can search by topic, you could search by guest name, for example, there's a lot of things that you can do with a really good search engine, really good podcast search engine. And what Listen Later allows you to do is build a special feed of episodes that you are pending. What does that mean? Well, instead of subscribing to a podcast, an entire podcast, just to listen to, let's say, three episodes of that podcast, and then you have to remember to unsubscribe and kind of muddies up the feed and your feed is always going to be based on date. All of these things can be really frustrating in the typical podcast application. But what Listen Notes allows you to do is add these specific episodes to your Listen Later playlist. Right. So now you have this feed that you can subscribe to in a normal podcasting app like overcast or breaker or even Apple iTunes. You can, I believe you can add this feed specifically to it. And when you subscribe to it, you get these episodes that you're pending from wherever your Listen Notes account on your browser. You can get these episodes added to your feed. So next time you pick up your phone and go to that app, there is that episode of that ESA TARG show that you only wanted to listen to a couple of episodes from anyway. It's a really cool tool. Great idea. Even if it's just for that feature, but there's a bunch of other features. I want you to go and check it out. Head over to ListenNotes.com to check it out today. Thanks to Listen Notes for sponsoring today's episode of Developer Tea. So how do we create these best practices? We have our main characters, Brian, Danny and Jane. And they sit down to create some best practices to avoid some really bad occurrences. Jane might come in and say, well, we've got these coding practices that I want to uphold. And I want test coverage across all of the main pipelines. Right. I want to make sure that our payments are always working. Right. That's really critical. We want to make sure that test coverage on payments is at 100%. And we want monitoring. We want all of our monitoring to be at a certain level of uptime. And Brian may suggest that he wants all code that goes into the code base to be reviewed. Right. These are really common best practices. There's nothing specifically wrong with them. So Brian suggests he wants code to be reviewed. Perhaps it has to pass some kind of linting processes. And then Danny, of course, with DevOps is going to suggest integrating some kind of CI, some kind of continuous integration and automated testing so that we don't end up deploying bad code. The stuff that we can easily catch with our already written tests might as well get the most out of those. And so all of these seem totally normal. Right. There's nothing necessarily wrong with these practices. Another practice that seems totally normal is not deploying on Fridays. This is something that Danny might bring up. It's DevOps, a common DevOps practice. Don't deploy on Fridays. And the rationale is that if something goes wrong, which statistically we're always going to have some kind of failure at some point. If something goes wrong on a Friday, well, that could be really bad. Because if it goes wrong, it may take us till the end of the day to find out or it may take us until tomorrow on a Saturday to find out. And then we can see some engineers maybe off doing whatever they do on Saturdays, and we don't necessarily this startup, even though it's an early startup phase is not working on the weekends, generally speaking. And so having bugs over the weekend could be really costly because it may take longer. There's a longer, longer cycle time to actually figure them out. And so we don't deploy on Fridays. This is a new best practice that startup adopts. We're going to pause the story here and we're going to talk about the shape of our work. How did these best practices arise? They arise from the shape of our work. What do we mean by the shape of our work? Well, for example, with the payment tests, we want to ensure that the payment pipeline is clear that it's always working. Well, the shape of our work suggests that we always have a payment pipeline. It may even suggest that we always are responsible for the payment system. And the shape of our work is invisible because it's largely made of assumptions. We can kind of make out the shape of our work as it relates to these best practices by asking what would make this practice unnecessary? What would make this not why is this practice needed? Right. We need our payments to be online or we need that pathway to always work. We need CI to always be passing. We always need review on code because we want reliable systems. Everybody wants reliable systems. That's not a revealing answer. A revealing answer is what would make this practice unnecessary? Right. We don't need tests on our payment platform because we are not responsible for processing payments. So this shape of our work begins to emerge when we ask this question. We don't need PR approval if we are always pairing. These are extreme examples. It's not necessarily a good idea to always pair, but we don't need PR approval if we are always pairing because every step of the way we've had collaborative. We've had more than one set of eyes on the code. So all of these are probably good practices, but there is one that's maybe not a good practice in this list. And it's the last one. Not deploying on Friday. So this is a very common practice. I want to kind of zoom in on it and talk about it for a second because it's revealing of the approach that we're talking about here. The choosing our best practices based on assumption based on the assumption that the shape of our work is not going to change. So not deploying on Fridays. The goal of not deploying on Fridays is to ensure that engineers don't have to run fire drills on a Saturday afternoon. The goal of not deploying on Fridays is to ensure that our product remains reliable. The reason why we don't deploy on Fridays is because deployments sometimes cause bugs. So all of these are perfectly normal rationale, but we need to inspect a little bit about whether this is the right decision, whether this is the right response to those realities. Number one, and number two, whether there's something that we can change so that not deploying on Fridays is unnecessary. This best practice that we have, this restriction that we have is unnecessary. And we also need to evaluate what are the costs. Sometimes our best practices, in fact, always our best practices come at a cost. Not deploying on Fridays might cause a backup of your code. Not deploying on Fridays may create a lack of flow for your engineers, right? It may kind of trip them up from a flow standpoint. It might create a little bit of a frustrating merge experience, whenever it is time to deploy on that Monday or Tuesday. Your code can start stacking up. This is especially true once you get past that one or two team members. When you start queueing up code and now you have merge conflicts because they're working on the same code base, they're working on the same area of the code. So there is a cost associated with any of the best practices that we have. But it's deeper than that with this particular one because most of the time, the reason why we don't want to deploy on Fridays is because of some fear. We are not confident that the code that we are releasing is stable. We're not confident that the code that we're releasing has a very low likelihood of causing a bug. Now, I want to clear something up here because it's true. It's true that even in high confidence code bases, you could release something on a Friday that causes a bug that means a Saturday, fire drill. But here's the problem. If you have a code base where a deploy could possibly take out the whole system, it could be so catastrophic that everything has to be stopped and we have to go and fix it right this second. If you have a code base that is like that, then not deploying on Fridays is not going to fix that problem. That's going to be true on Thursdays and it will be true on Mondays and Tuesdays. The only difference is the fire drill is not happening over the weekend. This is bad because we don't want unreliable code bases, right? We don't want systems that could fall over just from simple changes. So what we're trying to do is we're trying to find some balance and you have to decide what your tolerance is on your teams. This is not something that we can say for sure here on the show. But the balance is simple. If my deployment has a percentage chance, right? Let's say above a 10% chance of causing a bug that we can't simply roll back, right? Or we can't wait a few days to fix. There's our two options. Those are very simple options, low cost options where you delay the fix of a bug for a day or two. The bug is just going to live out there for a little while. Maybe it's a non-critical issue. Delay the bug fix or you just simply roll back, right? If rolling back is not an option, if delaying the bug is not an option in greater than 10% of cases, then we have a broken code base. We have an unreliable code base. And therefore deploying on Fridays is scary. So we're kind of going backwards here, right? We're ending up at not deploying on Fridays because we are afraid that deploying on a Friday is going to cause something that is so catastrophic. That we have to tend to it immediately. Instead, if we can make deploying on Fridays normalized, right? If it's a normal part of our process, if it's allowable, and if we accept it and embrace it, that's going to require that we make our code base reliable as well. That we decrease the percentage chance that deploying is going to require immediate attention and a fix. If we have a low percentage chance, and if our percentage chance of small bugs is acceptable, right? If we can delay fixing it until Monday or if we can roll back right away, well now deploying on Fridays becomes a non-issue. Of course, why wouldn't you deploy on a Friday if the chance of something bad happening is incredibly low? I hope it's plain to see that the shape of our work, the invisible things that we take for granted, the shape of our teams, who is on our teams, what their experience levels are. All of these are invisible to us. We often are responding to them. In the same way that sounds, my bounce off the walls in a particular way, and we might get used to the way that the sound is bouncing. We don't really know when we're hearing echo because we've gotten used to, we've kind of accepted the shape of the room. We are able to see it. We're able to see the shape of that room, but we're not necessarily able to deduce exactly how we are responding to it. What exactly are we doing in response to the shape of our work? How do our best practices echo off the surfaces of our teams? That's what I want you to think about as we close out this episode. Thank you so much for listening. My name is Jonathan Cutrell. A huge thank you to today's sponsor. Listen notes. Head over to listennotes.com to get started with your Listen Later playlist. If you have not yet joined the Discord community, please reach out for an invite link. I'm not pusing these in our show notes just yet because I want this community to be established by people who care very deeply about the careers. Hopefully you care enough to reach out to me on Twitter. My Twitter handles, we have two. There's Developer Tea and at Jake Attrell. That's at Developer Tea at Jake Attrell. Thank you so much for listening. Until next time, enjoy your tea.