Podcast appearances and mentions of josh clayton

Steve, Darren, Josh & Clayton taste the new Cathedral French Oak from Bardstown Bourbon Company's Distiller's Reserve Series. TBD music is by Kevin MacLeod (incompetech.com).   Important Links: Patreon: https://www.patreon.com/theabvnetwork Our Events Page: bourbonpalooza.com Check us out at: abvnetwork.com. The ABV Barrel Shop: abvbarrelshop.com   Join the revolution by adding #ABVNetworkCrew to your profile on social media.

Steve, Darren, Josh & Clayton taste the new Cask Strength Wheated Bourbon from Green River at the ABV Barrel Shop's tasting bar. TBD music is by Kevin MacLeod (incompetech.com).   Important Links: Patreon: https://www.patreon.com/theabvnetwork Our Events Page: bourbonpalooza.com Check us out at: abvnetwork.com. The ABV Barrel Shop: abvbarrelshop.com   Join the revolution by adding #ABVNetworkCrew to your profile on social media.

Deacon Josh Clayton says that small, consistent habits, like putting the lid on toothpaste, can help us reflect the value of structure in life. Dcn Josh draws a parallel between this and the spiritual practice of structured prayer, reading scripture, meditation, emphasizing that routines and discipline can foster personal growth and a deeper relationship with God

My guests on the podcast this week are most-hyped (and deservedly so) hardcore band SPEED. We talk about their dedication to the Australian Hardcore scene, how NOT to act at a show, their collaboration with Nike, and much more. Insane band. Check them tf out. Learn more about your ad choices. Visit megaphone.fm/adchoices

My guests on the podcast this week are most-hyped (and deservedly so) hardcore band SPEED. We talk about their dedication to the Australian Hardcore scene, how NOT to act at a show, their collaboration with Nike, and much more. Insane band. Check them tf out.

Deacon Josh Clayton says that while life includes hardship and uncertainty, reading the Bible reminds us that life brings challenges, but God's promises provide hope and strength to persevere.

Deacon Josh Clayton reflects on the challenges of supporting a child during stressful academic periods, such as the HSC or university exams that occur this time of the year.

Deacon Josh Clayton says that by focusing on acts of kindness and reaching out to those in need, we align better with Christian values and overcome our selfish tendencies.

Deacon Josh Clayton says that it's good for us to encounter new people, to hear about the ways that God has worked in their lives

Deacon Josh Clayton says that we need to set up good spiritual routines to complement our lifestyle routines such as routines for expanding and growing our understanding of God, prayer time, reading scripture, and reading books that help understand faith and who Jesus is.

The Bush Deacon–Dcn Josh Clayton–Country Shows (Deacon Josh notes that we are in country show season in the leadup to the Sydney Royal Easter Show. Josh says that country shows are renowned for their hospitality, bringing the community together to celebrate and promote the many activities of the local area. Among the strengths of the country show is the ability to welcome the newcomer, celebrate achievements and recognise and respect the difficult times since the last show. This makes Deacon Josh think about our own faith communities and how we welcome the stranger as well as the old-timers, support each other by celebrating achievements and acknowledging the difficult circumstances, and maybe our church communities can learn a lot from how we celebrate the local agricultural show so we can also be a grand-champion parish community this Easter.)

The Bush Deacon–Josh Clayton–Evacuate (After several recent safety exercises on evacuation, Deacon Josh has been thinking about one of the challenges of evacuating, having to leave behind stuff that not needed. That caused him to think about what's the most important thing you have? What's the thing that you couldn't bear losing? The challenge for each of us is to not become too fixed on goods, our possessions, but what are the relationships that we couldn't bear to leave behind? Those key people, those people we know and love, our family, our friends, and faith community. All of these people can be challenging, but it's also essential for us to remember the importance of those around us, not just things, but the people who form our relationships.)

The Bush Deacon—Josh Clayton—Library (Deacon Josh has been thinking about the books, the resources, the things in your life that you consider important, and the things that you have used and experienced as a way of growing and developing as a person and even the books that you no longer see because they've been hidden behind other books. What about those books that can help me to grow in my relationship with God and with others. Do you have multiple Bibles? Different translations, different footnotes to help you understand more fully the message that is present in our Sacred Scripture. What are the books that you see as key to who you are and forming you into the person that God wants you to be? Books that will challenge you to grow.)

Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests. Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition. Ruby class instance variables (https://www.codegram.com/blog/understanding-class-instance-variables-in-ruby/) Build vs Buy by Josh Clayton (https://thoughtbot.com/blog/build-vs-buy-considerations-for-new-products) Sustainable Rails (https://sustainable-rails.com/) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: My world has been kind of frustrating recently. I've been fighting a really frustrating bug where I'm integrating with a third-party database. And there are queries that just straight-up crash. Any query that instantiates an instance of an ActiveRecord object will just straight-up fail. And that's because before, we make the actual query, almost like a preflight query that fetches the schema of the database, particularly the list of tables that the database has, and there's something in this schema that the code doesn't like, and everything just crashes. Specifically, I'm using an ODBC connection. I forget exactly what the acronym stands for, Open Database connection, maybe? Which is a standard put up by Microsoft. The way I'm integrating it via Ruby is there's a gem that's a C extension. And somewhere deep in the C extension, this whole thing is crashing. So, I've had to sort of dust off some C a little bit to look through. And it's not super clear exactly why things are crashing. So, I've spent several days trying to figure out what's going on there. And it's been really cryptic. STEPHANIE: Yeah, that does sound frustrating. And it seems like maybe you are a little bit out of your depth in terms of your usual tools for figuring out a bug are not so helpful here. JOËL: Yeah, yeah. It's a lot harder to just go through and put in a print or a debug statement because now I have to recompile some C. And, you know, you can mess around with some things by passing different flags. But it is a lot more difficult than just doing, like, a bundle open and binding to RB in the code. My ultimate solution was asking for help. So, I got another thoughtboter to help me, and we paired on it. We got to a solution that worked. And then, right before I went to deploy this change, because this was breaking on the staging website, I refreshed the website just to make sure that everything was breaking before I pushed the fix to see that everything is working. This is a habit I've picked up from test-driven development. You always want to see your test break before you see it succeed. And this is a situation where this habit paid off because the website was just working. My changes were not deployed. It just started working again. Now it's gotten me just completely questioning whether my solution fixes anything. The difficulty is because I am integrating [inaudible 03:20] third-party database; it's non-deterministic. The schema on there is changing rather frequently. I think the reason things are crashing is because there's some kind of bad data or data that the ODBC adapter doesn't like in this third-party system. But it just got introduced one day; everything started breaking, and then somehow it got removed, and everything is working again without any input or code changes on my end. So, now I don't trust my fix. STEPHANIE: Oh no. Yeah, I would struggle with that because your reality has come crashing down, [laughs] or how you understood reality. That's tough. Where do you think you'll go from here? If it's no longer really an issue in this current state of the schema, is it worth pursuing further at this time? JOËL: So, that's interesting because it turns into a prioritization problem. And for this particular project, with the deadlines that we have, we've decided it's not worth it. I've opened up a PR with my fix, with some pretty in-depth documentation for why I thought that was the fix and what I think the underlying problem is. If this shows up again in the next few days, I'll have that PR that I can pull in and see if it fixes things, and if it doesn't, I'll probably just close that PR, but it'll be available for us if we ever run into this again. I've also looked at a few potential mitigating situations. Part of the problem is that this is a, like, massive system. The Rails app that I'm using really doesn't need to deal with this massive database. I think there's, you know, almost 1,000 tables, and I really only care about a subset of tables in, like, one underlying schema. And so, I think by reducing the permissions of my database user to only those tables that I care about, there's a lower chance of me triggering something like this. STEPHANIE: Interesting. What you mentioned about, you know, having that PR continue to exist will be really helpful for future folks who might come across the same problem, right? Because then they can see, like, all of the research and investigation you've already done. And you may have already done this, but if you do think it's a schema issue, I'm curious about whether the snapshot of the schema could be captured from when it was failing to when it has magically gotten fixed. And I wonder if there may be some clues there for some future investigator. JOËL: Yeah. I'm not sure what our backup situation is because this is a third-party system, so I'd have to figure out what things are like in the admin interface there. But yeah, if there is some kind of auditing, or snapshots, or backups, or something there, and I have rough, you know, if I know it's within a 24-hour period, maybe there's something there that would tell me what's happening. My best guess is that there's some string that is longer than expected or maybe being marked as a CHAR when it should be a VARCHAR, or maybe something that's not a non-UTF-8 encoded character, or something weird like that. So, I never know exactly what was wrong in the schema. There's some weird string thing happening that's causing the Ruby adapter to blow up. STEPHANIE: That also feels so unsatisfying [laughs] for you. I could imagine. JOËL: Yeah, there's no, like, clean resolution, right? It's a, well, the bug is gone for now. We're trying to make it less likely for it to pop up again in the future. I'm trying to leave some documentation for the next person who's going to come along, and I'm moving forward, fingers crossed. Is that something you've ever had to do on one of your projects? STEPHANIE: Given up? Yes. [laughter] I think I have definitely had to learn how to timebox debugging and have some action items for when I just can't figure it out. And, you know, like we mentioned, leaving some documentation for the next person to pick up, adding some additional logging so that maybe we can get more clues next time. But, you know, realizing that I do have to move on and that's the best that I can do is really challenging. JOËL: So, you used two words here to describe the situation: one was giving up, and the other one was timebox. I think I really like the idea of describing this as timeboxing. Giving up feels kind of like, defeatist. You know, there's so many things that we can do with our time, and we really have to be strategic with how we prioritize. So, I like the idea of describing this as a timeboxing situation. STEPHANIE: Yeah, I agree. Maybe I should celebrate every time that I successfully timebox something [laughs] according to how I planned to. [laughs] JOËL: There's always room to extend the timebox, right? STEPHANIE: [laughs] It's funny you bring up a debugging mystery because I have one of my own to share today. And I do have to say that it ended up being resolved, [chuckles] so it was a win in my book. But I will call this the case of the leaky stub. JOËL: That sounds slightly scary. STEPHANIE: It really was. The premise of what we were trying to figure out here was that we were having some flaky tests that were failing with a runtime error, so that was already kind of interesting. But it was quickly determined it was flaky because of the tests running in a certain order, so-- JOËL: Classic. STEPHANIE: Right. So, I knew something was happening, and any tests that came after it were running into this error. And I was taking a look, and I figured out how to recreate it. And we even isolated to the test itself that was running before everything else, that would then cause some problems. And so, looking into this test, I saw that it was stubbing the find method on an ActiveRecord model. JOËL: Interesting. STEPHANIE: Yeah. And the stubbed value that we were choosing to return ended up being referenced in the tests that followed. So, that was really strange to me because it went against everything I understood about how RSpec cleans up stubs between tests, right? JOËL: Yeah, that is really strange. STEPHANIE: Yeah, and I knew that it was referencing the stub value because we had set a really custom, like, ID value to it. So, when I was seeing this exact ID value showing up in a test that seemed totally unrelated, that was kind of a clue that there was some leakage happening. JOËL: So, what did you do next? STEPHANIE: The next discovery was that the error was actually raised in the factory setup for the failing tests and not even getting to running the examples at all. So, that was really strange. And digging into the factories was also its own adventure because there was a lot of complexity in the factories. A lot of them used hooks as well that then called some application code. And it was a wild goose chase. But ultimately, I realized that in the factory setup, we were calling some application code for that model where we had stubbed the find, and it had used the find method to memoize a class instance variable. JOËL: Oh no. I can see where this is going. STEPHANIE: Yeah. So, at some point, our model.find() returned our, you know, stub value that we had wanted in the previous test. And it got cached and just continued to leak into everything else that eventually would try to call that memoized method when it really should have tried to do that look-up for a separate record. JOËL: And class instance variables will persist between tests as long as they're on the same thread, right? STEPHANIE: Yeah, as far as I understand it. JOËL: That sounds like a really frustrating journey. And then that moment when you see the class instance variable, and you're like, oh no, I can't believe this is happening. STEPHANIE: Right? It was a real recipe for disaster, I think, where we had some, you know, really complicated factories. We had some sneaky caching issues, and this, you know, totally seemingly random runtime error that was being raised. And it was a real wild goose chase because there was not a lot of directness in going down the debugging path. I feel like I went around all over the codebase to get to the root of it. And, in the end, you know, we were trying to come up with some takeaways. And what was unfortunate was that you know, like, normally, stubbing find can be okay if you are, you know, really wanting to make sure that you are returning your mocked value that you may have, like, stubbed some other stuff on in your test. But because of all this, we were like, well, should we just not stub find on this really particular model? And that didn't seem particularly sustainable to make as a takeaway for other developers who want to avoid this problem. So, in the end, I think we scoped the stub to be a little more specific with the arguments that we wanted to target. And that was the way that we went forward with the particular flaky test at hand. JOËL: It sounds like the root cause of the problem was not so much the stub as it was the fact that this value is getting cached at the class level. Is that right? STEPHANIE: Yes and no. It seems like a real pain for running the tests. But I'm assuming that it was done for a good reason in production, maybe, maybe not. To be fair, I think we didn't need to cache it at all because it's calling a find, which is, you know, should be pretty quick and doesn't need to be cached. But who knows? It's hard to tell. It was really old code. And I think we were feeling also a little nervous to adjust something that we weren't sure what the impact would be. JOËL: I'm always really skeptical of caching. Caching has its place. But I think a lot of developers are a little too happy to introduce one, especially doing it preemptively that, oh well, we might need a cache here, so why not? Let's add that. Or even sometimes, just as a blind solution to any kind of slowness, oh, the site is slow; let's throw a cache here and hope for the best. And the, like, bedrock, like, rule zero of any kind of performance tuning is you've got to measure before and after and make sure that the change that you introduce actually makes things better. And then, also, is it better enough speed-wise that you're willing to pay any kind of costs associated to maintaining the code now that it's more complex? And a lot of caches can have some higher carrying costs. STEPHANIE: Yeah, that's a great point. This debugging mystery an example of one of them. JOËL: How long did it take you to figure out the solution here? STEPHANIE: So, like you, I actually was on a bit of the incorrect path for a little while. And it was only because this issue affected a different flaky test that someone else was investigating that they were able to connect the dots and be like, I think these, you know, two issues are related. And they were the ones who ultimately were able to point us out to the offending test if you will. So, you know, it took me a few days. And I imagine it took the other developer a few days. So, our combined effort was, like, over a week. JOËL: Yep. So, for all our listeners out there, you just heard that Stephanie and I [laughs] both went on multi-day debugging journeys. That happens to everyone. Just because we've been doing this job for years doesn't mean that every bug is, like, a thing that we figure out immediately. So, separately from this bug that I've been working on, a big issue that's been front of mind for me on this project has been the classic build versus buy decision. Because we're integrating with a third-party system, we have to look at either building our own integration or trying to use some off-the-shelf components. And there's a few different levels of this. There are some parts where you can actually, like, literally buy an integration and think through some of the decisions there. And then there's some situations where maybe there's an open-source component that we can use. And there's always trade-offs with both the commercial and the open-source situation. And we have to decide, are we willing to use this, or do we want to build our own? And those have been some really interesting discussions to have. STEPHANIE: Yeah. I think you actually expanded this decision-making problem into a build versus buy versus open source because they are kind of, you know, really different solutions with different outcomes in terms of, you know, maintenance and dependencies, right? And that all have, like, a little bit of a different way to engage with them. JOËL: Interesting. I think I tend to think of the buy category, including both like commercial off-the-shelf software and also open-source off-the-shelf software, things that we wouldn't build custom for ourselves but that are third-party components that we can pull in. STEPHANIE: Yeah, that's interesting because I had a bit of a different mental model because, in my head, when you're buying a commercial solution, you, you know, are maybe losing out on some opportunities for customization or even, like, forking it on your own. So, with an open-source solution, there could be an aspect of making it work for you. Whereas for a commercial solution, you really become dependent on that other company and whether they are willing to cater [laughs] to your needs or not. JOËL: That's fair. For something that's closed-source where you don't actually have access to the code, say it's more of a software as a service situation, then, yeah, you're kind of locked in and hoping that they can provide the needs that you have. On the flip side, you are generally paying for some level of support. The quality of that varies sometimes from one vendor to another. But if something goes wrong, usually, there's someone you can email, someone you can call, and they will tell you how to fix the problem, or they will fix it on their end. STEPHANIE: For the purposes of this conversation, should we talk about the differences, you know, building yourself or leaning on an existing built-out solution for you? JOËL: The project I'm working on is integrating with a Snowflake data warehouse, which is an external place that stores data accessible through something SQL-like. And one of the things that's attractive about this is that you can pull in data from a variety of different sources, transform it, and have it all stored in a kind of standardized structure that you can then integrate with. So, for pulling data in, you can build your own sort of ingestion pipeline, if you want, with code, and their APIs, and things. But there are also third-party vendors that will give you kind of off-the-shelf components that you can use for a lot of popular other data sources that you might want to pull. So, you're saying; I want to pull from this external service. They've probably got a pre-built connector for it. They can also do things like pull from an arbitrary Postgres database on some other server if that's something you have access to. It becomes really attractive because all you need to do is create an account on this website, plug in a few, like, API keys and URLs. And, all of a sudden, data is just flowing from one third-party system into your Snowflake data Warehouse, and it all just kind of works. And you don't have to bother with APIs, or ODBC, or any of that kind of stuff. STEPHANIE: Got it. Yeah, that does sound convenient. As you were talking about this, I was thinking about how if I were in the position of trying to decide how to make that integration happen, the idea of building it would seem kind of scary, especially if it's something that I don't have a lot of expertise in. JOËL: Yeah, so this was really interesting. In the beginning of the project, I looked into a little bit of what goes into building these, and it's fairly simple in terms of the architecture. You just need something that writes data files to typically something like an S3 bucket. And then you can point Snowflake to periodically pull from that bucket, and you write an import script to, you know, parse the columns and write them to the right tables in the structure that you want inside Snowflake. Where things get tricky is the actual integration on the other end. So, you have some sort of third-party service. And now, how do you sort of, on a timer maybe, pull data from that? And if there are data changes that you're synchronizing, is it just all append-only data? Or are you allowing the third-party service to say, "Hey, I deleted this record, and you should reflect that in Snowflake?" Or maybe dealing with an update. So, all of these things you have to think about, as well as synchronization. What you end up having to do is you probably boot up some kind of small service and, you know, maybe this is a small Ruby app that you have on Heroku, maybe this is, like, an AWS Lambda kind of thing. And you probably end up running this every so many seconds or so many minutes, do some work, potentially write some files to S3. And there's a lot of edge cases you have to think about to do it properly. And so, not having to think about all of those edge cases becomes really enticing when you're looking to potentially pay a third party to do this for you. STEPHANIE: Yeah, when you used the words new service, I bristled a little bit [laughs] because I've definitely seen this happen maybe on a bit of a bigger scale for a tool or solution for some need, right? Where some team is formed, or maybe we kind of add some more responsibilities to an existing team to spin up a new service with a new repo with its own pipeline, and it becomes yet another thing to maintain. And I have definitely seen issues with the longevity of that kind of approach. JOËL: The idea of maintaining a fleet of little services for each of our integrations seemed very unappealing to me, especially given that setting something like this up using the commercial approach probably takes 30 minutes per third-party service. There's no way I'm standing up an app and doing this whole querying every so many minutes, and getting data, and transforming it, and writing it to S3, and addressing all the edge cases in 30 minutes. And it's building something that's robust. And, you know, maybe if I want to go, like, really low tech, there's something fun I could do with, like, a Zapier hook and just, like, duct tape a few services together and make this, like, a no-code solution. I still don't know that it would have the robustness of the vendor. And I don't think that I could do it in the same amount of time. STEPHANIE: Yeah. I like the keyword robustness here because, at first, you were saying, like, you know, this looked relatively small in scope, right? The code that you had to write. But introducing all of the variables of things that could go wrong [laughs] beyond the custom part that you actually care about seemed quite cumbersome. JOËL: I think there's also, at this point, a lot of really interesting prioritization questions. There are money questions, but there are also time questions you have to think about. So, how much dev time do we want to devote upfront to building out these integrations? And if you're trying to move fast and get a proof of concept out, or even get, like, an MVP out in front of customers, it might be worth paying more money upfront to a third-party vendor because it allows you to ship something this week rather than next month. STEPHANIE: Yeah. The "How soon do you need it?" is a very good question to ask. Another one that I have learned to include in my arsenal of, you know, evaluating this kind of stuff comes from a thoughtbot blog by Josh Clayton, where he, you know, talks about the build versus buy problem. And his takeaway is that you should buy when your business is not dependent on it. JOËL: When it's not part of, like, the core, like, value-add that your business is doing. Why spend developer time on something that's not, like, the core thing that your product is when you can pay someone else to do it for you? And like we said earlier, a lot of that time ends up being sunk into edge cases and robustness and things like that to the point where now you have to build an expertise in a, like, secondary thing that your business doesn't really care about. STEPHANIE: Yeah, absolutely. I think this is also perhaps where very clear business goals or a vision would come in handy as well. Because if you're considering building something that doesn't quite support that vision, then it will likely end up continuing to be deprioritized over the long term until it becomes this thing that no one is accountable for maintaining and caring for. And just causes a lot of, honestly, morale issues is what I've seen when some service that was spun up to try to solve a particular problem is kind of on its last legs and has been really neglected, and no one wants to work on it. But it ends up causing issues for the rest of the development team. But then they're also really focused on initiatives that actually do provide the business value. That is a really hard balancing act that I've seen teams struggle with. JOËL: Earlier this year, we were talking about the book Sustainable Rails. And it really hammers home the idea of a carrying cost for the code, and I think that's exactly what we're talking about here. And that carrying cost can be time and money. But I like that you also mentioned the morale effects. You know, that's a carrying cost that just sort of depresses the productivity of your team when morale is low. STEPHANIE: Yeah, absolutely. I'm curious if we could discuss some of the carrying costs of buying a solution and where you've seen that become tricky. JOËL: The first thing to look at is the literal cost, the money aspect of things. And I think it's a really interesting situation for the business models for these types of Snowflake connectors because they typically charge by the amount of data that you're transmitting, so per row of data that you're transmitting. And so, that cost will fluctuate depending on whether the third-party service you're integrating with is, like, really chatty or not. When you contrast that to building, building typically has a relatively fixed cost. It's a big upfront cost, and then there's some maintenance cost to go with it. So, if I'm building some kind of integration for, let's say, Shopify, then there's the cost I need to build up front to integrate that. And if that takes me, I don't know, a week or two weeks, or however long it is, you know, that's a pretty big chunk of time. And my time is money. And so, you can actually do the math and say, "Well, if we know that we're getting so many rows per day at this rate from the commercial vendor, how many weeks do we have to pay for the commercial one before we break even and it becomes more expensive than building it upfront, just in terms of my time?" And sometimes you do that math, and you're like, wow, you know, we could be going on this commercial thing for, like, two years before we break even. In that case, from a purely financial point of view, it's probably worth paying for that connector. And so, now it becomes really interesting. You say, okay, well, which are the connectors that we have that are low volume, and which are the ones that are high volume? Because each of them is going to have a different break-even point. The ones that you break even after, you know, three or four weeks might be the ones that become more interesting to have a conversation about building. Whereas some of the others, it's clearly not worth our time to build it ourselves. STEPHANIE: The way you described this problem was really interesting to me because it almost sounds like you found the solution somewhere in the middle, potentially, where, you know, you may try building the ones that are highest priority, and you end up learning a lot from that experience, right? That could make it easier or at least, like, set you up to consider doing that moving forward in the future if you find, like, that is what is valuable. But it's interesting to me that you kind of have the best of both worlds of, like, getting the commercial solutions now for the things that are lower value and then doing what you can to get the most out of building a solution. JOËL: Yeah. So, my final recommendation ended up being, let's go all commercial for now. And then, once we've built out something, and because speed is also an issue here, once we've built out something and it's out with customers, and we're starting to see value from this, then we can start looking at how much are we paying per week for each of these connectors? And is it worth maybe going back and building our own for some of these higher-volume connectors? But starting with the commercial one for everything. STEPHANIE: Yeah, I actually think that's generally a pretty good path forward because then you are also learning about how you use the commercial solution and, you know, which features of it are critical so that if you do eventually find yourselves, like, maybe considering a shift to building in-house, like, you could start with a more clear MVP, right? Because you know how your team is using an existing product and can focus on the parts that your business are dependent on. JOËL: Yeah, it's that classic iterative development style. I think here it's also kind of inspired by a strategy I typically use for performance, which is make it work before you try to make it fast. And, actually, make it work, then profile, then measure, find the hotspots, and then focus on making those things fast. So, in this case, instead of speed, we're talking about money. So, it's make it work, then profile, find the parts that are expensive, and make the trade-off of, like, okay, is it worth investing into making that part less expensive in terms of resources? STEPHANIE: I like that as a framework a lot. JOËL: A lot of what we do as programmers is optimization, right? And sometimes, we're optimizing for execution time. Sometimes we're optimizing for memory cost, and sometimes we're optimizing for dollars. STEPHANIE: Yeah, that's really interesting because, with the buy solution, you know very clearly, like, how much the thing will cost. Whereas I've definitely seen teams go down the building route, and it always takes longer than expected [laughs], and that is money, right? In terms of the developer's time, for sure. JOËL: Yeah, definitely, like, add some kind of multiplier when you're budgeting out that build alternative because, quite likely, there are some edge cases that you haven't thought about that the commercial partner has, and you will have to spend more time on that than you expected. STEPHANIE: Yeah, in addition to whatever opportunity cost of not working on something that is driving revenue for the business right now. JOËL: Exactly. STEPHANIE: So, the direction of this conversation ended up going kind of towards, like, what is best for the team at, like, a product and company level. But I think that we make these decisions a lot more frequently, even when it comes to whether we pull in a gem or, you know, use an open-source tool or not. And I would be really interested in discussing more of that in another episode. JOËL: Yeah. That gets into some controversial takes, right? It's the evergreen topic of: do we build it ourselves, or do we pull in some kind of third-party package? STEPHANIE: Something for the future to look forward to. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

The Bush Deacon–Josh Clayton–Basketball (While attending a recent juniors basketball game for his youngest son, Josh was struck by the difference a small amount of coaching was appreciated by the young boys. It made Deacon Josh think about how important it is for each one of us to reflect on who are the people that we have in our life that help coach us, help guide us, give us ideas as to how we can live our life in a better way so that we can be who we're meant to be. Jesus is an amazing coach, but it's also coming alongside other people in our everyday life, mentors, people that can work with us to help us to grow and develop. Maybe it's your local church. Maybe it's part of a community group. There's plenty of people out there willing to help. We just have to be willing to put our hand up and ask for that assistance.)

The Bush Deacon–Josh Clayton–The Bells Unite Us (Recently one of Josh's knowledgeable friends explained that the ringing of church bells is not only a reminder that the liturgy is about to begin in the church, but also a reminder to those unable to be there with the community that they are united in prayer with the worshiping community. Josh says he now thinks differently about hearing the bells ringing or tolling at a funeral, wedding, or at other times such as midday and how we can be united in so many ways and at various times praying for God's Kingdom. Listen out for the bells. They're uniting us.)

On The Journey This Week: Fr Mark De Battista says when it comes to faith and knowledge of God, it's those with a childlike heart who have the deepest insights. Mother Hilda compares King David's harp playing to the music of Jesus in our heart. Plus, Pete Gilmore's faith testimony, Trish McCarthy on the gift of water, and the bush deacon, Josh Clayton on why tolling bells unite us.

The Bush Deacon–Josh Clayton–Football Gala Day (While sitting and watching his youngest son play rugby, Josh was reflecting on the amazing work that happens in so many volunteer organisations around our country. So many parents, so many individuals working hard to enable this day for these 10 year olds to have a great day playing rugby. But it did make me think if each of us were as passionate about our faith as what we can be about our sport, I wonder if the world would be a different place. I wonder whether it would be more empowering for people to see that faith isn't something you keep at arm's distance. Faith is something you can be excited about. Jesus Christ is someone who you can have on your side that's going to make you a winner. So, if you're after something that can transform the world, then finding your local church and putting your hand up to help is a way to transform the world in a way that you could never really imagine. Volunteering is great, what's something you can do to help God's message be reached and heard by more?)

The Bush Deacon–Josh Clayton–Proclaiming Jesus Christ Today (Deacon Josh continues to be amazed by how participants respond over the weeks of Alpha with how God works in their life, and how they don't want to miss out on sharing with each other each week. Alpha is one tool that we can use, but sometimes what we need to do is be people of faith, people that value others because that witness will transform the world as it did in the early Church. It's what we're all called to do as Christians. We're called to journey with each other. We're not meant to live in isolation doing our own thing. What do we need to do today to help other people see and hear that Jesus Christ is alive? What is holding you back from proclaiming Jesus Christ today?)

The Bush Deacon–Josh Clayton–Vanuatu God is Working (Deacon Josh has been on a trip to Vanuatu to speak to young people in the Christian communities about the next World Youth Day. But it was the aftermath of the recent double cyclones that the Island communities experienced that impressed him and how the local communities were responding in faith-filled support of each other. There's lots of things that happen in our lives that are challenges, and sometimes it's hard to see how God might be working. It's the perennial struggle that each of us has; why do bad things happen to good people? It's more about how we can see God in the situation. It's God in the care and help that comes from supporting each other and for all the external help given. The challenge for us is to see the good and to see how God is working through that goodness.)

This week, we dive into the topic of "Catholic Leadership Insights for Diocesan Work" with our guest, Deacon Josh Clayton, the Director of Mission and Renewal at the Diocese of Bathurst, Australia.   Diocesan work can be challenging, as trust is often difficult to establish and maintain. However, with the right approach and mindset, it's possible to build trust between leaders and create a shared vision for the community.   Deacon Josh Clayton shares his experiences and insights on building trust and winning others over to a God-sized vision. He provides practical advice on how to communicate effectively, engage with others, and inspire them to become part of a greater mission.   Join us as we unpack the importance of building trust, creating a shared vision, and impacting lives for the Gospel in the context of diocesan leadership.   Watch on YouTube: https://www.youtube.com/watch?v=5IB_dVnAtkA   About Deacon Josh Clayton: Josh is Vocational Deacon for the diocese of Bathurst, he is also part of the Mission and Renewal team committed to working with communities to ensure they are living the call of Church to the best of their God given gifts. He is committed to proclaiming Jesus in his life, because that's what's made his life so wonderful, so he wants others to experience that too! Josh is Married to Anna, and they have always ministered together and their greatest work is their four children, Jack, Mia, Lucy and Patrick.   Website: https://bathurst.catholic.org.au/ Facebook: https://www.facebook.com/cdobathurst

On The Journey This Week: Fr John Corrigan's reflection for Divine Mercy Sunday. Mother Hilda's story on St Bede, Bishop Brian Mascord's Easter message, the Divine Gardener, plus, Pete Gilmore on the faith of Thomas, d the bush deacon Josh Clayton on wilderness.

The Bush Deacon—Josh Clayton—Outlast the Journey (Deacon josh has been watching the Netflix series– Outlast, the stories of 16 people dropped into the Alaskan wilderness, and it has reminded him of John the Baptist in Matthew's Gospel and that great moment of the proclamation by John the Baptist of Jesus. Each of us, for many different reasons, have times in the wilderness when we have moments where we need to orientate ourselves and determine what's important, what's going to give us life, what's going to help us to be who we're meant to be, as well as encounter and help those that need assistance in the wilderness. We're not in the Alaskan wilderness, but we do have those moments where we're called to reorientate ourselves towards God. Make sure the path in our heart is as straight as possible and keep focus on the main thing, Jesus Christ.)

thoughtbot had an in-person Summit in the UK! Joël recalls highlights. Stephanie is loving daily sync meetings on a new project. The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Thoughtbot summit video (https://www.youtube.com/watch?v=6d7gUq5J-ck) Gather Town (https://www.gather.town/) Sustainable Rails episode (https://www.bikeshed.fm/368) Chelsea Troy on deleting features (https://chelseatroy.com/2021/01/21/reducing-technical-debt/) Unused (https://unused.codes/) elm-review-unused (https://package.elm-lang.org/packages/jfmengels/elm-review-unused/latest/) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And today, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I just got back from a few days in the UK, where thoughtbot has been having an in-person Summit, where we've brought people from all over the company together to spend a few days just spending time with each other, getting to know each other, getting to connect in person. STEPHANIE: That sounds like it was a lot of fun. I've been hearing really great things about it from folks who've come back. Unfortunately, I couldn't make it this year. I got sick a little bit beforehand and then ended up not being able to go. But it sounds like it was a lot of fun just to get together, especially since we're now a remote company. JOËL: Yeah, I'm really sorry you weren't able to make it there. It would have been amazing to do a Bike Shed co-hosts get-together. STEPHANIE: I know. In the same room, maybe even record. What a concept. [laughs] JOËL: So thoughtbot is a fully remote company, and so that means that getting a chance to have people to come together and build those in-person connections that you don't get, I think, is incredibly valuable. I was really excited to meet both the people that I work with and that I see on my screen every day and people who I don't talk to as often because they're working on different teams or different departments even. STEPHANIE: What was one highlight of the time you spent together? JOËL: I'll give a couple of highlights, one I think is more on the activity side. We went bouldering as a group. This was a really popular activity. We were trying to sign up people for it, and it was so popular we had to make two groups because there were too many people who were interested. And it was really fun. There are people with a whole variety of skill levels. Some people, it was their first time, some people had been doing it for a while. And just getting together and solving problems was a lot of fun. STEPHANIE: Yes, I saw that. That was one of the things I was really looking forward to doing when I was still thinking that I was going to go. And it's cool that it had opportunities for both beginners and people who have been doing it before, which I think, if I recall correctly, Joël, you are a boulderer yourself back home. So that's pretty neat that you were able to, yeah, I don't know, maybe share some of that experience IRL too. JOËL: Yeah, yeah, I think it's great because people were able to help each other. Sometimes you have a different perspective down on the ground than you do up on the wall. And then, in my case, because I've done it a lot, I know a little bit of actual climbing technique. And so I can give some tips on, like, oh, if you're stuck and you don't know how to get past a particular point, or you don't know how to start a particular climb, or your arms are getting tired halfway up, here's maybe a small change you can make that would make things easier for you. STEPHANIE: Honestly, that also sounds like a really good metaphor for pair programming, [laughs] like, looking at things from different perspectives, you know, someone who's on the wall? I don't know what the lingo is. But it's the equivalent of someone driving in coding, the navigator having a little more perspective and being able to point out things that they might not see that's right in front of them. JOËL: I love that metaphor. Now I'm going to think of that both when I pair and the next time I climb. STEPHANIE: I love it. JOËL: I think climbing, when I do it, it's always more fun with a friend, specifically for what you were saying. I climb alone sometimes, but as much as possible, I'll reach out to another friend who climbs and say, "Hey, let's climb together." And then we can alternate on the same route even. STEPHANIE: That's cool. I didn't realize that it could be such a social activity. JOËL: It is very much a social activity, and I think that's part of the fun of it. It's challenging physically but also mentally because it's a puzzle that you solve. But then also, it's a thing that you do with friends. I think another aspect that was a highlight for me was getting a chance to connect with people from other teams, other departments within thoughtbot. I think one thing that was really nice when we were located in an office is that over lunch, or just at the water cooler, or whatever, you would connect with people who were in other teams and who were in different departments. So I might talk to people in People Ops, or in marketing, in operations just sort of in the natural course of the day in a way that I think I don't do quite as much of now that we're more remote. And I tend to talk more with other developers and designers on my team. So I think that was really great to connect with people from other teams and other departments within the company. STEPHANIE: Yeah, I know what you mean. I think I really miss the spontaneous, organic social interaction that you get from working in an office. And I think we've maybe talked about remote work on the podcast before, or previous co-hosts Steph and Chris have also talked about remote work. But it definitely requires a lot more intention to manifest those connections that otherwise would have been a little more organic in person. And so, while you all were at an in-person summit in the UK, there was also a virtual summit hosted for folks who weren't able to travel this time around, and I really appreciated that. I got to spend a day just connecting with other people in Gather Town, which is a web app that's like a virtual space where you have little avatars, and you can run around and meet up with people into virtual meeting rooms on this map. [laughs] I'm not really sure I'm describing it well, but it's very cute. It is almost like a little video game. It's like a cross between a video game and video conferencing [chuckles] software. But yeah, I think I just really appreciated how inclusive thoughtbot has been doing remote work where, like, yes, we really value these in-person gatherings, and we understand that there is a bit of magic that comes from that, but also making sure that no one's left out. And at the end of the day, not everyone can make it, but we were still able to hang out and socialize amongst ourselves in a different way. JOËL: Agreed. I think that inclusivity is part of what makes thoughtbot such a great place to work at. STEPHANIE: Speaking of inclusivity, I mentioned a few weeks ago that I joined a new project recently and had been going through the onboarding and hopping into all these new meetings. One thing that I've really enjoyed about this new client team that I'm on is that in their daily sync meetings, we all share what we're working on. But we also all share something that's new to us, which is a little bit meta because we do that on this podcast. [laughs] But each person just shares maybe something they learned at work but also usually something just totally not work related like a new show that they're watching. There's another person on my team who learns a lot of things from YouTube videos. And so he's always telling us about the new thing he learned about, I don't know, like mushrooms or whatever, or AI [laughs] through YouTube. And yeah, someone else might show a sweater that they just knit themselves. And it's been a very easy way to get to know people, especially when you're meeting a whole new team. And yeah, I've been enjoying it a lot. It's made me feel very welcome and like I know them as people outside of work. JOËL: I love that. Yeah, they're more than just people you're shipping code with. You're able to build that connection. And it sounds like that helps smooth the...maybe we can say the social aspect of onboarding. Because when you onboard onto a project, you're not just onboarding onto a series of codebases and tools; you're also onboarding onto a team, and you need to get to know people and build relationships. STEPHANIE: Yeah, absolutely. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: So you've been...is it two weeks in a new codebase? Have you gone and deleted any code yet? STEPHANIE: I wish. I am glad you asked this question because this has been a topic that has been swimming around in my head a little bit lately because this new client codebase it's very big and it's quite old. Like, I've been seeing code from 10 years ago. And it's been a really challenging codebase to get onboarded into, actually, because there's so much stuff. In fact, I recently learned that some of their model specs are so big that they have been split out into up to seven different files to cover specs for one model. [laughs] So that has been a lot to grapple with. And I think in my journeys working on a starter ticket, I've just stumbled upon stuff that is very confusing. And then I might follow that thread only to realize that, like, oh, this method that I spent 20 minutes trying to grok turns out it's not actually used anywhere. JOËL: That's a lot of dead code. STEPHANIE: It is a lot of dead code, but I am also not quite feeling confident enough to delete it because I'm new, because I have no idea what consequences that might have. So, yeah, the idea of deleting code has just kind of been swimming around in here because ideally, we would be able to, but, for some reason, I don't know, at least for me, I feel very nervous about it. So it hasn't been something that I've reached for. JOËL: That's a great question because I think in maybe Ruby, in particular, it's not always obvious if code is being used or not. When you do find yourself deleting code, how do you gain the confidence that it was safe to delete that? STEPHANIE: Yeah, that's a good question. In the past, when I've done it successfully, I'll probably post a Slack message or something and being like, hey, I noticed this code is not being used anywhere, or I'd like to delete it because why, like, I don't know, because it's been misleading me because it's just not providing any value. And then kind of give it like a day or two, and if no one speaks up about it, then I will usually go ahead. And obviously, get some code review, hopefully, get some other eyes on it just to make sure that whatever assumptions I made were valid, and then go for it. And then just watch [laughs] the deployment afterwards and make sure that there are no new errors, you know, no new complaints or anything like that. And, yeah, I think that has been my process, and I've definitely found success doing that. But I have also experienced a bad result [laughs] from doing that where one time, on my last client project, we were refactoring the signup flow. And we realized that after you signed up, you were redirected to this blank page for like 10 seconds or something. It was completely empty. There was nothing on it except a spinner, I think. [laughs] And then it would then redirect you to the dashboard of the app. And we were like, oh, we can definitely delete this. We have no idea what this is doing. We don't want to try to refactor this as part of the effort that we were doing. And so we deleted it, only to find out later from the marketing team that they had been using that page for something Google Analytics related, and we had to revert that change. And it was a real bummer because I think when we removed it, we felt good about that. We were like, oh yes, deleting code, awesome. And then having to bring it back without a clear plan of how to actually fix the problem that we were trying to solve was a bit of a bummer. JOËL: So, as programmers, we're hired to write code. Why does it feel so good to do the opposite of that, to delete code? STEPHANIE: That's a great question. I actually want to know what you think about this, but before that, I wanted to plug this Slack channel that we have at thoughtbot called Dead Code Society, where people can post their PR diffs showing more red than green, so more lines removed than lines added. And I have been really enjoying that Slack channel. It's very delightful. [laughs] But, Joël, do you have any thoughts about why it feels so good to delete code? JOËL: There are probably a few different reasons. Especially when it's not your own code, you're often not attached to it. There's often, I think, the sense when you go into an existing codebase you're just like, oh, everything's just bad, and I don't understand it. And those other coders who wrote this didn't know how to do their job and kind of be the curmudgeon character. So it just kind of feels good to remove that and maybe rewrite it yourself. I would say that's not a good mindset to go in for deleting code. I think there are positive ways where it is actually a good thing. STEPHANIE: That's fair. Just removing code because you would write it differently is not necessarily a net positive. [laughs] JOËL: But I think...so when I initially asked the question, I said, "We're hired to write code." And I think that's a bit of a false assumption built into the question. We're not hired to write code. We're hired to solve problems, to build solutions. And as much as code can be an asset in solving problems, it's also a liability. And code has varying maintenance costs that are typically not low. They vary from expensive to very expensive. And so any chance we get to remove some of that, we're removing some of the carrying costs, to use a term that we discussed a few episodes back when we talked about sustainable Rails. STEPHANIE: Yeah, absolutely. One thing that I remember you sharing about the client project that we're both on in the past is they have a very cumbersome test suite. And in some situations, you have wanted to advocate for deleting some of those tests. JOËL: Deleting tests is a really, I think, spicy take because you're trying to get better test coverage. And if your test coverage isn't great, you don't want to lose any of that. So there's definitely a loss aversion there, and we might need it later. At the same time, tests have a cost, cost to run, cost to maintain. And if they're not providing a lot of value, then the cost of keeping them around might be higher than any kind of benefit they're giving you. And I think a classic case of this is tests that have either been marked pending in the codebase with an exit or something like that or that have been marked in your CI server as muted; just ignore failures from this test. Because now you're still having to maintain, still having to execute these tests. They're costing you time, but they're giving you zero benefit. And they're just taking up space in your codebase, making it harder to read. So if you can't get these tests back into the point where they're actually executing, and you're caring about the output, then you probably don't need those tests, and they can be removed. STEPHANIE: Yeah, that's fair. I'm thinking about the perspective of someone who does not want to delete those tests. I think in the past, I've seen it and even felt it myself as someone who probably wrote the tests, kind of hoping for some ideal world where I will finally have time to go back to that test. And I already put a lot of effort into trying to make it work, and I want to make it work. I want to have the value of that test. And it's kind of like a sunk cost fallacy a little bit where it's like, I already spent however much time on it that it must have some kind of value. Because just hearing that someone else wants to delete the test can kind of hurt a little bit. [laughs] And it's tough. I do think that it's easier for someone with an outside perspective to be like, "Hey, this test is costing more than the value that it's providing." But yeah, I can see why people might have a little bit of pushback JOËL: Sometimes, the value of a test is also in the journey rather than the destination. STEPHANIE: Yeah, that's a good point. JOËL: So if you're practicing TDD, maybe you use some tests to help you drive out some functionality, help you come up with a design that you want to do. But maybe once you've actually created the design, the test that helped you get there is not actually that useful. I've heard some people will do this by writing a lot of more system tests-like tests that are very integration-heavy, that have a lot of edge cases that you might not care to test at that level, at that granularity. And so they use those to help drive a little bit of the implementation and then remove them because they're not providing that much value relative to their cost anymore. STEPHANIE: I think that's a really good point. The tests that you write for implementation can have value to you as a developer, but that's different from those tests having value to the business when you commit them to a codebase and incorporate them as part of CI and a CI that everyone else has to run as well. So yeah, I think in that case, the context definitely matters. And hopefully, you can feel good about the value that it provided but then also have that eye towards, okay, what about the business, and what values does the business have? JOËL: Yeah, and accept that the test did the job that it was supposed to do. It got you to where you needed to be, and it completed its purpose. And now it's ready to move on. STEPHANIE: Another thing that I recently read about deleting code...and this was from Chelsea Troy. She advocates for regularly evaluating features in an app and deciding whether they're providing enough value to justify keeping around and maintaining for developers as well. And I thought that was really interesting because I don't know if that's something that I'd really considered before that sometimes an app might outgrow some features, or they might not be worth keeping around because of the problems or the maintenance costs that they carry into the future. JOËL: That's fascinating because I think you're taking the same analysis we were talking about tests and then kind of like bringing it up now to the product level. Because now, we're not just talking about deleting code; we're talking about deleting functionality that a product might have. STEPHANIE: I think the challenge there is that the effects of the carrying cost of a feature is not necessarily felt by the business stakeholders, or product folks, or people operating at a higher level, but it is felt by developers. If there's a bug that's come up from this old feature, and oh, I have never seen this feature before, and now I have to spend a day learning about what this thing is before I can fix the bug. It did feel like a radical idea that maybe developers can play a part in advocating for some features to be retired, that is, you know, maybe separate from how products thinks about those things. JOËL: I think in order to be able to make those decisions or really just to be part of those conversations, the dev side needs to be really integrated with the product team and with larger business objectives. And so then you can say, look, if we take a week of one developer's time to provide the support this feature needs and we have one customer paying $20 a month for it, that's not a good business prospect. Now, is this strategically an area that we're trying to grow? And so yeah, we're doing it for one customer, but we're hoping to get 100 by the end of the year, and then it will be worth it. Then yes, maybe we keep that feature around. If this is the thing, like, we experimented for a few weeks five years ago, and then it's just kind of hang around as a legacy thing that this one person knows about and uses, then maybe it's worth saying, look, this has a high business cost. It might be worth sunsetting that feature. But it's a conversation that everybody needs to be involved in. STEPHANIE: Yeah, yeah. I like the idea of it being something more proactive versus, I don't know, something that I think I've seen at other orgs and just in general as a person who uses digital products, like, a feature or a product, just kind of dying. And probably the organization just wasn't able to find a team to continue to support it, and it just kind of kept being this burden. And then, eventually, it just was something that they had to let go. But then, at that point, you had already spent all of that time, and effort, and energy into figuring out what to do with this thing. Whereas the approach that Chelsea is advocating for is more realistic, I think, about the fate of [laughs] software products and features. And as a developer, I would get that feeling of deleting [laughs] code that is so satisfying. And I'm just not burdened by having to deal with something that is not providing value, like cumbersome tests. [laughs] JOËL: I think it's always the fundamental thing that you have to go back to when you're talking about deleting code, or features, or anything is that sort of cost-benefit analysis. Does this thing provide us any value? And if so, does that value outweigh the cost of the work we need to do to maintain it? And in the case of dead code, well, it's probably providing zero value, but it's imposing a cost, and so we want to remove it. In the case of a test that is not muted or pending, then maybe it does provide some value. But if it's really brittle and constantly breaking, and it's costing us many hours of fixing time, then maybe it's not. If we can't find a way to fix it and make it more valuable because sometimes it's the other option, then it might be worth considering deleting it. Have you ever, on a codebase, taken some time to actually seek out code that could be deleted as opposed to just sort of stumbling onto it yourself? STEPHANIE: That's a good question. I think I have not just explored a codebase just looking for stuff to delete, but I have...maybe if you had something under a feature flag and you no longer needed the flag because it was released to everyone, you know, going back to delete it because you specifically made a ticket to make sure that you went back and cleaned that up. I do really appreciate the tracking of that work in that way and just making sure you're like, hey, I want to avoid a situation where this becomes dead code. And even just making a card for it is putting that intention out there. And hopefully, someone, if not yourself, we'll take that on because it's important. JOËL: Yeah, kind of proactively trying to make sure that the work that you've done doesn't become dead code, that it gets pruned at the appropriate moment. STEPHANIE: What about you? I'm curious from your perspective as an individual contributor when you are just moving through a codebase, and you see something suspiciously [laughs] looking like dead code what you do with it. JOËL: I often like to split out a small PR just to remove that if it's not too much work and it's semi-related to what I'm doing. I'd like to give a shout-out to two tools that can help detect or confirm that something is dead code. One is Unused, written by former thoughtboter Josh Clayton. It uses, I think, Ctags under the hood to track all the tokens in an app and then tries to determine are there tokens that are orphaned, that are isolated, and are not used? And it can then build you a report. And that can be good if you're doing a code audit of a codebase or if you're looking to confirm that a piece of code that you're working on might not be, like, is it actually used or not? Another one is elm-review-unused, which is a plugin for elm-review which is Elm's linter, kind of like RuboCop. And what's really nice there is because it reads the AST, and Elm functions don't have side effects. You know that if something is not reachable from the main function that, it is completely safe to remove. You've run the script, and it will delete a bunch of functions for you that are unused, and it's 100% safe. And it is very thorough. It finds all of the dead code and just removes it. It's practically just a...it's not a button because it's a script that you run but that you can automate to run on commit or whatever on the CI. But yeah, that's an amazing experience to just have it auto clean-up for you all the time. STEPHANIE: That's really cool. I like that a lot. I think that would be really nice to incorporate into your development workflow, like you said, that it's part of the linting system and just keeping things tidy. JOËL: Yeah, I think it's a little bit harder to have something that's quite as thorough for a Ruby or Rails app just because it's so dynamic, and we've got all this metaprogramming. But yeah, maybe this would be a thing where you would want to run something like Unused or some other linting tool every now and then to just check; hey, do we have any dead code that can be removed? STEPHANIE: Yeah, absolutely. And I think this is totally a little bit different because we're just talking about tools, but I'm also thinking of red flags on a team level where I have definitely asked in a Slack channel, "Hey, I've never seen this feature before. What does it do?" and just crickets. [laughs] And even the product folks that I'm working with, they're like, "I don't know. It predates me," that being a bit of a smell, [laughs] if you will, to reevaluate some of those things. And those flags can exist on many different levels. JOËL: That's always terrifying because you're like 80% sure that this is dead code, but there's like a 20% chance that this powers the core of the app, but nobody's touched it in 10 years. STEPHANIE: Yeah, it is very scary. [laughs] JOËL: Hopefully, your test suite is good enough that if you comment out that function and then you run your test suite, that it just all goes red, and you know that that's actually needed for something. STEPHANIE: Yeah, though I think sometimes you might remove a piece of dead code, and there are some issues afterwards, and you find out, and you just revert it, and it's fine. At the end of the day, there are a lot of safeguards in place, and we've all done it. And so I think normalizing it is also very important in that it's okay if sometimes you make a mistake there. JOËL: Stephanie is giving you permission to go and delete that code today. Ship it to production, and if something breaks, it's okay. STEPHANIE: [laughs] JOËL: You can revert it. Hopefully, your company is set up where reverting commits from production is a cheap and easy thing to do, and life goes on. So I'm curious, Stephanie, have you ever gone into GitHub and checked your stats on a project to see if you're more red than green or what that ratio is for you on a given project? STEPHANIE: I have. Actually, someone else did on my behalf because I was posting a lot in that Dead Code Society Slack channel. And they then shared a screenshot of my overall contributions to a repo, and it was more red than green. I felt pretty good about myself. [laughs] JOËL: All right. Net negative but in a positive kind of way. STEPHANIE: In a positive way. [laughter] JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. [laughs] Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

The Bush Deacon—Dcn Josh Clayton—Sun Beach Cricket (Recently Dcn Josh attended a retreat for 18- to 25-year-olds at the beach that was a chance for young people to stop before life becomes too busy, to reflect on what they hope for this year. You can't get away from the fact that a summer in Australia has a different feel, with our focus on beach, sun and cricket. But it means that we must be intentional about how we're going to enable faith to be part of our life. Sometimes it's hard to get time to pray, to worship, to come together in and as church because it's busy, it's hot, we want to go to the beach. But good habits form good people, and taking the time to reflect, allowing ourselves to be transformed by scripture, shared faith, conversations with others who share the love of God lets us appreciate the great gift of faith that we're given.)

On The Journey This Week: Fr Mark De Battista says we can learn much from the Samaritan woman's faith journey in this week's Gospel. Mother Hilda says called or uncalled, God is always present in our lives. The Triumph Lenten series continues with Ken Bryant and Darren McDowell. Plus, the bush deacon, Josh Clayton.

Interview—Fr Mike Delaney & Dcn Josh Clayton—Divine Renovation Australasia Conference (Journey Editor Max Norden in conversation with Fr Mike Delaney and Deacon Josh Clayton on their experience of the 2023 Divine Renovation Australasia conference last weekend in Sydney. Over 500 delegates, including clergy, religious and lay people, gathered to share and learn how to move parishes from a maintenance mode to mission. The conference focused on how to cultivate communities of discipleship that are vibrant and dynamic faith communities.)

The Bush Deacon—Dcn Josh Clayton–Baptism (For many of us, we don't think about baptism much. We don't think of when it occurred, who was present, maybe who baptised you? What was the circumstances? It's a wonderful thing for us to take time to reflect on. Drill a bit deeper and find out when you were baptised. Was it a church service? Was it when you were young? Was it when you were older? What was the date you were baptised? Each year we celebrate our birthdays. We celebrate anniversaries. We celebrate lots of key things and maybe it's time we all took the time to celebrate and reflect on how baptism has changed our lives.)

The Bush Deacon—Dcn Josh Clayton– Ever Youthful and Ever New (Recently Josh was taking his daughter through his workplace in Bathurst when she spotted a car with a red “P” plate. Her response was that she thought only old people worked for the Church. Sometimes we think that Christianity can be something that is only for the old. Regardless of age, Christianity is a faith that challenges, not something that's safe and easy, it's something that calls for radical life changing decisions. What are some things that people may think about you or about your faith that you can challenge? Is faith just for the old or is faith for each and every one of us ever youthful and ever new?)

On The Journey This Week: Fr Rob Galeas' Gospel reflection on the story of the incarnation that Jesus became one of us. Mother Hilda says follow St Joseph's way when dealing with life's pains. Plus, extra Christmas season reflections from Fr Sean Cullen and Ken Bryant, and the Bush Deacon, Josh Clayton's Christmas greeting, we are called to care for and be a Christmas gift of God's love to those who are struggling this Christmas.

The Bush Deacon—Josh Clayton—Christmas Greetings (The Bush Deacon sends his Christmas greeting as he reflects on the year we have experienced, our different circumstances as we participate in the Christmas season, responding to COVID, the widespread flooding, for some – still recovering from previous bushfires, and for others - smaller personal challenges. The juxtaposition of the Aussi Christmas is striking; the traditional Northern hemisphere cold, darkness and short days to our radiating bright light, the heat, the bushfire and other natural disaster threat, can sometimes make it more difficult to appreciate the full circumstances of the miracle of the incarnation. However, the one Christmas action we have in common with the rest of the world, regardless of which hemisphere we live in, is, we are called to care for and be a Christmas gift of God's love to those who are struggling this Christmas.)

The Bush Deacon–Josh Clayton–Pilgrimage (The Bathurst Diocese has had its first “setting out pilgrimage”, a pilgrimage for those preparing to attend World Youth Day next year. Josh says one of the things about pilgrimage is to keep it simple giving time to reflect on what is the most important thing in your life. Bathurst Diocese's local pilgrimage included time in their cathedral, walking to the site where Mary Mckillop and Julian Tennison-Woods established the first settlement of Josephite Sisters in NSW, and time interacting with a Parish community. Josh encourages us to break away from everyday routines and take the time to think and to pray. Your local pilgrimage could be to your local church, a slow purposeful walk through your local community, or it could just be taking some time to walk around the block and pray allowing ourselves to be with our loving God.)

The Bush Deacon–Josh Clayton–Hold Your hands Up (During a recent ecumenical group gathering to share, to pray and to support each other, the members asked Josh to explain the role and use of the Divine Office as a prayer tool. It's a wonderful way of going through, praying through the Psalms, through scripture, and through understanding of the things that we should pray for as a society. It reminds Josh of the Book of Exodus, when Moses' arms, grew heavy because he was raising them in prayer, and the moment where others come to help him pray, to hold his arms up. Sometimes that's what we need, a prayer buddy or two, so that like Moses, we can have people come and hold our arms up and help us to pray when we don't feel like praying.)

Crossroads Cantina presents: Whispers in the Mycelium: Myths and Monsters Dragons Deal by Josh Clayton. Whispers in the Mycelium is available on Amazon! https://www.amazon.com/Whispers-Mycelium-Dark-Fantasy-Anthology-ebook/dp/B09YBRDTFT (https://www.amazon.com/Whispers-Mycelium-Dark-Fantasy-Anthology-ebook/dp/B09YBRDTFT)   Credits: Episode Written by Josh Clayton Narrated by Josh Clayton Produced by Wolfgrove Media LLC     Don't forget to subscribe to the show and leave a rating and review.  See you next episode!   https://www.patreon.com/CrossroadsCantina (https://www.patreon.com/CrossroadsCantina)   https://www.facebook.com/CrossroadsCantinaPodcast (https://www.facebook.com/CrossroadsCantinaPodcast)   https://crossroadscantinapodcast.com/ (https://crossroadscantinapodcast.com) This podcast uses the following third-party services for analysis: Podcorn - https://podcorn.com/privacy

On The Journey This Week: Deacon James Arblaster's Gospel reflection on faith and gratitude. Mother Hilda on the African philosophy of Ubuntu which translated means I am because you are. A faith testimony from Dominic Beltrame (NET member from Vancouver). Plus, Fr Mike Delaney on his daily highs and lows and seeing the power of God working in his life and inn the lives of others, and Josh Clayton looking at the impact water has on us and the life that it brings.

The Bush Deacon–Josh Clayton–Rain (After years of drought, we finally have rain, but as Josh observes, the absolute devastation that rain and floods have caused in so many parts of our world over these last few months and years makes him ask, why do we always want something different? He says we can learn much from Jesus and the gospel stories to live with what we have and let our faith inform us and help us to understand that challenges placed before us help us to encounter God and help us to enable others to encounter God. Josh says there's something beautiful about rain. There is something beautiful about water, and especially the impact it has on us and the life that it brings, and most importantly the waters of baptism that changes us forever.)

The Bush Deacon–Josh Clayton–Elizabeth (Josh wonders why the death of Her Majesty the Queen has had a large impact on so many. For Josh it was her genuine faith, and how that transformed her life and helped her to see the calling she had every day. From her life we can learn about faith and about vocation. We may not get a tiara or crown put on our head, but we can live our life as God calls us to, in a way that will transform lives and be the people God calls us to be.)

The Bush Deacon–Josh Clayton–Firepits (Josh has been pondering why firepits draw us in to the experience of sitting around one, staring in silence at the dancing flames. It's a little bit like when we take time for silent prayer. Where we just allow ourselves to be in the moment, to not be rushed, to not talk, but to just be silent and be with God. Jesus did that a lot. He went away to his quiet place went away and took time away from everyone else. In our world that is so loud and so busy, maybe we all just need a little bit more silence. Maybe we all just need a few more fire pits in our lives, the times to sit and look at those flames and hear what God is saying to us. God will talk to you more than you probably realise or even expect.)

Billie Branham talks with Josh Clayton, an online gamer using platforms to walk with people through hard times and share his faith.

Billie Branham talks with Josh Clayton, an online gamer using platforms to walk with people through hard times and share his faith.

On The Journey This Week: Fr Slawek Plonka's Gospel reflection on a baptism of fire to immerse us fully in God's love. Mother Hilda reflects on a famous poem, “The Prophet.” Plus, a faith testimony from Verity Lebeter (Caloundra, Qld), Fr Mike Delaney on dealing with challenging questions of five-year-olds during school visits, and Josh Clayton reflects on the life of Jason, a person on the edges of life, who challenged us to realise that sometimes being a follower of Jesus isn't as one-dimensional as we like to have it.

The Bush Deacon–Josh Clayton–Jason (At a recent funeral Josh reflects on the life of Jason, a person who had always been on the edges of life, always been on the edge of community life, of church life, but that always taken part in so many different things in the wider community. One of the challenges about Jason was he didn't really fit the perfect mould of someone going to church. He challenged us to realise that sometimes being a disciple, sometimes being a follower of Jesus, isn't as one-dimensional as we like to have it. Jason was being more than just himself, he was being Christ to us, and it gave us a chance to help him as well and to be Christ to him and I wonder whether we noticed the Jason's in our lives. God bless Jason, God bless all he helped to encounter God in a deeper and stronger way.)

On The Journey This Week: Fr Joseph Murphy's gospel reflection on praying just like Jesus. Mother Hilda's moving Amen prayer story. Plus, a faith testimony from NET member Michael Adams, and Josh Clayton making a thousand sausage sandwiches.

The Bush Deacon–Josh Clayton–Sausage Sandwich (Josh joins a community event bringing people together to share their experiences of the last couple of years of Covid, bushfires and floods. He finds his practical calling on the day is to join with his children helping cook a thousand sausages. The day's activities remind Josh of the importance to go out, join the community spirit, help others, and see it as a practical way of sharing the love that Jesus expressed whenever he was feeding the multitudes. Stepping outside our own little circle lets us get to know and understand ourselves and our community better, creating an opportunity to live out the mission Jesus asked us to do.)

The Bush Deacon–Josh Clayton–Encountering Jesus Back Pocket (Deacon Josh says it's by sharing the scriptures with others that enables us to encounter Jesus in the same way that the disciples did when they were on the road with Jesus. Josh says spend some time this week reading a scripture passage and then share it with someone else, reflecting on what it would have been like at the time with Jesus and then what it's like for us now. Make your sharing encounters even easier by getting a pocket edition of the gospels and carrying it with you ready for your next sharing encounter.)

Steph is joined by a very special guest and fellow thoughtboter, Rob Whittaker. ngrok (https://ngrok.com/) Time Off Book (https://www.timeoffbook.com/) Rob's Codespace Setup (https://github.com/purinkle/codespace) Rob Whittaker on Twitter (https://twitter.com/purinkle) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. STEPH: I think the fancy term for that is just delegating. [laughs] ROB: Yes, thank you. [laughs] STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. STEPH: Have you found any helpful strategies to normalize that take a break culture? ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? ROB: Yeah, let's wrap up. CHRIS: 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 hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! 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.

On The Journey This Week: Fr Rob Galea's tribute to mothers on Mother's Day and Good Shepherd Sunday. Mother Hilda's prayer to start each day. Fr Mike Delaney's memories of rainy-day productivity. Trish McCarthy putting on Isaiah's clothing, plus the bush deacon, Josh Clayton on Easter invitations.

The Bush Deacon–Josh Clayton– Easter Invitation (Josh reflects on the stories in Acts of the Apostles and how the apostles shared their own experiences of the resurrected Christ with each other and then others in the wider community. He remembers how an invitation given to him to join a faith group changed the direction of his life and asks to remember a faith experience or invitation that changed our life. What's stopping us from inviting others to join us on the faith journey with the resurrected Christ.)

The Bush Deacon–Josh Clayton–Invitations (Josh asks why is it so easy for us to invite people to social events yet we are reluctant to invite the same people to a faith event? He uses an example of a recent Bathurst youth event that took a different approach to invitations and tells of its outstanding success. Each Year 10-12 student was given only a few personal invitation cards that they could use. The result was each participant focused on inviting those they thought would benefit by coming to the event. Josh wonders if we become more intentional about who we invite to share our faith with, such as those who know us well in our social circles who we think would benefit from being part of our faith gatherings like Alpha, we would enjoy greater success and have the joy of more of our mates and friends sharing our faith with us.)

The Bush Deacon–Josh Clayton–First Do No Harm (COVID has made us more conscious of how we interact with and impact upon others. Our lived experience has been an opportunity to change our attitudes and behaviours towards others, being more conscious of how our decisions & actions impact others. Have we used it to revamp our discipleship, to be Christ-like in all that we do)

Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed. Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding. Together they answer a listener question who asked for advice on crafting project estimates for clients. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. Newton (https://newtonhq.com/) Subscribe to Email Newsletters in Feedbin (https://feedbin.com/blog/2016/02/03/subscribe-to-email-newsletters-in-feedbin/) GitHub - Shopify/packwerk (https://github.com/Shopify/packwerk) Sunsama (https://sunsama.com/) TickTick: To-do List, Tasks, Calendar, Reminder (https://ticktick.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: I am now recording. STEPH: Me too. CHRIS: [laughs] That's my recording voice. STEPH: [laughs] CHRIS: That's how you can tell. STEPH: I just like how it sounds suspicious where we're like; I'm now recording, so be careful. [laughs] CHRIS: This is now on the record. 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, what's new in your world? STEPH: Hello. Happy, happy Friday. Oh, I have something that I'm excited or intrigued about. I don't know. Okay, I'm hyping it up. [laughs] But I'm realizing I'm also very skeptical of it. CHRIS: This is the best sales pitch I've ever heard. I'm so excited to hear what this is. [laughs] STEPH: I am trying a new email client; it is the Newton email client. And I so want to love my inbox. I want to check on it. I want to help it grow. Okay, that's the opposite. I want to help get through all the emails that come through, but I just want to love it. I want it to be a good space that I want to go to. And I just hate email so much. And it always feels like this chore that it's really hard for me to bring myself to do, but yet it's really important because a lot of good things come through email. So this is my rambly way of saying I'm trying the Newton email client because I saw on Twitter from Andrew Mason, who has very similar feelings that I do about email, where we are just not fans of it. And we rarely check it and have declared email bankruptcy at several points in our life. And he's also one of the co-hosts for Remote Ruby. But I saw on Twitter that Andrew was talking about the Newton email client and how it actually made him feel that he enjoyed writing and looking through his inbox. And I was like, yeah, that's the sales pitch I need. So I'm giving it a go. It's been only a couple of days. But one of the nice things I have noticed about it is it's very focused, and there's not much noise, and it actually feels like very minimal design where if you open up like a new email, so you're opening up a new draft, there's no much noise. You get to just focus, almost like you're writing a little blog post or journal post or something. It takes away a lot of the noise. While in Gmail, it's going to open up a small window in the right, but then you still have the rest of the noise that feels distracting. So I like that very intentional like, hey, you're just doing one thing, just focus on this. And then also you can integrate other email accounts as well. So you can have one-stop shopping versus Gmail, then you have to click around and sign in, sign out, or visit different email accounts. So we'll see if it helps improve my email life, but that's something new I'm trying. CHRIS: Very interesting. So you're fully on inbox zero life now. That's what I'm hearing. [laughs] STEPH: Ah, hmm. I don't want to lie to you. [laughs] We have a good friendship. I won't start lying now. CHRIS: I appreciate that. So you're halfway to inbox zero. You're not even entertaining that idea, right? This is just you want a better tool to do email. STEPH: Exactly. Inbox zero is not incredibly important to me. But I do want to make sure that I know that I've seen everything important, and I know where to find things. And then making sure that I am responding to people in a timely manner. Those are more my goals. Inbox zero, if that supports it, then great, I'll work on it. But not necessarily that has to be the goal that I reach. CHRIS: Gotcha. I'm not seeing Newton, but I'm intrigued. Particularly on mobile, I have the Gmail mobile app, and that has unified inbox, which I appreciate. But Gmail on the web does not, and I find that odd. And I've never found a mail app that I enjoy because I want some of the features of Gmail. I want to do Gmail snoozing because I still want that to be consistent and whatnot. And to be honest, that's the main way that I get to inbox zero. I just say future me will have more time. I actually tweeted recently. It was a screenshot from my Saturday inbox, which I think was 15 emails that I'd snoozed from the previous week into Saturday morning. Because I'm like, Saturday morning me will have so much time, and energy, and coffee, and it'll be great. And then it became Saturday morning and, ooph, what a view. STEPH: [laughs] Yeah, your snoozing tip has been life-changing for me because that's not something that I was using all that much. The two things are, one, schedule send so that way if I do have a sudden burst of energy and I want to write an email, but I want to make sure that person doesn't get notified until a decent time. Being able to schedule an email and snoozing is amazing. I think Newton and Gmail have pretty much similar features. I was trying to do a comparison. I was like, is there something really snazzy that Newton does that Gmail doesn't already give me? But it looks like they all do about the same, having those important features like snoozing and then also being able to schedule emails. So I think it really just comes down to a lot of the UI, and there may be some other stuff I'm missing since I'm new to it. But that's the main appeal for me right now is the focus and the look and feel of it. So then maybe I will find looking through my inbox a more zenful experience, I think is how I saw them advertise it. CHRIS: Well, I definitely look forward to hearing more as you explore this space. I will say looping back to what you were just commenting on around deferred send, which is definitely something that I use, but you described one of the reasons that I use it. So the idea of wanting to be respectful of someone else and not send them an email on Sunday night because you happen to be working at that point. But you don't want to put that on their plate. I would say equal amounts; that's the reason I use scheduled send. And then the other reason that I use scheduled send is please, for the love of God, I do not want another email back in my inbox. So I will reply to something such that now I'm done with that, but I will schedule send it for the next morning. Because tomorrow morning me can deal with whatever reply this generates. There's some adage; I don't know if it's an adage, but the idea that every email that you send generates 1.1 emails in reply. So emails just have this weird way of multiplying. And so if you send one out there, you're probably going to get something back. And so often, if I'm trying to clear my inbox, I don't want to get another email in my inbox at that moment. So I will not actually send the reply. I will schedule it for a future time because I do not want to hear. I want no new inputs at this point. I'm trying to process them. So that's part of why I use deferred send. STEPH: I had not thought of that, that yeah, that if you schedule it for tomorrow, you've really gamified this inbox zero because you're like, yeah, if you send something, then you might get an email back. But you're like, if I wait till tomorrow to send it, then I'm less likely to have another email, and then I've hit inbox zero, and I'm set for the day. I like it. It seems helpful. CHRIS: Yeah, inbox zero sounds like an altruistic thing, but it is not. It's a way to force myself to have to make decisions, which is something that I want to get better at broadly. And that's part of the role that I have now. A lot of what I'm interested in exploring is just getting better at making decisions, being more decisive, being more action-oriented. Because I just have a tendency to make many, many spreadsheets and think about stuff for a while and take a long time to make a decision. But I don't get to do that, particularly now. But broadly in life, that's probably not the right mode to be in. So inbox zero is another thing that forces me to deal with things rather than just be like, I don't know, I don't know, I don't know, and keep looking at the same thing over and over. So just more thoughts about inbox zero, but now I'll stop talking about it. STEPH: I do like that, though. And you're totally right; it can be a very helpful constraint. And I think that's sometimes why I fight it because then I haven't curated my inbox enough that then when I go to it, there are so many interesting things that then I feel a little bit overwhelmed where I'm like, oh well, I want to read this, and I will look at that. And this seems interesting, and maybe I should be a part of this. It feels like one of those like; you could be a part of these ten amazing things. Do you want to be a part of all of them? And given a person that it's hard for me to say no to or recognize that no, I'm just going to not do anything with this, that is hard for me and would be a good skill for me to hone in on and practice and make quick decisions and be very realistic. Because I used to be subscribed to more newsletters, and then I finally had to stop subscribing to them because it had that same effect on me of that FOMO of like, I'm missing out on this great article or this great video. And I've become more honest with the fact that my Saturday morning self isn't going to want to read through a bunch of newsletters and videos about coding, that I'm going to want less screen time. So that is a really good constraint and helpful skill to cultivate for sure. CHRIS: All right, I said it was done, but one more thing. I feel like I've mentioned this in the past, but Feedbin is the thing that I use for RSS. I still believe in RSS as a technology. But everyone's moved to newsletters these days that go via email. Feedbin gives you an email address that you can use to subscribe to newsletters, and then they do the job of converting that into an RSS feed. So for me, I take something that was now a push into my inbox, and now I can pull whatever I want from that RSS feed. And on Saturday morning, if I'm feeling like, with a cup of coffee, I can enjoy some newsletter about all the new hot tips in Svelte land or whatever it is or not. But it's not clogging up my inbox. And with that, I think I'm actually done talking about inbox zero. [laughter] STEPH: Yeah, that's a nice separation. We could keep going. I have full faith in us that we could keep going about this. But I'll share a slightly different update. I've been implementing a suggestion that you provided a couple of weeks back where we were talking about Rspec's selective test running and how some applications will speed up their test. If you change one part of the codebase, then perhaps you only need to test this chunk of test. You don't actually need to run the full test suite. And that is complicated and seems hard to get right, and really requires understanding boundaries. But then also knowing Ruby, then how do you really identify? Do you really know where this method is being called and can identify all the tests that need to be run? I think we'd mentioned before there's a really good article from Shopify where they have worked on this and created an open-source project called Packwerk. So we can link to that article in the show notes. But more specifically, you suggested, well, what if you just change a test file? That seems very low stakes and also has the benefit of creating a reward where if someone does see something that they can improve in a test, then that's a very quick feedback. Let me just get this change. It's going to be fast on CI. I can merge it right away and also saves time on CI. So I've been working on implementing that change. And it's one of those the actual change is easy, like checking with Git to say, "Hey, what files have changed?" Does it have an _spec.rb at the end of it? Great. Does it not? Okay, we've changed some application files. So let's run the full test suite. That part's easy. Getting it integrated into the build system has been more complicated just because this team has done a lot of work around trying to improve and speed up their test. And there's a fair amount of complexity that's there. So then figuring out a way to stitch my change into all the different build processes that take place has proven to be more difficult. But it's also been insightful just because it has now helped me really understand and forced me to learn, okay, what are all the different steps? What's important for each one? Where can I cut off the rest of the running of the test and instead just focus on running these tests? So in some ways, it's been challenging, but then on the positive side, it's been like, okay, well, this has taught me a lot about the existing system. So at this moment, it is still a work in progress. I'll have more updates in the future. I am excited to see the rewards. I've gotten to the point where I just have a proof of concept where I've gotten pushed up, but it's not production-ready. But it's at least I just wanted the feedback that I'm in the right spot and that we're running just the right test. And so far, it does seem like it's going to be a nice win, even if it's maybe not used by everybody because it's probably rare that someone is altering just a spec file. But for people who are looking specifically to improve the CI build time and working on tests, it will be very helpful to them. So yeah, I'm sure I'll have some more updates in the future. What's going on in your world? CHRIS: Well, I definitely look forward to hearing more about that. However, we can improve CI speed; I'm super interested in that as a topic. Mid-Roll Ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. CHRIS: Well, similar to your email adventures, I continue on my search for the perfect to-do list. It's not going great, if we're being honest. [laughs] To be clear, because I've mentioned this on a few different episodes, I'm not spending much time on this at all, some but not much. And so it's not really moving. But there are two interesting things. I took a look at TickTick, which was one that I mentioned in the past, a tool for this. It seems good. It seems like an intersection between things, which is what I'm currently using, Todoist, which I've used in the past, and some other tools. So I think I'll probably explore that a little more. It seems like a good option. Decidedly, the most interesting thing is a tool called Sunsama, which is different in some interesting ways but very interesting. So one thing to note about it is it's $20 a month, which is a lot of money for one of these tools because most of them are like, "We're $20 forever, and then it's free." And it's a surprisingly low-cost space. And so, they're definitely positioning themselves as a more costly entry. I would be fine with paying $20 a month for a tool if it really is like, no, cool, I feel great. I'm more productive. I'm happier when I'm not working, et cetera. But what's interesting is they seem to do a let's reach out to all the places that tasks can live for you. So there's your inbox for email. There's your Trello board that you've got. There are GitHub issues. There's Slack. There are all these different sources of potential tasks. And they do a really good job of integrating with those other tools and then allowing you to pull that list into Sunsama and then make each day you have a list. And those items can be like, this is a reference to a Trello card on that board. This is a reference to a Slack conversation over there. So I'm super intrigued by it. It's also got a very intentional plan your day mode, which I like because that's one of the things that I'm really looking for is at the end of the day, I want to clean everything up, make sense of all of the open items, and then reprioritize and set up for the next morning so that I can just hit the ground running. That said, I tried it, and it just didn't quite click. And I think it's one of those it takes some effort to understand how to use it. So I'm not sure that I'm going to get there. But it is super interesting because that idea of our work lives in all of these different tools these days feels very true. And so, something that is trying to act as a hub between them to integrate them is very interesting to me. Again, I haven't really gotten anywhere on this. I'm kind of just reading blog posts, as it were. So I'll report back if that changes, but -- STEPH: The search continues for the right to-do app. Yeah, that seems interesting. I don't know why I'm feeling hesitant towards it. I'm one of those individuals...you're right; there are so many tools. And the fact that they integrate with a lot of them seems really nice. I'm at the point where I just grab links to stuff, and I'm like, hey, if this is my priority, I grab a link to a Trello ticket, and then I just copy that into my to-do. I guess I like that bit of work over having to integrate with a bunch of different platforms. Because once you get used to integrating...I don't know; I'm just rambling. But I wish you the best on this journey. I'm excited to hear more. [laughter] CHRIS: Thank you. I will certainly report back. But yeah, nothing pointed to share at this point. But I do have something pointed to share on the hiring front, which is that we have hired some folks. STEPH: Hooray! CHRIS: Yay. So this has been a fun saga across a couple of different episodes. And in my mind, it feels like this much longer, more drawn out thing, but it's; actually, I think, come together relatively quickly, all things considering. We've got someone who's starting in a little over a week's time, and then someone else who's starting in, I think, two or three weeks after that. So that'll be great. Hopefully, we can transition into onboarding, which is a different whole approach. But hiring as a distinct activity can scale back significantly. As we discussed last week, I want to be in the always be hiring mindset but in the more passive mode of having conversations with folks, staying connected. And if a great candidate comes along and it's the right time, then bring them on the team but not actually actively reaching out and all that sort of stuff, which will be great. Because it turns out that takes a lot of time and also a lot of energy for me. Having those first conversations, going into it very intentionally trying to communicate about something, and there's a tone of salesmanship to it that is not my natural resting state. So I come away from each conversation being like, that was fun, but also, I'm drained now. Why am I so drained? So not having that be a thing that is filling up my calendar is great. And also super excited with the folks that'll be joining the team and to be able to now grow our little team and define the culture and the shape of the groups that we will be collectively. I'm excited for that work and what we can build together. So yeah, it's an exciting time. STEPH: That's awesome. Congratulations. Because yeah, everything you're saying sounds like it's just been a lot of work. So that's very exciting. There's someone that I was chatting with earlier today where they were talking about the value and the importance of understanding what your natural skills are and the things that bring you energy. And so you're mentioning there are certain activities that you enjoy them, but they're also draining because perhaps they are on the outer boundary of what you might define as your own natural skill or the things that get you really excited. And I found that all very interesting. It had me thinking about that today about where are the natural areas that I find that I get energy that are easier for me? And then making sure that I'm trying to prioritize my day so that I am more focused on the activities that just align with who I am and also that I'm engaged with and then also looking for ways to stretch. But they made the point that if you are always in a space where you are not using your natural talents, and you're always having to stretch, then that can be what leads to burnout. Versus if you're in that sweet spot, that zone of where you are using your natural skills, but then also stretching a bit. And I think there are some assessments and things like that that will help you then determine what are my natural skills, and what do I like to do with my time? I just like that style of thinking and recognizing, like you said, like, hey, I did a thing. It was fun, but I'm drained. So now I know that this is something that requires more effort for me. Like hiring, that's one for me. I really like interviewing. I like talking with people, but I'm so nervous for them because I know interviews suck. [laughs] I just have so much empathy for them where I'm like, this is going to be a hard day. We're going to make it as pleasant and positive as possible, but I know this is a hard day. And so I feel like I'm in it with them. And so afterwards, I feel that same relief of like whoo, okay, interview day is over. CHRIS: I don't know that I quite achieve the same level that you do but in no way am I surprised that that is your experience of hiring. And just to name it, you're a wonderful human being that feels for the people on the other side of the hiring table. Like, oh my God, this must be so stressful for you. It's so kind of you to be in that space with folks. But coming back to what you were saying a moment ago, that idea of, like, understanding where your strengths are and where they're areas that you're not quite as strong. And I think critically, the question of like which are the ones where I want to just kind of say no to? I'm like, that's fine. This is not going to be a competency of mine. And I'm going to just avoid that or find other people to work with that balance that out. So for me, sales is the thing that I don't think that's ever going to be my bag. I don't think I'm ever going to move in that direction, and that's totally fine. Whereas decisiveness, which I was describing, is like, I think that's the thing I could get better at. That is one that I don't want to sleep on that. I don't want to say, "That'll be fine. I'll just have other people make the decision." No, I need to get better at making decisions, making decisions with less information or more rapidly, having a bias towards action. All those things I think will be deeply beneficial. So I'm trying to really lean into that. Whereas yeah, again, the sales stuff I'm like, yeah, and there's plenty of examples of this otherwise. But I've also been coding a bit more this week, which has been lovely because the hiring stuff has ramped down. And that has freed me up amongst some other stuff that's been going on. And you know, I like to code, it turns out. It's fun. I just clack about on my cherry brown keys, and it's great. STEPH: Do you remember when we first got introduced to mechanical keyboards, and we had co-ownership of one of the keyboards? And we literally had days of where it was like your turn to use the keyboard. And then it was my turn to use the keyboard. How long did we keep that up before we were finally like, we should just buy our own keyboards? CHRIS: It was a while because we were working with a colleague who was trying out a Kinesis, I want to say, one of the split little bowl of keys. But yeah, we had a shared custody over a keyboard, and it was fantastic. I remember that very fondly. STEPH: The days that it was my keyboard, I would go to the office and be like, oh, today is my day at the keyboard. This is great. This is going to be such a wonderful day. [laughs] And now I'm just spoiled. CHRIS: It went on for a while, though. And this was something where we both obviously enjoy this keyboard. Why don't we just buy one of these keyboards? We totally could have done that. And yet, for some reason, both of us were like, no, but what if...I got to think about this. Again, decisiveness. [laughs] We come back to this topic of well; I had to really think about it. And then somebody got the 92-Key test or whatever it was in the office. And so I just went over and poked every one of those for a while. STEPH: Exactly. It was option overload where we're like, well, okay, we're going to buy one, and then you open it up and search, and you're like, oh, you want options? We have options. Do you know about the blues, and the browns, and the colors, and these different options? Like, I don't know any of this language that you're talking about. I just want to clackety-clack. So yeah, it took time. We had to do our research. CHRIS: And then I ended up on basic browns. So here we are. Let's see, popping back up the stack a couple of levels, hiring that went on for a while. Now it is less going on. Although to be clear, like I said, always be hiring. So if anyone out there in the world is hearing what I'm talking about with Sagewell or seeing any of the stuff that I'm putting on Twitter, which isn't much, I occasionally just post screenshots of my commit messages, which recently included better snakes as a commit message. [laughs] I have to dig into that or not. But we were just doing some snake case to camel case conversion. But the commit message was better snake, so here we are. Anyway, if any of that sounds interesting, please do reach out. But I'm excited to transition back to focusing more on the work. On that note, actually, I'm going to call it interesting things that is happening right now organizationally is; we are working with an external security firm to help with some...they helped us out with a penetration test when we needed that. And then they have stayed on retainer and are helping with various different configurations, taking our AWS S3 buckets and making sure those are nice and secure, and all that kind of stuff. But we've recently started to focus more on organizational security, specifically a bowl of acronyms. We've got SSO for single sign-on, MDM for something device management. I don't know what that first M is. I probably should learn it, but it's fine. That's why I've got help on this is I think they know what the acronym stands for. But so we're working on each of those. And on the one hand, they're probably going to be kind of annoying, like having to go through the single sign-on. It's a whole thing, and it's harder to sign into stuff sometimes. I mean, ideally, it's actually easier. But in my experience, it adds some friction at some points. And then MDM means that there's now some profile manager on the computer. So I can say like, "Every computer must have full disk encryption or else you can't use it. And we need a passcode, and it must be this long and those sorts of things." So it's organizational controls that I think are good for us having a robust security setup throughout the organization. But yeah, they're the sort of things that I think historically, I probably would have, as someone working in an organization, had been like, do we have to? Do we need these things? Couldn't I just do whatever? But now there's something about it that I really like. I'm trying to name it in my head, but I'm kind of like, I don't know. This feels like growing up as an organization. And there's always weird corollary that I've been thinking about with the Rails app that we've been building, intimately familiar with just everything that's going into it. And I know the vast majority of lines of code. I haven't written them all, but I've had an eye on all of the different features that we're building in. And it's hard to get out of that headspace where it feels like a bunch of pieces. It doesn't feel like a hole to me, even though it definitely is. But when does a bunch of boards that you nail together become a boat? To make a really weird analogy because that's what I do; it's a hobby of mine. But when does that transition happen? At some point, certainly. But that's harder for me to see on the code side. And organizationally, somehow getting these things in place feels like the organization sort of an inflection point for us, a growth point, which is I'm really excited about it. Even though they're probably going to mean a ton of annoying nuisance work for me because I'm the person in charge of making sure it all gets rolled out. And anytime anyone locks themselves out of an account, I have to help with that. And so it's probably just putting a bunch of annoying work on my plate. And yet, I don't know; I'm kind of excited about it. STEPH: I feel like that shows our roots in terms of how we approach projects that we work on where you mentioned do we need this? Do we need this yet? Because I feel that we're constantly as developers and consultants just we're trying to advise on the more simplified do we need this? Is this the right thing to spend the money on? How do we know? What are the metrics? What does success look like? And all those questions. So I feel like the way you just phrased all of that just really shows that sort of mentality that you grew up with in terms of checking in, and yeah, it's cool. Like you said, you're at a growth point where then it's like, yes, we are at this point that I've asked myself all those questions, and we're here. This feels like the right next step. CHRIS: I like the way you described it as that you grew up with, my formative growing years at thoughtbot. Mid-roll Ad Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Well, switching gears just a bit, we have a listener question for today, and this one comes from Stephanie. So not me, another Stephanie in the world. Hello, other Stephanie out there in the world. And they wrote in, "Hi, Steph and Chris, fellow software consultant here. And I'm wondering if you'd consider talking about how to craft a project estimate for a client on the pod. It's such an important aspect of consulting." Amen. I added the amen. "And I feel like I'm very much impacted as a project team member when the estimate isn't accurate." Double amen. So true. [laughs] "Would appreciate any and all thoughts, especially since it might be part of my job in the future. Thanks." I just realized I put us in consultant church by adding all those amens, but here we are. [laughs] CHRIS: I'm glad you clarified that they were additions by you and not part of the original question coming in. STEPH: Sure. I don't want to speak on behalf of Stephanie. So I have some thoughts on the matter. I think there are a couple of different ways that we can talk about this particular question because I think there are different formats as to when you're estimating and who you're providing the estimate for. But I'm going to pause because I'd love to see what you think. How do you go about approaching crafting an estimate? CHRIS: Sure. I'm happy to share some thoughts. And for a bit of context, this question came in to us, frankly, many months ago, but I did send an initial reply to Stephanie because I know that sometimes we take a little bit of time to get back to folks. So if ever you do send in a question, know that one of us will probably respond via email earlier, and then eventually, will make it on the show. And again, just to say, we do so appreciate when folks send in these questions. It's an interesting way to shape the conversation and a way to get topics that you're more interested in into the fold here. But so the two main ideas that I shared in my initial reply were, first, is an estimate really necessary? I think that's a critical question because an estimate implies that this thing is knowable. And as many of us, probably all of us, have found out at some point in our lives as software developers, it's really hard to do software estimation, like wildly difficult. And not just the thing that we'll eventually get better at it, which you do, but there's just some chaos. There's some noise in this work that we do that makes it so, so difficult to get it right. So pretty much always, I will ask, like, do we need to estimate here? What if, instead, we were to flip the whole question on its head and say, let's set a deadline. Let's say two months from now that's our deadline. And let's ruthlessly reprioritize every single week to make sure that we're building something that's meaningful, and we're getting there. And obviously, we have to have some general idea of what we're doing. Is two months a meaningful amount of time to build a rocket to go to Mars? Probably not. But is it enough time to build an app that can allow users to sign in and manage a simple list of items? Yeah, we can definitely do that, and we can probably add a bunch of more features. The other thing that I think is worth highlighting is there's a bunch of stuff that is table stakes and very easy to do. But I would, whenever doing estimation, emphasize unknowns. So, where are the external integrations with other systems? Where are the dependencies that rely on other folks to provide some inputs into this process that we can't be certain where there'll be? In my experience, the places where estimates go awry are often these little intersection points that you're like, well, this will probably take a day, maybe two. And it turns out; actually, this can somehow balloon into a month. That's not a thing that feels comfortable saying in an estimation process, but it is definitely real. I've seen it happen so many times. And so it's those unknowns. It's those little bits that I would emphasize as part of the process if you do need to do an estimate and say, all right, here's the boring stuff. I think we can do that pretty easily. But this part, I don't know, it could be a week, could be three months. And frame it in that way that there is this ambiguity there. Because if someone's asking you for an estimate and they're looking for like it is seven days and two hours exactly, it's like, well, that's not realistic. That's not how this thing works. Unfortunately, I wish it did. But pushing back and changing the conversation is the thing that I have found valuable. I think there's some other really interesting stuff in here around the team dynamics that Stephanie is talking about. But I want to send this over to other Stephanie to see your thoughts because I'm super interested to hear what you have to say as well. STEPH: Oh, I like how you hinted at the team dynamics. Yeah, that could be a fun one to circle back to. So I love how you called out highlighting the unknowns. There are a couple of ways that this comes to mind for me. So there's the idea of the weekly or the bi-weekly estimates that we make as developers and designers. So let's say we as a team are getting together to focus on a chunk of work and decide what we can and can't get through. And that feels one of those the more you get to practice it more frequently; you get to ask a bunch of questions. And that feels like a good rehearsal and exercise of how to go through estimates. And I know you and I have pretty similar strong feelings around how those estimates are then treated by the company. They should really just be used for the team to talk through the complexities in the work to be done versus used to communicate outwardly as to this is when it's definitely going to ship. So there's that more immediate practice of providing estimates. And then there's the idea for more of a consultancy or a company, and someone is coming to you, so thoughtbot being a great example of then how do we work with teams that are looking to come to us and gain an estimate for getting a certain feature implemented? So actually, I went to the source on this one. I went to Josh Clayton, who does a lot of the conversations for the Boost team when it comes to talking with clients and about the potential work that they would like to be done. And mostly our work is often teams will hire us. They have specific goals in mind, but they're really looking to hire ongoing development and services. So they really want to add to their existing staff. And then it's going to be an ongoing relationship versus a hey, we need you to quote us for how long it's going to take to implement this particular feature. And on that note, we don't do fixed-bid work. So we don't say it's X dollars for specific features. But on the realistic side, customers are often capped by a budget. And so that estimate is very important to them because it could be a difference between it's a go versus a no go. So if you have larger companies that are like, "Yep, we want to engage with thoughtbot. We really just want additional development power and design services," that's great. For those that are smaller, it could be an individual product owner, and they need to say, "I really want this feature, but I only have this much money. And frankly, if I can't ship it by this time, I'm not going to do it because it's not worth the investment to my company." And then, in those cases, those are the ones that we're going to spend more time with them to talk about what does the fallback plan look like? And what's our opportunity for simplifying the features? And Josh, in particular, referenced this as systems thinking. So he will go through the idea of drawing out the set of steps, understanding the complexity of the different screens. So what are the validations? What are the external dependencies? What is owned by us and what isn't? What is the likelihood that we're going to get permission to simplify or remove complexity? And even then, when we start to provide some estimates, it's going to be in weeks. It's not in hours; it's not in days. It's going to be in a slightly larger time frame. And then we're also going to spend more time in the discovery phase to say, okay, well, we know you need to fix this particular issue, or you need to integrate with this particular service. So we're going to need to ask a lot more questions about your codebase. What problems have you already run into? Have you tried to do this before? Do we have experience doing this? Is this something that we can lean on and ask someone in the team? And, say, how long do you think it would take for us to work on this? And that's knowledge that isn't privy to everybody. It depends on where you're at in your career as to like, oh yeah, I've done this like five times before, and I know exactly how this stuff can fall apart. I know where the complexity lies. So I think that's why estimation is so difficult is just because it does often pull from that existing experience. And so, if you don't have that experience for a particular set of work, of course, it's going to be hard to estimate because you just don't know. So that was a very broad scope of as day-to-day developer and designers; I feel like we're constantly getting practice and estimating and communicating the progress of our work. And then on the larger scope of if you are a consultant who's then looking to give estimates to clients, then understanding what other need can you sell them? Just ongoing development services. Or, if they are a smaller team and very focused, then what legwork can you do ahead of time to de-risk the project? And then understand how much control you're going to have to be able to simplify as you learn more as you go. Because you're going to, you're going to uncover some things, and you're going to learn some things. And what's that collaboration going to look like? I do have one more concrete example I can provide around some of the smaller projects that we take on. So when we are helping someone that's, say, getting a new product out to market, then we do have a more deliberate three, four-phase approach where we first focus on discovery, and ideation, and validation. And then, we move on to iteration and then launching. And I really like how you said about providing a deadline because then that helps us scope aggressively as to what is the minimum thing that we can get out into the world that will be valuable? And then there's usually some post-launch support as well. But that's often how we will structure those smaller, more specific engagements. CHRIS: I think one of the critical things that you highlighted in there is that thoughtbot doesn't do fixed-bid work. So we're going to do these 20 features, and it's going to take four months. thoughtbot does not do that, and frankly, that's a privilege to be able to take that position and say, "No, no, no," we're not going to work that way. But it is, I think, a trade-off. It's not just something that thoughtbot does to be like, listen, that doesn't sound fun. So I'm not going to do that. It's a trade-off. Not doing that comes in concert with saying, "But weekly, we're going to talk about the work that we have done and the work that remains and constantly, ruthlessly, reprioritize and re-decide what we're doing." And it's that engagement, the idea that you can have a body of work, look at it and say, "Yeah, that'll take about six months," and then go away for six months, and then come back with the finished software. Our strong belief is that that's not the way good software gets built. But instead, it's a very engaged team where the product owner and the development team are in constant communication about each of the features that are being developed. And then again, ideally, on a weekly cadence, coming up for air and saying, "How are we doing? Are we moving in the right direction? Are we getting towards the goals? If not, do we need to simplify? Do we need to change things?" And similarly, as I mentioned deadlines, I feel like deadlines is probably a word that many people think of as very bad because deadlines often come with also a fixed scope, but that can't happen. That's two constraints, and you can't have them fighting that way. But a deadline can be super useful as a way to say we're going to put something out there in the future and say we're heading towards that moment. And let's, again, cut scope. Let's change what we're building, et cetera. But critically, not say, "We got a deadline and a fixed scope. We're going to do that." And so it's, again, just ways to gently shift the conversation around and say, what if we were to look at this from a different angle? Because just having a pile of work and saying, "That'll take six months," I've never seen that play out. STEPH: Yeah, to me, deadline is a bad word when the deadline is set by a team that's not doing the work. So if you have leadership or if you have someone else that is setting this deadline and then just passing that down to someone else to then fulfill, regardless of the feedback or how things are going, then yeah, then it can be a nasty thing, which I think is a little bit of in that question that you picked up on that you highlighted where there could be some interesting team dynamics that Stephanie called out, highlighting that I'm very much impacted as a project team member when the estimate isn't accurate. And I'm making some assumptions here because I don't actually know the exact situation that Stephanie is experiencing. But it sounds like someone else externally is setting these team estimates. And so then you're handed this deadline, and then stuff goes wrong, but you're still pressured to meet this deadline. And I've certainly been part of projects that are like that. And then that is one of the number one things that then often comes up in a retro or like, we don't have control over these deadlines, or we don't know why these deadlines are being set. And then people are working extra hours and working nights and weekends to then meet this arbitrary deadline that none of us signed up for, and that's just not fair to treat deadlines in that way. So full-heartedly agree that deadlines can be a very positive thing, but they need to be set by the people doing the work. And then there has to be discussions and updates about how is this going? Do we have control to simplify this? We thought we could do this with this particular external provider. It turns out that that's a nightmare. Is there another provider we can go with? Can we ship this incrementally? Like some features, you can't. They may have to go out wholesale. But is there a small chunk of this that we can deliver that is then a success that leadership and others can brag about? And then we can keep working on the rest of it. So it's always identifying what are the smallest wins, and how do we get there and getting buy-in from the team? Going back to something that you said earlier around, it is a privilege, where so as thoughtbot, we don't do fixed-bid work. And that is a nice thing for us to be able to focus on. But for people who do need to do fixed bid work and are relying on that, I think that often requires more legwork. And maybe that becomes part of your estimate. I'm just making up how I might approach this if I were trying to do fixed bid work. But there's a discovery phase that's very important. So maybe the first part of your estimate is I need to really understand the feature and see the different screens and know what materials we do or don't have. What does the codebase look like? Do I feel like this is a codebase that I can work quickly in? And is it going to be hindersome for me? But answering a lot of those questions to then help me paint a picture of, like, okay, this is a feature that I've implemented before, so I feel pretty confident that I could do this in a month. And then also communicating that this is my estimate but just know it's an estimate. And I will continue to update you each day as to how things are going or each week as to how things are going, and things may adjust. And we can always talk about ways about simplifying this. But I think that's how I would go about it is; frankly, it's going to require more legwork for me to feel more confident as to then telling someone as to how long I think the work will take. I think that's a nice, broad scope of the different types of estimate work to be done with the general idea of if you can avoid estimates and go for more frequent updates, then that's wonderful. But then, if you are forced into a corner where you need to provide an update, then just do as much research and honesty as possible and then still include the frequent updates. CHRIS: Yeah, that I think summarizes it quite well. STEPH: As a side note, it's been a lot of fun to feel like I'm referring to myself as a third person as Stephanie is working through this problem. So that's been novel. But yeah, thank you, Stephanie, for the great question. I hope that was helpful. 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 hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!! 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.

Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections. Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. GitHub - asdf-vm/asdf: Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more (https://github.com/asdf-vm/asdf) Factories Should be the Bare Minimum (https://thoughtbot.com/blog/factories-should-be-the-bare-minimum) Mystery Guest (https://thoughtbot.com/blog/mystery-guest) GitHub - varvet/pundit: Minimal authorization through OO design and pure Ruby classes (https://github.com/varvet/pundit) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed. [laughs] CHRIS: Hello, and I'm singing, and I love singing. STEPH: It's Buddy the Elf; what's your favorite color? [laughter] For reals, here we go. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris. What's new in your world? CHRIS: My world continues to be focused on hiring as a pretty core aspect of things. We have happily had one offer extended and accepted, so that's great. We've got a person who will be joining the team in a couple of weeks. That's very exciting. And we're continuing in conversations with some other folks. So I look forward to the place where I can be on the other side of this and have that team and be growing the team and not having to focus because hiring takes a lot of effort. It is something that I believe should be done as well as possible and intentionally as possible and then just outreach and all that. So yeah, I'll be fine with being on the other side of that. But it's going well, so that is nice. STEPH: That's awesome that you're making progress. Once you have hired your team, will you then add to the agenda to hire someone to help with hiring? CHRIS: I don't actually know if the organization, if the whole company has someone who's focused on hiring. I think that can make sense. Working through recruiters and things like that is something that I've seen in the past. I've seen it work for certain organizations. I've also been on the receiving end of plenty of obviously copy and pasted very generic "Hey, person, I saw that you do lots of Java and other enterprise code software. Would you like to come work with us?" I'm like, none of those are true, and I do not want to go work with you. But thanks, I still appreciate the outreach. [laughs] So I am intrigued to see how we think about it. More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open. Networking is perhaps what the people call it. I don't know; I've never felt super comfortable with that word, but I think it's that and being friendly and staying connected with people whose work I respect and would love to work with more. So that's part of what I will come out of this with is yeah, let's always be hiring in a certain sense. STEPH: I'm glad you expanded on it because I was just thinking I have specific ideas as to what always be hiring means to me and what those activities would include. So I was curious what it means to you. And I agree, I think it's a lot of networking. It's a lot of taking chats and social chats with folks and just talking about the company and finding out where they're at. And then one day, if it works out that then they want to make a shift, then you've already got that relationship that started, and they're already potentially interested in your team. I guess some of the other big stuff that comes to mind, too, is like thoughtbot we have the blog. I feel like that's always really helpful too. Like when you help somebody, when you publish information that then helps them in their career, I feel like that will then draw people towards you as well. CHRIS: Yeah, the thoughtbot blog and basically everything that thoughtbot does, the podcast here, or Upcase, or all those things were so incredibly helpful in the hiring. But I also know they're hard to spin up, is what I would say. The thoughtbot blog has I don't even know how many hundreds of thousands of hours maybe. It's weird to try and put a number to it. But I've written a handful of posts for it, and I'm not great at writing them. They take me way longer than they should, but they took many hours. And then I had wonderful peer review by other developers at thoughtbot. And so, the amount of effort that goes into the thoughtbot blog absolutely produces wonderful benefits. But it's not free by any means, and similarly, the podcasts or Upcase or any of those sort of things. Similarly, the one that's actually most interesting that I see a lot of organizations go for initially and then often walk back is open source. Like, oh, we have this internal library that we built to do something. What we'll do is we'll just package it up and share it with the world, and then it'll be great. And the maintenance burden and support necessity of an open-source project is so high. I've actually historically gotten into the mode of suggesting...when I was working with clients, they would start to mention this and be like, "Oh yeah, we think we'll open source this thing, and it'll be great." I'm like, "Are you sure, though? Do you definitely want to?" There's definitely a difference between open sourcing and just putting an idea out there is one thing that I would say. Can you just write a blog post that has code snippets but not reusable code that you have to maintain that people, unfortunately, I think unfairly expect responsiveness and maintenance over time? And what if you stopped using that technology? What if you stop using this thing, but your name is still attached to it? And people have expectations of what that looks like. Or people come in and say, "Hey, this is great, but I want to change it in this way." And you're like, "Yeah, but that actually doesn't work for us. That's not how we use it. But we would be on the hook to maintain that code if we accept your pull request." And so, as wonderful as open source is, I tend to be on the more conservative end of the spectrum of like, are you definitely sure you want to open source this? Is there another way that you can share this with the world? Can it be a conference talk, or a blog post, or something like that? But it is an interesting one. STEPH: Yeah, I've been a part of several teams that have started with that; let's start an engineering blog. And their hearts are totally in the right place, and I understand why they want to do it. But like you just said, there's a cost to that. And if you don't have something like thoughtbot has like an investment day or a time for engineers to then be able to contribute to that blog, then either they're just not because they're not going to have their downtime to be able to do that. And it is hard to write and publish and be happy with what you're going to publish with the world. I really like what you're talking about in terms of the maintenance burden because I can't remember if it was an Upcase conversation or if there was something...but I was early on at thoughtbot and had a similar thought of why can't we just open source it? Why can't we make it public? And there was a very big thoughtful discussion around well, we have to have all these considerations in place. Who's going to maintain it? Just like FactoryBot is a really big internal project at thoughtbot. And there's typically a rotation of folks who will then take ownership and then onboard other people who are interested in it and curate the issues. And it's very important work, but you have to allocate time for it. All of that to say, I totally agree. There's a big burden that goes with it. CHRIS: Yeah, it's interesting that this has been an evolving thought in my head, and it makes me sad is another thing I'll say about it. I wish it were easier to just put code out there in the world and have the expectations properly calibrated for like, hey, I did this thing. Here's a code sample. It worked for me. Actually, I found dropping something in a Gist...a Gist just has a point-in-time connotation to it that I like. Like, if I see a code sample in a Gist, I'm like, I have no expectation that that person is going to do anything or respond to anything I have to say. But this is great because I now have this sample code that helps me get a little bit further. And I may have to vendor that code or take it on myself, and I now own it. It's not this person's responsibility. But the minute you have a repo with a README that says stuff and like, here are the installation instructions, the expectations just flip in a way that I don't think is...at least I become cautious around. And that does make me sad, though. STEPH: Yeah, it feels like you went from offering an example to I'm offering a product. And so then as soon as people feel like, oh, you're giving me something as a product that you maintain, then I'm going to have higher expectations of it should work how I expected it to work. I'm going to ask questions. And yeah, you make a lot of good points. CHRIS: Would you like to pay me $0 for me to build software for you? That sounds fun. STEPH: [laughs] CHRIS: And open source is such a wonderful thing. And so I'm interested in...like, I follow a lot of folks who are in the open-source world and have found ways to make it make sense financially or otherwise or organizationally. Open Collective and things like that is one option or OpenCore and then paid pro models and things like that like Sidekiq as an example. Sidekiq just celebrated ten years with some wild numbers in terms of the revenue, and it's like, yeah, that's fantastic. This is a cornerstone piece of software in the Ruby and Rails community. And also, Mike Perham had a great outcome from it. I think that's a win. So maybe blogging, maybe, but not sure. Probably not open source is my suggestion, at least for me. But one thing that I am interested in that hasn't been an option in my mind for a long time, but I'd love to get back to is conferences and going there, especially with a small team from an organization. The three developers we go, and we hang out at a conference and the company has a space there. And there's room to have conversations and meet people. That is one that I would love to continue in a way of making sure that our name is in people's minds as a place that they could work in this world. It is interesting, though, that it gets scoped a little bit like we are definitely a Rails shop. But that's not all that we are, or that's not the complete totality of our technical identity, so it becomes interesting. But I think it's probably the most representative. And I definitely see the Ruby and Rails community is having a good product-centric mindset that is definitely the sort of thing that I want in the teams that I'm building. STEPH: Yeah, I think that's an awesome idea because it's a way that you could focus on creating content. It'll likely have a big impact. But then you can also replay that content, but it's not the commitment of a blog or a commitment of open source. CHRIS: But yeah, so hiring has been, I would say, most of what I've been doing. One other thing that was fun this week, so I have my new laptop that I've had now for a couple of months, I'd say. And just this week, we had a very frustrating issue where Heroku stopped deploying our application. Just one day, it was like, nah, it doesn't work anymore. And I was like, well, that's less cool than I want it to be. And so one of the developers on the team dug into it, and it turned out Node-sass was the answer, which we're not even using is extra unpleasant. It's just part of Sprockets and Webpack or something like that. There's some downstream dependency sequence. We're using Tailwind and PostCSS. So we don't even need Node-sass. I think maybe PostCSS does. But anyway, turns out Heroku had switched to using version 16 of Node just without telling us. We were previously on 14, and then Node-sass didn't build on that. There was just this weird dependency chain that stopped working one day. And we weren't pinning the Node version within our application. So one of the developers figured this out, pinned us back to version 14 something of Node, and that was fine. But then my computer got confused because the versions were out of sync. Anyway, asdf is great. That's the first thing I'm going to say. So I use asdf to manage the versions of Ruby, and Node, and Yarn, and Elm, and basically everything else that I use. And I love that it's all under one hood, so asdf, wonderful. Also, my laptop, wonderful. I really love the M1 fancy laptop. But what was fun was I had to install the new Node version. And this was the first time in the three months I've had this computer that I've heard the fans come on. Finally, I asked it to do something hard enough that it was like, whoa, whoa, whoa, I'm going to need some backup here. And so the fans finally kicked in. So I don't know what's going on installing Node, but good for everyone involved, [laughter] impressive to make such aggressive use of all of the hardware in my computer. STEPH: Yeah, I love asdf. I miss it right now because I'm on my client machine, and we're not using asdf. Instead, we are using Chruby, C-H Ruby to manage Ruby versions. asdf is awesome. That's fun. It's the first time that the fans kicked on. I'm intrigued with my machine. I haven't really paid attention to it when the fans kick on except the one time where I had like a Ruby process that was running away, and I had to figure out what was going on there. Because then all the CPU was just being dedicated to Ruby even when I wasn't using Ruby. But since then, I haven't heard the fans. It's been very, very quiet. It's lovely. I like when it's quiet. CHRIS: Oh, it's been great. It was interesting because it was this weird noise that I'd forgotten about. STEPH: [laughs] CHRIS: My previous computer was so old that this was happening regularly whenever my backup process would run. Apparently, that is a very computationally intensive activity. So I would hear the fans kick in, immediately go find the backup process and say pause for 60 minutes or whatever it was. Just like, leave me alone. Stop it. The computer is getting too hot. You need to calm down. But now, with the new computer, there was nothing I could do to make it happen. And then finally it happened, and I was like, oh yeah, I guess this computer has fans. That's neat. But yeah, so things that are great, asdf and the M1 laptops. STEPH: Nice. Yeah, you're one of the few individuals I know that's using one of the M1 chip. So it's been reassuring to hear how well it's going because I did not opt in to that new-new. I opted in to the give me something stable and steady that I know so that way I don't have to fuss with it because I can then fuss with all the other things that I need to fuss about. CHRIS: So much fussing to do. STEPH: Lots of fussing. Fussing and cussing is what I do over here. CHRIS: [laughs] Mid-roll ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's New Relic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. CHRIS: Well, speaking of, what have you been fussing and cussing about this week, Steph? STEPH: So this is more in the pranting area, which is our portmanteau for praise and rant, where I'm super excited. I have a delivery coming from Amazon today. So I'm that person that keeps checking and waiting for it to show up. But I'm finally going to have one dongle to rule them all. I have a very messy approach right now [laughs] where I have all the dongles and have to plug everything in. And you know what? Normally it's fine. It's fine because I do it once, and I don't have to mess with it that much. But because I now have my thoughtbot laptop and I have a client laptop, and I needed to be able to switch back and forth, it is just too much. And I was realizing how many dongles I'm having to use. So I have one dongle to rule them all. It's showing up today. It's a very exciting day. CHRIS: I'm very excited for you. I recently made a similar switch when I got this new laptop. I was like, you know what? I'm going to look into it because power can come over USB-C and whatnot. And I was like, all right, it's finally time. I want to be able to just click in. And it's one of those things that feels trivial, or at least in my mind, I'm like, this doesn't feel like it'll make that big of a difference. But it makes it so much easier to disconnect my laptop, go somewhere else, and then come back. And I noticed myself doing that more, which I think is a positive thing. Otherwise, I'm just anchored to my desk. I'm like, I don't want to unplug everything and then have to replug it. That's like a whole thing. But now that it's not, I am more mobile, more flexible in where I'm working from, and I found benefits from that. So I'm a fan. I'm very happy that this is going to show up for you [laughs] and really change the way you're working. STEPH: Well, I've started moving away from a lot of Bluetooth connections as well because my keyboard will support Bluetooth, my headphones support Bluetooth. And I liked the idea of being wireless. But then, especially from switching laptops back and forth and then having to reconnect and all of it, it was just too tedious to go back and forth. And yeah, I'm with you where I didn't want to have to leave my desk and unplug everything and then bring it back where I'm playing, you know, like the game Operation where you had to reach in and then you had to grab different little bones? If you don't know the game Operation, that sounds really weird. But it felt like a game of Operation where then I was having to find all the dongles and connect them and plug them all in. And yeah, so it's going to be wonderful. CHRIS: Even knowing the game Operation, that still sounds kind of weird. STEPH: [laughs] CHRIS: But I really love that there are people out there listening that are like, what are they talking about? STEPH: What weird childhood did you have? CHRIS: Yeah, I'm definitely Team Wired-Almost-Everything. The only thing that I have that's wireless is my headphones. And it only works kind of, and I have to trick them sometimes. And the worst thing is occasionally my computer will have control, whatever, they're connected. So I'm listening to music on my computer and then suddenly, my phone will just steal it. It's like, what are you doing? No. Or, randomly, my headphones will be sitting away from me, and they'll just connect. And I'll be in the middle of a call on something else. Like, I'm here talking to you, and suddenly my headphones are like, hey, we wanted to join the party. It's like no, absolutely not, [laughs] not at this moment, under no circumstances. So I don't really believe in Bluetooth as a technology. I'm very much a fan, particularly with things like keyboards and whatnot. Bluetooth I've yet to be convinced that it is a sound technology. STEPH: I have the headphones where they try to be very smart, and they are pretty smart where they will block out sound. But then, if I am talking, then it will put me in more of an auditory space where then I can more easily hear, and it won't filter out sound as aggressively. But I've noticed a problem. And it's when I'm watching anything that's funny that then I'm laughing. So every time I laugh, my headphones think I'm talking to someone, and then it will switch over to where it's trying to let me hear more sounds out in the universe. And then it kicks back on because it's like, okay, she's done talking. It's a very jarring experience. [laughs] And I haven't figured out how to turn that setting off. It's like, oh, I just can't watch funny stuff with my headphones right now, which is also problematic with pairing because I tend to laugh a lot with pairing. It's a thing. I'm working on it. The struggles of Shteph. CHRIS: Well, at a minimum, it sounds like your dongle life is going to be improving very soon, and that's exciting. STEPH: Dongle life, it'll be single dongle life. That's it. [singing] All the single dongles, all the single dongles. Put your adapters up. [laughter] On a different note, talking about some of the work that I've been doing this past week with Joël Quenneville on our client work, is that we have been looking for ways that we still want to build up CI time. We've talked about the fact that we're working on some of that horizontal scaling. And I don't have an update there. But the other update I have is where we want to be very strategic about where we invest our time because improving the test is not trivial work. A lot of the low-hanging fruit has already been done, so triaging a flaky test can be very difficult, and it can take us a while. So we just want to make sure and verify that before we invest a lot of time into a portion of the test that then we know what the outcome is going to be. Are we improving developers' lives by this much? And how do we measure that? Are we reducing the CI build time, and how do we know that? And one of the areas that I really wanted to focus on is FactoryBot because there are a lot of factories. The factories tend to do a ton. So they are calling out to the database and building a lot of associations. And that's something that the team knows about as well is that there are just so many SQL queries that get executed in tests. And it would be great if we could reduce the number of SQL queries that are going out. And FactoryBot includes some ActiveSupport notifications, which means you can subscribe to factories being run which then gives you access to details like which factories are being used? What build strategy is used? Are you calling build build_stubbed or create? And the factory's execution time. So then the idea of this is that if we can harness a lot of the data that we can collect from FactoryBot, then can we ask questions around what's our slowest factory? How long does it take, and how many places is it being called? Because then ideally, we can calculate to say, okay, if this factory takes this long and it's used in this number of places, then we can have a formula to figure out how many minutes of our test suite is spent just on executing that factory. And then if we can reduce the time of that factory, let's say by half, then we know how much time we're shaving off of our CI build. And then we have this more concrete verified okay; this is worth our investment. We want to pursue this, even if the factory may take us a full day to improve because it does so much. And it's just gnarly. So it's going to take some time to really refactor it into a more simplified state. So, in theory, this sounds really, really great, and it was a lot of thanks to Josh Clayton, who was the one that advocated saying that we could use the ActiveSupport notifications to find a lot of this data. And so Josh and I paired on this for a bit to look into can we answer some of those other questions as well? And we were testing it on a small side project that he had, which was great because the other codebase is very big, and feedback is just a lot slower. So we wanted to first prototype it and have a proof of concept in a very quick space and just to be able to look through the data and make sure the assumptions that we had and the value would be there. So we applied that first, and that was going really well. And then Joël Quenneville took that strategy and then applied it to all the specs in the spec models directory and ran it for the much larger client codebase and got some really great results. And we also used a low fidelity approach where we wanted to be able to see which factories were the most popular. So how often are they getting called? And the average execution time. So that way, we could then quickly look at this scatter plot, and then we could see, okay, who's in the far upper right quadrant? Because those are the factories that are causing the most pain. But we started looking into a graphing library and what are we going to pull in. And Josh had the great idea. He's like, "I wonder if Google Sheets has a scatter plot. Can we export this to CSV data and then copy it from the terminal and import it into Google Sheets?" And it turns out that you can. So then we grabbed it and put it in Google Sheets and then just converted it into a scatter plot, which was really nice because then we didn't have to incorporate any chart library or any graphics or anything. We could just plop it into Google Sheets and then easily share it. So we now have this list thanks to Joël because he ran it through the spec models directory of all the factories that are getting called. And it's really interesting. And there's one, in particular, that is high on the list. And it was actually one of the first ones that we worked with when we were troubleshooting a test that took us a while when we first joined the project. And the average time for this factory is four seconds, and it gets called over 500 times. It's like 527 times. So then if we multiply that, so if we say, all right, it takes about 4 seconds times 527 and then divide it for 60 for minutes, that's 35 minutes, 35 minutes for that factory. Now, granted, these are getting parallelized across different processes. But still, if you divide that up across four processes, that's a non-trivial amount of time. So I think this is going to be really helpful and really interesting data that we can then use to drive our decisions to say, okay, we want to take this factory and let's say even if we can cut it into half, let's say if we bring it from 4 seconds to 2 seconds, it'll go from 35 minutes to 17 and a half. CHRIS: Oh wow, I love the methodical approach. I love that actually having a number you're like; this is how much pain or the cost of this right now. And so we've identified that this is this high-level thing. I love the intentional starting with, like, let's measure it. Let's understand where the most bang for the buck is. In particular, the graph that you're describing reminds me of one I haven't actually worked with it much. But Code Climate has a graph that they use, which is it's churn versus complexity. So it's like, you may have a very complex piece of your code, but someone wrote it once, and it just sits in the corner. And you know what? It quietly does its job. And yes, it's very complex, but nobody needs to touch it. So it's not a big deal. And then you have stuff that changes constantly, but it's super simple, so that's fine too. Your UsersController is probably going to change a bunch; that's fine. But the stuff that is constantly changing and very complex that's the magic quadrant that, like, pay a lot of attention to that. And similarly, which are the ones that are being used a lot and take a while? That's the magic quadrant. I'm intrigued now. I want to search for more magic quadrants that deserve attention. But for now, that sounds like a lot of fun. So now, what's the approach that you're going to take? I imagine you need to alias that factory and have it exist because some tests will rely on certain details of it. This is my guess. So let me see if this is the way that you're thinking about it, alias the factory, so you have a representation that does all the stuff that the current one does. But then you have a new one that is much more pared down. And then, on a test by test basis, you start switching it over and trying to move things to the lower weight, the slimmer version of the factory. But I would think you would want to do a gradual process if there are 520-ish usages. Because otherwise, just changing that factory out from under all the tests, I imagine you'd break some tests if you just were like, what if it did less? STEPH: Yeah, I like that idea of the incremental approach. And that all sounds great, especially the alias because you're right; we want to change it incrementally and not all of them at once. But then essentially implement, one, because I want to see what does the pared-down factory look like? What is the basic factory that we can get away with? And then how long does it take for that factory to execute? Because then that will help confirm, can we really get it down to two seconds? Or is this just a factory that's always going to take three and a half seconds, and then it's not really that much of a payoff? Maybe we should look for a different factory to investigate. And then also understanding from the test are people reaching for this factory all the time because it builds up the world and all of these tests need the full world? Or are people just reaching for this because it does the one or two things that they need, and we can get away with a much slimmer factory? So right now, it's in the space of understanding why are people reaching for this? What are the tests they actually need? And yeah, how can we do it incrementally? At one point, we may even be able to try to programmatically switch it out. Maybe we just find 50 tests that are using this once we have the slimmed-down version and we replace...50 is probably too big. But if we replace X number of tests with this factory, how many of them fail? Maybe 10% of them passed. Cool, let's just take those 10% as a win and issue those as a PR. So that could be a strategy as well just to find if there's any that are super easy to change. All we had to do is literally change the name of the factory. The other big part that's on my mind is education around factories. I think a lot of people on the team understand that factories are very important. They can be very helpful. They can also be very cumbersome. But it feels like a good opportunity to say, "Hey, we are specifically working on these factories. Here's the reasoning that led us to work on these factories. When you're in the space of factories, please be mindful about what are you reaching for? Is there a slimmed-down factory that you can reach for? Maybe you can implement your own slimmed-down factory if one doesn't already exist." So I like the idea of coupling it with also just broader awareness because we are but two people. So I would love for more people to be part of the changes. CHRIS: Unsurprisingly, there are some wonderful blog posts on the thoughtbot blog that speak to this topic. One that I'm a fan of is Factories Should be the Bare Minimum. This was written by Matt Sumner. And it describes basically that idea of factories shouldn't build the worlds. They should give you the pieces that you can use to build the world but not build the world entirely. And so I'm a big believer in that, having your factories be as minimal as possible. They should be valid, but that's about it. And then I will often reach for extracted helper methods and keeping those as locally scoped as possible often in the spec file, or if not, maybe they're sharing spec support. But being intentional with where we reach for them and not having everyone use the same thing that just slowly gets added to. And it's like, do I actually need everything that's in there? The other thing that's interesting is the idea of having a factory that does a ton is, in my mind, sort of in direct contradiction to what I believe factories exist for which is when I think of factories, they're useful to fill in the rest of the details such that you don't have mystery guests in your test. But you can explicitly say build me a user who has an email that looks like this because, in this test, I care about the email, but I don't care about the rest of the details. I don't care about their name. I don't care about their password, or the roles, or any of the other details. Just let the factory deal with that because it's not important to the test. But I want to make sure that the relevant detail is present and specified within the spec. If you have a factory that builds everything in the world, that's like build a user and then grabs the first action from the project that that user has, because I know that they do because they use the big factory, that is just in direct contradiction to what we want factories to do. We want tests to tell their story. We want to avoid mystery guests. Factories are a great way to do that while still remaining concise. But if your factories just build the world, then there are some mystery guests in the world, I can assure you. STEPH: Yeah, I agree where factories have served as an abstraction for what I think is important to the test. But then there becomes this moment of where someone thinks, well, I need to build up these records, but I don't really need to reference them directly. I just have some coupled code that's going to rely on these. And so I don't explicitly need them, but they need to be there. So I'm going to extract it away, and a factory feels like a good place for me to extract that too. And I would take the very hard opposite approach where if you have coupled code and you have these dependencies that aren't necessarily explicitly used in the test, but they are required for the test, I'd rather see a painful test setup than have all of that extracted away from me. Because then if I do need to triage or troubleshoot that test, it's going to take a lot of just mental overhead to work through what do I actually need here and why? So I'd rather see that painful test set up then have it moved somewhere else. But I think a lot of people take the opposite approach of where if I abstracted away, my test looks prettier. And I'm like, yeah, but maybe to you in the moment, but it's going to cause me a lot of pain further down the road when I have to work with this. So show me all the crap that you had to do upfront. Just let me know. [laughs] I'd rather the test be honest with me. And then it's a really nice jumping-off point because you can see a test that does all of this. And instead of blaming the test and thinking it's the test's fault, you recognize this test has a lot of complicated setup, and it's probably because of the code and how the code was written. And we should look at refactoring the code, not at how can we make our tests look prettier? CHRIS: Unsurprisingly, I agree with 100% of that. Someday we'll find things other than Pop-Tarts and IPAs that we disagree on. But today is not that day. [laughs] Once again, today is not that day. Mid-roll Ad Hi, friends. And now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Well, here's one more that maybe you'll agree with, maybe you won't. We'll see. I'll try not to lead you in either direction, but shared examples. If I'm going to rant for a little bit, shared examples are in that space of where they just get used so heavily, and they abstract away important information about the test. And it makes the test so succinct that I don't actually know what the test is doing. And I've seen a number of places where a shared example has been extracted, and it is only used within that test file once, maybe twice. And I'm just like, friends, too much abstraction. Please keep it close. [laughs] We don't need to move it away. We want our test to be friendly and just full of context, which is what I mean when I say friendly. I want full of context is what I'm looking for, well-named variables. And I won't be able to read the test and see what's happening. So my little complaint for today would also be about shared examples and how they can be overused. And they do have a really neat purpose. They can be helpful for if you're testing maybe a controller action and you want to say you're extracting that authentication, making sure that a controller always has authentication and then that is getting included. Sure, that feels very helpful. But that's really one of the few cases I can think of where a shared example comes into play. And if you are testing code over and over throughout different parts of your codebase, there's probably a part of your codebase there that needs to then be pulled out into a class and test that class in isolation. And then you don't need to retest it throughout all of your other classes. Have I already ranted about shared examples? I can't recall at this point if I have or not. [laughs] CHRIS: I don't think we have talked about shared examples before. And I appreciate you not leading the witness here. But I think I'm in agreement with you, particularly the way you refined it there at the end because that controller example is the one rare case where I might reach for it. But in general, I think this is one of those things that I saw early on in my career. I was like, oh, cool; this is a way to clean stuff up and DRY and all those wonderful things. And then I've definitely felt the pain of just overuse of shared examples and ways to pull details out of tests. But it's like, I want to see the details. And I think broadly, that's the theme that you and I are very aligned on is like, no, no, no, tell me the story in tests. I am much less interested in having these concise tests that have a single line, and it's like, expect foo to have bar. And it's like, why? Because...oh, there's a let and then a subject, and it's a shared...oh okay. Now that I can put it together, I can tell the story, but I cannot look at this test and see a story. I want to see a story, friends. So yes, I'm totally in alignment, especially with the slight caveat at the end of like, there are cases where it's useful. Similarly, I've used let. I definitely have not even that long ago. And I stand by the usage, but it was very rare. It's very rare, and it is something that I'll look at and be like, am I sure? Definitely, is this the right thing, or did I do something wrong? Because if I find myself leaning towards let, it's like there's something that I don't think is important to the story of this test that still needs to happen. Why is that? What's going on here? Something feels off about that. And similarly, with the shared examples, it's like, is there not a different way to extract this such that I can test it in a way that I have confidence in, and then we're good? I occasionally will talk myself into using shared examples or something like it where I'm like, oh, but it's really important that everything in the app has that authentication layer put in. And so, I should definitely have this very easily reusable test that can ensure that I have it. But there's a tautology there of well, if I write the test, then I'm definitely thinking about the implementation. But if I forget the implementation, I might also forget the test. And so, it actually doesn't provide any real safety. And in those cases, that's a rare case where I would reach for some weird metaprogramming thing that's like, controllers must do the thing. And we say that in application control and then everything inherited from that will raise if it doesn't implement the authentication layer. Something like weird code that says, "You shall not pass. You must, in fact, implement the authentication layer." Rather than saying, "Oh, we'll just make it really easy to test it so that we always test and, therefore, always use the necessary authentication layer." But yeah, that's a hard one to describe in the radio. So I don't know if that came through clearly. But that's sort of my headspace on this. STEPH: Yeah, and all of that makes sense. I'm trying to think of a good example. And it's been a while since I've used Pundit, but I feel like Pundit may have a really good example of this where it's very easy to document to say, hey, all of these controllers need to make sure that they call out to this class or that there's authentication. I can't remember the exact code and how that works. But I feel like Pundit has a really good example of that behavior. CHRIS: I think they do. It's something where I think it's a configuration level thing, but you say, "Hey, Pundit, we should definitely authorize any access to models." And so Pundit then has a before action, or it's an around filter one of those. But it will raise an unauthorized error, I want to say. Like, you did not do the authorization dance in this. And that's a great example of like, I like that it is loud and annoying and in your face. And it is not possible for me to forget it because we configured it throughout all controllers. And so it's that sort of thing that I would probably reach for even though that code gets complicated and messy, and actions at a distance. But it's worth that trade-off in my mind to have, like, I don't want to forget to do the authorization stuff. Permissions matter. STEPH: That was a really nice pre-emptive approach as well. Because in most cases that we're describing, it's the I'm going to write a controller, and then I need to add this test to verify and prove that yes, I didn't forget the authentication stuff versus upfront, you're setting in a configuration to say, "Hey, please remind me to do the configuration or the authentication step that I don't miss this." So that's also a really, really nice approach. CHRIS: Yeah, the same version of me that's going to forget to write the test is going to forget to write the implementation. So I don't want to trust that version of me to save that version of me. I'm equally untrustworthy in those situations. STEPH: You want to trust the version of you that's going to get yelled at by the code if you don't do it. CHRIS: Yep, I'm going to trust the version of me that was like, I don't trust any future version of me. I will yell at myself if I have not done the necessary things. STEPH: [laughs] CHRIS: To be clear, this is like a life philosophy of mine. I don't try to remember things because I forget stuff a lot. It just happens. And so if I need to take something out the door with me, it goes in front of the door but extra critically, and this is the subtle line. Because plenty of people do that trick where you put a thing in front of the door because then you can't leave without it. There's no way to forget it. But by virtue of that, you cannot put something in front of the door until it is time to use it. Like, if ever you have to go and be like, oh, I don't need it now, though, so I'm going to move it out of the way, open the door, and then leave. No, no, no, because then you've broken the magic of the thing in front of the door must leave with you. So it's a very subtle line. I will play games with myself. I'll be like, I am forgetful. I will not remember this. I do not trust future me, so I'm going to play a trick on them. But you got to calibrate it just right. STEPH: That's really funny because I totally [laughs] didn't think about it until now how you described it. But I have definitely done that where I set a rule for myself, but then I'll break it. And then, of course, everything all of it collapses. There is a time when Tim, my husband, was going through a developer bootcamp. And as he was learning the whole world and everything that's out there, he would ask me all these questions. And he's like, "Do you know this?" And I'd be like, "No." He's like, "Do you know that?" I was like, "No." He was like, "I thought you knew this stuff." He's like, "I thought this was your job." And I was like, "Yeah, I'm really good at finding it and Googling it. But I work really hard to not store this in short-term memory because I'm filling it up with other stuff. So I work really hard to be able to find this stuff and track it and Google it." But now, there's a lot of stuff that I try very hard to not hold on to until I need it. But that was a funny moment where he seemed very upset that I didn't know stuff. And I was like, "Well, welcome to web development. There is too much to know. You're going to have to have a really good catalog system." CHRIS: Also, just so we're clear, it's going to change by next Thursday, so don't hang on to anything like it's just true forever. STEPH: [laughs] CHRIS: SQL will probably be around. That's about it. That's the one thing that I'm really confident in. STEPH: Yeah, that feels fair. Get really good at understanding HTTP forms, SQL, all that feels like some really good groundwork. CHRIS: There are some foundations. We should have a foundations episode where we talk about what we think the foundations are, the stuff that we bet won't be different in 10 years. But everything else is going to change by next Thursday, specifically. STEPH: Yeah, I like the idea of foundations. I'd be intrigued to see what we talk about and what happens there because I feel like that's going to be very representative of already what we talk about. We often will sprinkle in some new-new, especially thanks to a lot of the adventures that you go on. But I feel like a lot of the stuff that we talk about we always bring it back to the foundation because we do want the experiences that we're having to be applicable to everyone else as well. So yeah, that would be interesting to see what comes out of that. 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 hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!! 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.

The Bush Deacon– Josh Clayton–Ordered Days (As we begin a new work and school year, we have the challenges of re-establishing a regular routine getting a household ready for work and school each day. It also reminds us of our need to create structure and routine for our faith life. What does it look like? One thing we do know is that our prayer life in 2022 will not look the same as prayer life of previous years, both COVID and non-COVID years. We are all different, changed by the events of 2020 & 2021, but it's essential to create a good prayer routine to continue to build our relationship with God.)

On The Journey This Week: The gospel reflection with Fr Chima Ofor. Mother Hilda tells the story of an 8 YO Polish girl in WW2. A faith testimony from Lisa Bright on questioning God while dealing with COVID and personal crises, new presenter Cathy Jenkins on choosing to be joyful in 2022, and the bush deacon, Josh Clayton observing our fences.

The Bush Deacon–Josh Clayton–Fences (while travelling during January, Josh notices the difference in fences and the grass either side of them. During the drought, fences were very obvious but since the rains of La Nina it's easy not to see the fences as they become overgrown with lush new growth. Josh wonders about the fences in our life, the things that divide us in our families and communities. Are we using fences to stop us from experiencing new growth in a new year?)

Josh Clayton is the Chief of Police for Patterson California, he is also a lawyer and entrepreneur.  Chief of Police Josh Clayton Advice on School Shootings Police and Community Relationships Applying Lean Concepts to Law Enforcement Officer Training 

Spirit of Christmas– Dcn Josh Clayton–Christmas Time (Christmas can often be a challenging time, overcommitting ourselves, running out of time for self and others, but as the Christmas story tells us, a simple act of humility and kindness can have a profound outcome. Thanks to the humility and kindness of an innkeeper, Mary and Joseph had a place for the birth of Jesus. What act of kindness can we do this Christmas so that another can experience and share in the joy of the birth of Jesus?)

Spirit of Christmas–Dcn Josh Clayton–Be the Rejoicing (This time of year sees the traditional Christmas party season, a time of rejoicing with family, friends, and work mates. As Christians we need to ask ourselves how we can show the joy and rejoicing that comes from knowing Jesus. This Christmas how will we be the face of Jesus to all those we encounter, particularly those who have found this year very challenging.)

Fellow thoughtboter Edward Loveall joins Steph to cohost and talk about alternative frontends and his own that he created: scribe.rip: an alternative frontend to Medium, learning about what it's like to be a manager/non-IC, and helps answer a listener question re: how do you think about empathy in your work? This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Empathy Online: Edward Loveall (https://thoughtbot.com/blog/empathy-online) Scribe (https://scribe.rip/) GitHub - mendel5/alternative-front-ends: Overview of alternative open source front-ends for popular internet platforms (e.g. YouTube, Twitter, etc.) (https://github.com/mendel5/alternative-front-ends) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And this week, Chris is taking a quick break. But while he's away, we have a guest on today's show. Today's guest is fellow thoughtboter, and wonderful friend, and British accent enthusiast Edward Loveall. EDWARD: Oh, hello, Steph. It is lovely to meet...No; this is not my real accent. Anyway, hi, friends. [chuckles] STEPH: [laughs] Hello, British Edward. I am so excited to be chatting with you today. Are you going to maintain that accent throughout the whole episode? EDWARD: No. There's no way I could do that. I need a lot more professional actor training to be able to maintain quality of that level, I think. STEPH: That's fair. I won't hold you to that standard. I was reflecting on preparation for this chat. I've been thinking about all the fun that we've had together, the time that we have worked together at thoughtbot, all the remote coffee walks that we have gone on together as we've talked through consulting challenges or coding challenges. And I realized that we have never worked on a project together, which is wild to me. EDWARD: Huh. Yeah, I think you're right. That is wild. Because I've been here three and a half years, and you've been here even longer than me. So in three and a half years of overlap, we've never done that. STEPH: And yet we've still always found ways to hang out. EDWARD: We make it a priority, you know. STEPH: I think we need to...we might have to bribe somebody for us to get on a project together. EDWARD: I'm pretty sure we know the person to bribe. STEPH: We do. EDWARD: We can go talk to our boss and make that happen. One thing we've both done in our career here at thoughtbot, too, is we have gone from individual contributor to being a manager, which is a cool transition. STEPH: That's a really good point. That is fun that we have embarked on that journey together. I was very much encouraged to become a team lead, and that was very helpful. Because I'm the type of person where I'm not sure I would have put myself up for that role. I'm very thankful that others encouraged me to do so because I really love it. There are certainly challenges with being a team lead. But overall, I have very much enjoyed the role. Just to provide some context for being a team lead a thoughtbot, because I feel like those management roles tend to differ from company to company as to the level of responsibilities that you have. So for us in particular, it's really focused on leading a team of developers, usually two to three developers, and conducting regular one-on-ones to ensure that they are fulfilled and are successful in their projects and their growth at thoughtbot. And then helping them become senior developers if they're not already and essentially coaching them through difficult development and consulting scenarios. EDWARD: Yeah, there is still an expectation that you are an individual contributor in some form on client projects. It is not just a management position. STEPH: Yeah, that's a good point. For me, that context switching is often what makes it challenging but yet also helps me still feel that I can coach somebody and that I can have one-on-ones because I am still in the trenches. I'm still contributing to client projects. And so, it really helps me still stay in touch with the work that's being done and the struggles that people will face. Let me say again I am positive I wouldn't have pursued this path if I lost my IC status. I really like that part of the role. That's really a split. How about you? EDWARD: Yeah, and I still do. We've been experimenting. So thoughtbot generally does four days a week on many projects. So we do four days a week with our client, and then we do one day a week as investment. And team leads, at least on the team that we are on, have been experimenting with just doing three days a week on a client, one day dedicated towards team lead, and then one day for investment. I like that split so far. We're still seeing how it goes, still pretty early on in that experiment. But I've enjoyed continuing to be in the trenches, as it were, and working sometimes with the people that report to me so that we can really grow in the same way. There's a lot of context shared there. And that's been really wonderful. STEPH: Yeah, I have some specific questions I'd love to ask you about that shift in schedule. Because in some of our meetings, there has been discussion about that ability to context switch between I'm only billing three days now instead of my typical four. And I now have more time to focus on team lead priorities, but then that also means I lose a day with client work. And so there's that battle going back and forth between focusing on client work and also focusing on team lead work. So I'm going to leave that as just a teaser because I want to come back to that. But I'd really love to circle back to earlier in the year when you were thinking about becoming a team lead and correct me if I'm wrong, but I think you were pretty hesitant about it. And you were still deciding if it was something you wanted to do. Do you recall what helped you make up your mind as to which path you wanted to take and why you chose this one? EDWARD: Yeah, that's a great question. I did also get some encouragement, a pretty light encouragement from a previous co-worker. And that was helpful, but I turned it down initially. Someone asked, "Hey, are you interested in this?" And I said, "Nope, definitely not." And, I don't know, a year-ish later, I then ended up applying. And I think what happened in the intervening year was that I started to naturally do some of the work of a team lead primarily, checking in with people and talking with them, pairing with them on things more regularly. So I felt as if I was already doing some of the work, not exactly running a one-on-one, not getting people promoted necessarily. But I cared about the people I was working with and wanted to see them grow and be happy and thrive. That realization helped me think, oh yeah, I'm just kind of doing this. And I should maybe apply for this role. STEPH: Wow, that resonates so much. I've heard that from other folks, too, as they have progressed into team lead or other management roles is it was often they already felt like they had started doing some of the work, or there was some natural inclination to start taking over those activities. And so then it felt right to then actually acquire that title and take on those responsibilities officially. Well, how's it been going? You had almost a year now. So you had some of those hesitations at the beginning. How's it been? What do you think of being a team lead? EDWARD: Yeah, I'm really enjoying it. It is a challenge like you said. But that's every job, right? Every job should be a bit of a stretch. So I did come into it with some natural inclinations of wanting to talk to people and check in with them. But there are all these other pieces that I wasn't good at. One thing that has been really challenging is instead of completing things myself, being that individual contributor, is trying to coach and sponsor people to do something that I would do. And I think the hardest part about that is they may not be as far along in their career as you are. And so it is hard to watch someone struggle in the way that you used to struggle without saying, "Oh, here, let me just do that for you.” And I think what I started to realize is that the efforts that I'm putting in I can really be a force multiplier and end up effecting more change than what I could do by myself. Like, if you think about it, I have four reports right now, and they're all really smart and talented people. But let's just say they were half as good as I was. That is definitely not true but just go with the numbers here for a second. If I could teach them to do what I do, even if they were half as fast as me, because there are four of them, they can get two times the work done. The math adds up in a way where if I can unblock those people, help them just get to the next one little step, do whatever it is that they need, they're going to do way more than I could by myself. And really wrapping your head around that and the advantages there is so hard but so rewarding once you figure it out and get it going. STEPH: Do you feel like anybody told you that up front going into taking on some more management responsibilities? Or is that something you learned as you went? EDWARD: I definitely learned that as I went. I got some great advice from Josh Clayton, who we work with, and he's been a manager for a long time. And that's a lot of how he thinks about it. And he encouraged me to do things like pairing with everybody on the team or running little workshops to teach, to fill in knowledge gaps for people asking questions, instead of giving answers, to help them find their own answer. And that's all been really, really helpful. STEPH: Yeah, that's one of the things that I have valued very much about our culture. I've seen some other companies struggle with is that when someone does get elevated into a management role that they still need support. They still need to be coached. And they also need room to make mistakes and grow. And at thoughtbot, I feel that we have been very supported and where there's someone that I can still get mentoring and coaching from. And I can learn to be a manager on the job versus I'm not just put in a position where I'm going to fail or just put there without the expectation that I still need to grow as a manager and as a person as well. So that has helped me out tremendously as well. You highlighted the idea of pairing more with others and then asking more questions around providing answers. And as you're learning those skills or as you've acquired those skills for being a team lead at thoughtbot, have you found those skills also transition well to client work? EDWARD: Yeah, they do. There's a lot of overlap, especially around gaining trust with somebody. I'm gaining trust in one-on-ones, but I'm also gaining trust with my client or helping my client understand something. This gets a little more into the client-side of it. But a lot of times in client work, I'm looking to bridge a gap. I understand something because of my consulting experience, and they want my knowledge and consulting experience. But it's hard to just go in and say, "Do X or do Y." And in the same way, with somebody who's reporting to me or who we're having a one-on-one, it's not usually very helpful to just say, "Do this, do that." You want to help them understand the why and bridge that knowledge gap to get to where you want them to be and where you think they should be. Those really do go hand in hand, and I have used a lot of the same skills. Giving feedback also has been a huge thing to share. It's really, really hard to give critical feedback to somebody. It's very easy for them to shut down and not take the feedback, which is the opposite of what you're trying to do. And the same can be with clients. Like, they've gotten to where they've gotten to because of whatever they've done in the past, and trying to show them why what some of the things they're doing is maybe not ideal is really tricky without triggering that flight or fight response. So yeah, there are lots and lots of crossover to answer your question. [chuckles] STEPH: I get so excited when clients that have brought on thoughtboters recognize that we are there temporarily, that we bring an outsider perspective. And they will set up essentially reoccurring; maybe it's weekly, maybe it's monthly to say, "Hey, give us feedback. Let us know what are you seeing? What do you think about the team? What do you think about our processes? What would you like to change?" And I don't mean just in a retro setting that you're having with the team, but it may be meeting with leadership of that company to give them that feedback directly. And that's awesome. It's rare because, I mean, that takes confidence on their part to be able to say, "Hey, give us all of your feedback, constructive, positive, whatever it may be." But I feel like they get so much value out of doing that where they really get to leverage the fact that they have brought in these external members. And they get to hear from them as to how things are going and insights that they may be missing or not hearing from their people otherwise. EDWARD: Agreed. STEPH: Circling back to the manager IC path for a moment, I have a question for you because I often find myself asking this question to me or sometimes other people asking this question. But how do I know which path to follow? How should I explore do I want to be a manager? Do I want to continue and invest in my individual contributor skills and really lean into that path? Have you found any resources that have really helped you or ways that you coach others through that scenario? EDWARD: I probably don't have a very interesting answer just because I'm going to mostly repeat what I think I said. But I think it's still so relevant and valid, which is, do you find yourself doing some of the work that a manager does? And it doesn't necessarily have to be the thing that I did, which was reaching out to people and checking up on them and seeing how they're doing. It could be that you really, really like running big team meetings or something like that. You just get a kick out of doing that kind of work. Or maybe you really enjoy working less on yourself and more on the group around you. That could also point to more of a technical leader. It doesn't have to be a person leader. So I think I would look for where you find yourself wanting to effect change and figuring out if that fits into a manager role or not. And I've had people tell me they definitely do not want to be a manager, and they know that for sure and people that are on the fence. And I think that's another useful thing is to ask your manager what they do as the job and see if that's interesting. See if any of those things spark joy for you, as it were. STEPH: I love the approach of just flat out asking your manager or someone that you see where perhaps you would like their role and saying, "Hey, what's your day like? What do you do? And can I be part of more of your day just to see if I would be interested in this type of work? Essentially, can I shadow some of the meetings that you're in?" I really like that idea. And I think in the past, I would have been more hesitant about this approach. And it certainly depends on your company's culture. But there's a part of me that's like, just try it out. Like, if someone is encouraging you to go for a management role or to go for maybe it's a stronger individual contributor role, maybe it's being a principal engineer or something else, but if there's someone that's already there encouraging you or if it's just yourself and you are your own cheerleader, then go for it. Try it out. See if you like it. Take some notes. See if what you thought the job was going to be like actually matches reality. Because then, at the end of the day, you can always decide to change your path. And if you are at a company that supports that type of experimentation, then you can step back to your current role if you decide that you don't like it. Or you might find that there's a really nice mix in there. But I feel like, with time, I'm getting a bit more bold with strategies in terms of just trying things out, even when it comes for technical challenges as well. Like if there's something that you're really nervous about or there's some big technical problem or something that the team is working on, and you're really skittish and nervous about it, just go ahead and say, "I'll do it, or I'd love to work with somebody on it," and then try it out and take some notes, see how it goes. EDWARD: You could be really sneaky too. You can say to a colleague, "Hey. You want to get lunch?" And like you turn that into a secret one-on-one. Or you offer to run the retro board during retro, or you step up for doing a bunch of pull requests that week or something like that. You can try these little test things without even having to let somebody know or committing to anything publicly or even privately. Just really internally to yourself, you can try to take some of those steps. STEPH: I like the sneaky success ladder. People won't talk about that one as much. [laughs] That's how I definitely found out that I didn't want to do sales. There was someone that I was talking to that was interested in working with thoughtbot, and Josh Clayton was very supportive of like, "Do you want to come along and be part of the conversation?" I was like, "Yeah, sure." And so I went along, and it was fun. But I definitely walked away like, yep, I don't want to be part of sales. I really like everything else minus this part. [laughs] EDWARD: Yeah, it's good to know. It's good to know. STEPH: Circling back just a bit to something you said earlier, you had mentioned that as you were becoming a team lead, you realized that helping others be successful at their job was really then what led to you feeling successful as well and that you could be a force multiplier. And you'd mentioned that a lot of that work comes down to bridging knowledge gaps. And I'm really curious because this is something that we're always working on at thoughtbot. We are looking to identify what skills people would really like to learn. How can we help people learn those skills? And I'd love to know more. How do you go about this? How are you helping people bridge those knowledge gaps? EDWARD: Yeah, so that is a doozy of a question. I have a couple of different answers. First is something I talked about before, building trust. And there's a bunch of different ways to do that. And I see trust as the foundation of almost everything in consulting. If you don't have that trust, it's really hard to deliver feedback like we talked about. It's hard to bridge that knowledge gap. Because effectively, nobody knows who you are, and what you're doing, what's going on, why you are coming to talk to them. It's really strange. And we can come back to how to build trust. But once you've built that trust, I approach bridging that knowledge gap in a couple of different ways. One is asking questions instead of giving answers. The goal behind this is I want them to think about their goals. And that will often help lead them to some answer to bridge that gap that we have. I have some idea. They have another idea. If I can ask the right open-ended question, they will walk themselves across and get to where I want. Now, that doesn't always work. Another strategy I've found is outlining a bunch of different possible solutions and their pros and cons. That has done two things. One, it helps them understand where I'm coming from, what my goals are in relation to what they're trying to do. And another one is that actually tends to gain a lot of trust. In the meantime, you're showing your expertise. You're showing that you're really considering all their problems. Because almost every solution has trade-offs, there's very rarely a silver bullet. And so it's really helpful to say, "Well, here's the pros, here's the cons. Here's where I think you should go, but you know your business better than I do. And I've outlined all the things here. So whichever way you want to go forward on this, let's do that. And let me help you get there." Joël and I, a colleague that we both cherish dearly, we did that on a project recently, and it was really, really successful. We put a lot of work in and helped them get to a really difficult architecture decision. And it could have gone one of, I think, four different ways. And we were sort of vying for one. They were vying for another. And we found a couple more in the middle, and I believe we went more towards the middle. And we were both pretty happy with how that turned out. STEPH: I really, really like how that approach gives someone so much autonomy, and they're part of that decision. So you're not just saying, "Hey, you need to do this," and then just following through with it. But instead, it's saying, "I think I've heard everything. I think I understand the different problems that we're facing. Here are my suggestions, but you still have more context. What do you think, or which option would you like to pursue? I really like that option." EDWARD: Yeah, because you're always writing this line as a consultant of like, they did bring you in for your skills and expertise and theory. But you really want to level them up so that they can make the right choices because that ultimately is...like, their success is your success as a consultant. That's the job in a lot of ways. And so yeah, giving them the tools they need to make the right decision is so often the job. And I think that can get lost in the shuffle of, oh no, we have to meet these sprint goals. Or I got to get this ticket done or this bug fixed or something. And stepping back to get them to a better place is another goal that you can get to down the line. It's not to say shipping tickets is bad [laughs] or getting the sprint goals is bad. It's just another facet. Have you had any aha moments in consulting? STEPH: Oh my gosh, I have had so many aha moments. I think most of them, for good or for worse, are here on The Bike Shed, or at least they've been shared here on The Bike Shed. [laughs] EDWARD: Yeah, you should write a book of them all. STEPH: Could we just grab the...I'm lazy. Can we grab the transcripts? We'll just turn that into a book. EDWARD: [laughs] Yeah, just put it all together, call it The Bike Shed Diaries. STEPH: Yeah. Oh, I like it. Okay, all right, that'll be next week's task. We'll publish The Bike Shed Diaries. [laughter] Specifically, in terms of bridging aha moments for helping someone bridge knowledge gaps or even for myself is I will often focus on what skills do you need today to make your job easier? What challenges are you facing? And also, what skills would you like to have six months from now? So that way, you are meeting the needs and the requirements that you really need today to fulfill your job. But then also six months out, we're still looking towards the future. Maybe that's also more job requirements related, or maybe it's just for personal growth, or the areas that you're really excited about. You really want to contribute to an Elixir, open-source project, or something more specific that contributes to your fulfillment. So when it comes to knowledge gaps, those are often the questions that I'm asking are, what do you need this week to make your job easier and to make your life easier? And then where would you like to be in terms of what skills would you like to have six months from now or what concepts? It may even be too lofty to say what skills because that could be huge to say that I want a whole new skill to be able to work in a language. So maybe it's something that's more specific of like, I'd really like to understand forms a bit better six months from now, or I'd really like to feel a little more confident with SQL, or maybe you'd like to take a look at Arel, things like that. And then set those targets and then check in to say, "How's it going? How do you plan to learn these skills? Would you like help learning these skills? What are some resources?" Because I am not always the person that can help someone acquire that knowledge. So in that role, I'm often a facilitator where I will say, "Cool, you want this. You're interested in this particular skill. I don't know that skill. But I do know someone else who's really good at this. So let's get you all connected, and then you can work together on this." EDWARD: And to dovetail a little bit with that manager individual contributor piece we were talking about before, that's another piece we didn't really talk about, which sounds like sponsoring. It's not just you doing the thing for your report or even coaching them necessarily. It's how can I get my report into a situation where they can exercise that skill or connect them with somebody who can help them with that thing? I'm still working on that one, honestly. That's a really, really difficult one. That's not something that comes naturally. STEPH: When you say that's the part that's still challenging for you, is it the connecting of one person to someone else to learn a skill? I'm curious to hear more about which part of that is challenging for you. EDWARD: I think I don't always think of sponsorship as a tool that I can lean on. It just doesn't come to mind as naturally. I think the very natural thing to do is mentor first, which is like, here's what you should do. It's kind of giving somebody a fish. Coaching then is more like teaching them how to fish. And then I don't know if we're going to extend this analogy farther. Sponsoring is like you're going to open up your own fishing teaching school or something. [laughs] And that just doesn't always occur to me. I don't necessarily think like, oh yeah, like my friend over here could totally teach you about this technical skill that you're trying to learn or set you up to speak at a conference or something like that. It's a much different level of being a manager that I'm just not used to yet. I'm getting better at it. But it doesn't come naturally. STEPH: Yeah, that's a very powerful form of managing someone as well because then you are helping that person go beyond their current bubble of who is their manager in their team and then helping them shine in other circles. And that's incredible and also something that I am always working on getting better at. EDWARD: Let's get better at it together. STEPH: We can do it. Also, when you mentioned opening a fishing school, I definitely pictured fish in a school in front of a chalkboard and someone's writing on that board and little fish in their school seats learning. EDWARD: [laughs] A little Finding Nemo action. STEPH: You got it. [laughs] You know your fishing school. You got to learn to stay away from those hooks. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: So pivoting just a bit on a slightly more technical note, you've been working on a side project called scribe.rip R-I-P. And I've heard a bit about it, but I would love to hear more. Could you tell me more about that project that you're working on? EDWARD: Yeah, sure. So Scribe is what I would call an alternative frontend. And specifically, it is an alternative frontend for medium.com. The goal of the project is to give people a tool to read the Medium articles, not on medium.com, which might sound like a strange goal. [laughs] I'm happy to go into a little bit of a lie there. But that is the tool. And yeah, the domain is scribe.rip, mostly because that was a cheap domain. [laughs] So I got it and put my project there. STEPH: I like that phrasing that you're using, alternative frontends because I think when you had first mentioned that, when I'd heard that in other conversations, I was like, oh, what is that? And I didn't know what it meant. But now, when you put it into some context, that makes all sense. I am intrigued. Why would someone be interested in using an alternative frontend versus, say like, there's an article on Medium; I'll just read it there. What might inspire me to want to use Scribe instead? EDWARD: Definitely. There's a bunch of different reasons. The alternative frontends cover a pretty broad ground. But I'd say the most common reasons that someone might want to use one are privacy if they're worried about the main service, whatever that might be. Let's say Medium, in this case, is doing something with their user data that they'd rather they not do, potentially a better experience on that service. If you don't like the way Medium's articles look, you might want to see them in a different way. It can also be a way to vote with your actions, saying that this is the kind of web that I want to see if you don't like in general what a platform is doing. And if you think a platform is potentially even harmful, it can be a way to say I don't want to support that platform, but sometimes I find myself needing to interact with it in some way. The alternative frontends can be a tool for that. On the very cynical angle, you can also go to you don't want to see ads. And sometimes, these are ad-supported platforms. Alternative frontends can get rid of those ads. And so that's another way too. I'm conflicted more about that one. We can dive into that. But those are the most common reasons I've seen that people want to use alternative frontends. And to be clear, Scribe is not the only alternative frontend out there. There are frontends for YouTube, for Twitter, for Instagram, for Reddit. There's a huge list of a bunch of them, but those are some popular ones. STEPH: Oh, that's really cool. I've never used any of those before. Will be sure to include some links in the show notes so people can check those out. And you listed some really interesting reasons for why folks might want to use an alternative frontend. I'm curious, to make this possible, though, does it mean that the service that is hosting that content do they have an open API into which then you can pull that content? How is an alternative frontend possible? EDWARD: It is possible through APIs almost always. In some form or another, the APIs aren't necessarily open. One interesting side effect to many of the JavaScript rendered apps is that they often talk to some API in the background. And that can often be used to get the content in a more computer-friendly way. And so, with Medium, in particular, they don't really have an open API. So I ended up trying to figure out their API in the background that they're using to fetch articles and was able to get the content and display it in a different way. STEPH: So everything you're describing sounds really interesting. I feel like I do have to ask the question, is it okay that these alternative frontends are taking content and are essentially rendering content but then not using the original service in which the content was published? How do you feel about that aspect? EDWARD: Yeah, it's a really interesting question. There's a bit of a moral argument here, and I think everybody has to make that call for themselves. I think every platform if it gets large enough, is going to have people that don't want it to exist for some reason. I think, in some ways, providing alternative frontends is a bit of a release valve for that platform. Not to say that the alternative frontend explicitly helps that platform, but I imagine it gives people literally an alternative to then use instead and can make a peaceful, neutral ground in a way. So instead of being forced to use only the official platform, you can now use it at least in a limited fashion outside of that, which may alleviate whatever concerns you have and therefore keep everybody happy. And I think honestly, in the long run and in practice, most platforms will not particularly notice the impact of these alternative frontends. Overall, we're talking very, very small potatoes. YouTube is not going after Invidious, the alternative frontend for YouTube, because it's probably a drop in the bucket. Nitter is not getting cease and desist from Twitter. Instagram is not sending a cease and desist to Bibliogram. These are some of these alternative frontends. And I think that's just because it's okay. They don't mind. It's so small. And it's giving people what they want in a way that is not harmful enough for it to really matter in the long run for them. STEPH: Interesting. Because yeah, as you'd mentioned earlier, I think most people are going to continue to use that main service because that's what they see advertised. And it's more well-known, and it's frankly easier to go to. But then for folks who do want a little bit more control over their experience and they still want to access someone's content. So it is interesting. You still want to ensure that the person who created that content always gets recognition and ownership of the content that they have. And in this case, that very much still applies. If I wrote an article on, say, Medium, but then I'm using Scribe to be able to read that content, it's still known who wrote the article. But this way, you are perhaps opting out of something else that service is doing, maybe if they have some type of tracking or something that you're not comfortable with. But you still want to be able to appreciate that person's content, even though they're perhaps only able to publish on Medium for right now. Or they're still looking for more ways to publish their content for folks who would like alternative ways to consume their information. Yeah, it's an interesting spot. EDWARD: Right. And some ways that I think Scribe can provide a slightly better experience are trying to highlight the author more than the platform. The only time it says Scribe on the website is on the homepage. If you go into an actual article, I don't put branding or anything like that. Because I think I really want people to have their work speak for the author, not for the platform, and that's really important to me personally. And that might not be important to you, and that's okay. Maybe you use scribe because it supports dark mode or something like that, and that's totally fine too. I don't mind at all. There are many aspects on which an alternative frontend can provide for people that the official platform doesn't. In some ways, it's augmenting their features, but in some ways, it's just giving people a bit more choice. And I think that's important. STEPH: I have found since you'd mentioned the side project, that I've started using it more to read content. And I have found it helpful because it really silences all the noise because a lot of services want you to see ads, and they do want you to click on more articles that are related to the thing that you're reading. And so, I do appreciate the simplicity that it brings to the content. So then I can really just focus on that one article that someone has written. Overall, it seems like a really neat project. EDWARD: Yeah, thanks. I'm glad you enjoyed it. STEPH: Pivoting just a bit, I would love to go on a slight adventure and answer a listener question with you. What do you think? EDWARD: Yeah, let's do it. STEPH: All right. So this listener question focuses on empathy in your work, and this person writes in, "I'm curious how you all think about and notice empathy from yourselves and others around you. Empathy is so helpful and critical for making and maintaining healthy, productive relationships. I've noticed that the way you frame your client engagements, empathy sounds to be at the heart of them. For myself, I've noticed I'm better at it in certain contexts and certain times and with specific personalities, more so than others. More concretely, how do you stay empathetic with your clients and with cross-functional teams like product or design or even yourself? Can you teach or increase your empathy? And if so, what have you found successful in these situations? So, Edward, this seems really on topic for some of the things that we were discussing earlier. So I'm going to hand it over to you first and get some of your thoughts. EDWARD: This is a really great question. There's a lot to unpack. And one question they asked was, can you teach or increase your empathy, and if so, what have you found successful in what situations? I have found that being vulnerable both publicly and being empathetic publicly is a really useful tool. A lot of teams don't communicate very publicly; it's a lot of stuff in private messages. Being vulnerable publicly in a big team channel can really open the door to letting other people be vulnerable and see what other people are doing, understand what people are feeling. And that's really at the heart of empathy is understanding someone else's point of view. I've also found that starting small, like, just do it with your close co-worker. Maybe try to effect just change with them. And then once you've gotten them on board, broaden it to two other people, and then two more people, and then two more people, because it's really hard to take that leap of faith and be vulnerable by yourself. So I totally get that. And also trying to take this on really early in someone's career or someone's tenure at a job. Offer to help new people to your team. Work with them, so they just start off with a very empathetic experience. And that can grow into a more empathetic team as a whole. Encourage team members to update documentation on their first day because they're learning so much in those first few days. Once they've learned it, the only reason they want to document it is because they have empathy for that next person. And so, just like setting that baseline and that boundary, I think is super helpful. What do you think? STEPH: Yeah, I think those are some great examples. I really love that one way to acquire more empathy is to go on a journey with someone else. So if you have someone new that's joining the team, be their onboarding buddy. Go through that journey with them so you can understand what they're going through, what challenges they are facing. And that will boost the knowledge that you have and will likely also boost then the empathy that you have for people that are new to the team or for future onboarding buddies if you realize that there are some processes that really need to be smoothed out. I also think it's worth highlighting that I don't think empathy is a single skill. I think it's a number of things. It can be the ability to feel someone else's emotions, so you can understand what someone else is feeling at that moment. It could be reasoning about another person's perspective, or it could be just, frankly, wanting to help. So I think there are a number of ways that we can demonstrate empathy to someone else. And it's going to depend on the situation as to which one of those skills is going to be helpful. For how you stay empathetic with clients, that one is a really interesting one just because the way we work with clients; we do get to go on that journey with them. We are with them in making decisions around priority and technical decisions and what pain points they are feeling. So I think going, as you described earlier, going on that journey with someone is what helps us stay empathetic with our clients. And I think that's true for cross-functional teams. So if you are working with someone that's maybe on customer support or on the design team, it could be grabbing lunch with them and saying, "Hey, what's your day like? What challenges are you facing?" Maybe it's your company has rotations where you actually are part of the customer service team for a day. So you get to respond to tickets and have more of an understanding. I'm realizing there's a theme here. I feel like a lot of it comes down to stepping into someone else's shoes and seeing the world from their perspective and not just seeing it but experiencing the world from their perspective. EDWARD: Yeah. And another way to do that...because that can also take a lot of time. It's a hard ask potentially to say, "I'm going to go be a customer service rep for a day," if your job is also, I'm going to be a programmer and ship features or fix bugs. That's hard to do. And I think there are ways to do that, to experience what someone else is experiencing by trying to take on not necessarily the role of the other person but just trying to support the other person in their role. So, for example, we see teams become really siloed where the product is solely responsible for writing tickets, development is solely responsible for understanding what makes the code work or fixing a bug, and design is only responsible for user interactions. I found it really, really helpful to try to approach design and say, "What's the goal here with this user interaction?" I don't know. I'm not a designer. And so, how can I ask them and again bridge my own knowledge gap? Because that can really help you get to that point and help them understand maybe what you're going for and say, "I wasn't going implement it like that because I thought X, Y, and Z." And they go like, "Oh, I see what you're saying." And then now you're making those barriers…or maybe when you're working with products, they're like, "I see what you're trying to do here. But in my experience, I've seen websites like this. How do you feel about that?" And it's not to say that you're just trying to steamroll over them. It's that you're trying to share your experience and get on the same page and trying to get them on your page so that you're all making the decision together, not just handing it back and forth across the wall. STEPH: Yeah, and that was really well said where I think the more that you do collaborate with others and the more that you make decisions with others, the more context you're going to have for why someone else is making a decision, what challenges they're facing. And so again, it comes down to having more information about what that person is going through to then help you be able to be empathetic because I don't think this is a skill you can just turn on. If you don't know anything about somebody, you don't know anything about what they're going through. Being empathetic is going to be incredibly hard. And in this question, they mentioned that they're better at it in some contexts, at certain times with certain personalities. And I think that makes sense because anyone that's more like you, I think you're going to find it easier to be more empathetic. And anyone that has had similar situations, ones that you can relate to, you're going to naturally be more empathetic to. Also, timing is important. Maybe it's the end of the day, and you have already used up your empathy bucket, and you have nothing left to give. And that's just something to be aware of. You may have reached that threshold. And with practice, maybe that bucket will get bigger, and you will have more empathy to give throughout the day. But just be aware when you've also hit that threshold, and maybe you don't have any more to give in that moment. But I do think it's very much a skill that you build with a lot of practice. EDWARD: Yeah, it's absolutely a muscle. You're totally right. You are trying to do it, and the first time you do, it will be very hard. You will be very drained. And you need to recognize that that's okay. You can step away and come back the next day, and it will get a little better. But that's a wonderful point. STEPH: There is a really nice example that you have captured in a thoughtbot blog post that will be sure to link to in the show notes that highlights how difficult it can be to communicate the tone of voice and even how impactful that can be for someone who is reading that message that you have sent, and they don't understand that tone of voice. EDWARD: Yeah, that post was very focused on trying to bring in emotion to a more or less emotionless conversation, which is often text. It's very hard to understand when someone is being sarcastic or angry or bubbly or whatever. Just even silly things like adding emojis can really help in that process of bringing in more emotion and getting that tone across. And I'd say finally to this person who asked the question that the fact that you're thinking about it is already an empathetic thing. Just the fact that you want to get better at this shows that you're already empathetic, and that's really great to hear. STEPH: Yeah, I think that's a really great observation, and I think that's a perfect note for us to end on. So thank you so much to the person that shared this question with us. It is a very interesting question. And I applaud you for being so thoughtful about how to be empathetic with everyone around you. Edward, thank you again for being a guest on the show. For those that are interested in following more of your work or checking out your alternative frontend, where can they find out more about the life of Edward Loveall? EDWARD: You can find the alternative frontend called Scribe; it's scribe.rip. You can find me at edwardloveall.com. And I have links to various social media or email if you want to email me or whatever. And yeah, it's been a pleasure. Thanks for having me, Steph. STEPH: Thanks so much. On that note, shall we wrap up? EDWARD: Let's wrap up. Ta-ta, Stephanie. CHRIS: 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 in 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 hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeeee! 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.

Deacon Josh Clayton–Checking In (We now see checking in as something very different to its original meaning, that idea of spending time with another and catching up on recent events. As we go through the daily routines of checking in are we doing the same with God. Are we using our phone to scan a QR code to check into God's Word, love and desire for each of us to spend time sharing our recent life happenings. This Advent, take time to check in with God)

Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide. Empathize with Your Customer by Josh Clayton (https://thoughtbot.com/blog/empathize-with-your-customer) thoughtbot Boost (https://thoughtbot.com/boost) Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) Follow Josh on LinkedIn (https://www.linkedin.com/in/joshuadclayton/) or Twitter (https://twitter.com/joshuaclayton) Check out Josh's website (https://joshuaclayton.me/) Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Josh Clayton, Managing Director of the thoughtbot Boost team. Hey, I know that company. Welcome, Josh. JOSH: Hey, Chad. How are you? CHAD: All right. I'm back to the show I think. I didn't get a chance to look up the last episode you're in, but it was probably hundreds of episodes ago now. JOSH: Yeah, it's got to have been a while. CHAD: [laughs] Speaking of a while, you recently…now time is all messed up for me, but I know that you have been at thoughtbot for a long time. How long has it been? JOSH: It was 12 years in August. CHAD: It's been a wonderful 12 years, Josh. JOSH: I agree. I agree. CHAD: [laughs] JOSH: It's been fun. CHAD: So in that time, you have had a few different roles. But you've been a Managing Director for a while now. JOSH: Yeah, I think that's...let's see. It was seven and a half years for the Boston team. And then it's 10 and a half months with Boost. CHAD: So your background is as a developer. And you, like a lot of people who have a background as developers at thoughtbot, myself included, still do development on a fairly regular basis. What does the Managing Director job at thoughtbot actually do? JOSH: What don't we do [laughter] is maybe a better question. Effectively, we're running that team's business. So it involves some amount of software consulting. It involves software sales. It involves managing the profitability of the team. There are marketing functions, and, I don't know, anything and everything, hiring-related things. We opened up and recently filled our Development Director position, which was open for a couple of months over the summer. We've just opened up a Design Director position. So it's everything. [laughs] It's everything it feels like. CHAD: At the beginning of this year, we did an episode about the changes that we had made at thoughtbot to reorganize the teams around rather than geographic studios around the types of work that we would do on that team. And that's how the Boost team was created. So in that episode, we gave people an overview. But I'd love to hear in your own words, what makes Boost at thoughtbot different than the other teams, and what do you focus on? JOSH: So what makes Boost different? I think one of the drivers, one of the motivators, is to embed alongside existing product teams, engineering, and design teams, and help them get better, help them grow as well as ship features and fix bugs. So I think that the way that I position it is if there's an existing product that's deployed, people are using it day in and day out. Hopefully, it's been battle-tested. There are probably some funky areas of the code. Those are the codebases that we're operating in. It might be a team of two people; it might be a team of 200 people. But there is an existing product and an existing team. They're looking for our support to help make it better. CHAD: One of the things I love about Boost and the changes that we've made, especially relative to Boost, is that at thoughtbot, we really believe in integrated teams of designers and developers. And a big part of what we've always done has been to be a complete product design and development team that brings new products to market, big and small. And because we were one of the first consulting companies in the world to switch to Ruby on Rails and because of that deep experience with Rails, and scaling, and working on existing products, we had a significant number of customers who engaged us for development for that expertise, and to help them scale, and grow, and hire, and implement best practices or solve problems that they were having in their existing codebase or on their existing team. And even though that was a significant part of our business, it was always something that seemed that we maybe even didn't really want to be doing it, or it was on the periphery of our marketing and positioning. And I was super excited when we officially created this team because it allowed us to acknowledge that this was a significant part of what we do, a significant part of our revenue, and to have a team of people that opted into doing this kind of work who would not only love the kind of work but want to even grow it and do more of it. And we haven't really had that for this kind of work. We've had individuals wanting to do it but not at an organizational level in an organization that supports it. That was more of a statement than a question, but reaction? JOSH: [laughs] I think you're spot on. It's always been interesting to me to hear that it's...obviously, at thoughtbot, we have been building MVPs and working with a lot of different types of companies over the years and helping them launch products. But I think that the type of work that I and, ideally, obviously, other people on the Boost team enjoy working on is existing platforms and working alongside existing teams. We talk about legacy systems, and I think they get a bad rap. And it's like, no, it's battle-tested. CHAD: [chuckles] JOSH: The business has proven its viability. It is still around years later. Conway's law applies in all of the stuff. Again, there are gnarly aspects of the code. But I think that's what the folks on the Boost team enjoy being challenged by is problems where these things are larger systems. They've been around for a while, and they do get pretty gnarly. CHAD: I think one of the things that held us back in the past is that it is a skill set, and it's an experience. And you are going to be on an MVP project where you're doing design and development, going from concept to launching of a new idea, usually in a matter of weeks, working directly with a founder or a team of co-founders. And then you rotate on to this significantly larger project with maybe an engineering team of tens or dozens or hundreds of other developers on it. It's a very different skill set, and you have very different challenges in that environment. And when you're constantly switching between those different kinds of projects, you can't necessarily get better at it. And that's one of the other things that I think is helping us be more successful. JOSH: I remember one of the teammates had joined the kick-off call with me at the Boost inception that very first meeting. And it was Joël. And Joël had asked pretty straightforwardly, "What is the expectation in terms of project rotations?" Because I think historically across the company, we'd aimed to do two to four-month engagements before we'd rotate folks. And I told him point-blank it's going to be six months to a year probably. And I don't think it necessarily shocked him or other folks on the team. But I think when you're going into existing codebases and working alongside existing teams, there is inherently politics at play and complexities at play where it might take you being a new developer on a team six weeks, maybe longer before you actually feel comfortable and confident navigating the codebase and knowing where you can have and make an impact. And so, I think some of the shifts there have been particularly interesting to watch the types of consulting conversations that we have within the team just because it is a different beast, I think than building and launching products. CHAD: So let's get into a little bit of detail about the kinds of projects we're doing in Boost to the extent that we can give specific examples and maybe more importantly and relevant to the audience, what are the things that we see? What are the common challenges that we see as products grow and evolve, as teams grow and evolve? What do you think one of the most common challenges that people have is? JOSH: As teams grow and evolve, I think a lot of teams run into onboarding issues and general knowledge sharing. I think when you start a small team, and you're two, three, maybe five engineers, it's pretty easy for everyone to keep probably the entirety or the majority of that domain in their head at any one time. As you work to scale a team...there's a client of ours right now where they're effectively doubling every...I don't know what the time period is, but they're growing very, very rapidly. And the feedback that some of our team have provided to them is it's really hard, and there are very much knowledge silos. And they're working through, okay? How do we tease this out? How do we share this context so that you don't have a couple of folks that are effectively blocking every single other member of the team? And so that's one of the core areas that hangs up our team and other teams. [chuckles] Our clients bring us on, and a lot of times, it's like we're rip-roaring and ready to go. And it's like, I need information from a bunch of people, and the processes aren't in place such that we can be as effective as we would want to be given the nature of work that we're doing. CHAD: I think that's a straightforward problem, and it's a good example...I don't want to make this an hour-long thoughtbot commercial. But I'll just point blank say one of the reasons why sometimes working with us is positive for clients is it's really easy to have a certain pain around your onboarding process or company, even just simple things like how long it takes to get a new person a computer or to ramp them up on their existing team. If you're just hiring an employee, it's easy to ignore the cost of that. JOSH: Yes. CHAD: But when you're bringing on thoughtbot and we have a specific start date, and it's a certain cost, and those kinds of things, it can really expose the pain that is already happening but was just being ignored and provide the impetus to actually fix the problem. JOSH: One of the things that we try to set out to do on the first day for any project is to open up a pull request to the codebase, whether it's an improvement to the onboarding like the README for the repository or whatever it might be. Ideally, we are finding ways to contribute on day one. And sometimes, that's frankly not realistic for individual contributors doing it from their own machines. But oftentimes, we'll know that going in. And as we onboard new folks and things like that, we'll say, okay, well, day one is going to be your pair programming over Tuple or some other tool so that you are able to engage and interact with a team and work on the code, even if there's still a bit of a lag between GitHub access and everything else that's the base of onboarding steps. CHAD: So another common one that people bring us on to help with is scaling challenges in terms of the actual product itself, maybe that's performance or other scaling challenges. I'm working on a project now where that was how we first got involved. The service was failing, and it was only getting worse under the increasing scale. So, what are some tips that you have for how to effectively solve some of those problems while not bringing everything else that you need to accomplish to a screeching halt? JOSH: At the end of the day, you can't fix something that you don't know is broken. Or you might have a hunch in terms of, oh, I know this page or this set of pages are slow. I think so much of what we see is teams come in, and they're like, "We don't have New Relic setup." We don't have an instrumentation setup. So they can't measure anything. And so it's like, I know this page takes three or four seconds to paint, but I don't know why. And I don't know how to fix it. It's like, okay, well, the first thing that we need to do is set up some amount of performance monitoring and application tracking just to get a sense of what that's like. There is a potential customer who had reached out back in January of this year. So this was weeks into Boost's inception. And they said, "Listen, we've got some performance-related issues. We don't really know what to do, but we know the application is really, really slow on these couple of pages." It's like, "Are you using New Relic, or Scout, or anything like that?" They're like, "No." It's like, okay, that's the first thing that you need to do. And they came back about a month ago and were like, okay, "Here's the access to all of this data. Now we're ready to go," and it's like, "Yes!" They probably didn't need to wait for that long. But it really speaks to that in order to address some of the performance-related stuff; we need to have some sense of what is going on and where. I know Steph over on The Bike Shed Podcast had talked to Nate Berkopec. And she had floated one of the questions I had had. And he basically schooled me on that podcast and reiterated it really is ultimately about measuring so much of what we're doing. CHAD: Yeah. One of the things, especially for teams that are having a problem but feel like they don't know what to do it's tough when it's actually the case. But the reality is a lot of times; there's actually very low-hanging fruit that it's just no one has the time or experience to actually identify that. And putting some monitoring in place combined with actually taking the time to look through it, especially if it's the first time you ever hit scaling problems...There's either a missing database in that index or some N+1 queries, and fortunately, once you identify that kind of problem, it's usually fairly quick to fix as well. It's a different thing when there's maybe fundamental architecture things that are causing your app to have scaling problems. But it's very unlikely that those are the first problems you're ever experiencing. The first problems you're ever going to experience if your app is running slow are going to be things happening at the database level or missing an index or something like that. And it's very unlikely that significant architecture changes need to be put in place in order to fix the first scaling problems that any product usually has. JOSH: That wasn't the type, or at least I think when we got brought on, and you were working on your most recent clients, we were well beyond...maybe we weren't, maybe I'm misrepresenting or misremembering, but it feels like we were well beyond some of the low hanging fruit. CHAD: Yeah, there was a batch of low-hanging fruit. One of the things if you're working on a product that is scaling super rapidly, what can happen is that the low-hanging fruit masks the other problems that are happening there because it all happened too quickly, all at the same time. And that was the case on this project. So it went from having hundreds of people using it to millions of people using it in the span of a month. And so there was low-hanging fruit. But removing the low-hanging fruit didn't make the app suddenly work again; it just made it so that we could look at the metrics and say, "Okay, those things are no longer the problem." The real problems are not being masked now. We now can identify the architectural changes that need to be put into place in order to operate at the scale. JOSH: Yeah, it's the low-hanging fruit when the orchard is on fire. [laughter] That is true. CHAD: Right. So you got to peel back like an onion. And this is the case with I think a lot of...whether it be a technical challenge or a team challenge. You can't always come in and very quickly solve the root problem. You might not even know what the root problem is. You just have to start solving the problem that is obvious in front of you and learning more. And then you solve that one, and then you expose the next one, and you expose the next one. And even when you can identify the root problem, you'll be like, this is the problem, and everyone agrees it's the problem. It still might be too hard to actually fix that problem. It might be an organizational or a systemic problem. And instead, you say, "Okay, we have to iteratively solve that problem." And you start peeling back those layers to get to the point where you've positioned yourself to solve that core problem. And I think we face that a lot, particularly as external consultants. We're coming in, and we can't just be the bull in the china shop. Because we haven't built the trust with everyone necessary to make the changes, or we don't know enough to know what the changes need to be. JOSH: Right. And I think the people aspect of all of these things in my opinion...and I should caveat this with I've been writing software professionally for almost 20 years. The people, in my opinion, are always the harder aspects to any engagement. It's very rare that we go into a technical project where it's like we literally cannot figure out a technical solution to this thing. We can usually figure it out. And it might take weeks or months to implement, especially as it spans multiple systems. But more often than not, it's really navigating the people and the relationships and building that trust like you had mentioned that is really what will help dictate success within that project. CHAD: I have a line that I use fairly often, and it's that I really believe very few, if any, developers sit down and are like, I'm going to write a bad solution today, or I'm going to write bad code today. That's not what people are doing. I think the majority of people genuinely try within their entire capacity to do a good job. And so that means that when I'm coming into a situation where there are problems, or things are messy, or there were bad decisions or bad code written, it can't be chalked up to like, oh, that was a bad developer, or that was a bad choice that was made. There was usually some people or organizational problem that caused that to happen in the first place. And merely fixing the bad code is not going to be what we should focus our time on. We probably need to do that. But if we don't fix the reason for that problem in the first place, it's just going to happen again. A really popular example of this is when we get approached to do a Rails upgrade on a very significant product that is very behind with Rails. First of all, it's very expensive to do that on a very significant project if there's no test coverage. People could hire us to spend and spend a lot of money just getting to the next Rails version. But if they do that and don't solve the reason why they were so behind with Rails and have no test coverage and all that stuff, along the way, it will have been wasted effort because in a year or in two years, it will be back to the way that it was before. And that's one example that's very technical. But that kind of stuff happens all the time, even with squishy things [laughs] like the structure of a team or something like that. So if you could give advice to people that are struggling with a particular problem, what would you tell them? And let's maybe make it a little bit more concrete. Like, one thing that can happen is as teams grow, like you said, not everyone can know everything. And so it starts breaking down into pods; maybe is one way to organize the team. And then you've gone into a bunch of individual teams working on discrete features. And that's happening fairly quickly. What are some ways to manage that change and manage that growth while maintaining continuity and making it go well? JOSH: I think a lot of it depends on the goals from the technical leadership in terms of areas of ownership. That'd be the first part that I would dive into, I think. We work with clients where they segregate front-end from back-end development. And that allows the teams to focus on React and TypeScript versus Ruby or Go or whatever their back end is written in. But if the goal is to share that knowledge, I think you've got options in terms of lunch and learn and shared code review and team demos and things like that. There are other ways to spread that information across the team so that everybody still has maybe not intimate knowledge of the code that's being written on a day to day basis, but they're at least aware of those patterns and practices and what each of the individual pods is may be responsible for and is delivering. So you have that team cohesion across more of the functional space, on the engineering side or on the product design side. CHAD: One thing that I think I would also add is that a lot of times, people take for granted how better developers will do their job if they understand the reason or the business drivers behind what they're working on. And it's really easy for people to take that for granted because it's like, there's a ticket to the ticket. It says what to do on the ticket. [laughs] JOSH: I have a blog post about this, actually. CHAD: [laughs] Okay, great. We'll put that in the show notes. But if someone doesn't understand the reason behind that, it's not going to go the way that you're expecting frequently. It's not as straightforward. JOSH: Yeah. You're left guessing what the underlying customer need is. And if you're guessing about the motivations, I don't want to say not in absolutes, but you're likely not going to address all of those core needs and implement an effective solution. I think in the blog post that I had written, ultimately, it was advocating for getting engineers to participate in customer interviews and really understand, like, how are people using the product that I am implementing features for? Because without that exposure, without seeing those pain points, oftentimes, it's okay, you've got a product designer or a product manager who's putting together this list of things to do. And if it's treated as a checklist or oh, I need to go implement XYZ without understanding why that needs to be done in the first place, what is the pain point? What is the customer-facing? How are they feeling as they're going through the product? Without that context and without that empathy, the solution is going to be...it might functionally work. But will it be a good user experience? Will it be a good customer experience? It's a little bit more shaky, I think. CHAD: Yeah. And in a fast-moving, fast-growing startup where everyone has a lot to do, if you're experiencing this kind of problem, it might manifest to you as stories get caught up at the beginning stages of when a developer is supposed to be working on them. And you find yourself having calls about what something is even supposed to be or supposed to do. And as the person who originated that ticket or originated that idea, you might have the feeling like, I can't believe we're having this conversation. Like, we don't have time to educate you about all the reasons why this is important and just please just do what we've said on the ticket. That is a natural reaction to that thing. And so my advice would be if you're feeling that, if your team is feeling that or something similar, there's probably something small you can do. It might not even be having developers participate in discovery or interviews or anything. It might be as simple as just making sure that on the ticket you say why it's important. If your ticket is a checklist of things to change or do, making sure that the reason why is communicated there will go a long way to having the person pick up that ticket, get the context necessary to understand, and make good decisions as they work on it. JOSH: Yeah, I remember the switch to the jobs to be done format. And I remember just being like, oh, [laughs] this makes a lot more sense because we can understand the context and the why. What is driving it? What is the problem there rather than what is the solution? And I think that shift in mindset does go a long way, like you said. CHAD: I think one of the ideas behind a well-functioning team is we talk about this idea of collaboration which is you feel like you're doing your best work, that things are moving quickly, and you're enjoying the people you're working with, and you're building upon each other's ideas, and you're making things better as a team. And I was recently talking to someone else, a candidate for VP of Engineering at one of our clients, and they were talking about flow, the idea of flow. And it wasn't a way that I had articulated it previously, but it's certainly another way of thinking about and a good way of thinking about it, especially when it comes to what is the role of a VP of engineering? Or what is the role of a CTO at a small company? Or what is the role of a development team or a product team in general? And one way to think about that is to work to maintain a flow state. And when we think about the processes that we have in terms of retrospectives where every week we gather, and we identify things that could be better, and we come up with action items, a lot of the things that drive what could be better or what we want to try to do differently are all identifying the things that take us out of the flow state and trying to fix that problem so that items flow from beginning to end smoothly, that they go from concept to production smoothly as quickly as possible, and that individual people know where the next item to take is that it's ready so they're not blocked as they begin it. And they're able to get that to staging, and get a pull request out, and get that reviewed quickly, get it to staging, get that reviewed quickly, and then deploy it to production. And in theory, even do a continuous deployment so that that whole flow is automated as much as possible. So this idea of flow resonated with me. Has it resonated with you? JOSH: Yeah, I agree. I remember seeing the comparisons people saying, okay, you're not actually looking for an engineer's passion necessarily. What you're looking for...and I come back to the hiring side of things because I'm doing that right now. But rather than looking to assess passion, it's assessing capacity and ability to get into a flow state more quickly. And obviously, so much of that is dependent on the team, and the communication style, the management style, and things like that. But flow is very much...I think once you get into that and you know how to get into that like you said, every waking moment is spent trying to optimize how do I get into this space? Because when you're in that space, when you're flowing, be it from an IC level or above, there's nothing quite like it. It's just this calm state of just everything feels like it's firing all the time perfectly, and it's good. And I think trying to make those spaces available for the rest of the team to get into that state and maintain that state makes a lot of sense. I remember years and years and years ago, there was the focus on maker versus manager time. And we talk about anchoring manager time either at the start of the end day or around lunchtime or whatever is a logical time for a break. The idea is to maintain that flow state for as long as possible so that nothing else eats into that. Because you do an hour of writing software, and then you've got a 30-minute one-on-one with a teammate. And then you go, and you run for another hour, hour and a half, and then it's another half an hour meeting. It's like you're being sucked away. It is really hard to get into that zone and then stay there. So I think there's been a focus on it for a while. And I'm really glad that there's now a name and a thing that we can point to. CHAD: I don't want to lead people astray about what Boost is. There's a big important part of Boost, which may not be immediately obvious to people, and that is design. I may have insinuated that design wasn't part of Boost before when we were talking about it, but it is. And it's designed on existing products and existing teams which is a different need than going from concept to launch of a new idea. JOSH: So we had done some work with The New England Journal of Medicine. And their team, a very small team, internal team, had basically designed an application. And they ran into a number of accessibility and usability issues. They continued to hear feedback from a lot of folks saying, "This is not effective for what we're looking to do." And they'd engaged us in a couple of different times basically to rip apart and re-architect some of the application hierarchy and the usability side of things. It's been really interesting to see okay, well, within the design side of operating within existing products, it's often lended or leaned more towards doing some amount of a design audit and usability audit, talking to customers. And less around we're going to start from scratch and more what are some of these iterative improvements that we can make to make the product more accessible, easier to understand, easier to navigate, easier to use within what is, again, these very large platforms sometimes? CHAD: I know one common request we get is we're thinking about implementing a design system or introducing a design system with the first version of the product. And we're having this growing pain around introducing new features. Is a design system the right thing to do there? That's a request we sometimes get. JOSH: Yeah. And I think a lot of it at the end of the day, what we're looking to assess is what are the knowns? How much do we know about the application, about the interface? We talk about on the software development side of things avoiding premature abstraction, and I think the same thing is true about design systems. Like, if we're going through a product, maybe it's a wizard, and apart from forms, the pages are individualized, and there's not really any common patterns. It's like, okay, well, maybe now it doesn't make sense. But when you've got an application that spans hundreds of pages, there are going to be patterns across the different pages in terms of application hierarchy and componentization and things like that. And the work that we're oftentimes brought in to do is let's assess what's there, figure out what are the common patterns here. And it's almost like refactoring and teasing things apart to where we get slight...it's a reduction in code use or rather an increase in code reuse because we're removing some of the idiosyncrasies that maybe were not teased apart into some component-based system. And that's fun work. [chuckles] It's really interesting. You get things like React when you're doing client-side rendering. And within the Rails side of things, there's a big push for the GitHub ViewComponent. RubyGem is another example. It's both ways to introduce these layers of abstraction that allow more of the engineering team to take on more of the application development, not because design isn't necessary, but they're then empowered to reuse these logical set of components. And so it amplifies the dev work, but it also amplifies the design work because the entire team is now leaning on that pre-baked work. It enables designers to shift focus and priorities to okay; what are new components? What are different ways to position this or present this information? And also, for our designers, it frees up their time to talk even more to customers, to people using the system. CHAD: Well, I guess we'd be remiss if we didn't do a more blatant plug. You mentioned it earlier, but we do have an opening for Design Director on the Boost team. JOSH: We do. CHAD: So who would be a good fit for that role? JOSH: That's a great question. I think a couple of the things that we're really focusing on for this role is someone who has done the work, so to speak, at an IC level for a lot of the work that we're doing right now with customers. And so we ask point-blank on the application sheet, have you worked in HTML and CSS? Have you facilitated design exercises like design sprints? Have you facilitated user interviews? Because so much of what we're seeing from a vision and a strategy perspective is we need to take and leverage these tools in the skill sets that our teams are looking to hone in on, and we want to take it a lot further. I think there's a big opportunity there. So I think it's less around years of experience. I wouldn't say you need to have 15 years of management experience or having been a director in order to apply for the role. But it's someone that can empathize with the team and has some opinions and some thoughts in terms of okay, what is design? What is not only visual design but product design accessibility? What does that look like in the next 5 to 10 years? Those are the people that I would love to see apply. CHAD: If someone's interested, where's the best place for them to do that? JOSH: thoughtbot.com/jobs. And the listing is there. CHAD: So what's next for Boost, Josh? What do you have your sights set on as we wrap up 2021 and head into the next year? JOSH: Oh boy. A lot of where the focus has been on this year is continuing to double down on Rails as the technology stack and get our feet wet, not that our feet aren't wet, [chuckles] continue to invest on the front end with React. I think for 2022, I think the big focus...we've run in the past some pretty successful custom trainings workshops for engineering teams. I think one that we had done earlier was late last year into early this year. We ran about 120 or so of their engineers through a custom RSpec course. So we worked with their engineering managers and some of their teams and got a sense of okay; given this codebase and given the skill sets of this 100-plus person engineering team, where should we focus? And we put together a two-day RSpec workshop. We administered over; I think, five or six weeks. We did it virtually. And the reception from that was incredible. They ended up bringing us back on. We're getting ready to start another round of consulting work where we're embedding alongside their teams. So I see that as a huge opportunity for Boost coming into next year. And then I think one of the things that we've been pushing for is reducing some of the billing time from folks in leadership positions so that they're in a better position to support their designers and developers. And I'm really excited about the progress that we've made thus far. And I'm excited to continue carrying that into next year. CHAD: Awesome. Well, thanks for taking the time to talk to me. JOSH: Thank you. CHAD: Part of this new season, Season 11 of the podcast, for the next few episodes, I'm going to be talking to each of the managing directors at thoughtbot about their teams, about the different kinds of work we do on those teams, and the challenges, and what phases are clients in those different stages of the product lifecycle. So you can subscribe to the show and find notes for this episode and all the other episodes at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Josh, if folks want to get in touch with you or follow along with you, what are the best places for them to do that? JOSH: Definitely Twitter. My handle is @joshuaclayton, all one word. CHAD: Awesome. Thanks again. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Special Guest: Joshua Clayton.

Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations. They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy The Nightmare Before Christmas - What's This (https://youtu.be/QLvvkTbHjHI) Giant Robots Smashing into other Giant Robots - Plucky with Jen Dary (https://www.giantrobots.fm/search?utf8=%E2%9C%93&term=plucky) Plucky (https://www.beplucky.com/) Services are Not a Silver Bullet (https://thoughtbot.com/blog/services-are-not-a-silver-bullet) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Boom. I'm recording. Magic is happening. [singing] What's this? What's this? It's a Bike Shed episode. What's this? What's this? CHRIS: You did that on the mic. [laughter] So you just started recording too, so it's not like you're like, "Oh, I forgot I was recording." STEPH: Oh, I didn't have a finishing line that rhymes with shed. CHRIS: Head, dead, bread, spread. STEPH: [singing] Is TDD dead? I don't know. [laughs] CHRIS: Cool. I liked it. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? CHRIS: What's new? I had a fun experience over the past week or two of regaining some of my developer merit badges, which is always enjoyable. So one was I had to configure AWS, specifically S3 and IAM such that I could upload files to an S3 bucket, which seems like one of those things that a developer should be able to do, and it's just not that hard. And, man, I failed so many times, and I stared at the screen. And the ARNs I think that's another acronym that I had to try and figure out what it means and fight against. Anyway, I got there. So that's one merit badge earned. I really hope [laughs] I correctly and securely configured access to an S3 bucket such that we could upload files in our Rails app. Cool, neat. Moving on, the next merit badge that I went for was restoring the sea of green dots. Our RSpec output had gathered some noise. There was a whole bunch of noise across a variety of things. There were some dev tools that were dumping some stuff in there. And there was something related to apparition, which is the...I want to say it's the Capybara feature spec driver that we're using now, which sits on top of ChromeDriver or something like that. I don't really understand the details, but it was complaining about something. And I found a fix, and then I fixed it and whatnot. But it was one of those. I did this on a Saturday because I was just like, you know what? This will be cathartic and healing. And then I got to the sea of green dots, and I was so happy to get to it. STEPH: This is me...I'm giving you a round of applause. CHRIS: Well, thank you. Arguable whether it delivered any real value to users, but again, this was Saturday effort, so I was allowed to indulge my fastidious caretaker of the code role. STEPH: Sorry, before we move on to more serious, can we pause to talk about developer merit badges? I really, really want cute felt badges that we can...I mean, I can't design them. I don't have the talent. But I think between us and other folks, we could design amazing merit badges, and then people could collect those. I'm very much in love with that idea. CHRIS: I love the idea. I am now certain that if we were to really pursue this, that we would fall into the deepest of bike sheds as we try and define well; what are all the merit badges? And what are the different levels? STEPH: [laughs] CHRIS: And how many do you need to collect before you can get to what are the different...There are just so many different taxonomies that we could introduce, and, oh man, I could spend a couple of weeks on that. STEPH: [laughs] It has a very strong Pokémon vibe too of you got to catch them all. CHRIS: Absolutely. STEPH: Okay. All right. We won't digress into bikeshedding merit badges, but I'm still very, very interested in that idea. CHRIS: Indeed. If anyone out there in the listener space wants to just make these, that would be great. This is the way that I avoid bikeshedding now is I just say I'm not allowed to make these decisions or even think about it. But if these happened into the world, I would be happy about that. STEPH: Oh, I just remembered we do have something similar at thoughtbot. They're not physical where you can hold them, but I think we've talked about turning them into physical badges. But we have our internal tool hub that we used to track our schedules. And one of the fun Ralphapalooza events that we had, a team came up with the idea of introducing badges in the tool hub, so then you could award people badges. You could give people badges. And it's very cute. So they could probably help us with the taxonomy. They've probably already figured out a number of badges we could get started with. CHRIS: And of course, this is where my brain went initially to like, oh, what would the taxonomy be? But I think that's how this goes bad. And if we just keep it in the this is cute and fun, and what are all the possible merit badges, but they're all equal, and the points are made up anyway, and then it's just a fun thing, then I'm like, I'm super into this. Let's do that. Have you used a regular expression to parse HTML? Congratulations, you get a merit badge. Have you not used regular expressions to parse HTML? You get a different merit badge. [chuckles] STEPH: [laughs] I feel very positive that I could be chief of cute and fun. I could manage that department. CHRIS: Yes, that feels like definitely a role that you could really excel at. But shifting around ever so slightly, I did run into a fun bug this week. And it was a mystery tour of, I'm going to say, sadness and then eventual learning and understanding, and I think we've come to a better place. But I want to tell a story, take us on a quick tour of the adventure that I went through. So we recently saw a handful of exceptions come through in our exception monitoring service and then piped into Slack, where we see those around CSRF token expiry. So this occasionally happens in a Rails app. The CSRF token that was on the page gets rotated. And therefore, when someone...if they have an older version of the page open and they try and submit a form or something like that, then CSRF protection is going to kick in. And you do get some false negatives there or some cases where like, nope, this is actually a fine user, this is not hacking, this is nothing bad. It's just that that user had a tab open or something like that. I'll be honest; I want to understand better the timeline of expiry and how Rails expires those and whatnot. But it's one of those things; it's deep enough in Rails that I trust that they are doing a very reasonable thing. And I think the failures that we're seeing that's part of the game. And so, mostly, we wanted to add a nicer handling around that. So thankfully, Inertia actually has a really wonderful page in their docs about handling Cross-Site Request Forgery expiration token, this whole thing. This is a particular failure mode that your app might have. And so it's nice to be able to provide a nicer user experience. And so what we ended up doing is if we catch that exception, we have a rescue_from in our application controller that will instead of having this be a 500 and just a full, like, something went wrong error page, we instead respond in an Inertia-like way to basically show a flash message that says, "This page has expired. Please refresh the page to continue." And if the user just refreshes the page, then they will get a new CSRF token. And from there, everything is going to be fine. So it's not ideal. But it is, I think, both secure and now a nicer user experience. STEPH: Yeah, that sounds really nice. When they refresh the page, do they lose all that form data? I'm curious how painful of a flow that is for the user. CHRIS: Currently, yes. Inertia actually has a really nice feature for remembering form data. If you've ever been on GitHub and you're filling in a box, and then you go away to a different tab, and you come back, and it's still there, and you're happy about that, it's that sort of thing. So we could configure that. At this point, we don't have...most of our forms are pretty small. So this is not something that we opted to do proactive management around. But that is definitely something that we could add but not something that's default or anything like that. STEPH: Cool. Yeah, that makes sense. I was just curious because yeah, either small form doesn't really matter, or also, this may be just a small enough error that only a handful of people are experiencing it that it's also just not that big of a deal. CHRIS: Yes, this definitely should be an edge case. And we've also recently been working on functionality to log folks out after a period of inactivity, which would also, I think, obviate this in a different way. So all total, this shouldn't be a big deal. And this was basically a quick, little snippet of code that we thought we could just drop in, and everything would be great because it shouldn't happen much. But then I was testing out a different feature on staging, and everything I tried to do was popping up this little alert flash message that was like, "Hey, your page is expired." And I was like, that seems bad. And then I realized literally every action, any non-GET request, was getting this response that the CSRF token didn't match. And I was like, well, this seems bad. Luckily, it was only on staging and hadn't made it to production. But it had made it to staging, which meant it had gotten through CI, which was very concerning because we have a pretty robust set of feature specs at this point. We built up a bunch of fakes for all of the external data systems that we're interacting with. And we're really putting the app through its paces and trying to do so in a very production-like way. And so I was like, this is such a deep fundamental breakage. I don't know what's going on here. And so I started to investigate. And it turns out that in a recent commit, I had started using Axios, which is a little wrapper around the Fetch API. They may not actually use the Fetch API under the hood, but it allows you to have a nicer interface to make XHRs. And we implicitly had that in our package already by virtue of Inertia. Inertia uses it under the hood, but I wanted to make it explicit because now I was using it directly. So I figured that's cool. I will yarn add Axios, and then I will continue on with my day. And I worked on my feature and everything was great. And then I pushed it up into a pull request, and everything was great, and CI passed. And I got it onto staging, and everything was very sad. So then I started on the adventure of like, what is going on here? It turns out that somewhere between version 0.21.1 of Axios and 0.23.0, which there's a bunch of things about those version numbers that make me uncomfortable but here we are, somehow the behavior where you can configure the XSRF header name, which is what they're calling it on their side, the configuration stopped working. And so our override that says this is what our CSRF or XSRF token should be called when it's sent back up to the server in a header that was getting lost. And so they were falling back to their default name, Axios was. And, therefore, Rails was like, "There's no CSRF token here. So this is going to be a no for me. I'm going to reject all of the requests." So the fix was relatively easy to roll back and to pin the version of Axios to the previous version that we had been using. I didn't actually intend to upgrade it. I just intended to make it an explicit dependency. But by doing that, I accidentally upgraded it. I don't love that there was this pretty deep breakage in that. I haven't done the good work of trying to open an issue. I still want to scan through and see if there is an open issue or a conversation around this before I start making any noise. But I think if I don't find anything, this is the sort of thing that should be reported because I can't imagine I'm the only one running into this. Likewise, I was very sad that my test suite did not find this. Turns out in Rails, CSRF protection is just turned off in test mode, which may be overall makes sense. But for feature specs, in particular, I definitely want to have it. And so, it was nice that I was able to find the relevant configuration. And we introduced an RSpec configuration that says, "If it's a feature spec, save off the existing configuration and enable CSRF. And then after the spec, go back to whatever the previous was." So now all feature specs run with CSRF. And I did make sure to push up that as a singular change to CI, and CI was very unhappy with me. Many, many features-specs failed, which was good. That was what we were going for. They failed for the right reason because things were fundamentally broken. And then, I was able to update the package-lock or the package.json on the yarn lock, pin the version, fix everything. But man, there was this period of like, oh man, the app is broken in such a fundamental way. Users just can't do stuff anymore. They can view anything, but they couldn't change any data. And it just snuck through CI. And that feeling is the worst feeling. We had, at this point, built up a lot of trust in our test suite. It was really telling us when stuff was wrong, and if it was green, I felt very good merging. And suddenly, this just really shook me to my core on that front. STEPH: I love these journeys that you take us on. I mean, they're painful for you, and I am sorry to hear that. But I love these journeys that you take us on. [chuckles] CHRIS: I usually only take us on them when I've figured out the answer. And I'm like, all right, here's where we're at. It was rough for a little while, but now we are happy. And thankfully, the one configuration of saying, hey, Rails, also, please include this as part of our production like, configuration for test mode. So I feel better that moving forward, this breakage won't happen again. STEPH: We should add that as another merit badge for telling a bug story. All right, I'm taking off my hat of chief of fun and cuteness. So this may not be terribly relevant to all the things that you just shared. But I am curious where you mentioned that with Axios because you'd specified the name of the token, and then that overriding behavior is what then broke. And so then that's what led to this whole adventure that you went on. I'm curious, why did y'all customize the name of that token? CHRIS: A, this is a great question. B, I'm not super sure. C, I think the reason is because we were trying to align to Rails. So we have a little middleware on the Rails side that will serialize the CSRF token into a cookie. And then that cookie value gets read by Axios and sent back up as a header on the request. So this is the way that with Inertia CSRF just kind of works and is good. And it's different than Rails' normal. We put a hidden input into any form. And so Rails holistically knows about both sides of that, and everything works fine. But now I have to manually round trip the CSRF token. And Axio's default configuration is a header name X-XSRF-TOKEN, and we needed X-CSRF-TOKEN because that's what Rails is looking for. I probably could have configured it the other way on the Rails side. But one way or another, I had to get Rails and Axios to come to an agreement, to meet at a table, and to agree to collectively protect the app. And so I had to mediate that discussion, and that's what ended us here. STEPH: A meeting of the minds. [chuckles] Cool, cool, cool. Yeah, that makes sense. I was just curious because then that would have changed the whole journey. But yeah, that is super interesting. And I definitely resonate with the idea of when you've really invested in your test suite, and you trust it that then when it doesn't catch something that obviously breaks the application, then that feels like something worth prioritizing and digging into and then figuring out how to bring back that parity. I don't know that I've turned on enable CSRF for feature spec. So I'm also very interested in looking at that configuration and considering if I need that for any of my future client projects if that's something that I need to remember for the future because that's very niche but good to know about. CHRIS: I feel like this only really comes up if you're working in the...it's called the odd middle ground that Inertia ends up occupying. If you're in a traditional Rails app that is generating HTML server-side, forms are generated. They got the CSRF token inlined there in a hidden input. And then when you post that form, it's coming back up. The names automatically are going to match. You don't need to worry about it. And it's probably fine to not have it included in test mode. And if you're at the other end of the spectrum and you've got API interaction, and that's the way you're doing everything, then you have a different auth mechanism and cookies, and whatnot just don't apply in the same way. And so it won't really matter on that side but for a different reason. And it's only because we're in this interesting middle ground, which, again, I really love. And it's the thing that I love about Inertia. But this is a rare case where it's like, oh, we do have to bring the two sides to meet in the middle. And this is a case where, unfortunately, due to a very subtle breakage on a minor release of...a package that we're using silently broke so, yeah. But yeah, thankfully, everything is back to working. And again, we've been able to enhance the test suite in that little way that I feel confident again because this won't sneak in another time. We have coverage around this. We're good to go. So while I was very scared when this initially happened, I feel better now. I'm happy to go into the weekend feeling better about this. But that's my story. What's new in your world? STEPH: So I feel like I've been having one of those weeks where I have less code adventures. In fact, it's one of those days where I went to thoughtbot's daily sync...because we often have our client daily syncs, but then we still have a thoughtbot sync as well. And I went to the group, and I was like, I get to write code today. It's going to be a great day. All the other things I'm doing are also interesting, but I get particularly excited when I get some maker's time and get to write some code. So I feel like I've had less coding adventures recently and more hiring and process-related adventures. And specifically, I just completed the Plucky Manager Training, which is a program that's founded and led by Jen Dary, who was recently on thoughbot's podcast, The Giant Robots Smashing Into Other Giant Robots. I'll be sure to include a link in the show notes for anyone that's interested. CHRIS: I believe this was the third time she was on. It's at least the second, possibly the third. And all of them are great listens, just as an aside, so we should include links to all of them. STEPH: Yes, I think she's one of the rare guests that has been on the show three times. And I think I've only listened to the first couple minutes of that episode. But I think they talk about the fact that this is her third episode, which is really, really cool. And I'm still frankly synthesizing all the information and the ideas that I've collected from the course. But I do have a few quick takes that I'm interested in sharing with you. So the first one is my cohort...we were the Panda Cohort, so go, Pandas. And some of the things that we talked about were…, and I think that this may have been the first day. So it was three days, and it was three hours for those three days. And they're spread out over a couple of weeks, which is really nice because then you show up for those three hours of the class, but then you leave with some ideas and some things to experiment with. You get a week to then try out an experiment and then come back to class next time and talk about this is how it went; it went to wonderful, or it went terrible. And you get to share that with others and work through it. And in the first class, we talked about coaching versus managing, which I found just a helpful definition to review. So managing is more direct, and telling someone what to do while coaching is encouraging someone to determine their own path and find their own solution. And I find that as a team lead at thoughtbot, I'm very often more in that coaching space than I am in that managing space. I think it's frankly pretty rare that I actually need to put on a manager's hat. And I often feel like I'm wearing my coaching hat instead. And some of the other things we talked about one of them is what is work? Which is a fun question to ask. And Jen had an analogy for this speaking about imagine that you have a plastic Easter egg. So it's got two sides, and side one is all the skills and desires and things that you're fulfilled by. And side two is a company that needs those skills. And it's great when those line up and click together, like when you take a job or get a promotion. Have you ever played...do you know what I'm talking about? Those little plastic Easter eggs. Have you ever played with those as a kid? CHRIS: Yes, certainly. STEPH: [laughs] I realize I just launched into that analogy. [chuckles] And then Jen goes on to say that's totally normal for then those sides to unclick. And Jen continues to say that it's totally normal for them to unclick. So maybe the company changes direction, the company is acquired. You've fallen out of love with something that you do about your job, or you have kids, and that has changed the things that you are fulfilled by and what you're looking for. And that's not necessarily bad. So it can be like, hey, you are working on x now, and you're not fulfilled by that anymore. But then another company comes along and says, "Hey, we're working on this, and you are fulfilled by that." So then another click happens. And essentially, it's a nice analogy to represent someone's career path and the ways that we are going to shift and re-prioritize what we're interested in. But it's also a really nice way to help it feel less personal because both sides are allowed to change. The company can change. You, as an employee, can change. And then you can look for that next click that is going to match up with a company that meets your skills and things that help you feel fulfilled. One of the other topics that we talked about are hard conversations, which I love that we dug into this one because that's certainly one that I struggle with or...I mean, we all get that feeling if you have to confront someone if you have to have that uncomfortable discussion with someone. It is a very hard thing to do. And so we had some very honest conversations around what is a hard conversation? What does that represent? And essentially, they represent that there is stalled progress and something can be improved. So Jen likens a hard conversation to a tool. It's something that you can use to then help something move forward again if something feels stalled or if there's something that needs to change. And during those hard conversations, you may not get to the resolution that you're looking for. So you may be looking for a specific outcome. But you also have another person that needs time to respond and to take in everything that you have said and process that information. So when you have a hard conversation, you may actually only move forward an inch. So if you had a lofty goal of we're going to talk and then we're going to have this hard conversation, and we're going to get to this space...But instead, you actually just make incremental progress. Like, okay, at least this person is now aware of this concern. That might be your win for the hard conversation versus actually tackling; how are we going to address it? I just want them to be aware of this concern. And it's a very vulnerable conversation, and they often take time before you can get to that ideal resolution. But essentially, the idea is get in the game, start the conversation, and then have follow-up conversations for that hard conversation. And I really appreciated that framing because I often will think of hard conversations of oh, we have to have this hard conversation and get to this specific outcome. But if you shift the goal line to be like, no, I really just need to at least make this person aware of a concern, that makes it a lot more approachable. And then also probably yields more fruitful outcomes because that gives the other person time to think about what you've shared to also come to the table with their own ideas and then work together to then get to that ideal resolution. CHRIS: I like that framing a lot. I can definitely see the case where you, as someone who has recognized something that needs to change (perhaps you're a manager),lineup you've now thought about that a good bit; you've observed it, but the individual that you're bringing that to this may be novel. This may be a surprise for them. And so if you come into that interaction both about to share this information but then also trying to resolve it and trying to get to I need you to internalize it, and I need you to fundamentally change your behavior as a result of this conversation we're going to have, that's quite possibly not a realistic outcome. And if you're trying for that, it might inherently lead to just a bad outcome because that individual is not in a position to do that. But they are potentially ready to hear it. And so you can just achieve step one and then later have step two. So I like that a lot. STEPH: Yeah, in general, I found the course incredibly helpful, very insightful. It was also really nice to hear from other managers that are facing similar problems or perhaps novel problems and then getting to weigh in and help each other. So it's a wonderful course. I'll be sure to include a link in the show notes for anyone that is interested. And I'll probably come back with some more insights from the class because it's really...we just wrapped up. So I'm sure I still have some ideas that will percolate over time, and I want to come back and share those with the group. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Pivoting just a bit, we have a listener question that I'm excited to dive into. This question comes from the one and only, the Edward Loveall, fellow thoughtboter. And Edward wrote in, "How does the process of software development change at different team sizes? What's a process that breaks down soon after the team starts growing? What's a process that is resilient at all sizes? And by process, I mean anything that involves other people including organizing tasks, code review, deployment, or anything else that isn't you alone writing code in a vacuum." I'm really excited about this question because I think there's a lot here. And there's actually one part that I'm struggling with a bit, so I'm curious to see what you think, Chris, about it. But I'm going to start off with saying that I think there are a number of management processes that definitely break down as a team grows. But in the spirit of Edward's question, I'm going to focus more on the software development process and how those might need to change and what starts to break as your team grows. So starting off with processes that break after the team starts growing, this one, frankly, what really starts to break is not a process specifically, but it's the lack of process that really starts to become visible and painful. So, how do we track work? Before, maybe the product manager or someone would just send you a message and say, "Hey, can you work on this?" or "Hey, can you fix this thing?" And how does code need to be reviewed before being merged? Does it need to be reviewed? Are people just merging as they get stuff done? How are deploys performed? Oh, we have a super urgent production fix that needs to go out, and the only person that knows how to deploy is out sick today? Cool. That's the type of process that I think that really breaks down, or at least you start to notice when the team starts to grow. What are your thoughts? CHRIS: I definitely feel that first one very strongly. We're feeling it right now on the team, which is still very small. There are only three developers working on the project, and then we have a product manager. And each week, we're slowly iterating, and tweaking, and honing, and trying to introduce just enough process in terms of how we define the work to be done, communicate the status of it, all of that fun stuff. We started with Trello. And we just had a board with some columns, and then we had more columns, and then we got rid of a few of them. And then we recently added a Power-Up to the Trello board, which allows for epics. So there are cards which are epics which tie to sub cards. And I'm staring at it, and I'm like, how long until we're Jira? How long can I hold out here and not be Jira? But it does feel like we're slowly iterating towards a more useful process for this team rather than process for process' sake, which I feel like is a really useful distinction. There's also a question of like, what can be known or what can be adequately measured and whatnot versus what can't be? So we've talked many a time on the show about estimation and velocity and trying to track that and the pitfalls inherent with that. And so there's, in my mind, two different camps. There's the process we want to avoid. And again, to reference German Velasco's wonderful blog post, Say No To More Process. And I really feel like there is a tendency often when things go wrong to then try and paper over that with process. Oh, this team didn't use the design system. So we need to write ESLint rules to make sure you can't import from the directories that aren't the thing. And it's like, we can do that, and I've definitely done that. And I will do that again in the future. But I always have the lens of do we need this? Is it worth the trade-off, the cost, the overhead, the complexity that it's bringing in? But definitely, organizing and communicating tasks is one of the ones that becomes really difficult. The more people that are working on something, the more you need probably more than one person staying out in front of them and trying to define the next bit of work that needs to be done after that. Code review feels like it probably should stay similar, with the exception that I lose the ability to review all code at some point. Right now, I'm trying to review every single PR that goes through or close to it. At some point, I'm just going to have to give up on that. But for now, that's my goal. But fundamentally, code review, I think, will hopefully take the same shape. Deployment, similarly, like, I've talked about the merge queue thing. I want to get a little bit of process in there but not too much. There is definitely some necessity for change. But I definitely want to resist the urge to change everything and to just say, like, slowly over time; we're going to have to be a big Byzantine organization with lots of rules and standard operating procedures and all of that. I've heard anecdotally, and I don't know if this is true, so maybe someone out there on the internet can correct me if I'm wrong, but my understanding is that at Google, they're pretty tight in terms of what languages and frameworks can be used and what processes, and workflows, and build tools and all of that whereas Facebook, as a counterpoint, is relatively lax. Obviously, React is used very heavily on the core web application. But there's some flexibility in terms of different languages and frameworks and things for sub-projects or small individual teams having a little bit more autonomy. And I think that's a really interesting thing of are you one large, cohesive, organized company or do you try to act like a bunch of small disparate but roughly connected teams that share good ideas but can work independently? And that changes how I would think about this question. STEPH: I really like how you're describing the addition of process. It sounds like a just-in-time process. So as you're learning that something needs to be added, then that's when you look for answers. And then you sprinkle on a bit of process that everyone agrees that feels very helpful within also the right to review and see if that still makes sense for the team. There's one additional area where I think the lack of process really shines through in addition to the number of ways that you've mentioned is also onboarding. So if you have a very small team and you are onboarding, it's likely that...Chris, you can let me know if I'm wrong, but when someone's joining the team, there's probably a good chance that they get to pair with you at some point, or they even get welcomed by you to the team. And then, they get an overview of the product and the codebase. And there's probably this really nice session where they get to ask you questions, and then they have that onboarding session. Does that sound about right? CHRIS: Yes. But I would go so far as to say it's not just a day or a session, but it's probably a couple of days. So yes, and. STEPH: That's even better. And with some of the smaller teams that I've seen, that onboarding process is where they are pairing with that lead person on the team. And that's going well until suddenly that lead person can't pair with everybody. And nobody has really thought about how to streamline that onboarding or how to coach or teach someone else to be a really good onboarding pair. And I have strong feelings about this area because we often focus so much on hiring, but then we drop the ball when it comes to onboarding that new, wonderful colleague that we've worked so hard to recruit. And at the end of that day, someone's going to reach out to them and say, "Hey, how was your first day?" And it makes a big difference for that person's retention as to how those first couple of days ago. So I think onboarding is another really important part that when you're a smaller team, you probably don't need much process because you have more of that personable onboarding experience. But as the team grows, there needs to be more of a process to help other teammates join the team. CHRIS: It's interesting. I think I totally agree with you that over time, there is a necessity to be more intentional and to have a little bit more structure in the process. And I don't think you're saying this, but I just want to make sure we are saying the thing that I think we believe, which is that shouldn't replace the human that helps you onboard. Like, I still like the idea that everybody gets a pair for some amount of time when they start at a new company. And you're working together on a feature, or you're working together on bug fixes. You're shipping to production as soon as possible. But you're not doing that based on some guides in a wiki. You're doing that with another human that's helping you. There should also be guides, and a wiki, and documentation, and formalization as the organization grows but not in place of having another person that you get to talk to. STEPH: We're just going to send you a little yellow rubber duck and then with a little Post-It note that says, "Good luck [laughs] with your onboarding process." Definitely. I agree with everything you said. It does not replace that human element where there's someone that's helping you onboard. I just see that onboarding is one of those things that gets forgotten, or we often point someone to a README which I do think is great because then it is battle-testing our README. But then there still needs to be someone that is readily there to say, "Hey, how's it going? What are you struggling with? Can I pair with you?" There still has to be that human element that is helping guide you through the process. And I think smaller teams may forget that they actually need to assign somebody to you to make sure that you have someone that you know. Like, hey, this is who I can reach out to with all my questions. Because they're probably not going to be comfortable posting in the company channel at that point or a larger communication to say, "Hey, I'm stuck on something." CHRIS: There's one other area that comes to mind, or I guess it's more of an anecdote that I have heard, but it speaks back to GitHub's early, early days. And they were somewhat famous for being very flat in terms of the organization and very self-organized, and everybody's figuring it out, and you're working on the thing that's most important in your mind. And for a long time, this was a celebrated facet of the company and a thing that they talked about rather publicly. And then I think there was this collective recognition, and maybe they reached a tipping point where that just didn't work anymore. Or maybe it actually hadn't been working for a bit, and there was just the collective realization of that. But it was interesting to watch from the outside as GitHub added more formalization, more structure, more managers, and hierarchy, and career ladders, and things of that nature. And I think there's a way to do all of those things in a complicated, overloaded, heavy way. But I think a different version of it is...like, you were using the word coaching earlier. Having formal structures within your organization to encourage people on their career path, to help them grow, to have structure around that, I think is a really difficult thing to get right. But I think it is critical, and I think just not having it can't be the answer past a certain probably pretty small size. So that is an interesting one where I think you do need to introduce some process and formalization around how you think about the group of people and how they work together within your organization. STEPH: I agree. I think where some folks may see a lack of hierarchy; others feel a lack of support. And adding levels of management should really be focused on the outcome is that we're helping people feel supported. So even getting feedback as you're adding those different levels of management, like, hey, did we make your life better? Did we make your life worse? I think that's a great question for management to ask as they're exploring a less flat structure. CHRIS: So, Steph, I have a question for you now on a variant of this topic. In general, we seem to be fans of having a codebase. Probably a Rails app that's got a database behind it, and that's where you put the data. Everybody commits to that same repository. It's all kind of one collected thing. And often, organizations grow to a certain size, and they're like, this is untenable. We cannot have this many people working on this same codebase. So we shall do the logical thing, which is we will break it up into small pieces. And those pieces will communicate over HTTP, and it will be great because then our teams can be separate from each other and can manage their little piece of the world. What do you think about that? Is there truth there? Is it not true at all? What do you think? STEPH: All right, so your team is getting too big, and to the point that you feel like you need to split it out so then you can have small teams, and they can all work independently on different parts and services of the codebase. I don't love the idea. I'm trying to think through because I feel like there's a lot of nuance here. But I don't love the idea that that's the driving force as to why are we making the change? And that is often a question that comes to mind whenever we are making a big change, either architecture or process-related is like, what's driving this? And then how are we going to measure it? And if we are driving it just because we have a large team, let's talk more. Why are people blocked? Why can't people work together? What's preventing people from being able to contribute to the same codebase? Are people blocked for a long time because they're having to wait on someone else to complete that work? I have a lot of questions that I don't know if I can fully answer your question. But my instinct is to say let's not break up the architecture just because our team grew in size. CHRIS: Yeah, I think I definitely agree with that. There's probably a breaking point where it's just too many individuals, and there'll be too much contention. But I think resisting that or at least naming that as like, okay, that's what we're saying but is that really what's true? Or are we actually feeling that this system is so deeply coupled that there's no way to change some small piece of the code without impacting other parts of it? Like, is the CSS completely untenable because we're just using global class names, and it's leaking everywhere? Okay, do we need a different solution there? And then it's actually fine. We don't need to have different services that have their own different style sheets. We just need a different approach to CSS. That's a particularly easy one to go for because there's inherently a global namespace there. But the same thing is true in a lot of different contexts. So services are a way to break things apart and enforce those boundaries. But if inherently coupling is your problem, then you're just going to be coupled over HTTP, and I think it's going to be difficult. There's a wonderful blog post by Josh Clayton, which I think does a better job than I'm doing in this moment of highlighting some of the questions I would want to ask. The blog post is titled Services are Not a Silver Bullet. And so Josh goes through and enumerates a bunch of the different versions of the story that he's heard throughout the years of well, we need to go to services because x, because our test suite is slow because pull requests are constantly having merge conflicts and whatnot, because the code is very deeply coupled and any change here affects everything else. And a fix over here broke something over there. This is no good. And so he does a really good job of presenting alternatives or at least questions that you can ask to say, like, is this the problem, or is this a symptom? And we need to address the more underlying cause. And so I think there is a point where you just can't have 1,000 people trying to commit to the same Rails codebase. That feels like it's maybe too big. But it takes a while to get to 1,000 people. And there will be times where extracting a service makes sense or integrating with an external service that exists. Like, I've talked about Stripe before as my canonical like, yeah, it's actually deeply intertwined with the data model, but they're just dealing with such a distinct complexity set over there. And they have such expertise on that that I'm happy to accept the overhead of the fact that that service lives outside of my core application, and I need to deal with synchronizing state and all of that. I will take on that complexity, but it's not worth it for everything, and it's not a silver bullet. Again, to reference the name of Josh's blog post there, Services are Not a Silver Bullet. And so, coming back to Edward's original question, I would say that having a monolithic codebase works for a really long time, but there is probably a breaking point somewhere well along, but fight it for as long as you can. I think. STEPH: I really like how you touched on coupling because it really helps ask those questions to get to the heart of what are the pain points that you are feeling? And it is less of a decision that is based on people and process but more if you're going to split out a portion of your architecture. It is in response to an actual business need and a business value versus some other pain points that you're trying to fix. A particular example might be like maybe you have a portion of your application that really just needs to spend a lot of time crunching data. And it's really not as specific to your application; it's something that can happen on its own. And then it's beneficial to move that outside so it can scale and relate it to the work that it needs to perform versus keeping it in-house with the application. I do want to circle back to another question that Edward included which is what's a process that is resilient at all sizes? And the ones that really come to mind for me...and these are a bit amorphous intentionally because it will look different for each company. But three areas that are very resilient at all sizes, whether you are 1 to 2 employees versus you've got hundreds or thousands it's communication, testing, and accountability. So communication, where are we headed, and how do we know what we're working on? For testing, it's how do we test our changes? Do we write tests? Do we use QA? Do we have a staging environment? What does that look like? What's our parity between staging and production? And then how do we know what's in progress, and how do we know when it's done? Those are three core areas that, regardless of your team size,,I think are very crucial to the team success. What do you think? What are some of the processes that are resilient at all sizes? CHRIS: I actually really like the list that you just provided. That is a wonderful trifecta, and I think it will take you very far, so probably not much to add from me. But I guess on that note, should we wrap up? STEPH: Let's wrap up. CHRIS: 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 in 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 hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeee! 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.

The first West Nile virus-positive mosquito pools have been detected in South Dakota, along with the first human virus detection of 2021. South Dakota's state epidemiologist Josh Clayton joins us for an update. The drought in South Dakota is causing issues all across the state including ranching. Eliza Blue and her husband Max are experiencing real-life problems on their ranch in Perkins County. The future success of the state depends on developing homegrown leaders. That is Leadership South Dakota's mission. Rick Melmer is its director and joins us today with more. This week in South Dakota history, we remember that four decades ago, then South Dakota Governor Richard Kneip resigned to become the U.S. Ambassador to Singapore. Bob Yapp is a national expert in historic preservation. He joins us to talk about the costs and benefits of preserving history in rural South Dakota. Harper and Midwest Kind perform Wednesday evening at the Red Rock in Rowena during Bike Night, a benefit for the

This week's guest is Mike Farrell, Assistant AD for Broadcasting and Video Production at University of Maryland.  As part of Maryland's 75-year Terrapin Club "Reinvented" campaign, Mike and his team created Terrapin Club +.  Often referred to as "Netflix for Terps", the subscription service is the first of its kind in college athletics and features five shows to create additional value for Terrapin Club members and share the stories of Maryland current and former student-athletes. We go in-depth on content strategies and deepening ties with your tribes in this episode.6:30  Terrapin Club “Reinvented” and Terrapin Club +8:17 Creating Membership Value Over Donor Programs11:10 Biggest Production Surprises and Challenges14:56 The Student-Athlete Perspective16:30 Content Strategy and Distribution Strategy25:06 Authenticity vs. Production Quality28:08 Diving in on the Terrapin Club + Five Series38:11 The NIL Impact43:30 Measuring Success47:46 Maryland's Sources of Inspiration50:24 Rapid Fire Questions     Books Inspiring Mike     A Life-Changing Perspective     Mike's Billboard*SLIGHT CORRECTION* - Since the launch of Terrapin Club +, the Terrapin Club has seen a 100% year-over-year growth, rather than the 100% growth mentioned in the show.----Check out  Terrapin Club+   |  YouTubeFollow MikeTwitter  |  InstagramAdditional ReferencesErrol Morris DocumentariesMichael's Favorite BooksThis is Not a T-Shirt by Bobby HundredsWinning the Story Wars by Jonah SachsTrue Story by Ty MontagueShout out to all those who produce and support Terrapin Club + Haley Timple, Jonah Haas, Tony Price, Jarred Belman, John Bartman, Josh Clayton, Alex Gross, Thomas Mason, Jason Yellin, Patrick Fischer, Taylor Smyth, Jordan Looby, Brian Ullmann, Carrie Blankenship, Kendall Butters, Jake Rose, Andy Wray, Alex Grant-- Today's episode was sponsored by CheckdIn.  Know exactly who's working in your venue.Want more from EngageMint? Subscribe to our newsletters at https://engagemintpartners.com/newsletters

In Part Twelve of The Visceral Voice's new limited series, Christine and Kimberly listen to "The Voice Of: The Music Director & Orchestrator."John Bell (Music Director) On Broadway, John has conducted My Fair Lady, Fiddler on the Roof, On the Town, and An American in Paris. He is also the music director of the First National Tour of Lincoln Center Theater's My Fair Lady.  John has been the music director/supervisor at Irish Rep for their innovative digital streaming production of Meet Me in St Louis, as well as On A Clear Day You Can See Forever, Finian's Rainbow, Donnybrook, and their gala concerts since 2014. For City Center Encores: Brigadoon, Me and My Girl, The New Yorkers, Cabin in the Sky, Do I Hear A Waltz, Lady Be Good, and more (Associate Music Director). Other New York credits: Sondheim's Marry Me A Little(New Cast Recording) and Adam Gwon's Ordinary Days(Keen Company); Radio City Christmas Spectacular; Candideat Carnegie Hall.  He holds a BFA in Musical Theatre from Ithaca College, a Masters in Music from CUNY, and has studied at the Manhattan School of Music.Josh Clayton (Orchestrator) Josh's orchestrations have been heard across the country in the National Tour of Lincoln Center's Tony-winning revival of My Fair Lady. Other recent orchestration credits include; The King and I (National Tour), Titanic (Signature Theatre and South Korean productions) and A Funny Thing…Forum (Two River Theatre). He has provided arrangements for many shows at the Irish Repertory Theatre in NYC including productions of Meet Me In St. Louis, On A Clear Day, Finian's Rainbow, Donnybrook! Recently,  On Broadway, Josh provided additional orchestrations for Gypsy (with Patti LuPone), On The Town (Revival), and was the assistant conductor of the 2009 revival of Finian's Rainbow. He has provided orchestrations for such stars as Patti LuPone, Kristin Chenoweth, Nathan Lane, Cheyenne Jackson, and Denyce Graves. He is currently the assistant musical director of the New York City Center Encores! series.Be sure to check out my Self-Care Membership, courses, and events at www.thevisceralvoice.com! And follow us on Instagram!Are you willing and able to becoming a Supporter of The Visceral Voice Podcast to help keep this podcast running? Please click here.

Jem and Josh (Forge Ahead Podcast, Speed) are my guests for this episode. Ripping chat about Parkway Drive's 'Killing With a Smile' - fun to chat with two mates who are getting started with their own podcast and talk about a record that had a big impact on the three of us in one way or another! Check out Forge Ahead here: https://www.facebook.com/forgeaheadpodcast/

Straight from Atlanta / USA, we discovered some fabulous underground artists with a big love and passion for diggin' music. 'Simulate' is the combo of John Shallcross and Josh Clayton, together they have an extraordinary mixing technique and special music taste, which totally complies the way we love it. Enjoy this journey of 1.5 hours nicely trippin' tunes and stay healthy! Check check: https://soundcloud.com/simulate-atl And here the releases on 'as usual.music'... @as-usual-music

South Dakota Gov. Kristi Noem, Department of Health Sec. Kim Malsam-Rysdon and State Epidemiologist Dr. Josh Clayton held a press conference this afternoon to provide the latest information on the status of COVID-19 (coronavirus) in the state. Ten cases have been confirmed in the state so far out of the around 500 people that have been tested.

South Dakota Gov. Kristi Noem, Department of Health Sec. Kim Malsam-Rysdon and State Epidemiologist Dr. Josh Clayton held a press conference this afternoon to provide the latest information on the status of COVID-19 (coronavirus) in the state. Three more cases have been confirmed, bringing the total (as of 4pm March 11, 2020) to eight. Eleven tests are pending and 27 have come back negative. 

As of April 26, 2019, almost 700 cases of the measles have been reported in the United States--none in South Dakota. State epidemiologist Dr. Josh Clayton tells DRG news and farm director Jody Heemstra although the disease is quite contagious, it's also quite treatable.

Sabrina Hill talks with South Dakota Department of Health State Epidemiologist Dr. Josh Clayton on how to stay healthy and free from infection when coming in contact with potentially contaminated flood water.

On this episode of the Bike Shed, Chris is joined by Josh Clayton, thoughtbot's managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development. Specifically, they touch on server side frameworks like Ruby on Rails and Phoenix in the Elixir world. In addition, they discuss a variety of front end trends including the move towards typed languages like ReasonML, TypeScript, Elm, PureScript, and Scala.js, as well as frameworks like React, Ember, Angular, and Vue.js. Bike Shed 20 w/ Josh Clayton: Intentionally Excruciatingly Painful Google Lighthouse Beyond React 16 by Dan Abramov - JSConf Iceland AirBnB Moving Away from React Native Josh Steiner - Elm native UI in production Announcing Purple Train ReasonML Elm TypeScript PureScript Scala.js Software disenchantment blog post 166: Are Services the New Rewrite? Apollo Client Vue.js Thoughtworks Technology Radar Parcel Bundler Terser javascript minifier Rufo - Ruby autoformatter

Often in business, people discuss and agree on terms of engagement. Today's conversation is about what to consider with business contracts and putting things in writing. On this show, we have Josh Clayton from the law offices of Josh Clayton, located in Shreveport, Louisiana. He began his career with law firms in Baton Rouge and Hammond, then worked briefly at an oil and gas outfit in Shreveport before going into private practice in 2008. Click here to find more information on our website. Contracts - Key Points When does one need to invest in documenting a legal contract? Why lawyers say that phone calls never happened. Contracts don't need to sound like a lawyer wrote them. When entering into a relationship for any service, at the very minimum, put your expectations in writing and get a confirmation. Good contracts make good business partners. Lawyers can use past email correspondence to come up with a proper contract. An attorney will ask the tough questions that you might have overlooked in normal business dealings. No need for reservations; contracts are modifiable. Lawyers are encouraged to write contracts in simple English. When someone hands you a contract, don't be too eager to sign on the dotted line without getting a legal opinion. People sometimes underestimate the value of building a trusted advisor network. A tip on how to find the best lawyer when you have a specific need. Invest the next 20 minutes in finding out more. Links ShreveportAttorney.com If you have not checked out all of our free resources available to you. Click here for our site. Here are some of our featured free resources. How Can I Organize My Financials? Should I Have A Business Plan? What Steps Should I Take Towards Branding? How Can Marketing Bring In More Clients? The Start-Up Checklist What Type Of Corporation Should I Be? Things To Consider When Scaling A Business

Often in business, people discuss and agree on terms of engagement. Today’s conversation is about what to consider with business contracts and putting things in writing. On this show, we have Josh Clayton from the law offices of Josh Clayton, located in Shreveport, Louisiana. He began his career with law firms in Baton Rouge and Hammond, then worked briefly at an oil and gas outfit in Shreveport before going into private practice in 2008. Click here to find more information on our website. Contracts - Key Points When does one need to invest in documenting a legal contract? Why lawyers say that phone calls never happened. Contracts don’t need to sound like a lawyer wrote them. When entering into a relationship for any service, at the very minimum, put your expectations in writing and get a confirmation. Good contracts make good business partners. Lawyers can use past email correspondence to come up with a proper contract. An attorney will ask the tough questions that you might have overlooked in normal business dealings. No need for reservations; contracts are modifiable. Lawyers are encouraged to write contracts in simple English. When someone hands you a contract, don’t be too eager to sign on the dotted line without getting a legal opinion. People sometimes underestimate the value of building a trusted advisor network. A tip on how to find the best lawyer when you have a specific need. Invest the next 20 minutes in finding out more. Links ShreveportAttorney.com If you have not checked out all of our free resources available to you. Click here for our site. Here are some of our featured free resources. How Can I Organize My Financials? Should I Have A Business Plan? What Steps Should I Take Towards Branding? How Can Marketing Bring In More Clients? The Start-Up Checklist What Type Of Corporation Should I Be? Things To Consider When Scaling A Business

Many businesses establish their online presence by having a website, but do you know what the law says about the information you display and collect? How do you determine whether or not you're complying with regulation? Learn how to shift your business risk from yourself to others. Our guest today is Josh Clayton who runs a private practice in Shreveport, Louisiana, and he will discuss some of the things you need to know about collecting information. Josh studied accounting but decided early on that he was cut out for law, so he went back to school for a law degree. He started his career at McKernan Law Firm in Baton Rouge, worked at the Hammond law firm of Anderson & Boutwell, and had a brief stint at an oil and gas outfit in Shreveport. He hung out his shingles in 2008 and has been in private practice ever since. Click here to find more information on our website. Shift Your Business Risk - In this episode Collecting customer information via your website Privacy statements Determining just what should be included on your website How do you avoid assuming liability for the risks inherent in data collection? The role of trusted third-party intermediaries Use of non-disclosure language when collecting certain information Storing information on a safe server with firewall protection An LLC is a safe structure for most businesses Sometimes a CPA has better answers to the question of corporate structure Operating agreements and why you need one LLCs, APLCs, APMCs Use iron-clad agreements and corporate structures to prevent piercing of the corporate veil Licensing and reciprocity agreements for attorneys A tip on optimizing your URL for search engines Let's dive in and learn. Links ShreveportAttorney.com If you have not checked out all of our free resources available to you. Click here for our site. Here are some of our featured free resources. How Can I Organize My Financials? Should I Have A Business Plan? What Steps Should I Take Towards Branding? How Can Marketing Bring In More Clients? The Start-Up Checklist What Type Of Corporation Should I Be? Things To Consider When Scaling A Business

Many businesses establish their online presence by having a website, but do you know what the law says about the information you display and collect? How do you determine whether or not you’re complying with regulation? Learn how to shift your business risk from yourself to others. Our guest today is Josh Clayton who runs a private practice in Shreveport, Louisiana, and he will discuss some of the things you need to know about collecting information. Josh studied accounting but decided early on that he was cut out for law, so he went back to school for a law degree. He started his career at McKernan Law Firm in Baton Rouge, worked at the Hammond law firm of Anderson & Boutwell, and had a brief stint at an oil and gas outfit in Shreveport. He hung out his shingles in 2008 and has been in private practice ever since. Click here to find more information on our website. Shift Your Business Risk - In this episode Collecting customer information via your website Privacy statements Determining just what should be included on your website How do you avoid assuming liability for the risks inherent in data collection? The role of trusted third-party intermediaries Use of non-disclosure language when collecting certain information Storing information on a safe server with firewall protection An LLC is a safe structure for most businesses Sometimes a CPA has better answers to the question of corporate structure Operating agreements and why you need one LLCs, APLCs, APMCs Use iron-clad agreements and corporate structures to prevent piercing of the corporate veil Licensing and reciprocity agreements for attorneys A tip on optimizing your URL for search engines Let’s dive in and learn. Links ShreveportAttorney.com If you have not checked out all of our free resources available to you. Click here for our site. Here are some of our featured free resources. How Can I Organize My Financials? Should I Have A Business Plan? What Steps Should I Take Towards Branding? How Can Marketing Bring In More Clients? The Start-Up Checklist What Type Of Corporation Should I Be? Things To Consider When Scaling A Business

We're joined by Josh Clayton to discuss our differing strategies on testing view behavior, strategies for dealing with brittle feature specs, and what types of tests each of us favor. Verifying partial doubles Decent exposure Defining helpers directly on the view in view specs Don't stub the system under test Clearance Back Door Automatic form filling driven by i18n and Factory Girl with Formulaic Mystery guests Using data attributes to decouple data from presentation Testing pyramid Shoulda Matchers Consistency Fail Josh Clayton on Twitter

Josh Clayton and Ben Orenstein interview each other about their managing director positions. Ben Orenstein's Twitter Josh Clayton's Twitter

Ben Orenstein interviews Josh Clayton and Laila Winner on their book, Geocoding on Rails. Geocoding on Rails Josh Clayton's Twitter Laila Winner's Github

Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot, and Josh Clayton, developer at thoughtbot and the lead maintainer of FactoryGirl. In this Rails focused episode, Ben, Joe, and Josh dish on ActiveRecord callbacks, observers, state machines, and before_filters vs. middleware. They discuss the good, the bad, and the ugly of each, and how to keep your app clean while doing the right thing. Then they touch on what's new in FactoryGirl, how using build_stubbed can speed up your test suite, and much more. Rails Guide: Active Record Validations and Callbacks Rails Guide: Action Controller, Filters Blog post: Ruby and KISS, Sitting in a Tree Method Object Feature Envy Rack: a Ruby Webserver Interface Rails Guide: Rails on Rack Rack::Cache Blog post: Use Factory Girl’s build_stubbed for a Faster Test Suite Blog post: Mind-Bending Factories Metaprogramming in the Wild: Source-Diving FactoryGirl Follow @thoughtbot, @joeferris, and @joshuaclayton on twitter.

Ben Orenstein is joined by Josh Clayton, the maintainer of FactoryGirl, and a developer at thoughtbot. Ben and Josh discuss FactoryGirl: using it, its development progress, and features. What it's like to run an open source project, and how to contribute to open source effectively. Looking at your old code and being a better developer. Approaches to testing. And answer your questions about: FactoryGirl, How to write effective tests suites and whether integration tests are a scam, our process for upgrading between Rails versions, testing complex UI logic, and leaving code untested. FactoryGirl The Pickaxe factory_girl_rails factory_girl Google Group FactoryGirl Tips and Tricks Integration Tests Are a Scam Lone Star Ruby Conference Follow @thoughtbot, @joshuaclayton, and @r00k on twitter.

Wynn sat down with Brian Hogan and Josh Clayton to talk about tmux, dotfiles, and the joys of text mode.

Wynn sat down with Brian Hogan and Josh Clayton to talk about tmux, dotfiles, and the joys of text mode.