The Context Switching Problem Every Dev Faces

Transcript is auto-generated and may contain errors.

Hey folks, we are going to the experienced dev subreddit and this one is going to be about task switching which for many of you is probably a very real thing. It happens all the time and uh I'm going to talk about this from a a handful of different angles. uh from being someone who uh you know was a software engineer who was constantly stuck with task switching uh as an engineering manager who was being you know you know told different priorities and having my task switched and then also as an engineering manager kind of uh doing that to people on my teams and you know how to navigate all this kind of stuff. And as usual, if uh you're not new to the channel, then you know uh how I try to approach topics. If you are new here, then just a heads up, I do try to as much as possible take different angles on things.

Uh I of course, like anyone else, have a bias just from my own lived experiences. So anything I say is not to try and tell you like this is the only way. Uh just probably my my own experience kind of coming through. So intention is just for it to be some type of perspective to to give you some different insights. Okay. So when it comes to task switching, one of the the big challenges is of course that there's overhead. Uh when you do a context switch, there's a lot of either mental overhead, it could be tooling, it could be whatever, but it's not free to switch contexts. Okay. And the other uh sort of unfortunate reality is that uh the idea of like eliminating context switches like you're never going to have to is also uh extremely unrealistic. I think the goal is that we want to be able to minimize context switches and then when context switches have to happen that they are um understood.

So they're minimized and then they're understood because the actual this is wipers man they're unerstood and the priorities between the person uh who is carrying out the work and the person who is uh sort of interjecting with the new priority uh everyone's on the same page. Okay. So as software engineers when this kind of thing happens and I think this is probably maybe you know making assumptions here the the most applicable kind of uh one of the areas to talk about. So like I said it's going to be uh disruptive right? So you're going to be working on something and someone comes to you and hey this is the new priority and you're like well I'm I'm midway in this or I just started this or I'm just wrapping this up. um and then you're kind of forced to go do something else. Pretty common.

Um the one part I wanted to to mention near the beginning is that like a lot of this can vary dramatically based on the type so like the industry you're in, the type of product or service you're building, uh and even like the company stage. So, uh what are some good examples here? If you're okay, let's go like one end of the the spectrum, right? If you're at a let's say a really big company, right? Well established product, well established service, you don't have something that is uh like let's say you don't even have a live service, okay? So, it's just a product and it ships uh monthly or less frequently. Uh it's it's not that you'll never have priority changes, but what's likely not happening is that you're getting called uh into an incident bridge. If you are, it's probably less likely than a live service because a live service is kind of like, you know, almost like this living breathing thing that uh anything could go wrong at any given time.

So depending on what you're doing, right, with the the types of products or services you're working on might demand other um sort of attention from you. And I would generally say, at least my experience at a like a bigger, more established company with bigger, more established products and services, the disruptions or the the context switching happen happen less. Um, and that's not always true, right? like I'm trying to give you some generalizations but even like on on my team or one of my teams now I have uh like a lot of work for security okay and so if anything is going on where there's something security related where we can help then like that's going to randomize someone and that's unfortunate but that's kind of the the nature of the role that our team plays right and so a lot of the time if possible I will make it so that I'm sheltering my team by randomizing me, right?

I would rather that my team who is doing who is building things who is you know moving the product and service forward um I would rather that they can continue to do that and then if there is something that I like that you know someone would need to get involved in that's going to be randomizing and because it's security it's extremely high priority I will as much as possible try to put myself into that situation to kind of shelter the team from having to do it and there's absolutely absolutely cases where unfortunately that's just not realistic and and then I will have to pull someone in or people in. Right. So it does happen but I would generally say that I've experienced this uh sort of pressure context switching less uh at at a bigger company where something is more stable but having live services really uh can interfere with that.

On the flip side, at a smaller company, um I noticed that we would contact switch a lot because we were uh even without a live service, we were always trying to like if you're actively talking with customers and you're always trying to like go after the next thing, uh the side effect of that is going to feel like there's always, you know, something new, something something you have to go chase to be able to get the next customer, the next uh customer base. whatever it is, always trying to learn something and then always trying to apply it to try and um you know drive drive more sales, right? And at the beginning, especially the earlier stages of a company, that could be absolutely critical, right? I don't know for how many people that listen to or watch this that I don't know how many of you have been at a startup where you know that that that is kind of like if you don't do those things you you may not be at a company.

Uh even where I was, I feel pretty fortunate that I don't feel like we were always like that. But at the same time, like we needed to make sure that we were prioritizing what was going to truly be the most valuable to deliver. And that often meant shifting over time. And I've said this in other videos, we had to try and reel that in more and more because as the company grew, the the cost of context switching wasn't like, oh, one developer is going to have to change what they're doing. It's like the whole team might and it might extend beyond engineering. It's now uh the UX team, the product team, the marketing team, the sales team is going to have to go, you know, switch up what they were focused on. So the cost of context switching the way that we were doing it certainly would not scale um as the company grew.

So as a developer like what can you do about this? Right? That's probably what people are are after. They want me to stop rambling. Um I think one of the most helpful things that I learned is that it was about providing context back. Okay. And so I can uh thinking back to uh I'll talk about both at Microsoft and even in my startup time um in the startup days the I will always put this disclaimer in uh loved working for the guy uh and wouldn't change a damn thing about it but especially in the early days like the CTO and the founder always coming to us with hey got got something new got something new and um we we needed to start pushing back, right? And what that looked like was, "Hey, look, like we had just talked about this other thing that we said is BP0.

We have to go absolutely do this thing." And so I don't know if you recall, but like we're doing that right now. And you know, so that's being worked on. This other thing's being worked on. This other thing is being worked on. And I'm just giving you this silly example. So, we got three things going in parallel right now. We recently just talked about how each one of these is like the most critical thing. Now, you're giving us a fourth. Um, there's only so many people in so much time. So, do you think that this fourth thing is more important than us, you know, completing or making progress on these other ones? Because if so, understood. like we will do, you know, sort of what needs to happen because this is a true priority. However, if you hear those three things I just told you, do you truly feel that this one's more important?

And over time, these types of conversations uh became a a lot more I don't know um the way I'm saying it, I don't know if it sounds confrontational, but it certainly wasn't. It was just like awareness, right? because when something seemed hyper critical, this is so urgent, we have to go do this. Um, depending on, you know, like at least for myself and my role, it was like I had a a pretty good handle on like what we were doing as a team. And not that not that my boss didn't, but he certainly had just to be transparent, like he certainly had less of a handle than I would because he's removed from it, right? it just makes sense that he would have less, you know, specific visibility into what we're doing. So, raising that awareness and then having him kind of think through the priority a lot of the time would mean that he would say, "Actually, no, that's a good point.

You know, those are more important." And it was more rare that he would say, you know, like now that I've heard that, I I do still think this one is more important. And then at least at least we were all on the same page because I think what was the most frustrating is that these context switches would happen and we weren't really aligned. Like we were like how can everything be the most important and it's frustrating but when we would have these conversations more often at least we were aligned on why. Okay. So uh that's one of the things I would highly recommend is providing that context back to the person giving you uh you know the new tasks to context switch to. Uh I've seen the same kind of thing even happen at Microsoft. I'll even use the security example, right? There are times where from a security perspective, we'll be having conversations with security teams and uh there's stuff that's like clearly like, hey, we have to go do this right now.

And there's really there's always more work that can be done. And I would say this about about anything. There's always more work that can be done. And sometimes in those conversations, what would happen is that you'd be uh you know doing a series of things that are like must go fix now and make sense. So we go fix them. But then periodically you have like in the mix this other thing comes up and we're like wait a second like is that a must fix now or is that like you know basically we know we need to go do that or we know that enhances things. It's more of like a a feature request versus like a mustfix now kind of thing. And so we started having more of these conversations where just finding the right way to work with the the stakeholder.

So in this case would be um you know my manager, my skip level manager and security teams just being like hey look like we just want to make sure we understand like the the severity of this the criticality and a lot of the time you know we would just ask clarifying questions and be able to say like oh wait no like that isn't a right now thing. So again, just going back to context, going back to the person who is making it seem like you need to switch context, new priorities, and just clarifying with them. Uh, so I'm just kind of saying this cuz it works the same for me as an engineering manager when when these types of things happen. Um, I wanted to add in I know I'm jumping all over the place cuz I'm realizing this would have been a way better conversation for the longer drive to work, but I'm almost at CrossFit.

Um the other angle I wanted to give here is that uh ideally like in my sort of ideal balance for for how I structure work with my teams is that uh I I don't like having people working on a ton of things all at once. So if you're familiar with things like uh like canban and that kind of stuff and not to just make this about agile processes just concept here uh the number of uh items like in progress right like your whip your work in progress and so I really have had good experiences where on a team if you limit the number of items in progress and kind of uh do a bit of a call it like I don't like the word force but like almost like a forcing function where people have to uh keep focus on just a couple of things

I found that does work really well um at least for the teams I've managed but um there's some other constraints and like just to to explain a little bit like where where I am at Microsoft a lot of the changes that we need to make are not something that lends itself well to uh to that kind of I don't know like cadence and that often means that so if you wanted to finish something right you have to deploy changes across the entire planet we purposefully do them at a pace that is uh like more staged and more controlled and that means that it goes slower it's not that the technology cannot do it it's that we consciously choose to do do it slower. And the side effect of that is if I only gave someone one thing to work on, they would be waiting for their change to to go deploy across the planet and they would have basically nothing to do.

So what often happens and I've done this across basically two like three teams cuz I inherited another team at one point. Um so three teams that I've had all sorts of different levels of uh employ like uh software engineers right whether they're new hires or or principal engineers done this across the board and this seems to be the preference when I have these open conversations with people and that is the way that we are set up is that people actually prefer to have multiple things to work on at once. It's just that we try to make sure the priority is clear. So to give you an example and this would depend on someone's level maybe a more junior engineer might have one maybe two things kind of going on okay so their thing goes up for code review um or they're deploying it they can

at least start on the next thing right have a have a look at it um for more senior engineers maybe they have three four kind of things going on for the same type of reason and uh sorry there's a big sign ahead that says is the lane's closed, but I can't tell if it's in my turn lane or not. I'll find out beside my wife. We'll see if she tries to race me. Or I should race her. Maybe we'll race each other. Um, man, what was I saying? Oh, that's the next light, so we're good. Um, oh yeah, number of uh items in progress. So, the idea being that even with like more principal level engineers, like they might have a design dock or two that's going on. So, they're working on designs. They have uh several features rolling out kind of like I was just saying for the more junior folks on the team.

Um they just have like more things that they can they can go between, but it just means that we all have to be on the same page for priority. But again, this seems to be a preference because that means that they're not sitting idle or they're not blocked. We do also have to be careful that the things that they context switch from don't sit blocked for uh extended periods of time, right? Like say something's blocked because it's rolling out like do they forget after after a couple weeks go by or if they were blocked waiting for, you know, feedback on design reviews, do they just forget that they're uh waiting because they context switch? So, we have some of that going on that obviously we have to to make sure people have awareness and stay on top of that stuff. But that's the one of the side effects of just having more things going on in progress.

So, I try as much as possible to shelter team members from context switches. Um, it's really uh challenging especially when you have a live service and things going on. Um, we'll have stuff that comes in to us from like organizational efforts uh that that happen to to spawn like spin up and they are super high priority and we're like okay we don't have a choice and this is kind of like every team is going through it so we'll have things like that. Um, but yeah, I think I I would expect from people on my team, I would want them to be able to say, "Hey, like here's what I got going on and like I just want to get on the same page as you." And I have had conversations like this. Um, my feeling is that they go well on both sides. Uh, but, uh, generally try to minimize.

I think one example of like a a like a call it a context switch that I think we got done pretty well was someone was literally transitioning from uh finishing up some work to go into the next and right before they started we were able to to do a context switch so they picked up a different work stream and then a new employee uh worked on their other work stream and I think that that timing worked really well. So, I would rather find those types of things. Um, versus someone's in the middle of some work and then it's like, "Hey, drop everything you're doing for this other thing." It's no good. So, for I briefly skimmed through the the Reddit comments on this one and I think some some people made some good points and if you are trying to convey this to your manager

not having a lot of success, try documenting some of it so you can show like here's what I'm working on like over a period of time and when you context switch, show it, right? so that when it becomes a problem and you want to talk about it, you can say like here's literally a visual of me working on these things and then context switching and you can see that I'm bouncing around and not actually finishing things. And again, it's just more context and visibility and understanding for the person who's assigning you this stuff. Um but yeah, I think ultimately it's unfortunate if you have uh people in management positions who are assigning work and don't really get that. But uh I think if you have people that aren't uh totally terrible, giving them that visibility and context back uh can be can be super helpful uh so that they can make a better priority decision.

I think a lot of the time they're just missing some of the context. Hope that helps. Uh, I wish I did this one on the drive to work, so maybe another time. But thanks for watching. I will see you in the next one.