337: Oh, Henry

We've got a tricycle anniversary! 🥳 Will it be ruined by a cockroach? Steph shares an update regarding some of the progress and discoveries that she's helped make with a client in regards to speeding up CI. Chris is finally getting a little bit more back into the code at work and finds himself riding another time management struggle bus. P.S.: Who even names these apps?!?! Children of Time Maker's Schedule, Manager's Schedule The Backwards Brain Bicycle - Smarter Every Day 133 Clockwise - Time Management For Teams One month on Analog Getting Things Done Bullet Journal Become a Sponsor of The Bike Shed! Transcript: STEPH: I have officially started recording. You are on the mic, friend. CHRIS: This is on the mic. Oh goodness. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, normally, I would say, "What's new in your world?" But this week, this day, in fact, is a very special day. Actually, technically, it's tomorrow. But did you happen to know that you have achieved your tricycle anniversary here on The Bike Shed? STEPH: No. [laughs] CHRIS: Three years. Three years ago tomorrow, Episode 196:I Can Be Wrong on the Internet, wonderful title for it, was released. That was the first episode where you were formally a co-host. You'd come on a few times before that, but that was three years ago. STEPH: That's incredible. Man, you totally got me. [laughs] You were switching it up for our intro, and our intro is very formalized. As you've said before, it is per your contract that’s how we do our intro. [laughs] CHRIS: Yes. STEPH: That is incredible. Three years. Wow. You know, I had thought about not the particular anniversary, but I was chatting with the Boost team earlier because I'm always encouraging people like, "Hey, write a blog post. What you just said sounds incredible. That would be wonderful as a blog post." And so I felt the need to convey like, I'm terrible at writing blog posts. I have written a grand total of two. I have a third one that's in draft state and has been that way for a long time, at least a month, I believe. And so, I am not great about writing and publishing blog posts. But I was like, but I could podcast. And so I looked up, and I was like, I know I've done around over 100; I think around 140 episodes. And so I was like, that makes me feel better. Those who can't write podcast. [laughs] CHRIS: I'm with you on that front, that she can just keep editing a blog post for forever. I actually do have some stats that I gathered for this as well. So like you said, you're close to 140 episodes. Let's assume an average of 40 minutes per. That gets us to around 5,000 minutes of audio or said differently; that's like 87 hours or 3.6 days. STEPH: Whoa. CHRIS: I know, right? STEPH: The hours really hit home for me. [laughs] CHRIS: Not the days? I like the days one. STEPH: No. The hours one, I don't know, the hours one resonates with me. That is something. That's very cool. CHRIS: 87 hours, yeah. Hopefully, in that time, I think we've said some useful things. STEPH: I was going to say as someone who started out as your co-host, and I was really certain I had nothing to say, I have 87 hours that documents otherwise. [chuckles] CHRIS: Indeed. And having been on the other side of the mic from you for most, if not the vast majority of those, you have wonderful things to say. It has been such an absolute pleasure getting to share the mic with you and talk about tech, and nonsense, and life, and all of the things. So yeah, thanks for coming on this adventure. STEPH: Well, that's very sweet. Thank you so much. And I appreciate you. And it has been amazing. It's been so fun to be your co-host. So I'm really glad that you convinced me to come on this adventure with you. Speaking of adventures, I have a very silly one that I'm going to start us out with. I want to tell you about Henry. You don't know Henry, so I'm going to introduce you to who Henry is. So we have moved into our new place in North Carolina, and I went to our bathroom to brush my teeth and get ready for bed. And when I turned on the water, out popped this giant cockroach that just came scurrying across the sink, and I panicked. And so I went flying out of the bathroom and hopped up on the bed because I'm an adult, and that's what you do when you encounter a cockroach. And I was like, okay, it's just a cockroach, calm down, which is funny. Like, cockroaches and spiders, I can't do. Snakes and mice totally cool with; I can handle them. But cockroaches and spiders are my fear. So then I was like, well, maybe if I name him or if I named them, this cockroach, then that will help, and I will be less scared of them. So I have named this cockroach Henry. And so now, when I go into the bathroom, I will often tell Henry like, "Hey, I need you to vacate. I'm coming in." And I reached over…it was a day or two later I reached over to get some soap, and then out pops Henry. Turns out naming them didn't help. I immediately ran out of the bathroom because [laughs] they are just so fast. Something moving that quickly just scares me. So I now have this ongoing battle with Henry. I think Henry is going to win, and I'm going to end up having to use the guest bathroom until Henry decides to vacate the home. CHRIS: Oh, Henry. Well, Henry wins this game. But I like that you tried, though, giving it a name. I will say I've actually had an experience very similar to this, and it worked in my case. So there's a really fantastic book series that I've read called The Children of Time I believe is the first one. There's the Children of Time and then The Children of Ruin. And then there's a third one coming out. It's by a fantastic author, Adrian Tchaikovsky. The first book, The Children of Time, was recommended to me by another former thoughtboter, Greg Fisher. It's just such a unique book. It's about spiders; just it's super-duper about spiders. Whenever I tell anyone this, they're like, "I don't like spiders." I'm like, "Trust me; I'm not a spider guy. That's not who I am." And yet reading this book, these spiders they've got personality. It's just fantastic. This author has such a unique voice and really does such a fantastic job of bringing to life a different type of intelligence, a different sort of point of view on the world and the universe, spiders specifically. And I found myself thinking about spiders differently. In the book, there are a handful of names for spiders. They're not specific characters in the book. It's almost like the names get reused for different representative spiders, which I realize I'm doing a terrible job of describing it. Everyone should read this book. It's utterly fantastic. But I found myself I would see a spider out in the world, and I'd be like, "Oh, that's Fabian. Yeah, no, Fabian is our friend," literally, this happened. There was a large spider that was living out on our deck, and I was like, oh, no, no, no, we have to protect Fabian. This is Fabian's spot now. Like, he's just chilling. He's killing some bugs that we don't want. Like, Fabian is our friend. And so this totally worked for me with that book. But I had to go to that level; just giving it a name would not have been enough. They needed to have a backstory, and a history, and all of that. But yeah, again, cannot recommend these books enough. STEPH: I really appreciate that I'm not alone in this approach and that it resonated with you as well. Okay. All right. So next, I will work on a backstory for Henry, and then maybe this will help. I also just need Henry to slow down. Henry is just…he's too fast. And so when he comes charging out of these hidden places, it scares me. [laughs] So I also need Henry to just be a little slower or a lot slower or to just go find another home. That would be great too. CHRIS: Yeah, I'll be honest; I haven't read a book about sentient cockroaches. I feel like, I don't know, maybe I could come around. But I was surprised by what happened with spiders, so... STEPH: Just the idea of that book, ugh. Okay, I'm going to move on. I'm going to move on. [laughs] CHRIS: It's so good. You have to read it. Here's the thing, like that feeling, what if that feeling got to go away and you could think about spiders differently? Because here's the thing, spiders are friends. Spiders are on our team. STEPH: Spiders I can handle. I'm into the idea of that book, but when you said a book about sentient cockroaches, that one just ugh. [laughs] CHRIS: Gotcha. Okay. All right. Okay. Sure. STEPH: So I appreciate you humoring my Henry story. But now, for my own sake, I'm going to move away from the topic of cockroaches. [laughs] That's what people came to listen to, right? So a story about roaches named Henry and spiders named Fabian. On a more technical note, I have an update that I'm very excited to share in regards to some of the progress and discoveries that Joël and I have made with our current client in regards that we're looking to speed up CI, interested in adding some more machines to then also speed up how quickly the tests run. And along that journey, we have also talked about tentpole. In terms of how we're splitting up and distributing that work right now, it's based per file. So for a tentpole, if you have a file that takes 10 minutes but all of your other files take 2 minutes to complete, then 10 minutes is the fastest that you're ever going to achieve because you have this one file that's holding everything else up. So we have manually addressed a lot of those files by splitting them out. So just literally taking like this 10-minute file and splitting it into three or four files, whatever we need to bring it in line with the other files. And that had some really positive results theoretically. So looking at the math, if we start with our current state, so we have 86 processors; this is on one machine. So on one machine, we have 86 processors with the presence of tentpoles, so we haven't manually split any files. It takes around 14 minutes for all of the RSpec tests to run. So that's around 560 minutes total of work that is then being distributed across these 86 processors. In theory, if we addressed all of those tentpoles and we could bring all the files down where they only take six and a half minutes to complete so everything is equal in that regard, we should be able to have the RSpec test complete in around eight and a half minutes. So essentially, the math behind that is we have 560 minutes' worth of work. We divide that by 86 CPUs. We added two minutes because there's going to be a little bit of like boot-up time and just maybe some other noise that's there. So then that brings us to around eight and a half minutes. The problem is we haven't seen that. We haven't gotten that low when we actually run the RSpec test suite. So we're seeing around more like 11 minutes. So it currently takes around 14 minutes. We've manually split files, and we're seeing more consistently that things are taking to 11 and 11 and a half minutes. And so we really paused because our next step is we want to automate how we address these tentpole files where we don't want to have to manually split files. That is just too brittle. It's very easy for someone to add to that file, and then suddenly it spikes back up, and it becomes the file that's holding up everything else. It's also really hard to split these files. I'm not going to go there, but this is one of my other gripes with shared examples. These files can be difficult to split because you don't exactly know what's getting run, and then trying to chunk them into different files is tedious and not an easy task. So we really don't want people to have to do that either or introduce metrics. We don't really want to do that, although we would around like, "Hey, you have now introduced some tests to this file. And it now exceeds the threshold that we're looking for in terms of how we want to make sure there aren't any tentpoles in the test suite." So to avoid a lot of those concerns, ideas, then we automate. So there are some tools that we could use. parallel_tests is the tool that we're using right now, but that's per file. There's another gem that I'd mentioned before called parallel_split_test that we have taken a look at that will then chunk them at smaller levels. I'm still not exactly sure how because even though I declared that I'm looking into that gem, we've gotten distracted with some other work. But there's parallel_split_test. There are also some other approaches. There's RSpec Queue. There's Knapsack Pro that will then split tests more at the individual example level, so then you don't have a bottleneck as to how long the file is. We don't care anymore. So we wanted to start looking into how we could automate using those tools. But now that we're not seeing the payoff from when we've done the manual splitting, we've now backed up to say, "Okay, before we invest in this automation, we really want to see this pay off first." So that's where we're at right now. And the mantra that has been in my mind as we're going through this is verify twice, automate once. And we've realized that we're just not there yet when it comes to automating. So to help us verify, before we go into automation mode, we are tracking the data in terms of we see how the tests are actually getting distributed across all the CPUs. We can see which tests were run for each CPU, and then we can see across which CPU how much work each process was given. And we're seeing that some of the processes are given more work, like maybe one process is given like nine minutes of work, but another one's only given like five minutes of work. But then, if we look at the individual tests that are being distributed, there's room. It's like, okay, well, why didn't parallel_tests then distribute some of these groups of tests over to this other CPU that only was given four minutes of work? And we see there's an opportunity because not all of those tests...it's like, well, maybe it's too big. They couldn't bring it over to the other CPU because then that would have pushed it to 10 minutes or something like that. But that's not the case because some of the test files are short enough where it's maybe like 30 seconds or maybe a minute. So it's like, it seems like a really good candidate that it could have gotten shifted to a CPU that has less work. The thing that we have discovered is we're analyzing two different things. So we are looking at the expectation. So we are providing to parallel_tests like, hey, in a previous run, this is how you split the test, or here's the runtime for every single file, so use this data to assign work to every CPU. Based on that data, then some of the CPUs weren't given more work because we expected that CPU to take longer to complete. But then, in reality, it took less time. So we're seeing that there is a variation in terms of how long a test file takes to run. So based on historical data, let's say we have like a controller test, and based on historical data, it took four minutes to run. But then, in actuality, maybe it took suddenly eight minutes to run, or maybe it took like two minutes to run. So we have this level of variation in how long a test actually takes to run that we can't achieve a perfect distribution because it's fluctuating so much. And that's why we're seeing in these graphs that we're creating around why one CPU has a lot more work than another CPU is because yes, based on historical data, this should have been distributed perfectly, but the actual runtime then of those tests has changed enough. That's why it looks like our distribution algorithm isn't working. And one of the ways we confirmed this is Joël took the parallel RSpec runtime log that is being generated from running that test (So that's the historical data that we're providing that shows how long each test takes to run.) and ran that through the parallel_tests algorithm, and it was perfect. Parallel_tests did a beautiful job of assigning those to all of the CPU. So we realized it had to be some fluctuation in the actual runtime that's then causing this concern. So I'm going to share some stats; a couple of these are a little scary stats where, for example, we have a test that could run anywhere between 6.4 seconds but has taken as long as 60 seconds to run. So when you have that level of variation in terms of how long the test takes to run, you can't begin to distribute the work perfectly because it's going to differ each time. And so now we're looking to understand what's causing that variation. Maybe it's real network requests that are going out that are then causing that fluctuation in timing. Maybe it's database contention in terms of some of those files are just creating a lot of records, and then sometimes it runs quickly, and sometimes it goes more slowly if there are a lot of other tests that are also running and hitting the database at that same time. Who knows? We have lots of interesting options to explore, but I know I've shared a lot. Hopefully, that painted a helpful picture as to some of the discoveries that we have made around how we're distributing this work. But yeah, I'm going to pause there. CHRIS: Oof. Yeah, that's an adventure. Partly, I think you're just making a great sales pitch for Knapsack because my understanding is this is exactly what their point of view and approach is; like, don't try and think your way out of this problem, just try and distribute the work on demand. Just in time distribution sort of thing of like, you got a bunch of workers, and each worker pulls off the queue. There's probably some intelligence to how to sort the queue like maybe you lead with feature specs or the things that have the highest variance put them earliest in the queue such that at the end, you're getting a very deterministic distribution such that you get nice and even performance across them. But nonetheless, Knapsack Pro seems like a very good thing. I'm intrigued by it for our usage as well. But I'm super intrigued by something that can vary by 10X, 6 seconds versus 60 seconds is just so interesting. Like, are these features-specs first of all? Because that's the only thing that could make sense. If this is a model spec and this is happening, I'm like, wow, what? A feature spec, maybe. But even then, it's still surprising. STEPH: So I haven't dug into the specifics of that file. There are some other files that also have some scary stats. So that is next on my list to figure out how that variation is taking place. I don't think it's a feature spec just from glancing at the title of the file. But I'm also intrigued. CHRIS: Huh. Like, the feature specs is one standout that could make sense to me because, inherently, there is waiting. There are wait characteristics in feature specs. And so they can have you stack up enough of those waits for each of the sort of like find, assert, look for, fill in, et cetera. Each of those can have a couple of seconds attached to it. But other stuff is...even a feature spec; it's surprising to take that long. Anything else is super surprising. A couple of things stood out to me otherwise on what you said; the verify twice, automate once I love that. The general sort of the follow-up, if nothing else, of did that thing that we thought might make a change actually do it? Is it impacting in the way that we expected? Are our assumptions being validated? There's a wonderful blog post that I read a while back that just sort of named an idea that has stuck in my head; it was called Calling Your Shot with TDD. I think I'm misrepresenting the title. But it was something in that space where TDD as an approach is a way to be like, I think I have a mental model of how the system works, and I'm now going to write a test that constrains to that behavior, and then we go from there. And TDD as a practice represents a certain sort of specific example of this. But what you're describing of like, well, we made this change. Did it produce the outcome? Or it's so easy to do this with performance optimizations of, oh yeah, an N+1 query. Let's fix that, and then the page will be better. And it's like, is it actually, though? In some cases, in most cases, fixing an N+1 will improve performance. But will it improve performance in a useful amount? Or is it the limiting factor in terms of the performance fixes? And so having that habit and that muscle of having the hypothesis, making the change, and then verifying that you get the expected result is so, so critical. And just sort of going through that loop is so important. It's interesting to hear that you're like, we had some ideas. And then we tried some stuff, and we're not super-duper seeing what we expected is...yeah, you're doing the work there if nothing else. STEPH: Yeah, we have found on this project that it's really important that, as you said, to call your shot in terms of like, what's the math telling us in terms of what we think is achievable versus what are the actual results that we're seeing? And then verifying it. And I feel a lot better because before, it was just like, we don't know why this isn't paying off. We thought that splitting up these files would totally pay off, and we would drop from 14 minutes to suddenly eight and a half minutes, and it was going to be beautiful. And we didn't get there. Why is that? And so this journey has helped me feel a lot better in regards to we have more of an understanding as to why, and it's because we validated that parallel_tests is doing a great job in terms of distributing the work across each of the processes. But because there's that variance in the test files, the algorithm can't begin to then manage that. I mean, there's if you have your data kind of lies to you in terms of what you think is going to run versus what actually may run, then we're always going to have this poorly distribution of work. And so then the next step is, do we actually dig into understanding more of like do we want to look at those files specifically and address that concern? Or do we want to go ahead and take that leap of faith over to Knapsack Pro? Because that's what paused us from moving on to something bigger to then automate how we distribute work Maybe since we now understand why we didn't see the payoff, we feel more comfortable taking that leap of faith that we will still see the payoff once we hand this off to a different process. And we're actually breaking it up per test or per example versus per test file. We may see less variation. Maybe that's not true. Maybe there will actually be some examples that still have a high variation, but at least it won't be grouped as an entire file, so it may get a little better. There's also the fun idea...I'm going to categorize this under the good idea, bad idea area. CHRIS: I think I go good idea, terrible idea, just to be clear [laughs] but. STEPH: I like it. All right. Yeah, good idea, terrible idea. So for this, one of the ideas that came up was, what if we try to finagle some of this just to still see some of the reward? Because there's part of us that we just want to see it pay off. Like, we've put a lot of effort into this. We want to see something get faster. And it's like, well, if we know there's some variance with these files, what if we had those files, like, we added to them in terms of instead of parallel_tests ever thinking that this test could take as few as six seconds, we just say, "Nope, we know this file is always going to take more somewhere in the middle," so to then improve our distribution. And that way, there's not such a high variance of maybe the historical data will show that it took 10 seconds, but then the next run it takes more like a full minute. And in this case, we're just like, no, you always take a full minute, or you always take 30 seconds. That might even out some of the distribution. That was one of the fun ideas that came up in terms of how could we help improve the distribution? I don't think we'll actually do that because that seems like unnecessary work and then has to be managed and justified and documented somewhere. And there are concerns that go with that. But it was still fun to brainstorm of, like, we have this thing. How do we want to do a better job of distributing between the actual work, tricking it, and then moving to another service? CHRIS: I vote I'm team tricking it just to be clear but nah, probably not. Looping back, there is one other thing that you said in there that really stands out to me is there's a moment as you're looking through all this data, like, A, again to highlight the important work of measuring and actually validating that your hypothesis and procedure and everything's doing what you expected. But then there was that moment of huh, that's weird, which is that is like a quote. That is an idea. That is a feeling; huh, that's weird. And whether or not you pursue it is such an interesting space to be in because a lot of the time, the work that we're doing has little bits of huh, that's weird. And do you pursue it, or do you not? Do you ignore it? And you're like, oh, that bug report is interesting. That could be a gigantic problem in our system, or it could just be a noisy network connection. I don't know. As I think about the spectrum between folks very early in their career and senior developer as we try and think about what that means, this is one of those spaces that becomes really interesting to me. How much stuff...like, how deep is your understanding of all of the different things that you're working on such that most of the time, you have a mental model, and then the system behaves roughly in accordance with your mental model? I think very early on in your career; I remember when I was starting out, I was like, I don't know how anything works. This is fun. I type some stuff. It works some of the time, and this is great. And slowly, over time, my knowledge and experience grew such that most of the stuff that I was doing fits within my mental model. And then every once in a while, there's those huh, that's weird moments, and do you pursue them or do you not? Do you put them on a list to follow up on later? Just, like, that judgment point becomes a really interesting variation of what you know and don't know. And so, just the way you described that was interesting to me because it reminded me of that sort of conceptual space. STEPH: I like that a lot because, yeah, that's constantly the space that we're in. And one of the things that I find so interesting about these kinds of Rails rescue or working with legacy code, I mean, I'm sure they apply to newer projects too. But there's a goal that you have in mind. And when do you recognize that you need to shift the goal, or you need to stick even more diligently to that goal? And we're in that space of where we're constantly reassessing; this is our goal to speed up CI. Do we need to break for a week or two to then improve some of these tests concerns that we see? Or is this one of those times where we need to ignore that and acknowledge that it's a thing and be glad that we know about it but then really stick to our goal of speeding up CI and then moving forward with pulling in a service like RSpec Queue or Knapsack? One of those. And I agree; I think that's incredibly interesting. And I like having those conversations of how do you decide what's the next best goal or a path to pursue? In my case, I often use timeboxing as my way to get around it where it's one of those okay; we have this idea. So like, I would like to timebox a couple of hours to look at those files to see. Because then I can collect more data to be like, how obvious is this as to why we have this fluctuation and how long it takes this test file to run? Is it because we're making a real network call? Is it that obvious? Or is it something that's a bit more murky, and it's going to take a lot more time for us to then triage? That is typically the tool that I will use that if I'm still not sure between two decision points, I'm like, okay, well, let me timebox and collect a few more data as if I'm pursuing this direction and then come back in a couple of hours to then reconsider which path I want to go down. I will keep you up to date as to which way we pursue, and yeah, I'll let you know how it goes. But that's most of what's going on in my world. What's new in your world? CHRIS: What's new in my world? This week I've been getting a little bit more back into the code. We've just got a bunch of work to do. And so I've been trying to move from more of the defining the work thinking about it into actually writing some code, as it were. And it has been harder than I expected, and I've been surprised by it. And specifically, what I mean by that is I have spent a lot of my time over the past handful of weeks more in the conversation, planning, negotiating, management-y type space. So we have a lot of different integrations that we're trying to work on. So many of the things that I'm doing are having meetings with the external companies and talking through those integrations and what does that look like? And what features do we need? And what's the contract going to look like? Yeah, interesting, fun little things, maybe not my favorite stuff in the world, but that's fine. It needs to happen. It's critical work. But at this point, I'm now ready to move back in and actually start writing some code. It was odd to me as I was struggling more than I expected to to get back into the code. And then it kind of clicked back in, and I was like, oh no, wait, the work was too nebulous, and I couldn't find an angle of attack. Where do I start with this big, amorphous...like, build the integration for system X. I was like, I don't know how to do that. And I was kind of like, you know, like a kid rolling around the peas on their plate and not actually eating any of them sort of thing. I was just like, well, or I could... It was weird. It was almost like in a dream where your legs don't quite work. I'm using a lot of analogies today, but that's fine. You think you can run. You're certain you knew how to run at one point in your life, but your legs just won't work. It was a little bit of that. And then I sort of snapped back in, and I remembered. I was like, oh, just break it apart into little pieces, write a checklist, sort that checklist by the things that make sense to you, start with the first one, and then work through it. And it came back. But there was this very odd moment where I didn't know how to do the work anymore. And it was like, that was scary. Yeah, it was weird. STEPH: I find it so heartwarming that someone who is as skilled as you are and experienced as you are that you still can have those moments of like, there's this really big task in front of me, and I'm not entirely sure how to do this. And then I love that you fell back to sort of that what's my systems approach and to like, how do I solve big, murky problems? And that is to start with creating a list of some of the things that I know to do to move this forward and then organizing those. I love that story. CHRIS: It's funny you mentioned timeboxing a minute ago, and I was like, yeah, right. That's another of the tactics that I use. And there's this whole toolset that exists, but it exists largely for me in the implementation side of the work that I do. And the other side, the conversations, and the planning and all of that, they really feel like these very distinct spaces. There's the Maker Versus Manager Schedule article by Paul Graham. And really, it's interesting to me to experience how I'm moving across what feels like a wider gap. Like, I've bounced from the frontend to the backend a lot, or from I'll do some product management planning sort of stuff, and then I'll get back into the work. And somehow, that has all felt more cohesive and consistent. And yet the nature of this work is sort of I'm finding that as I go back and forth between the two different sides, too, is also probably reductive. And there are probably like nine different ways in which this thing gets sliced up. But as I'm bouncing between the different facets of my work, it's been trickier. And so it was useful to just recognize that and to recognize the fact that I was able to click back in. There's a really fantastic video on YouTube. It's by...I believe the title of the channel is Smarter Every Day. It's this guy Destin who talks about different ideas and mechanical things and whatnot. But at one point, he built a bike that was backwards. And specifically, the way that it was backwards is your handlebars; when you turn your handlebars to the right, your front wheel turns to the right, when you turn to the left, your wheel goes to the left. So it's a very direct connection. He made a bike that was reversed such that when he turned the handlebars to the right, the front wheel would turn to the left. And obviously, he could not ride this bike. This is an impossible bike to ride for a person who has learned to ride a bike under the normal circumstances. But he battled, and he fought, and eventually, he tricked his brain into learning how to ride this new bike. But then he couldn't ride a regular bike. And there's actually a video of it. He describes the experience of trying to ride a regular bike and how it became this other foreign thing. And yet, at one point, his brain just clicked back in, and suddenly, he knew how to ride a bike again. And the people that were watching him thought he was pretending or something; really fantastic video. And it speaks to this sort of thing. There are modes of thinking and ways that you're operating, and it sort of felt like that. If you watch this video and you go to the end where he's in Amsterdam, and he has to try and ride a regular bike, and it clicks back in, that's what work kind of felt like for me this week. So I'm going to stop stacking analogies on top of each other, but that's sort of where I'm at right now. In a way, it's been fun. STEPH: Well, to be fair, your analogy of pushing the peas around on the plate, I could just see it. [laughs] I think that was a really good analogy for me that really resonated. I loved that one. I haven't seen that video. That makes a lot of sense to me. I think it does. I don't know. If someone was like, "Can you ride a bike with backwards handlebars?" I probably would have been like, "Sure," and then totally failed. I can't recall if we've talked about this before, but in everything that you're sharing, it made me think about the context switching in regards to how my schedule has changed where before, I have my one on ones, and then I also have client work. And then I was interstitialing a lot of those one on ones with client work. But now I have three days that are dedicated to client work, and I have one day that is dedicated to the Boost team, and then I have Friday for investment days. And that has been huge for me. I didn't realize how exhausting it was for me when I was switching context so much because then there's also some prep work and a little after work that goes with each one on one. And then just knowing that I had it and I had to make sure I budgeted time for that each day in addition to the client work. But then once I shifted to like, I have a day to just focus on this particular...like, my brain can click in to like, this is the mode I'm in. I am totally focused on my team and being a good team lead and having one on ones versus I am totally focused on I can just work on code and work on some of those gnarly problems. That has been a really big shift for me and something that I just can't unsee now to realize how stressful it was before and how I feel like I wasn't doing as good of a job. But now, I feel really good at the end of each day that I was in a particular mode, and I was more productive because I was focused on that mode. CHRIS: Yeah, absolutely. The phrase "click in" there I love that as a mental-physical sort of representation of the thing. There's a friend of ours and former guest on the show, Matt Sumner, has recommended a piece of software to me a few times, which is called Clockwise. And Clockwise does an interesting thing that I feel calm. I've not yet pursued it because I think there's sort of a...well, anyway, the thing that it does is it rearranges schedules to try and push meetings together such that you have larger gaps of heads down deep work focused time. I love that idea. I absolutely love it. But I think it's really interesting to like; I believe very strongly as a manager in not rescheduling one on ones with my teammates. I want to make sure that that time is protected, that to them, it's very clear that we have this time. This is the space that we've carved out to have these sorts of conversations. I'm more okay with them switching it on me. But I think it's very important for me to not change that out on them or to not reschedule at the last minute. And so I'm sensitive to just juggling around the meetings. But I love the idea of this thing of let's just try and squash all the meetings together. I'm happy to just have like three hours straight. I'm in that mode. That's the I'm thinking about people and process and all of that kind of stuff. And then I break, I have lunch, and I come back in the afternoon, and the afternoon is entirely clear. And that's heads down working time or vice versa. I'm actually more of I would like to have my mornings entirely clear, and that's where I do my heads down thinking work, precious brain, all that kind of stuff. And then in the afternoon, I'd prefer all my meetings. I don't necessarily want the world to entirely go around my preferences for meetings, but if it happened, it'd be fine. But Clockwise is a really interesting sort of technical solution to this problem that I've yet to pursue, but I'm intrigued by. STEPH: I'm intrigued by this too because I did this just today where I was going through, and I was updating my schedule. And I do this on my own. I am my own AI in this case where I'm thinking through, like, okay, I want to stack meetings together so that I don't have these awkward like 15-30 minute breaks, and then I still have more of a big chunk of focus time. And so, I am manually doing that for my schedule. And I would be intrigued to see what software would recommend...they could show me a pattern that I hadn't considered that works better for me than the version that I have. The flip side is I've also learned to just be really good with, like, I have 10 minutes. Well, let's look at my to-do list, and what can I push along for 10 minutes? That is the other thing that having a tight schedule has helped me get better at is where even if I only have 10 minutes, before, I might have been like, oh, that's not enough time to do anything. Totally a lie. Ten minutes is great. Ten minutes you can totally take a look at something and then make a comment, or read it, or just have a little more context and nudge it along. I love the nudge it along approach versus the I have to sit down and get it done approach. On this particular theme of context switching and productivity, I have a question for you. I was debating as to whether I was going to share it or not because I feel like it's still hand-wavy enough. I'm not sure I'm going to do a great job asking this question, but I'm going to go for it. I am looking for a way to manage not just the things that I have to do each day but some higher goals. So I really like the idea of themes. So I love when a week has a theme, a month has a theme. These are the things that I'm focused on. So then, when I do have like these 10-15 minutes or this focus time, I know there's a particular theme that I'm pursuing, maybe it's more technical related, maybe it's more mentorship, or it's something I'm interested in pursuing. But I know it's going to take a couple of iterations to work on. And I haven't found a really good way to capture those themes. Right now, if I have something like I know I'm meeting with someone on Friday and we have a goal that we're going to collect some examples of this topic, so then what I am currently doing is for my calendar is I'm setting a daily reminder each morning to be like, hey, just so this is like simmering in the back of your mind, don't forget about it. Collect some examples about this topic. So it's one of those if I happen to see something; I want to be able to grab it and remind myself, like, hey, you're looking for this. But it's been okay. I haven't loved it. And so I'm just in that space of where I'm trying to find a way of how do I capture the theme that I'm working on for a week or for a month but still keep that in line with my to-do items and my calendar and still ideally keep it all together? I don't want to have so many disparate places I have to go look to understand all the things that I'm focused on. Do you have any thoughts? Do you have a system for how you manage or even think about things in that space? CHRIS: Oof. You've opened Pandora's Box here. STEPH: [laughs] CHRIS: I have some thoughts. What you asked, I think, is an incredibly deep question or one that there's no singular answer to this sort of thing. And the answer is specific to the person, and it's an evolving thing. Like for me, I have explored this space, personal productivity, and how to think about the bigger goals and all of that. I've explored it a lot. And it's evolved, and each phase of my life has a slightly different answer to how I think about this. Also, to be clear, sometimes I say stuff, and it sounds like I know what I'm talking about or I've thought about this. And I'm like; I got it; I do not have it. This is a I do not have this one on lock. I'm constantly trying to solve this problem. I think the first thing that I'd go to is Getting Things Done book on personal productivity. It's the most sort of impactful or foundational in my thinking about how to look at this. And in particular, it has some ideas around the different levels at which we think about our work. There's like the day-to-day actions, and there are projects and areas. And it's a little bit formal, frankly, in my opinion. But it does introduce the idea of the weekly review. And I think that structure that's one of the things that has been true for me throughout all of the different variations of tools, and approaches, and productivity whatnots. But the weekly review being a really useful time to sort of take a step back and think about things at a slightly higher level to make sure that you're staying connected to bigger goals and whatnot. The other thing that comes to mind as you say this is Dave Rupert, another person who has been a guest on the show, has written a couple of times about his analog productivity system. So there's this...I think Ugmonk is the name of the cards, if I'm remembering correctly. But they're little index cards, basically, and you basically rewrite them every day. And it's this very manual, almost meditative, but very focused practice. It's vaguely similar to bullet journaling, which is another approach. But each of them have this structured way in which you look at the work that you're doing. And I think there's a good opportunity in both of those systems, either the analog productivity thing that Dave Rupert does or bullet journaling to be like, this is where my goals go, and so these are the goals for the week, and they're written at the top of the page, and then everything else goes underneath that. But you always have top of mind and very visible the goals that you're going towards. And so it's things like that that have been my answer to this of like, I need to find somewhere within the system that I'm working in to have the overarching goals be present and accounted for. That's tricky. And analog actually seems to be a really great way to do it, just like pen and paper is a great solution. So even if you're using a system like Todoist, then maybe your daily structure is written on a piece of paper such that at the top of it, you write those things that are true for the week, or they're on your iPhone, desktop, or whatever, that's not a thing. They're in like a widget on your iPhone screen or on your computer desktop or something like that. But you keep them top of mind. You find some way to do that such that you're constantly anchored to the things that you say or the big rocks that you want to fill the sand around. STEPH: I really like that book, Getting Things Done. I read it a long time ago, so that would be fun to revisit and see if I get any new bits of knowledge that are helpful for me. I like the idea of that more manual task of writing things down. I have found that to be very helpful for me because I am someone that I really like to have as little screen time as possible. So if I can have my to-do list away from my screen, that's really nice. But then I also just recognize that there's a nicety to having it stored in an app. So then that way, it is shared across devices, and I can see it at any point. And it's stored somewhere, and I don't have to try to reread my messy handwriting. There are benefits. But I think you highlighted the thing that I'm looking for, which is in Todoist or something similar. Right now, I have these discrete action items, and I would love if at the top...I've done this with Trello boards before where a team is working on a particular experiment or trying something new that for that iteration, we make a ticket and then we will label it something, some bright, pretty color, and then just keep it at the top of to-do and then each day we walk the board. And it's a friendly reminder of, like, hey, this is our theme for this iteration. Here's a friendly reminder. I would love something that's like that where it's like, hey, this is your theme for this week, or this is your theme for the month; here's a friendly reminder. And I think I'm going to see if there's a way I can do that with Todoist to keep things on the same space even though I don't think it's really built to support something like that. But I'm going to check it out. And there is a boards feature in Todoist that I haven't leveraged. So maybe if I, instead of doing the ordered list view if I do the boards view, then I could do what I just said with Trello in terms where I have a card that stays there for the week and reminds me of a goal that I'm working on or a theme that I'm working on. Cool. That was helpful, thank you. But yeah, I've been in that space of trying to figure out how to capture goals. So I appreciate you sharing those ideas with me. CHRIS: Oh, I'm always happy to talk about this. If anything, I've been trying to be somewhat reserved so that every episode of the show isn't me talking about my continuous search for a new productivity tool. I'm still in Things. I'm not super happy about it. I keep looking at TickTick. I want Todoist to work, but it doesn't. OmniFocus calls to me. I have a note on my phone with the list of features that I want. And I keep telling myself over and over, you're not allowed to write your own software for this. And thus far, I have successfully avoided once again writing my own productivity and list management software. [laughs] But I don't know how long I can hold out. STEPH: As you list the names for the different apps you're using, like, what was the first one? CHRIS: Things. STEPH: Things. Thank you. CHRIS: OmniFocus, TickTick. What else? There's plenty more that I've looked at, [laughs] Todoist. Yeah. STEPH: Yeah. As you're listing all of those, that reminds me that I have decided that I think people who name apps and startups are also the same people that name baby items because I've joined a mother's group. So another thoughtboter, Elaina, runs a really wonderful group of where moms get together once a month, and we just chat about all the mama things. And they were helping supply some recommendations. They were like, "Do you know what stuff you need to buy?" And I'm like, "No. Please, please tell me. What am I going to need?" But they're having this conversation around like, "Oh, you've got to get the Björn bouncer, and the SNOO, and the Cuzzle Wuzzle, and the Bippity Bop, and the like...all these things. I'm like, "I'm going to need y'all to use different terms because I have no idea what you're talking about." [laughs] And that is also, I think...yeah, that also goes with people who are naming things like TickTick and Things, naming those apps. CHRIS: I'm also going to need you to spell them because many of these are not phonetic or broadly, the English languages and phonetic, the BabyBjörn, you know, that sort of thing. To do but T-E-D-E-A-U-X, I think, is one of them. It's like, come on, what are we doing here? [laughs] So yes, it's complicated out there. STEPH: All I can think of is anytime someone's like, "Come on," all I can think of is that Peter Griffin clip where he's like, "Come on," and he's trying to get people to agree. I feel like that's some of the...that's my reaction when I read some of these [laughs] or some of those names where it's like, you're just trying to trip me up. But yeah, startups and naming baby items. CHRIS: That's what this podcast is about. STEPH: That's what it's all about, and cockroaches and spiders. [laughs] And I'm going to stop myself. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at [email protected] via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed