Do you multitask? If so, you'll want to check out this episode. We'll cover...

Michael_Berk:

Hello everyone, welcome back to another episode of Adventures in Machine Learning. I'm one of your hosts, Michael Burke, and I'm joined by my other host.

 

Ben Wilson.

 

And today we're gonna be talking about a less technical topic, something that is very near and dear to my heart, and that is context switching. So when we talk about context switching, we're talking about working on different projects simultaneously or maybe responding to Slack or email while working on something else, having different projects in flight at the same time. And this sort of gets a bad rap because it's considered multitasking, but in a modern workplace, you kind of have to context switch. So today we're going to talk about what context switching is, how Ben and I approach it, and then end with some practical tips. Sound good to you, Ben?

 

Mm-hmm.

 

Cool. So I sort of gave a quick outline of context switching, but Ben, how would you define context switching?

 

It really depends when we're talking about it from the perspective of what the show is about like working on projects It depends on where you are in your life cycle as a team where you are in your career as an individual and What the nature of your team and your responsibilities are? so That's a very convoluted way of saying The more seasoned your team is, the more senior you are, the more expectations that the organization is going to have that you're capable of doing context switching. And there are times where, you know, you can't avoid it. There are times where you need to avoid it at all costs. And it depends on what you're working on at that time and what's going on around you really.

 

Yeah, the seniority piece took me down memory lane, as you said, that for my first internship back when I was a wee lad doing like learning sequel, essentially, I remember I was super frustrated on the sequel project. And I was like, why is this joint making there like be a billion rows instead of 500 rows. And so I go over to my manager, and he has the webbed footed, like toe desk, one leg on a balance board, and he looks over without stopping his typing, answers my question, and then goes back to typing. Now, later I had a one on one with him and I was like, how the hell were you able to essentially context switch or sort of multitask, like keep writing A-B testing code while answering my very new question. And he was like, Oh, well, when I was doing my thesis, or not thesis, like Masters, I would set a time. and have two separate projects in flight at the same time or two separate assignments. The timer would hit every five minutes and every time I would hear the timer I would have to switch projects and through that process he got really really good at context switching and as a more senior person in his career this is incredibly invaluable because an intern could come up to you and say hey what's going on help me with this the CTO could come over and say hey other projects that you're managing. So as sort of a lowly intern you can just work on one project, but as you get higher and higher Ben is 100% right that there's a lot more expectation to be able to context switch and manage lots of different things in flight. So when we're talking about context switching it'd be interesting to sort of frame this problem as what is good and what is bad. So let's say we are working on optimizing an ETL pipeline as well as developing some machine learning model. Let's say we're predicting hot dog consumption, just going back to basics. Ben, what types of things do you consider bad in the context switching use case?

 

I try to avoid, if I'm directly working on something that requires a high cognitive load, I'm going to try to make sure that I'm timing my day so that when I tackle that, it has the lowest probability of interruptions and then I'm not going to be, end up being a jerk to people if they need something from me. And everybody's different for that timing. I produce my worst work at the very start of the workday. So I try to avoid having to tackle complex stuff like while I'm having my first cup of coffee in the morning. So because I know that about myself, I'll set aside, I'll block time on my calendar if I'm working something complex, like, hey, from two to 4 p.m., it's effectively do not disturb time. I'll do stuff like ensure that my email is not visible on screen. I'll mute Slack or I'll close Slack sometimes and I ignore everything. I don't work in a physical office anymore, but when I did, I let everybody know that, hey, if you see me with headphones on and I'm typing on the keyboard, I'd appreciate it if you didn't like tap me on the shoulder or ask me a question because I'm working on something that I need to. be 100% focused on. And that's not something that happens every day. Uh, it happened more when I was junior, when everything was challenging and you know, anything I was working on was novel to me. So I had to do a lot of research and prep myself before I was going to start working on it and understand what it is that I was doing, less so now there are still times where like, Hey, we're building something that's never been built before. when you really needed to think about this and this implementation is going to be complex and I need to do a bunch of testing. But it's much more rare. It might happen once every couple of weeks that I need to block three or four hours a time to really focus on something. And that's the, you know, it goes hand in hand with seniority. The more exposed you are to concepts, the more times you've done things in the past, they just become easier to you. So when your manager... in your internship when you came up and asked him, like, hey, why do I have this data explosion happening? I would be able to answer that too. Like, it's probably a Cartesian join. You didn't, you know, join on keys. That requires so little cognitive burden for me to answer that question that I could, I get to answer that in the process of working on something complex. So the context switch isn't that hard. But if you came to me and said, hey, I have this, this 1300 lines of SQL script here and you didn't, because you were an intern and probably the first time writing SQL, you didn't have comment table expressions in there. So it's just this wall of text with no aliases or references. So the cognitive burden of reading through that and trying to grok what the hell you were trying to do is pretty intense. So Bad code means you got to think about it quite a bit. But if you had written it really cleanly and had CTEs, and you could clearly see in these four lines of code, here's where this join is happening. And it's like, oh, you didn't join on those keys. OK. So it depends on what somebody is interrupting you about, how structured their questions are, how much understanding they have would how punishing that cognitive switch would be.

 

Yeah, that's a really good point. Interruptions are not created equal, and for certain things it's really easy to sort of stop what you're doing then return to what you're doing. But for other things where you actually have to completely interrupt your flow, interrupt your work mentality, there was a study that if you completely exit flow, it takes anywhere from 15 to 30 minutes to return to that state. And often I find it harder to return to that state than initially getting into it. But that's super interesting. So it sounds like we're trying to minimize interruptions because it can break your current thought process. Do you ever strategically use interruptions to help you work?

 

Oh, definitely. So I have this weird thing that I do. Whenever I'm working on something really complex, I'll maintain sort of a mental. sort of a mental iterator on how effectively I'm working through the problem. And how I write code now is very different than how I wrote it years ago. Years ago, I would be like, all right, I need to build this functionality. And I would, I would write a wall of, of text and then test it out once I'm completed with it, and then I'll almost always find that there's something broken in it and then have to debug that. So Now I've learned from working with amazing software engineers, particularly over the last three or four years, how other people tackle stuff like that. So like, hey, do a very simple thing first. Validate that. So writing tests as you're going and making sure that every time I'm adding two or three lines of code, I'm executing against this test that is also growing in tandem with this. So I can write code, test it, write code, test it, write code, making sure that I'm getting what I'm expecting for complex stuff. And if I find that that progress that I'm making in execution of that starts slowing down, I force a context switch for myself. And that might be because I work in sprints. You've got two weeks to figure out five or six features that you're developing. It doesn't all have to get done right away. You can say, all right, I'm going to put this aside until tomorrow. But what I'll do in that putting aside, I don't sit there and like stare at my screen or, or, you know, blast music or something in order to figure that out. I'll switch to something else and then I'll probably figure out. Nine times out of 10, I figure it out in what I refer to as shower thoughts or fridge logic. Shower thoughts being when you're in sensory deprivation, taking a shower at the end of the night, sometimes epiphanies happen. Your brain is processing the things that it was thinking about during the day, and you could come up with a solution. So having a writing utensil in a shower is good. Grease pencil, something, right on your shower walls. You'll only look partially insane to anybody else who sees it. And then fridge logic is you wake up right before you're going to go to bed. You want to go downstairs, get a drink or something from the fridge or get a really quick snack. And as you open the fridge door, you just kind of stare in there and then your brain just comes up with a solution. So having a notepad around or things to write on near places where, you know, you're going to not have a high cognitive load at that time. Sometimes your subconscious can be like, Hey dude, you forgot this thing. Oh, or hey, here's a more clever way of solving this that's way simpler. Um, so context switching can help for that if you're blocked. Um, it, it doesn't help if you continue working on something, or at least it doesn't help me if I try to brute force my way through frustration and I, you know, I don't care how many years or decades you've been. solving problems with code or working in software, you're going to come up to a block. Everybody does. And wise people know to bail out of that and not get into that frustrating funk of like, why can't I figure this out? And there's a time where as a junior person, you can get away with when you get stuck asking mom and dad. you know, ask a manager, ask a TL, and they're usually not going to ask like, well, what if you tried? Maybe they will, or they're not going to have an expectation that you've spent significant time and thought on trying to figure something out. They're just like, all right, I'll help this person out because it's usually a simple thing for them to answer. But if you're much more senior, the expectation that your peers or whoever's above you. is going to have that you've done your homework is going to be pretty high. So you can't just phone a friend when you get stuck after 20 minutes. Somebody they're going to ask like, well, what's the exception that's getting thrown and how did you debug it? And what's the, what process did you use? And if you can't show any of that, you just lost an enormous amount of respect from your peers. And they'd be like, what the hell are you doing, man? Uh, so taking a break. Revisiting it the next day is always a better thing,

 

Yeah.

 

instead of just focusing.

 

Yeah. There's been countless times where I personally have tried to muscle through a project and just build something that's completely wrong. I'm like, I'm the best. Go to bed. The next day I wake up and I'm like, what the hell is this? What was I thinking?

 

Mm-hmm.

 

And From a cognitive science perspective, according to Barbara Oakley, who's this researcher that developed this book called Learning How to Learn, it was one of the most influential books to me so far. There are essentially two modes of thinking. The first is called focus, the second is diffuse. Focus is headphones on, head down, you're very focused on a single project, a single object, a single problem. Diffuse on the other hand is sort of when you take a step back go for a walk hit the shower and Your brain sort of relaxes and the subconscious enters and starts working on the problem as well So focus is a lot more conscious oriented Diffuse is a lot more subconscious oriented and it's important for Creativity to sort of let the subconscious in and let it work on the problem because focus you sort of have blinders like a horse You you don't see the your peripherals and really effective to sort of work in focus mode for a bit, get that problem deep enough into your brain so that the subconscious has stuff to play with, then go for a walk or take a shower, or play basketball, or do whatever you do. Take a nap is also a famous one.

 

I use guitar, so I'll pick up

 

Oh

 

my

 

man.

 

guitar and play for five minutes sometimes.

 

How long does it take you usually when playing the guitar to reach a new idea, if it's gonna happen?

 

Um, well, it's important in, if you pick up an activity that's not related to what you're currently working on, don't choose to do something that has a high cognitive load as well. So if you're going to, you know, for me, if, if I've been working on a song that I'm learning over the past couple of days, I'm not going to pick up the guitar to take a break and continue working on that because I'm, I'm now still in that focus mode, I'm going to play something that I've I memorized six months ago and it's super simple to play. It's just really fun to play. And my brain doesn't have to think at all about where my hands are on the guitar neck, what my strumming pattern is or finger picking. It's just on autopilot. And that autopilot process, it's kind of like, like you said, it frees up the mind to focus on other things and your imagination wanders. And that is, it's pretty effective actually doing that. And being like, oh. Yeah, I just figured that out. All right, once I finish this song, I'm gonna get back to the keyboard and the vast majority of the time, whatever I come up with actually solves the problem.

 

Yeah, that's super cool. I would love to play instruments, but I just haven't learned yet. Keyword yet. Cool, so we've been talking about context switching sort of in a positive light. Let's get back to the negative. So, let's say we're working on a project in the prior conversation we were talking about how interruptions are really detrimental to your work because they interrupt flow. Can you break down a little bit more why interruptions are problematic? Is it the context switching time itself where you transition between tasks? Is that the issue? Is it relearning prior things? What exactly is harmful about context switching in your opinion?

 

I mean, if I have a project to work on and I can give you like a story from, well, not a story, but a process of how we do it in engineering at Databricks where you're expected when you're on on-call rotation. And we have a couple of different on-call rotations, but the one in particular, which is on-call, on-call, where if we get alerted to a system failure in production systems. There's no pausing that and saying like, ah, no big deal. You know, I'll get to it tomorrow. There's usually a time limit on response. If you don't respond to that, then your TL is gonna get notified in a couple of hours or your manager is gonna get paged. Nobody wants that. So what you need to do is acknowledge that you got this issue and then start investigating. So when you're on that on-call rotation, you're not tasked with implementing complex features because everybody knows that those interruptions, there's no guarantee they're gonna happen, but they could. And when you have a complex interruption like that, which it's, most of the time it's going to be something that requires investigation and you writing code and trying to reproduce something and figuring out what the root cause of this is, it can take It could take a half an hour to figure it out. It could take six days to figure it out, six full work days. So it really depends. You don't know what's coming, and you don't know when it's coming. You just know there's a high probability that something's going to happen. So avoiding high cognitive load focus activities for that two week period. and instead taking simple things that maybe they're not the most exciting thing to work on. They're not the most fun thing to work on. They're, they don't require a great deal of creativity to solve, but they just need to get done. So those small tasks usually get assigned to the person who's on call because everybody knows like, Oh, you can probably knock that out in 30 minutes. Take a break, you know, respond to some issue or something. Five hours later, you kick off the tests. They run for two hours in that time period. You're handling two other, you know, lower priority events that came in. So that two weeks is all just context switching, but the delicate balance is knowing what you need to focus on or what's going to be expected of you to focus on. And for a data science team. when I was in those, you have the same thing. You don't when your team is new, when your team is the first year or so of the team getting built up and working on projects, which a lot of teams that are out there, they're still at that phase. It might not be a year. It could be the first five years of the team's existence or the first five years of the company's existence where everything is greenfield. You're just working on new, exciting things all the time. If a production system goes down, everybody context switches and fixes that thing and then gets it back up and running. But at a certain point of maturity, you're gonna have to have an on-call rotation to support questions that come up about the predictions that your team is making. Or you have real-time services that are deployed on the cloud, what happens if you get a high retry rate? Or what happens if all of a sudden the... the endpoints aren't responding correctly, or there's a corrupt nature of data that's coming out, things are going to happen. So the team needs to switch gears, the people on the team needs to switch gears to start thinking about how software engineers do this. It's like, yeah, you have a sprint where one person just gets hammered with all of the complex on-call support while everybody else is free to focus on project work.

 

What's the hardest project you've ever worked on?

 

Um... from

 

And let's

 

like

 

look,

 

a cognitive load

 

yeah,

 

or...

 

yeah, let's,

 

Come-

 

let's ignore politics and like

 

Ahem.

 

poor management and that type of thing. And just talk about a really difficult technical problem.

 

In software, it wouldn't even rank in the top 20 most complex things I've had to work on in all my years working with computers. Stuff that I did at the LED company that I used to work for, that was complex. Just extreme cognitive burden to work on that stuff and figure out why a metal organic chemical vapor deposition reactor was behaving the way it was and how to program those recipes and It's just too many variables for the human mind to comprehend fully. So it's that stuff was hard. Um, but that company was structured in such a way that there actually was no disruptions. So the entire, everybody that was in engineering, everybody that was on R and D. You weren't permitted to be interrupted in your work. There was no way for people to interrupt you because you're in a lab in a clean room environment. sitting at a computer that's in the lab writing your recipes and evaluating results. So yeah, those were the most complex sort of problems. And then before that, working in the Blu-ray industry or DVD industry, working on some of those physical engineering problems and designing stuff, that was... There was some cognitive switching that was happening there because you're responding to production issues. And the way I solved that was just mentoring technicians to handle the vast majority of all of those problems that came up and working with them to be like, Hey, this is how we solve this. And by the way, I'm going to be unavailable for the next two days because I'm in the machine shop working on designing this new part. But in the data science world, there've been some projects that were sufficiently complicated that I learned a lot of hard lessons because I didn't have anybody telling me like, Hey, you need to, you need to focus on these elements and ignore all this stuff. Particularly when I was a team lead for the first time in a data science and ML engineering capacity, I was trying to be a good steward of the company and work on projects and do the project management aspect of it and do design. And then also be available for people to walk up to me and ask me questions at any time, because we were trying to build faith in the company with the idea of data science and what it could do. So I... I burned myself out at that job pretty hard because I just permitted all of that.

 

Got it. So for those really complex cognitive burden tasks, how often would you employ context switching versus just staying in focus mode for 24 straight hours?

 

I mean, it depended on the thing that I was working on. Some things, particularly in the ML world, you have the ability to force yourself to take a break. So you're testing out three different ideas, like three different modeling types, and you might have. for each of those models two separate feature sets that you want to test out or ideas of how you're going to do something. And for most real world production use cases, you're not going to get an answer very quickly from executing a model fit. So you have time. And with cloud computing, you can asynchronously run, you know, six, 10, 50, 100 experiments all at the same time. spend a little bit of time focusing on setting all of those up and then kicking them off, then you can have time to sit back and kind of think about what the next iteration is going to be. How am I going to analyze the results? I'm going to respond to Slack questions, I'm going to respond to emails, I'm going to go take a walk within the company's building, go meet some people, chat with people, get some ideas from people. So I would structure my day that way, where I'd say... before lunch, I need all of my ideas to be in flight. So then during lunch and two hours after lunch, I'm free for people to come and talk with me or I'll answer questions. So putting forethought into forcing a time of chaos and extreme context switching so that you're freed up, because your backlog of questions that are coming in. is infinite depending on how senior you are. So if you proactively answer as many of them as you can or do all of the things that you can, like hey, I'm gonna schedule all my meetings in this three hour block every day. And I'm gonna, within that three hour block, I'm also gonna answer all the emails that people have sent me from the previous 24 hours. And I'm gonna get caught up on Slack. And then when all that stuff's done, shut all that off. stop walking around the office and chatting with people, put the headphones on and work on the next stage of whatever you're doing.

 

Yeah, so it sounds like you would you say you've mastered how to structure your day?

 

I mean, I know what works for me. I don't think that works for everybody, but my only advice to people is to figure out what works for you. Uh, I can tell you that I've met very few people that perform really well in software engineering or data science or ML who don't have any rules associated with their calendar, people that. We're like, yeah, I'll jump on a meeting whenever. I'll jump on a call or yeah, come on, come on over to my desk and we'll chat for a bit. Everybody that I've known that does stuff like that. are really unproductive people and usually create a lot of bad solutions to things. It's not because they're idiots, it's because they haven't had enough time to focus on thinking something through or implementing something properly because they're too busy chatting with friends or people were coming over to their desk or they're constantly on Slack all day long. You know, every time a new notification comes up, they jump right on it and answer it. And they want to be helpful. It's not, it's not willful disregard for quality work that they're engaging in. It's just, they probably haven't thought about how they work best.

 

Yeah, yeah, that's a great point. I know a couple of those types and they're usually team favorites because they're super helpful. They always are down to be a sounding board to drop whatever they're doing and help. But yeah, you're right. They at the end of the day, the people that can really focus and also really effectively context switch and context switch between context switching and focusing, those people tend to be more productive in my experience. Uh.

 

Yeah. And it really depends on what path your career wants. You want to take your career. So if you're going to stay in this industry, stay in, you know, either software or data science, um, and you want to make it so that, Hey, I'm going to do this for the next 25 years or 30 years. understanding how you as a person deal with that sort of, like, what are you good at? Are you good at context switching to important things, rapid fire and succession, and like to do that, helping people out and communicating about what the team's doing and being more on the, sort of the business operations side. Have a thought about how that is for you. and think about management. Like that's what management is in engineering. You're the voice in the face of a team. And... If you look at a calendar of any manager, it's just filled with meetings that are talking with people, managers from other teams or talking with executives and discussing plans and making sure that resources are all allocated and budgeted. So it's just extreme context switching all the time. Some people hate that and I've known and have been somebody who did that who then was like, yeah, I'm going back to tech. And then the other side of the coin is people that enjoy that. deep problem solving for extended periods of time, and they like building things. They may be good at doing the communication stuff, and if they're really good at communicating and they're really good technically, their career path is probably an independent contributor. You know, there's somebody that's gonna rise up to be. somebody very senior in the technical field at the company and a wealth of information for others and a mentor to other technical people. But.

 

Wait, Ben, do you know anybody like that?

 

There's some amazing people at Databricks that are like that. It's a treat whenever I get to talk to them. I'm not going to name drop or anything, but people probably know who these people are because they're very famous in the software world. But they're sort of paragons of, hey, they invented this thing, or they've built many, many things, and they're the go-to person for everybody. But if you look at their calendar, they wall off days at a time. If you try to invite them to a meeting, they usually decline, unless it's in these defined windows within their calendar. And they're very gracious. And that's something I recommend, too, if you're a senior technical person or an IC, put indicators on your calendar about when you're going to answer people's questions or let people know, like, hey. I'm not somebody who responds instantly to Slack messages or to email and people get it over time. They're like, oh, I shouldn't expect that they're gonna respond. And the only other bit of wisdom that I've found about that aspect, if you are a senior technical person, go out of your way to let people know that they shouldn't think that they can't approach you. So don't let them assume that, oh, I can't bother this person. You know, I slacked them yesterday and they didn't respond for six hours. I guess they don't care or they're so busy that they can't. That's not the case. It's they're probably structuring their day. I mean, I do it too. I, there's certain people that I'll respond to usually my immediate team members whenever they, they contact me or notify me of something, because it's usually important. Um, but other people from different. groups in the company, they might be asking me a question. And if I just answer those, whenever they come up, I'll never get my, my sprint activities done. So I have to defer all of that, but then let that person know like, Hey, I wasn't ignoring you. You know, I, I was focusing on this work thing at this time. Now I'm done with it. How can I help you?

 

Yeah, that's a great point. I think people tend to forget how unimportant their work is because everybody is doing work, everybody is focusing on their specific projects, and when you ping someone and they don't respond within 10 minutes, you're like, what the hell, they must hate me or they must think that this work is not high priority. Well, they have the exact same work as you and they think their work is more important than yours as well. down headphones on it makes a ton of sense that they wouldn't respond and sort of double clicking into the headphones on flow it just reminded me that just even yesterday I had like essentially three separate projects in flight that I had to deliver by the end of the day and These are my favorite days, maybe not three, but like maybe two projects, because there's a sense of urgency, a sense of pressure. And I'm like, all right, I got to get my game face on. And so some of these strategies might help you, but I'll just throw out what I did. So. I came in in the morning, had a meeting, and then that meeting prompted this ETL optimization work that I was doing. So each time I run that pipeline, it was a pretty massive job. It would take anywhere from one to four hours. So I needed to deliver something by the end of the day, and I had a maximum of like anywhere between three and five or more like two and five runs until the end of the day. So those iterations were super, super important. So what I did is I got out a piece of paper. On one side of the piece of paper, I had sort of a checklist for this ETL project. And on the right side of the paper, I had smaller things that I could do in between runs. So what I did is I created a checklist of, hey, did I write this code? Did I change this cluster configuration? Did I change this really important parameter? And I'm like, all right, I think this is it. Stopped for about five minutes. Is there anything else that I can do to optimize this run be more successful. After the answer is no, I kicked it off and then I context switched over to writing this blog post. And that sort of switching back and forth was really really effective. And a key point is the whole time I had headphones on, I was listening to the same music, and I was able to context switch with almost zero transition time. I sort of held two parallel streams and put one on hold as I switched to the other. And this is definitely something that takes practice, but also a key point for this is when you do leave a specific stream and go to another one, it's super, super, super important to like checkpoint or cache where you are. So I always leave a little bit of a note. And the thing that I've actually found most effective is having a, if I see this result, then do this. If I see this result, then do this. Because I know while I'm in a specific stream, the potential outputs. And if it, let's say the runtime or the job failed here, then I need to explore this area. If the job failed here, then I need to explore this area. And that really facilitates when I come back to the job to be able to essentially hit the ground running and go right into where I was. And I don't have to sort of relearn or spend time transitioning. So that is... Those are my absolute favorite days because you get like a week's worth of work done in a day and sort of the day just flies by and disappears and also flow when you're in that that headspace, it releases tons of endorphins will skip the cog sci component. But that can be really, really helpful if you do need to focus for that four hour block of time and deliver something.

 

Yeah, and double down on the taking notes. So it's a habit that I got into many, many years ago as well with like dear future me sort of things. I used to do shorthand notation for that, which is like, hey, kind of like what you were describing that if this happens, then do this, else do this, else do this. Over time, I started to change the way I was doing that when I'm learning new things or trying out something that's that I've never explored before. And I'll write a little bit more information so that I have my own notebook, my own lookup table for, hey, I'm trying to build thing X, it needs components A, B, and C, here's the things that I am going to test and why I'm going to test them, and then here's what I'm gonna do next. And then I'll write the results down at the end. So if I'm... If I'm architecting something like, hey, I need to build or provide guidance on how to build this thing that solves this problem, I'll have three or four different approaches that I might suggest or things to test out and try. And if I write down all of the results and all of the context around that, the next time that I have to look at something like that, I can sort of mark that page in my notebook. Like, oh yeah, I tried this before. that didn't work for that thing that I was doing that other time, but yeah, I already have a testing plan and all the ideas that I had done six months ago for this other thing, which, huh, that just saved me a whole day of research. I'll just try that. And a lot of times when I go back and do stuff like that, um, that actually works. Like that, that idea works for this new use case. Um, not so much anymore with what my job is now, but When I was doing consulting work in the field at Databricks, a lot of times I was doing stuff like that. Like, oh, we need real-time serving for this particular use case that uses XGBoost as an underlying model. How do we package that up and get 50 millisecond response rate at 10,000 requests a minute? Draft up an architecture, try it out, demo, mock it up, and use dummy data. might have three different things that you're going to test. Read out the results. And if you have effective notes, it could save you tons of time, even in ML project work.

 

Yeah, where are these notes stored? They're handwritten?

 

Oh yeah.

 

So you have binders on binders.

 

I got into the habit of not keeping all of them. I used to do that, but I started to think of myself as like a hoarder. So a lot of that stuff's been purged. And it's irrelevant. I mean, a couple of years ago, I had binders that were from my days, like right when I got out of the Navy. Like my first couple of jobs that's completely irrelevant to what I'm doing now. It was cool to look at, you know, years later. Oh, I remember working on that project. Huh. That's how you draw a vacuum in 0.3 seconds in a closed system with the turbo. Cool. But not exactly useful to work on MLflow.

 

Yeah, yeah, I mean, you never know. Vacuums are very important. But yeah, for those of you that are more digitally inclined, I use this thing called Roam Research. I consider myself sort of a note-taking head and have used a lot of the products. But Roam Research, worth checking out if you like notes in one line. So Ben, we're coming up on time, but can you give one tip about context switching, whether it be how to leverage it, how to avoid the negative components of it, any anecdotal evidence of effectivity, efficacy, whatever it may be?

 

I would just say control it for how it works for you and what your job is. Uh, cause if you don't control it on the one hand, uh, if you don't control it from the negative aspect of it, you're never going to get anything done very well, or you're going to stress yourself out. Uh, and if you don't control it from the positive aspect of taking breaks, you could be in the position that I can't speak for you, Michael, but I I've done it a number of times, work on a project for months, get it in a perfect state because I was in focus mode and working so hard and then to find out that the business is no longer interested in using the solution. They're like, yeah, this is cool and everything, but because you were taking so long, you said it was going to take six weeks. It's been three months. We came up with a different solution. We're good with that. Thanks for the work though. And you're like, what the hell? fine controlling it in such a way that makes you the most productive that you can be and That can just be thinking about how many times in a day Keep a log. I did that years ago. I had actually take a log of how many times I had to contact switch in my job and do it for a couple of weeks and just see like man I Ended up my work all the time because of email Alright, I'm gonna stop doing that. So

 

That's a great point. I a while back made it a rule that I can only check email twice a day. And suddenly I'm like twiddling my thumbs. I'm like, wow, all my work is done. And you can easily fill it up with reading the latest emails, but there's better uses of your time. I think my tip would be I think a lot of people struggle with the confidence to control context switching, like you said. It's really important to know that your team, and obviously this differs between organizations, but know that your team cares about your output. They don't really care how you do it so much. So try blocking off an hour of your calendar, see if that's okay with your team, then maybe hour and a half, maybe two hours, until you sort of reach that optimal point. From there, iterate and experiment and explore to see what works for you, because everybody's different. Like Ben works best from two to four. I work best right when I wake up. Like as I'm sipping coffee all the way until the coffee wears off, that is my prime time. And then after that, I use the afternoons and nights for more creative context, switching work where possible. So, customize to yourself. All right, I will do a quick recap. Hopefully this will give you some tips and tricks to leverage context switching in your life. So. We essentially talked about three different situations where context switching can be either helpful or harmful. In management, it's often helpful because you're able to work with reports that know less than you, so you can quickly bestow useful nuggets of knowledge. And if you're able to then provide a ton of value to those people, they can become unblocked and then be more effective. For innovation and productivity, it's often helpful to trade off between context switching and focus mode. switching between focus and diffuse mode of thinking. And this allows for creativity and allows you to come up with novel solutions. And then finally, on the learning side, there's something called space repetition. We didn't really get into it, but it's important to learn things and then remind yourself of them over time. Feel free to Google that. And then just some three tips, use paper. Both Ben and I love paper. There's some science behind actually handwriting brings thoughts deeper into your brain than typing. Also, it's really important to control your context switching. So block off focus time, block off time for context switching as well, and be intentional with it. Um, and then finally, just a code writing piece. This is something that I actually currently don't do that I will do based on this conversation. And that is write code and tests in parallel and slowly build a really solid framework instead of creating a wall of text and then having it potentially crumble. Anything else you want to add Ben?

 

Oh, he nailed it.

 

Beautiful. Alright, well until next time, it's been Michael Burke,

 

and Ben Wilson.

 

and have a good day everyone.

 

Take it easy.