Hello everyone And welcome to the switch statement podcast It's a podcast for investigations into miscellaneous tech topics
This is an old episode from the archives where we discuss productivity.
audio:Hello again, John. To the switch statement podcast. How's it going? It's a podcast where we talk about pretty much anything that I think I said was defensively related to software engineering, programming, computer science. Okay. I feel like you're about to introduce a very out there topic. No, no, no. I just, this is just our kind of like. Just the introduction to the, to the podcast, you know, this is not, uh, well, it's a good introduction because mine is, uh, it's definitely related to computers and computer science, but it's a little indirect, a little more historical, I would say. Oh, interesting. Okay. Um, but just so, yeah, so let's say hypothetically, this is someone, someone's first, first, uh, episode of switch statement. This is so they'll understand what they're getting themselves into. And so, uh, so this, uh, flavor of episode is show and tell, right? So we're doing each, each bringing something surprising, random. We don't know what each other are going to talk about. So, um, so what I want to talk today about is developer productivity. Oh, okay. So I feel like velocity. Velocity. Yeah, I think that's, I think that's another way you can look at it. And it's, I think it's a kind of well understood to be a kind of a hard problem, uh, to, to do is to like quantify developer productivity. Um, and I kind of want to sidestep that because I, I'm not, I'm not going to give any absolute ways to measure your own productivity. Okay. I tried to come up with like. techniques that I think, you know, let's say hypothetically, you did come up with a good way to measure productivity. I think these would be techniques that would allow you to improve whatever that number was. Oh, wow. Okay. And so, but it's not like, I'm not going to say like, Oh, this is going to improve like lines of code produced by 50%. Like, you know, I'm kind of trying to sidestep that part of the conversation because like, I just don't think I have a good way to like. measure your productivity, even though I think I have some, or just, I've tried to come up with some things in my own career that I feel like I've tried to put into place to improve your own, to improve my productivity. I'd love to hear your, hear your thoughts. Yeah. I mean, this is huge. So you're about to give practical advice on how to improve developer velocity. Yeah. So just try how to kind of deliver, like achieve. goals. So right, like you have, you know, when you're working on a software team, somehow you arrive at kind of owning this, you know, feature that you need to provide this functionality that you need to implement. And these are techniques to try to kind of more quickly deliver that functionality. Okay. Uh, wow. I mean, I'm pretty excited about this. This is a topic that I. Care deeply about, I would say, but it's, it's always a struggle, I've been doing this for a very long time and it's still something that's just always top of mind. Every team is constantly trying to improve their own velocity. So let's get into it. Yeah. And there's no, I think there's no silver bullet. So let's, let's, let's get into it. I, you know, I have to admit, I don't, these are not necessarily prioritized in any particular order. Um, but so the first thing that I think is really, really important is to ask for help. Like, I feel like it's just like the most difficult thing to do. And like, you're always thinking like, Oh, like this is a stupid question. Or like, I should, I should be able to just like Google until I find the answer to this. Yeah. And I think it's just really important to Like, like I will be the first to acknowledge it's a continuum. Like, you don't want to just be immediately asking every single question that like arises. Yeah. Um, but like, but you don't also, it's also an anti pattern to just like struggle for multiple days in a, on a problem, which is something I have definitely done earlier in my career. Like. I would just, just be like reading a tremendous amount of code and being like, how does this whole system work? Trying to figure out every single problem all on my own. And I think it was just, it was just terrible from a productivity perspective. I agree with this so much. I think that, I think that software engineering has this incorrect. Uh, sort of foundational principle where, you should be super independent and, like, be able to, solve any problem. And it's, to me, it's become so much of, like, a collaborative effort where, you know, for any given problem, there's going to be someone who can solve that problem in, like, two seconds, either because they, wrote the API they are using or, like, you know, they're just wiser, they're, you know, more familiar with the system. There's nothing wrong with just reaching out to that person and, and getting that super fast solution, probably learning things you didn't know about the system. Uh, it's just helpful. And also people love being helpful. So if you're asking someone for help and they can, you know, directly help you and figure out what you're trying to do, like that's good for them too. That feels good. Yeah, they feel, they like that. So, um, so just like from a practical perspective, like the way that I think about it is You know, it's important to, you know, be a little bit systematic about how you search for solutions at first, right? Like, you should, you should be Googling, you should be searching internal resources, you know, maybe you have a Slack or kind of Google groups or what have you. Like, you should try to, you know, go through those resources. But then, uh, you know, after a certain amount of time, you know, and this is something you can tweak, but like. You know, 30 minutes or what happened, you've been searching, like, you don't see a really good thing. Like, just ask someone because, you've done your due diligence and like, and the other thing is they may come back and be like, Oh, look over in this other resource or what have you. And then you can kind of add that to your list of resources you should check before, you know, before reaching out for help. Yeah. Um. Um, but, but yeah, so that's, that would be the first thing I'd say, just like, don't, don't be afraid to, to ask for help. Uh, no one's going to be judgmental. The worst thing someone is going to do is probably essentially let me Google that for you. Yeah. Yeah. Like style response, which, you know, you will get that sometimes and it's frustrating. And I think that's another element to this is like, just be helpful. Like if you're the guy at your company who knows everything, like just help people. Don't be a jerk about it. Yeah. And I think you can, I think you can give that response in ways that are not dickish. Yes. Like, you can be like, oh yeah, have you taken a look at the XYZ docs? they're awesome, or what have you. And like, it, you know, it kind of diffuses the situation. Whereas like, some people literally will just like... Like, you know, let me Google, like send you a, let me Google that for you, link. And like, that's just passive aggressive and it just makes it just bad. So don't do that. And the other thing that I have realized, I have had the privilege of being like a senior person on a team that, you know, a lot of people are asking me questions and I figured out that if you do a good job of like, you know, quote unquote, teaching a person to fish, then people will ask you fewer and fewer questions. So that's another element, like if you're on the other side of this, people are asking you for help a lot, get better at helping people and you'll see, you'll ease your own burden. Right, right, right. And kind of on the, like on the opposite side, it's like, if you're concerned about the productivity of your team, like if you, if you like belittle someone who's asking for help, they're going to ask for help less. And like, that's going to be worse for it's actually funny because I guess from. Like an outsider's perspective, people could be asking for help less for potentially two different reasons. Like either you've done a good job and like, they don't need your help as much anymore. Or you've belittled them and mocked them and they're not asking for help because you're negatively impacting their mental health. Yes. Um, so just be, just be aware that like, you may not, you may not be able to tell the difference, I guess. Yeah. Don't be that second guy. Don't be that second guy. Um. Okay, so another super like super simple thing and like, I think it's just a super powerful technique. It's just beginning of the day, write down like the two or three things that you want to get done in that day. And like, you're probably like, okay, like, of course, that's just so obvious, but it's like, I think it is useful to talk about kind of the mechanism there where it's like, sometimes you have a little bit of downtime. And then, if you don't, if you haven't clearly articulated your goals for the day, it can be easier for you to, like, just, now it's a little bit of, like, mental effort to figure out, oh, what's the next thing I should work on? Yeah. And like, it's in that space where you can go, like, just kind of, I don't know, go on Meme Gen or like, not to say you should never go on Meme Gen or what have you, but like. I think it can be easier for you to go down these kind of like, productivity sinkholes where you're just like, I don't know, doing something, doing some nonsense while, you're waiting for a code review or something. Where you could maybe start to do something, um, slightly more productive. This is, this is an exercise that when I do it. It's, it definitely positively affects my productivity, but I'm just so bad at like the discipline of like every day, just writing down three or four things, you know, I, I also like trying to get better at, here we go. Remarkable. Yes. Yeah. Yeah. I also have my remarkable, I've been trying to write my task list in it. It's also good to have like stretch goals. This is just, you know, slight, uh, addendums to this, but, um, but yeah, and also like. When you come in in the morning, look at your previous day's goal, you know, this sort of thing. Yes. Like they carry over often. So very good exercise. And there's this other, there's kind of this other aspect to this, to like writing down your tasks. And I don't wanna get too deep into this. If you really want to deep dive into like, tasks, clicks, you should look into like bullet journals. Um, you know, this is kind of a, a whole like cottage industry essentially of like ways you can kind of manage your tasks. It also helps you from, you know, from letting things slip through the cracks. Like if you do a good job of kind of writing down what you need to do, and then you refer to the previous day's list of things you're supposed to do. Like, it's just harder for things to just like, you forget something and you just don't do it. So, um, but that, you know, that's like kind of less on the productivity and more like. On your reputation as like a reliable human being, you say you're going to do something. And like, even if it's not like critical to your, you know, day job, like you're making sure you're doing everything you're saying you're going to do. Um, okay. So then I have produce and share your artifacts, even if they're not perfect. You know, send, just send that design doc out like. I think, I think it can be really easy. It doesn't even matter like what you're working on. It can be really easy to, to be like, Oh, it's not perfect. You know, it's not like, I'm not ready to share this yet. Like I need this design doc to be like flawless before I send it out. And it's like, and that's, that's, it's an anti pattern and it's a, it's a pitfall and the fallacy that you can kind of produce this perfect doc. Like it's actually going to be much better for you to time box it. Make it as good as you can, you know, by the end of the day, but like, send it out because people are, people are probably going to have like fundamental comments about the way that you're doing this, which is like, if you spend an infinite amount of time polishing this, like you're just going to have to, all that polish was for nothing, right? Like your core premise was flawed. It doesn't make sense. Like, it's not worth the time to like super polish this, this design doc that you're working on for at least for the first version. And like, Maybe you don't want to share that with the entire team, like for the, for the V1. But it, but like, it makes sense to get early feedback and like shop it around a little bit. Yes. Early feedback, I think is one of the cheat codes of the software industry. Like once, once you realize that in order to build good stuff, you need feedback, you need to iterate, you know, you need people who don't have tunnel vision because whenever you're building something, you, you start to develop some form of tunnel vision. Um, and I've found, I mean, I've occasionally had extreme forms of tunnel vision where I just completely missed some detail and you're only going to find that stuff by sharing it. So I think this is amazing advice. Um, yeah, so, uh, I have, and this is, I, and this is kind of like sneaky productivity because like, like through a certain lens, like it's not advancing your own productivity, but. I think it's really important to eagerly prioritize reviewing other people's code. Yes, I review it immediately. That's my policy. I think that's the way, I think that's the way to go. And like all the other stuff, like we were just talking about, you know, start reviewing it, read it through, like, don't worry too much. Like, you know, you want to read it thoroughly, read every line of code, like understand the code review, but then just like send. You know, send the review back because I think it's going to be way more important to how, you know, cause that, this is like the, I don't know, it's, I'm not sure what the word is, but it's kind of like the medium of exchange or like, it's this ether that, you know, needs to be free, freely flowing, you know, code reviews are kind of this medium of exchange for software developer teams and it needs to be flowing. The spice must flow and the spice is code reviews. Hey, dude, you're so right. I like, this is something that, uh, yet another thing that has sort of become more and more true as my career progressed is like, unless it's in the repo, it's has no value whatsoever. Right. And then, No, and it's. That like, that goes for your own stuff, but it also goes for your teammates stuff. So you got to help your team get their stuff in the repo, you know, get more eyes on it, get more feedback, you know, get it into QA's hands so that they can break it and you can fix bugs as quickly as possible. And like. It's actually negative value actually, like when, if you have code that has not been checked in over time, like it actually swings from like positive to negative value because you're going to need to do so much work potentially to like get it merged in. Yes. Yeah. So I think I agree like, um, and, okay, so this one might be slightly controversial. Okay. But, uh, but I think it's, it's useful to. Get good at like context switching for Git, like, or whatever revision control system, like, and, and I think this goes hand in hand with, and I didn't say this, but like, uh, another one is like, you should be breaking your code changes as small as possible. This ties in directly with what you were just saying, John, about like getting into the code base. It's like, you want to make these, these code review units, a PR As small as possible so someone can just like read it really quickly and be like, okay, you're not doing anything insane in this couple of lines of code, because it's actually like the time to review increases exponentially with like the number of files because everyone's like, Oh God, like they need to track, track this complex code flow. So. But, uh, kind of an extension of that is you prepare this. Change for review. As soon as it's out, you know, it's going to take the person some time to review this. And I do think it makes sense at that point to like, you, it should be, you should practice switching over to this other code stream and being able to work on this other unit of code review and like start to prepare that while the person is reviewing your code. Yeah. Yeah. I mean, I do agree that this could be controversial. But I just think with modern development and the way version control systems work where, you know, there's usually a system where you can kind of build commits on top of one another, send those commits out for review, and you also have an ability to amend those commits where, you know, cause one issue you run into is you get a stack of five commits and someone puts a comment on the first commit and you got to go back, amend the first commit and then rebase, which is annoying. So a lot of people don't like this workflow, but ultimately I have found that it's more productive because of exactly what you're saying. Like you get code out in smaller units, quicker to review, easier to understand. Ultimately, like, like a lot of people think it's harder to understand because you're only looking at little snapshots of like an entire project. But I have found that it's actually easier to understand because you're just looking at everything in like the smallest possible unit. Um, and I guess, I guess you can commit the co or you can send reviews in such a way that you do make it harder to understand. So you do have to be thoughtful about how you structure these, these, uh, reviews, but I found it's, it's easier to understand. The way that I like to think about it is like, like, presumably you have some. Like layering like your repository layer and you have services and you have, what have, what have you, a way that I kind of like to think about it is like, okay, I'm providing, maybe I'm providing this utility that my feature is going to depend on, but it's like, this utility has a well defined contract in a vacuum. So like a user doesn't need to necessarily see exactly how you're using it. For them to evaluate like this unit of code, because you're, you're providing a well defined unit of functionality, even if it isn't making it all the way to the user yet. Exactly. Yeah. And that is the kind, those are the kind of CLs that I like to, you know, break it down where you're kind of like doing this in layers up until you reach to the user. Right. And I have heard people complain about that because Oh really? Yeah. Just because, you know, oh, you have this like thing that's just sitting in the ether and not being used by anything, which is why, you know, a lot of, uh, version control systems, you can actually look through the chain as a reviewer. You can literally look through the chain of, of uh, I guess commits or whatever they are. And you can sort of see how everything interplays with one another if you, if you care as a reviewer. I personally. If you send me a code review of like a unit that makes sense on its own and is right, is sort of logically correct, I'm going to say this is good to go. Looks good to me. Move on with your life. This is one thing that kind of bothered me about doing development in Google. Cause like, you would try to check, check something in, and if something wasn't using it in the code base immediately, P would be like, this is an unused unit of code. Exactly. And it's like, well, I'm going to be using it real soon. I know. Just don't worry about that. But like, no, like that's a very real, like, oh, this is unused code. And like, we can't have dead code in our code base. I, uh, yeah, that criticism bothers me. I mean, there's, there's definitely logic to that criticism, but it's like, as you're pointing out, and as I completely agree with, it just makes it so much easier to work with and review and it just helps the project move along, I think. Right. Um, but yeah, so like the reason why I say that this might be kind of controversial is just because I think that, um, you know, there's a lot of blog posts talking about multitasking. And how it's bad and no one can do it. Yeah. And I want to be clear, like, I'm definitely not proposing you try to like multitask at like a super fine grained level where like you're multitasking at like the five minute level or what have you. Like, no, I like if, if, if it's not gonna, if you're going to have to context switch back within like five minutes, like I don't think that makes sense. Yeah. Uh, but. But if you send something out for review, like that could be multiple hours before you have feedback that you need to respond to, right? And I just think that is a unit of work where you're like, okay, well, that work stream is. So now I should, like, it's silly not to continue to make progress, uh, you know, beyond that. Yeah, totally. Yeah, I agree. I think this, to me, this is uncontroversial, but I do agree that I've seen people, uh, you know, have a difference of opinion here. I think both of these things can be true. Like I, what I've seen is like, you shouldn't be working on like two projects simultaneously, which I think is true. Yes. Like that can be hard. Because if you're, because I'm not proposing context switching onto like whole projects. Uh, I mean, maybe if it's like a bug fix or something like a one liner, like that's okay. But like, I think if you do need to context switch between projects, like there is a lot of state to ramp up on. The thing that I'm proposing is like, you're still working on the same project. It's just like something like you're preparing something else for review. But like. I think if you read the blog posts by the letter, like there's one by Joel Spaholsky, which he calls a human, uh, tasks, which is considered harmful. And like, I think if you read it by the letter, you're like, Oh, like I shouldn't switch to preparing another, you know, CL for review. But, but I do, I think like, that's okay. Yeah. And I think it's better. Yep. Um, okay. Um, I am talking long, so let's, uh, I'll, I'll skip over a couple of these, but, um, I think that, uh, another one is like trying to understand the whole world, I think is an anti pattern in a productivity anti pattern. I think we've talked about this. Oh, yeah. Love this one. Where. I think you can get into a situation where you're like, Oh, like I need to understand the system at this deep level, all the way down the whole system. And you can just spend an infinite amount of time exploring the code base. Yeah, this is a, this is a paralysis trap there. Like there's so many paralysis traps in computer science and this is a, this is a really big one. You have kind of a halting problem where like you, you'll just never, you know, be able to deeply understand the code base on, on a, on a level and like, or on a level like that is maybe satisfactory. Yeah. So I think, uh, I think a better resolution is like, you should be, you should start by being able to build the code, make it, you know, make a, some modification to the way the code behaves. And then you can kind of start to be like. You have this, this concrete direction that you can kind of show someone you're like, okay, Hey, like, this is what I did. This is how I tried to solve this problem. This is what I'm trying to do. Yeah. And then you can show them that, and then that much more clearly articulates, like what, what you're trying to do, how you're thinking about the system to someone else. And then they can be like, Oh, actually we have this other utility and like. I think it's just a more, much more efficient way to get feedback from another person than being like, Hey, I'm trying to do X, Y, Z they'll be like, Oh, like, I don't know. Like, I think it can be maybe harder for them to like, give you concrete feedback. If like, you're like, Oh, how does like widget X work? Yeah. Like, you know, uh, that, that's one thing I wanted to add to this thought. This is another one that I completely agree with, but. Um, working with a system, like hands on, actually committing code to a system is just a very good way to learn a system. Um, so, and, and yeah, it's, it kind of goes hand in hand with what you're saying, where if you're showing people concrete work that you have, it'll be easier for them to give you feedback, but it's just also easier for you to like slowly learn and understand the system as a whole. Right. Or, I mean, like, and I think. I think in aggregate, like taking that approach is just faster, you know, you'll, you'll actually ramp up on like the way the system works more quickly and try to do it that way. In my experience, and I know I'm a specific type of person, but yes, like if I'm actively working in a system, I can learn the system way faster. It's so hard for me to learn a system by reading designs and, you know, chatting about it. Like I need to be working in it. Yeah. And, and that's not to say that like, and that, you know, reading through the rest of the code is like not worth your time because you kind of, as you go along, like your goal should be to understand the system at a, at a deeper and deeper level. Absolutely. Um, but I think that, you know, doing a mix and not like needing to read like every line of code in the existing system before you start to make any changes is, is an anti pattern. Right. Um. Okay. And then, um, this is another one that's maybe very specific to the situation that I am in right now. But I think just being aware of like stopping in the middle of a task, like the cost of stopping in the middle of a task, like it's the end of the day, you just want to leave or you want to go back. But like sometimes it's just, you know, it's an order of magnitude better to just like. Get the, you know, get the res, the task to like a resolved state or like, kind of going back to what I had said before, like getting it to a point where you can like, just send it out. Yeah. Whether it be a design doc or a CL or what have you, like, it's just an order of magnitude better because you're gonna need to come back, you're gonna need to pick up, like, you're gonna need to context switch into the middle of a task. As opposed to being able to start picking up like a new, a task anew. And like, it's just always much harder to, to like pick up from this like partially completed task than to just like get started on a new thing. Right. Yeah. And like, I think this is a particular superpower in my situation where it's like, I am working with teams that are mostly on the West Coast. So like, when I am. When I'm developing in the morning, like, I don't have anyone to review my code for like at least three hours. So like, I, you know, it's much more useful for me. Oh, no. Sorry. Yeah. Um, I was going to see if I could just fix it while you were chatting, but. But yeah, it's just, it's just much more useful for me to send it out at the end of the day. So they have another three hours where they can review it. And then I can come back and like, either I have feedback or like they've approved it with a couple of comments. I can quickly make their changes and check it in, which as we've just discussed before, like until it's checked in, like it's fake. So, um, and those are, those are just things that I, those are kind of like the high level things that I like to keep in mind as I'm like going about. My day to day. Yeah. And also you mentioned a bunch of, uh, very effective, like you didn't, you didn't call them out as bullet points, but in describing the other bullet points, you mentioned a couple of things that I also think are super effective. One that you touched on a couple of times is time boxing, like time boxing, like learning how to time box and being strict about it with yourself. Is so effective, like I have found that, you know, cause it's so easy to, especially if you're working on something nebulous, it's so easy to just sink an entire day into something. Um, so it's, it's good, it's a good exercise to think about how long a project should take set aside that much time for it and at the end, just share what you have, um, and yeah, and this kind of flows into a bunch of your other bullet points, but I think super valuable skill. No, I think that's, I think that's a really good point. Like, it's not something I called out explicitly, but I like, it's kind of like, you know, intrinsic to a lot of these things, you know, with, um, you know, three or four of these points where like count time boxing is like a fundamental part of that. So yeah, no, sorry. I appreciate you pointing that out. What was I going to say? Time boxing. Oh, well, the other thing I was going to say is like, maybe you. Don't have a like a concrete resolution, but like sometimes you just have to be like, okay. Well This, this task is not high enough priority for me to spend more time on it. Like, and cause I think it can also be, and I've also fallen into this, fallen into this trap as well, where you're working on a task and you don't want to not do the task, it feels weird. It feels like quitting to like not do the task, but it's actually really important to be able to say, you know, take a step back, maybe you've finished the end of your time box and you're like, okay. How important is doing this really because if it's not that important, it's another productivity time sink to continue to spend time on it, even if you haven't resolved it. So, yeah, no, that's so true. Yeah. Prioritization and proper time boxing help you focus on what's important. All right. Well, that's, that's all I got. But, uh, but yeah, so maybe we'll take a quick break and we can switch over to yours. All right. I'll see you back in a little bit. See you in a bit.