Podcast appearances and mentions of chelsea troy

One of the reasons why it is difficult to work with legacy code is the lack of preserving the contextual reasons for past coding choices.  Today we talk with Chelsea Troy, a Machine Learning Team Lead at Mozilla and a computer science lecturer at the University of Chicago. She tells us about the value of code review in the software-building process and why code review should not be treated solely as a mechanism for approval.  When you finish listening to the episode, visit Chelsea's website at https://chelseatroy.com. Mentioned in this episode: Chelsea's website at https://chelseatroy.com 

Jessitron is joined by Chelsea Troy, Staff Data Engineer at Mozilla, and one of the all-around most interesting people in software today, to discuss staff engineering, machine learning operations, and maybe also surfing.

Chelsea placed the start of her journey in undergrad with the insightful tale of an introduction to programming class involving a peanut butter & jelly sandwich. We then discussed how one teacher cut her wings by telling her she "lacked the intellectual firepower" to become a dev. She went on to study to become a spy instead. Just before entering this world, she realized she had missed the feeling she had had during this first programming class and decided to embrace development in a boot camp. We talked about her learning habits and how they helped her get a job at Pivotal Labs; we talked about legacy code and how those learning habits helped her become excellent at gaining context.Here are the links from the showhttps://www.twitter.com/HeyChelseaTroy@heychelseatroy@social.clawhammer.nethttps://chelseatroy.com/Peter Michael Oseara https://osera.cs.grinnell.edu/https://chelseatroy.com/2014/10/03/pairing-with-the-pros-a-day-at-pivotal-labs/https://chelseatroy.thinkific.com/collectionsOn September https://www.thestrangeloop.com/ Felienne (https://github.com/Felienne)'s annotation tool https://annotate.codereading.club/#/https://www.oreilly.com/live-events/legacy-code-boot-camp/0636920086297/https://www.oreilly.com/live-events/technical-debt-first-steps/0636920058624/0636920058623/https://anyonecanlearntocode.com/Music cover: Legends by HoliznaCC0 is licensed CC0 1.0 Universal License.The Imposter Syndrome Network PodcastFun conversations about technology careers that inform and inspire. =) Listen on: Apple Podcasts SpotifySupport the show Become a supporter of the show on Patreon or on Buzzsprout (our hoster). Gift the podcast a rating on the platform of your choice. Your host is Timothée (Tim) Bourguignon; more about him at timbourguignon.fr.

Richard talks to Chelsea Troy, a programmer working at Mozilla who has a side gig teaching Masters' Computer Science students at the University of Chicago. This is highly unusual, considering she does not have a computer science degree! They talk about how she landed that job, including how the interview process differs from industry interviews, among other topics.

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.

Robby has a chat with Chelsea Troy, the Staff Software Engineer on machine learning and backend systems at Mozilla. Chelsea also maintains the Zooniverse Citizens Science mobile app, the NASA landslide data processing pipeline, and a few other open-source projects. She is a maintainer for the rock programming language and mentors formerly incarcerated technologists through Emergent Works. She teaches Python and mobile development at the University of Chicago's Master's program in Computer Science, hosts workshops for O'Reilly, and writes at ChelseaTroy.com  For Chelsea, one of the most important characteristics of well-maintained software is a conscious effort to ensure that enough context remains available for engineers who come in without existing familiarity with the system to gain that context and maintain it. She shares more of her valuable insights on how we can go about making software more maintainable and explains why she's not a proponent of the term “Technical debt”. She also talks about some of the strategies she uses to quantify maintenance work, how engineers can document their code with more helpful error messages that provide more context, and how to discuss the removal of features to reduce long-term maintenance load with a product team. To learn more, including what you should do when you join a new team with existing software, stay tuned. Book Recommendations:Cork Dork by Bianca Bosker - http://www.biancabosker.com/cork-dorkHelpful LinksChelsea on Twitter - https://twitter.com/HeyChelseaTroyChelsea's Website - chelseatroy.com"A Rubric for Evaluating Team Members' Contributions to a Maintainable Code Base" - https://chelseatroy.com/2021/10/29/a-rubric-for-evaluating-team-members-contributions-to-a-maintainable-code-base/"Quantifying Technical Debt" - https://chelseatroy.com/2021/01/14/quantifying-technical-debt/"Reducing Technical Debt" - https://chelseatroy.com/2021/01/21/reducing-technical-debt/Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

02:28 - Kerri's Superpower: Having an Iron Butt * The Iron Butt Association (https://www.ironbutt.org/) 06:39 - On The Road Entertainment * FM Radio * Country Music * Community/Local Radio * Roadside Attractions * The World Largest Ball of Twine (http://www.kansastravel.org/balloftwine.htm) * Mystery Spot (https://en.wikipedia.org/wiki/Mystery_Spot) * Mystery Spot Polka (https://www.youtube.com/watch?v=VYHiGQiAPhI) 15:11 - Souvenir Collection & Photography * Fireweed Ice Cream (https://www.wildscoops.com/post/2018/08/28/botany-of-ice-cream-fireweed-chamerion-angustifolium) * Clubvan (https://www.google.com/search?q=clubvan&tbm=isch&ved=2ahUKEwjCk7zdiJn2AhXIFFkFHfvjC-kQ2-cCegQIABAA&oq=clubvan&gs_lcp=CgNpbWcQAzIHCCMQ7wMQJzIHCCMQ7wMQJzIFCAAQgAQyBQgAEIAEMgYIABAFEB4yBggAEAoQGDIECAAQGDIGCAAQChAYMgYIABAKEBgyBggAEAoQGFCMB1iMB2CUDGgAcAB4AIABS4gBjQGSAQEymAEAoAEBqgELZ3dzLXdpei1pbWfAAQE&sclient=img&ei=rNsXYsKNB8ip5NoP-8evyA4&bih=748&biw=906) * Lighthouses * National Parks 25:42 - Working On The Road 27:37 - Rallies, Competitive Scavenger Hunts * Traveling Salesman Problem (https://en.wikipedia.org/wiki/Travelling_salesman_problem) 30:40 - Tracking, Tooling, Databases * Penny Machine Locations (http://209.221.138.252/AreaList.aspx) * Penny Costs 1.76 Cents to Make in 2020 (https://www.coinnews.net/2021/02/23/penny-costs-1-76-cents-to-make-in-2020-nickel-costs-7-42-cents-us-mint-realizes-549-9m-in-seigniorage/#:~:text=Penny%20Costs%201.76%20Cents%20to%20Make%20in%202020%2C%20Nickel%20Costs,Realizes%20%24549.9M%20in%20Seigniorage&text=The%20cost%20for%20manufacturing%20U.S.,in%20its%202020%20Annual%20Report) 35:36 - Community Interaction; Sampling Local Specialties * Cinnamon Rolls * Salem Sue, World's Largest Holstein (https://www.roadsideamerica.com/story/2716) 38:40 - Recording Adventures * Kerri's Blog: Motozor (http://motozor.com/) * Stationary & Sassy (https://anchor.fm/stationary-and-sassy) (Jamey's Podcast) 41:46 - Focus / Music * Bandcamp (https://bandcamp.com/) * Steely Dan (https://en.wikipedia.org/wiki/Steely_Dan) * Neil Peart (https://en.wikipedia.org/wiki/Neil_Peart) (Rush) 42:22 - Directed Riding vs Wandering/Drifting Reflections: Mandy: Taking time to enjoy yourself is SO important. Jamey: Get started! Create a map, now. Coraline: Permission to go down rabbit holes: wander aimlessly, and explore. Aaron: If I'm not having fun, why am I doing this? Resetting expectations to your purpose. Chelsea: Making “it didn't always look like this!” stories accessible to folks. Kerri: It's a marathon. You can't do a lot of things in a single step. We have traveled far from where we began. Greater Than Code Episode 072: Story Time with Kerri Miller (https://www.greaterthancode.com/story-time) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: CORALINE: Hey, everybody and welcome to Episode 273 of Greater Than Code. You may remember me, my name is Coraline and I'm very, very happy to be with y'all today and to be with my friend, Jamey Hampton. JAMEY: Thanks, Coraline. I'm also excited to introduce my good friend, Aaron Aldrich, and it's our first time co-hosting together so I'm excited about that, too. AARON: Oh, Hey, it's me, Aaron Aldrich. I'm also excited. I'm so excited to host with all these people and I will introduce you to Chelsea. CHELSEA: Him folks. I'm Chelsea Troy and I am pleased to introduce Mandy Moore. MANDY: Hey, everybody. It's Mandy. And today, I am here with one of my favorite people! It's Kerri Miller, and you may know Kerri as an engineer, a glass artist, a public speaker, a motorcyclist, and a lackwit gadabout based in the Pacific Northwest. Generally, she's on an epic adventure on her motorcycle somewhere in North America. Will she meet Sasquatch? That's what I want to know and that's why she's here today because we're not going to talk about tech, or code today. We're going to catch up with Kerri. If you're not following Kerri on these epic adventures, you need to be because I live vicariously through her all the time and you need to, too. Kerri is a prime example of living your best life. So without further ado, Kerri, how are you?! KERRI: Oh my gosh. With an intro like that, how can I be anything but amazing today? Can I just hire you, Mandy just to call me every morning and tell me how exciting I am? MANDY: Absolutely. [laughter] KERRI: No. I'm doing really, really well. The sun actually came out today in the Pacific Northwest. I've been telling people lately that if you want to know what living in Seattle is like, first go stand in the shower for about 4 months [laughs] and then get back to me. So to have the sun bright and it's 53 outside, it's amazing. AARON: 53 does sound amazing. It's been like so far below freezing for so long here that I've lost track. Every once in a while, I go outside and it's like 30 and I'm like, “Oh, this is nice!” [laughter] JAMEY: Are we going to ask Kerri the superpower question? Because I feel like she's come on and answered it a bunch of times already. [laughs] We could ask her about Sasquatch instead. MANDY: I mean, I thought her superpowers were having epicly awesome adventures, but maybe she has a different answer. KERRI: Well, in the context of this conversation, I think that my superpower is being able to sit on a motorcycle for ridiculously long amounts of time. CORALINE: Kerri, would you say you have an iron butt? Is that what you call that? KERRI: Yes. I mean, of course, the joke being that I belong to a group called the Iron Butt Association, which is dedicated to promoting the safe and sane practice of long-distance endurance motorcycle riding. So the only requirement to join, besides having the defective gene that makes you want to sit on a motorcycle for hours and hours on end, is to be able to ride a 1,000 miles on a motorcycle in 24 hours, which once you do it once, you very quickly decide if you ever want to do it again and if you do decide you want to do it again, you are one of the ingroup. AARON: What's a reference point for a 1,000 miles? That's a number that I only know conceptually. KERRI: Let's see. It is a 1,000 miles almost exactly from Seattle to Anaheim to the front door of Disneyland. It's a 1,100 miles from Boston to Jacksonville, Florida. CORALINE: Oh, wow. KERRI: It's 2,000 miles from my house in Seattle to Chicago. JAMEY: What made you feel like you wanted to sit on a motorcycle for that long? KERRI: I don't really have a short answer for that, but I'll give you an honest answer. I mean the short answer is the jokey one to say, “Oh, I've got a defective gene. Ha, ha, ha.” But when I was in – I grew up in the country and had a lot of a lot of struggles as a teenager and the way that I escaped from that was to go get in my car and drive around the back roads of New England. Dirt roads, finding old farmsteads and farm fields and abandoned logging roads and that gave me this real sort of sense of freedom. When I moved out to Pacific Northwest—no real friends, no family out here—I spent a lot of time in my car exploring Pacific Northwest. I had a lot of those same vibes of being by myself and listening to my good music and just driving around late nights. When I got into to motorcycling, I rediscovered that joy of being by myself, exploring things, seeing new things, and if I wasn't seeing something new, I was seeing how had changed this week, or since last month, or since last few years since I've been through a particular region. And my motorcycling is basically an extension of that, it's this sort of urge to travel. A desire to be by myself under my own control, my own power, and to learn and discover new stories that I'm not learning just by sitting in my apartment all day. I work from home. I've worked remotely for 8, or 9 years now, so anytime I get to leave the apartment is a joy and adventure, but doing so for longest ended periods of time just lets me see more of the world, expand my own story, and learn the story of others as I travel. Being a single solo lady on a motorcycle, I'm instantly the object of interest wherever I stop and it doesn't help that I have rainbow stickers and all sorts of stuff all over my bikes. My motorcycle helmets are crazy pink, rainbow reflective, got unicorn horns, and things all over my bike, so people see me as being super approachable. Every time I stop for gas, or to get a burger, or a soda, or something, people come up to me and they want to tell me their stories. It's usually about the motorcycle, they're really interested about. It's usually middle aged and old men come up to me to say, “Oh, I had a motorcycle when I was in college and then I got married and had a kid.” You can kind of see them deflate a little bit. Or I've had lots of kids come up because it's covered with stickers and a lot of the stickers, they're all kind of at a kid eye level. They see them and they get really excited, they want to come over and talk to me. With rainbow bandanas and everything, I think I look safe as a biker. I'm not dressed in black and skulls and so, people see me as approachable and they want to come up and talk. So there's a lot of those great interactions that I get to have with people along the way. CORALINE: And you said at the beginning, when you were driving around the Pacific Northwest, you were listening to your good music. Do you also listen to music on the motorcycle and some of those have fancy speakers in the helmet and all that sort of stuff where you just go quiet and just listen to the road? KERRI: Honestly, over the course of the day, because I will ride 18, 20 hours a day if you just let me go and if I'm trying to make distance, I'll do that. It's kind of a mix, but for the most part, I actually do listen to something. The last few years, I've really embraced and tried to understand and integrate into my personal identity, having ADHD and how does that manifest for me and I found that if I'm riding my motorcycle and I'm not listening to something, my mind wanders. But weirdly, if I'm listening to something, then I'm paying attention and focused, patrolling the motorcycle and being safe and then whatnot, which seems paradoxical. But that's just how my brain works. So I pretty much always have something going. Until recently, I had a Spotify playlist with about 1,800 songs on it that was rotating through. I tried to do audiobooks and podcasts, but that's a little tricky with all the wind noise and whatnot. I'm trying to protect my hearing. Other than that, I also listen to a lot of FM radio, which is great. So I have opinions on country music now, which I never thought I was going to have opinions on that at before. Yes, country music is great. It's all over. Even in Seattle, we have country music, bars, and whatnot, but you don't just walk down the street in Seattle and hear country music. You've got to kind of seek it out and so, I haven't been exposed to it. So listen to a lot of FM country as I cross the vast planes of America and I've also used that to discover a lot of this rebirth that's happened in the last decade of community radio. A lot of small communities have their own low power, super local FM radio you can only pick up for 20 miles at a stretch. So if I'm passing through a town and I see a sign for K, B, C, or whatever it is for some small town, I immediately tune to it. it's always somebody who's just like, they're not a trained professional. They never went to broadcasting school. They don't have that trained radio voice. They're just talking about sheep that got out, or here's a problem with the town water supply, or whatever it is, what local road is closed. That's just an amazing way of even as I'm passing through a place, if I'm not stopping, I kind of get a little bit of a flavor for that. AARON: Well, just thinking that FM radios generally got to give you more of a flavor for the local area that you're at. I always thought of that as the frustration of FM radio when traveling, like, “All my radio stations keep changing. I don't know where to tune!” But at the same time, that's pretty cool. I love that as a positive of what do they listen to over here? What do they listen to over this part of the country? I would imagine even just where different musical genres are on the dial would probably shift around. Or maybe not. Maybe that's just my…coming up with things, but. KERRI: Yeah. You do learn that there are some patterns, like all of the NPR stations, they're all down in the 800s and also, a lot of the religious radio and the top end of the dial seems to be a lot of rock. The big rock stations seem like 107, whatever the end, or something. The best ones, though are the ones that have local commercials because you get a lot of the same like, law firms and drugs that I don't know if I have even the condition, but I should really talk to my doctor, see if it's right for me. But then you'll get local car places, or I got one when I was down south, somewhere in Louisiana and it was for a combination, an airboat rental and barbecue joint? It was amazing. It was absolutely amazing and the guy had this amazing regional accent, which I never hear up here in the Northwest. We have our own accent, but I got a little taste of this real Southern accent and it was the owner. It was clearly the owner just reading a little script that he wrote, “Come on down and rent a jet boat, bring your dog and your dog can go on it and then we'll have barbecue waiting for you when we get off the dock,” and I'm like, “I'm sold.” Like, “I'm going to turn around, go see this guy right now. This is amazing,” and I actually have that business. I keep a map of every interesting place I hear about as I travel and I put a pin there I'm like, “Someday, I'm going to be coming back by this place and I'm going to be hungry for lunch and I'm going to stop. I'm going to stop here.” So advertising works, I guess, is what I'm saying. JAMEY: Will you share that map with us? [laughter] KERRI: I really should. I really should. It's a lot of fun actually because you read these websites, or roadside attractions, or you hear about some abandoned theme park, or something and it's like, that's kind of a cool thing. You read the article and you move on your day, but I add it to my maps and those maps are my GPS unit. As I'm writing, I've got this old screen in front of me and if I see a little pin appearing on the map in front of me, I can say, “Oh, there's this old waterpark over here,” or “Oh, there's that resort over there that I always wanted to see,” or a particular weird statue, or the birthplace of James Kirk, or whatever it is. So I don't have to remember if the computer could do it for me. JAMEY: I was going to ask if you go to things like the world's largest ball of twine and like –? KERRI: Every time. JAMEY: Okay, cool. KERRI: Every time. JAMEY: I'm glad that I understand you enough to know that you would do that. [laughter] CORALINE: Kerri, have you been in the Mystery Spot? KERRI: I have been in Mystery Spot. MANDY: What is Mystery Spot?! CORALINE: I remember Mystery Spot is some kind of a place where they say gravity is out of whack and everything feels sideways and you're super disoriented. They have this whole mythology around it. I've never been myself, but I did pretend that I'd been there by putting a bumper sticker on my car 15 years ago. [laughter] There's this amazing song called Mystery Spot Polka. Can't remember where I read that, but I think that's how I learned about it. MANDY: I will put that in the show notes. CORALINE: I will find Mystery Spot Polka. It is incredible. MANDY: So Kerri, what are some of the coolest places you have visited? Can you give us a top three rundown? CORALINE: And I really hope that cracker barrel is in that top three, Kerri. JAMEY: But which cracker barrel? CORALINE: Oh, cracker barrels are the same everywhere you go. I really believe there's only actually one cracker barrel, the canonical cracker barrel, and it's multidimensional, so. JAMEY: Yeah. You teleport into it? CORALINE: Yeah. [laughter] KERRI: Well, interestingly enough, I won't call this a danger, but one of the side effects of traveling as much I have in the last 4, or 5 years is strange, random flashbacks to stretches of road and you can't remember where they are. So you were just asking about this and I'm thinking about, “Okay, two places I could talk about,” and then I suddenly, unbidden, had this memory of a stretch of road. I can't remember where that is. I don't even know what state that's in. It was an amazing piece of pavement that I really enjoyed riding and, in that moment, I had this amazing moment. If I skip way ahead to the end of the conversation where I sum everything up and tell you why I ride, or what I get out of doing this is that it's cemented for me, this concept of the impermanence of everything because if I'm having a great day on the bike, it's beautiful afternoon, the temperature's perfect. It's not going to last. The sun is going to go down, the pavement is going to be bad, traffic is going to pick up, it's going to start raining. So I need to enjoy this moment, this curve, this hour, this half hour, this 5 minutes, whatever it is. Something, conversely, if it's bad, if it's raining, or it's dark, or heck, if it's snowing, it's like, this is not going to last. I'll go through this and everything will be great. But once every six weeks, or so, I make a really bad decision on the motorcycle, for instance, like that rain's probably going to clear up, that's not going to be a rainstorm. Nah, this wind is going to die down, it'll be fine. I'll be riding through something and it makes me just completely miserable. 110 degrees, or sideways rain, or whatever, and I think, “Yes, this is it. This is the moment. This is the thing that I'm going to be remembered for. This is the dumb thing that I did,” but it never lasts. I always survive and I walk away with this just amazing memory and this amazing about that time I rode through a rainstorm, or illegally parked my motorcycle in front of the Alamo to just get a photo, [laughs] things like that if it happened. CHELSEA: Kerri, do you collect souvenirs of any kind from some of these travels, or is it specifically photos? Do you post about them specifically anywhere? Maybe you do a whole bunch of things. I've certainly seen a number of your posts, but I guess I'm wondering, I'm imagining myself in these situations collecting stickers, or something like that. Do you have things like that that you look for in these places? KERRI: One of the neat things that I enjoy about traveling my motorcycle is that I just simply can't, I can't buy anything. It's not any space for it. My gear is all pretty well packed tightly. Souvenirs are kind of out unless I'm willing to pay extra ship from home. So it's kind of rare. Although, I have occasionally gotten, if I know that I'm going to be visiting a friend in a day, or two, I'll stop and pick something up and usually, it's a food item that I haven't seen before. In fact, if you follow me on Twitter, you'll see I'm always posting about weird foods, or energy drinks. 90% of the time it's weird stuff I found in a weird gas station on the side of the road, especially when it comes to energy drinks. And it's much more about having that experience of a place at the end of the day. I don't take as many photos as I'd like, or I think that I should. Although, certainly, I do take more than I used to. I've been working on landscape photography with my iPhone because again, I choose not to travel with a full camera rig. Well, I've got my iPhone, how can I take photos with that? That turns out to be much more about composition and seeing a moment and grabbing it than having the right lens, or light conditions being just right, or whatever. CHELSEA: Ooh. So I'd be very interested to hear some of your tips for phone photography, because this is a thing. We all have our phones on us and I imagine if I just a little more about how to frame my photos sometimes, I could get something a lot better. KERRI: Some of the basic tips are just photography one-on-one, like how do you compose a shot in terms of the rule of three where you break it up, and you'll see in phones, a lot of times you have the option turn on a grid. So you're looking at a grid and then help you understand how much space something is going to take up in the final shot. You want to line up your horizon, for example, if I'm taking a picture of say, like a harbor. I've taken a lot of photos of lighthouses for reasons I can get into later. So I'm trying to take really nice photos of lighthouses, the sea kind of wants to be right around and take up the lower third of the shot and then two-thirds is the sky. It's about how much of the frame gets filled with different elements will psychologically suggest the viewer, what their importance is, or how they relate to the person who's taken the photograph. So just some basic rules around that. I try to do things where, especially when doing landscape photography, because the iPhone lens is just horrible for this. It's really meant to take photos of your friends at parties, or your car in the driveway. It's not meant to take landscaping vistas, but you can do some tricks. Actually, I found that zooming in a little bit, not a lot, but just a little tiny bit just brings it a little bit closer and the final result just feels a little different. And then if also, you continue to follow those rules of composition, you can get some good landscape. Putting something in the foreground is really great. So my motorcycle is in a lot of my shots because of that, because it gives some depth to the photo. It helps to not just be like, especially if you're doing a wide-open plane like you do, it's like, oh yes, here's some bars of color. It's like, oh, now here's something to give me perspective and humanize the scale of a landscape. It's just little things like that and that's all stuff that I've learn just because I'm just a naturally curious person. So I'm like, “Well, how do I take better photos of that?” So I went off and did 4 hours of research and audited a class online somewhere. CORALINE: Have all, or most of your travels been continental US, or have you ever gone on a motorcycle trip on another continent, or? KERRI: It depends. Is New Zealand a continent? JAMEY: Well, it's not in the continental US. [laughs] KERRI: Yes. Starting closer to home, though. North America, I've done. So I've done US, Mexico, and Canada. Right when COVID hit, I was actually in Baja, California down at the Southern tip at the Tropic of Cancer on my motorcycle. I rode there all the way from Long Beach, California and I've been up to Alaska through Canada twice now. JAMEY: I'm sorry. I was going to tell a Jerri Alaska story actually, because I was in Alaska – [overtalk] KERRI: Oh, please. JAMEY: Not too long ago and I posted a landscape photo from our rental car on Twitter and I did not label where I was and Kerri was like, “Where are you in Alaska?!” And then we were talking about this and she recommended that I eat fireweed ice cream, which I did and it was wonderful. KERRI: Oh, was it great? JAMEY: [laughs] It was great. So I was going to suggest that your superpower could be recommendations. KERRI: Oh, thank you. That's super flattering, actually. I sometimes think when I finally get tired of tech, I just want to be a tour guide, or something, or write a travel novel, or something. JAMEY: Oh yeah. You'd be great at that. KERRI: Yeah. I love being a hostess and I love – whenever somebody's like, “Oh, I'm traveling,” or “I'm going here,” or I see somebody post photos from someplace I've been, I'm like, “Wait, here's this restaurant, you should go here and make sure you talk to this person and do this.” A year after I got my first bike, no, not even a year. Oh my gosh, it was 5 months after I got my first motorcycle, I went to New Zealand for a conference and said, “Well, hassle in traveling to New Zealand is actually traveling to New Zealand. So I might as well take some time.” I took two weeks and rented a motorcycle and just did a couple thousand kilometers all over the South Island in New Zealand. So those are the four countries I've ridden in. I was going to rent one – I'd been to Berlin a few times and I thought, “Oh, I'll rent a BMW when I'm in Germany, that'd be cool and ride around.” But unfortunately, I got sick while I was in Germany, the one time I was going to do that. So I stayed my hotel and felt bad. JAMEY: How different is motorcycle on the other side of the road in New Zealand? [chuckles] KERRI: I only rode on the wrong side of the road twice. [laughter] Yeah, the shop I rented from actually, they rent to a lot of Americans, I guess. So they put arrows on the windscreen to say, “Drive pass” to help remind us. But it's funny because every single rental car down there, the left side of the car is the one that's completely trashed because when you're riding, we start driving on the wrong side of the road. The side you're not used to. Now, it's like your entire concept as a driver of the opposite side of the car is now completely inverted and so, it's like trying to do something with your left hand when you're right-handed. It's just like, how do left-handed people survive?! Like, what are you doing? [laughs] CORALINE: I was in South Africa a number of years ago and we drove out to this wildlife preserve and the only car I was able a rental, that was not a stick shift because I don't know how to drive stick shift, [chuckles] was this giant club van. So not only I had driven the wrong side of the road, but I was in the largest vehicle I had ever driven. [laughs] Had no idea where the other side of the car might be was, just terrified of exactly that the whole time. KERRI: See, you called it a Clubvan, but all I can imagine, the image that popped in my brain was a party bus. [laughter] So imagine you driving around South Africa in a party bus. [laughter] CORALINE: That would have been amazing. Yeah. KERRI: Very different trip. AARON: I just want to bring it back to lighthouse pictures because as a native New Englander, I need to know why you're taking pictures of all these lighthouses. KERRI: Well, as another native New Englander, hi. AARON: Hi. KERRI: How are you? [laughter] No. So why am I taking photos of lighthouses? One of the things about the Iron Butt Association, which again, is this group dedicated to promoting this, is not just the pure endurance of can you ride a 1,000 miles in 24 hours? Can you ride 1,500 miles in 24 hours? What are the limits of safe endurance events? We also do a number of collection style things. We call them tours. I'm doing a lighthouse tour. So you go to lighthouses and I've got this little passport, my lighthouse passport I got from the United States Lighthouse Society. When they're open, you can get a little rubberstamp in your book to prove that you were there. When they're not open, I take a photo of my motorcycle next to the lighthouse and that's the proof that I've been there. The challenge is I have to visit 60 in 12 months. AARON: Okay. KERRI: And that's the bare minimum. So there's advancing levels of difficulty and they're merit badges for adults, really. [laughter] 60 in 12 months I'm at 25, or 30 now and I scoured the West Coast. I'm going to also hit the Gulf Coast and the Atlantic next month when I'm down there in Florida. There are other challenges like go to 120, or 180 again, over the course of different time periods. You have different difficulty levels. I've also done one which is visiting national parks because national parks have a similar passports stamp program where you can go get these timestamped little cancellations to say I was in the Redwood National Forest, or I was at Wounded Knee, or not Wounded Knee, Little Bighorn, or Devils Tower, or whatever. The challenge there is to visit say, 50 of them, but now you have to do 25 different states. Of course, I've upped the ante and we have the silver level, which is you also have to combine that visiting one park in Washington, California, Florida, and Maine, in addition to those 50 and 25 states. So I did two of those last year and then year before that, I added Alaska just for fun, which is the gold, or insanity level. So it's just these little different ways of encouraging people to go out and travel and see more in the country on their motorcycle. CORALINE: You work from the road, right? KERRI: Yeah, I do actually. CORALINE: I would love hear about how that works with such an aggressive travel schedule. KERRI: That takes a lot of discipline and balance, which I am surprised I managed to pull off [chuckles] given how much I can normally do it without adding to traveling. Usually, what I do is I have days where I am in one place and days when I'm traveling. So for example, on February 28th, I'm going to be heading out for 2 months on the road and my first stops going to be San Diego. I will take that weekend and ride down to San Diego, which again, only 1,300 miles so that's a day and I've rented a little place down in Ocean Beach, a block from the shore and they have Wi-Fi in this little tiny one-bedroom studio. I'll work there and I'll kind of explore San Diego. I'll work all day and, in the evenings, I'll go over ride on the hills, or go up to Legoland, or whatever I want to do in that part of the world. And then Friday night, Saturday, I'll hit the road again for a couple days. This is actually how I initially started traveling these long, long distances was trying to say like, “Okay, I really want to go to Austin, Texas, but it's going to take me four riding days, or whatever to get to Austin, Texas. How do I manage do that and still work from the road?” So well, 2 days away is Denver, Colorado. So why don't I go to Denver? I'll work there for a few days and then next weekend, then I'll skip on. So it's like setting up a series of base camps as if I was attacking Everest so I can break up these big trips. But as I wanted to travel further and further distances overall, I had to actually physically travel, or do longer distances in the same amount of time. Speeding isn't going to do that safely and it actually really doesn't get you there that much faster in the end. So the only way to do that was to figure out how to ride longer more hours in the day, figure that out. JAMEY: Can you talk about these motorcycle scavenger hunt things that you do? KERRI: Yeah. Thanks for asking. I assume you noticed the trophies on the wall behind me. So these are competitive scavenger hunt style rallies. We call them rallies. A lot of people, when you say motorcycle rally, they think about Bike Week in Daytona, or Sturgis out in South Dakota. That's none of this. It is a scavenger hunt and there's a timer on it say, 36, or 60 hours where the night before you get a list of here's all the different places that you could possibly go, you call them bonus locations and at 4:00 in the morning, everyone's released and you're like, “Okay, go, be back in a day and a half.” You go and you take photos of these different places to prove that you went there and every place gets you a certain number of points. The harder it is to get there, or the further away it is, the more points that you would get for going there. You can do combinations for visiting certain places, visit three clown theme places and get the clown bonus, or whatnot. Like a pinball machine, if you will, where you score the right combination, you get more points. So it's a timed competitive thing to who can the most amount of points because you can't visit all of the – they'll give you 80, or a 100 places you could possibly go. You can't go to all of them in the time allotted. So can you construct an efficient route that is also one that you have that you the physical capability to travel in the allotted time and earn enough points to place well? They typically last, 36 hours is one level. We have a few that do 60. I'm doing one this summer that is 9 days long. So we'll be leaving Cheyenne, Wyoming and four days later, we have to be in State College, Pennsylvania where we'll all stop for 10 hours and then we'll turn around and head back to Cheyenne. I actually just put in my application for the Olympics of the Iron Butt Association is called the Iron Butt Rally, which is an 11-day version of the countrywide scavenger hunt – [overtalk] CORALINE: Oh, wow. KERRI: With locations all over North America and Canada. We call it, it's sort of the Olympics. It happens every 2 years. You actually have to apply to be accepted to enter because otherwise, you'd have a lot of folks that say, “Oh, I could do that,” and they don't really know what they're getting into and it's a little bit unsafe if you haven't done it before and you don't really understand what it takes to do. That's what's coming up my horizon for those and they're very competitive events, although at the end of the day, it's made-up internet points. There are no sponsorships, there's no recognition besides outside of this group of 300, or 400 similarly weirdo people who like riding their motorcycles longways. But no, I've had quite a bit of success competitively in that and that just scratch all the right itches because it's riding a motorcycle. Plus, it's basically a traveling salesman problem. It's a directed graph problem and you work with GitHub all day long and like, “Oh, I understand how to traverse a graph, this is easy.” CORALINE: Speaking of that, Kerri as a long-time software engineer, do you do anything, do you have any software, any kind of tools that you develop for keeping track of all this? KERRI: Yeah, I do a lot with spreadsheets, believe it, or not. The tooling, it's tricky because at the end of the day, you still have to ride the motorcycle and you can't really automate that. So a lot of the stuff I'm able to do with software is really around using software for planning and analysis. For example, there's a number of different databases around you asked about the collection of the lighthouses and one of the things that I'm around the country collecting this year is pressed pennies. Now a pressed penny machine, actually I think they're fascinating because a pressed penny machine is the only machine still in active production that interacts with the penny in any way, shape, or form. There's no vending machines. There's nothing who deals with the penny besides coin counting machine. Besides the penny smasher, you put a penny, 2 quarters and it smashes a little design in. Again, I've got to go collect a 100 of these from 20 states and 5 of them have to be on the other side of the Mississippi, all these weird rules, but how do you find them? There's one at every cracker barrel. There's eight at Disney, one at SeaWorld. There's some obvious things like that, but it turns out, there's almost 4,000 of these machines in the United States and there's a database for these on this weird creaky, old website written in ASP. It's actually an IP address. It doesn't have a domain name. JAMEY: That's legit. CORALINE: Dark web got pennies. That's amazing. [laughter] KERRI: If only there was crypto involved here, it'd be perfect. So I got to break out some scripting the other day and actually write a little script that went into kind of scrape these old web pages and then parse CHTML and kind of strip out, look, here's the address for the place and store them because you want the name of the place and the address so you can find it. You've got to take that and ship it over to Google API, actually get an actual latitude, longitude, and then reform it into the XML format that my GPS device – it's this whole chain of Rube Goldberg machine of how to get this data into a place that I can actually use it. CORALINE: I think the story of the entire internet is made. [laughs] KERRI: Right. CORALINE: Yeah. KERRI: So fast forward to the end of that and now I happen to be the maintainer for a website that maps pressed penny machines across the United States, based on this data that I'm scraping from somebody else's website. AARON: All because you have a DNS name. KERRI: Exactly, exactly. But this actually turned to be really, really crucial because a whole bunch of people in my riding community said, “I really wanted to do that penny collecting hunt and you have 12 months to do it and I'm going to go out to the West Coast.” So I was like, I thought, “I have plenty of places to stop, but I could never find the machines.” It's just like, “Oh, okay. So my putting this information into a format that other people could actually easily digest, that's the value that I'm adding here.” It's inspired at least a dozen people to go out and start collecting smashed pennies. So I've got to be responsible for some uptick in sales on these vending machines. JAMEY: They should sponsor you. AARON: I love the weirdness of these machines that interact with a coin that's so bad at being currency, we just sort of toss them out to the extent that I was at Disney World not too long ago and the machines have their own supply of pennies because people just don't have pennies. So [chuckles] this machine just has a stock of pennies and you can swipe a credit card and be like, “Give me the smashed pennies,” and it charges you a dollar in 1 cent and then goes through and does it. KERRI: God, it's fabulous. A lot of people have heard the story that pennies are actually – it costs more to make a penny than a penny is actually worth in terms of currency. It's wild. But every time I start thinking, “We should get rid of the penny,” I'm like, “That sounds like the craziest, insane conspiracy theory position to ever take.” AARON: But also, the penny is real bad at being currency. [laughs] KERRI: Yeah. Yeah. MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord's 30-day money back guarantee. KERRI: Way back at the beginning of this conversation, somebody asked me and sorry, I forgot who asked me about some of the best places I've been and the strangest things I've seen. I kind of got derailed on some poet nonsense, but I realize that I really am a sucker for world's largest ball twine kinds of things. I had this great opportunity. So collecting pennies, lighthouses, and national parks, I'm always just getting off the main roads and things. I see a lot of stuff. I found out that I'm a sucker basically for weird local foods like the fireweed ice cream. Anytime I see something advertised on a menu that I've never heard of before, that's the thing I'm going to order. Cinnamon rolls because when you travel up the Alaskan highway from Dawson Creek, BC up to Alaska, every 60 miles, or so, there's a gas station and a little bakery. So you can get your gas, you can get coffee, and you can get a cinnamon roll and they all claim to have the best cinnamon roll on the Alaskan highway. I stop every 60 miles and get a cinnamon rolls. After about 5 hours, I really just want to fall over and vomit because I'm sick of cinnamon rolls. But now when I travel, if I see some place advertising cinnamon rolls, I'm like, “Well, I've got to stop because that's my thing because I like cinnamon rolls because that's reminds me of Alaska.” So I get to go to a lot of these really great small towns and just seeing a lot of how, especially in the central part of the country, so many towns are struggling with just having jobs for people and keeping local economies going that a lot of them will do these sorts of things. They'll have interesting, strange festivals, or hold the film festival about corn, or soy, or they'll paint their water tower, or something. Last year, as I was traveling across North Dakota one time, I saw off on the horizon on a hill—first of all, yes, a hill in North Dakota so that was notable—a giant cow. A giant Holstein cow. This a 100-foot-tall fiberglass cow and so, I said to my riding partner, I'm like, “We're going the cow, right?” And she's like, “Yeah, we're going the cow.” So get off the highway and we rode this little windy dirt road at the top of this hill. It was just this huge giant fiberglass cow that they put on top of the hill 20, 30 years ago and now it's like the 4-H Club with the FFA kids take care of it and repaint it every few years. They collect like, they ask for donations. $5 each and the little two because we're passing through and that's part of our job. That's how I'm interacting with the community and plus man, I got a ton of pictures of this giant cow. It was right at sunset, we were on this hill, and it was actually really beautiful, the prairie, it was spread out for us and it was about an hour east of Theodore Roosevelt National Park. So it's right where the planes start to break up into the what's called Missouri Breaks where the rivers have really broken up the land quite a bit. So it was just gorgeous. It was just absolutely beautiful and I never would've seen that if I didn't stop because there was a giant cow. That's my giant cow story. CORALINE: Kerri, have you ever considered writing down your stories and the stories of the people that you meet along the way and the amazing places you've been? I hate to say the B word, but it would make a pretty interesting book. KERRI: Well, I'll throw back another B word at you, which is blog. I keep a travel blog at motozor.com. Lately, I've been writing more about, because I haven't been doing as much non-directed travel, so a lot of my travel lately has been around these sort of competitive rallies that I've been riding in, which are interesting in themselves because they're like, “Go take your photo with the giant cow,” or “Go to the Clown Motel in Tonopah, Nevada, or whatnot, take a photo there.” I've been writing quite a bit about those sorts of travels, but I also have a huge backlog of articles that I've written for that over the years of all the different trips I've taken to New Zealand, Alaska down into Baja, and the multiple times I've been across the country. The one that I'm working on, that I haven't finished yet because I'm trying a new thing, which is incorporating a series of interview video interviews with my riding partner, is trying to tell the story in written form of the trip that she and I did last summer, where we rode to all 48 states in 10 days starting in New England ending in Washington. JAMEY: Kerri, I have an important question to ask you, but I'm contractually obligated to ask you. How many miles at a time would you say that you live your life? [laughs] KERRI: Well, I guess, I supposed to say one quarter of a mile at a time. [chuckles] JAMEY: Well, Kerri was also a guest on my Greater Than Code spinoff, fast and furious show, Stationary & Sassy, so. KERRI: Which I love. JAMEY: I had to pull it back. [laughs] KERRI: I'll answer that in an obliviously serious way. [laughter] I can go an entire take of gas without putting my foot down. That's kind of fun. One of my current challenges right now is can I ride through the entire state of Oregon, north to south, without getting gas? Because it's 304 miles from the Washington-Oregon border to the California-Oregon border and Oregon doesn't let you pump your own gas and it irritates me. They usually, if they see you're on a motorcycle, they're like, “You got it?” I'm like, “Yeah, I got it. I'm not from here. I pump gas.” So the challenge right now is can I cross Oregon without having to stop for gas and then actually weirdly, mentally breaks up my day. It's kind of weird motorcycle Pomodoro of like, “Okay, I can go 3 hours before I need to stop.” So my day gets broken up into these chunks of where are the stops that I have to make versus the ones I want to make, or excuse me, the ones I want to make versus the ones I have to make. JAMEY: You heard it here, folks. Kerri lives her life 304 miles at a time. [laughter] KERRI: I live my life a quarter tank at a time. [laughter] CHELSEA: Kerri, you mentioned earlier that you listen to music while you're riding because you find that it helps you focus on riding. I find a similar thing with work, whether it's fulltime job work, or side work, I have a much easier time focusing—for the audience, I'm a programmer as well—if I've got something on. I like to listen to Boston Nova, or I also go on turntable.fm, I'm in a heavy metal room there that's kind of fun. I'm curious as to whether you find that music helps you focus anywhere off the motorcycle as well. KERRI: Yes. I am very susceptible to the emotional resonance of music, if that makes any sense whatsoever. There are kinds of music that I just can't listen to before I go to bed, like heavy metal gets me going, jam music. I'm a really huge Phish fan, which surprise, from Vermont, and I wear a lot of tie dye. Of course, I'm in the Phish. But that's the music I like to listen to when I'm riding and when I'm working. But I do a lot of chill hop stuff now. I've gotten into that and I'm finding my way back to a lot of again, country music. But there's this entire alt Nashville scene that's happened in the last 10 years. I completely missed that. I'm kind of getting caught up on these days. My Bandcamp catalog, I think I'm keeping at least three of their engineers paid for; I buy so much stuff on Bandcamp these days. CORALINE: I definitely get what you said about sensitivity to the emotional music definitely resonates with me as a musician. It's kind of weird to admit, but when I'm doing writing, I listen to Steely Dan [laughs] and I actually learned from a friend of mine that William Gibson listened to Steely Dan while he was writing all the seminal cyberpunk novels and thought that's kind of interesting, maybe good company, right? KERRI: Hey, Fagen and Becker, great albums. It's the stereotypical thing that Rush is this big band in programming circles and fun fact, the drummer for Rush was a huge motorcycle guy to the point that they actually had a trailer on their tour bus that he would carry two bikes on the trailer. So he would ride between concert stops. The band do their show and they'd leave on the bus and he got on his motorcycle and like, “See you in Chicago, guys,” “See you in Milwaukee,” “See you in Madison.” The band went along. He had some personal and his wife passed away and his daughter fairly tragically and he wrote an entire book about it, where he didn't really quit the band. Although, they basically shut Rush down for a period of time so the band could work through that. But he took that time and went on the road just writing his motorcycle around. He wrote several books about dealing with grief through riding his motorcycle. I found that to be a really fascinating book and it's one of those touchstones, the Canada motorcycle riders. What little we read, that's definitely a book that everyone recommends to me at some point like, “Oh, have you read this book?” I'm like, “Yes, I've read that book.” AARON: It's Neil Peart for anyone who needs to look that up. I relate to the music as a distraction preventative [laughs] as someone who also deals with ADHD. It just makes sense to me. It's like, “Oh yeah, without it, there's so many places for my brain to go,” but if you have music on the back and it's like, “Oh, great. All right. That's where my brain is going to go when it gets distracted, it's just going to listen to this, then I'll go back to riding the bike.” [chuckles] KERRI: Exactly. Exactly. CORALINE: Kerri, you said a word earlier when you were contrasting the way you were riding when you started out and being kind of exploratory versus, I think the word you used is directive there, or a sweet spot for you between directed activity, directed riding versus wandering, maybe even drifting—not a car movie reference. But is there a balance that rejuvenates you, or that energizes you? KERRI: Yes. I've talked to other motorcycle riders about this, where you say, “My gosh, there's so many great things that we see along the way,” and we say, “I would love to stop here.” So for example, when we're doing these rallies where we're collecting things, for example, you stop to take a picture, or something, and then you've got to go. You only really stop for 5 minutes because you have this timetable and a schedule that you're trying to execute, or if you're trying to ride 1,500 miles in 24 hours, you can't stop. Your gas stops, you're timed down to like oh, 5 minutes. So you'll see things. You're like, “Man, I wish I could stop,” or “I wish I had come back here and take this in and give something,” the respect that you want to give it, or really, really dive deep and taste a place, if you will. It's a really common thing in the long-distance thing. Other motorcycles will sometimes say like, “Well, you don't see anything that way.” It's like, “Well, actually, I see a lot. I see way lot more in my days than you see,” but you don't get to stop so you have to kind of try and balance that. That's one thing that I really like about these collection things that I do is, collection challenges, I carry satellite tracker, of course so I can plot out everywhere that I've been. I've been looking at the one for my lighthouse trip so far up and down the West Coast. It's just amazing, I'm going out to every little inlet, point, and little peninsula sticks out into the ocean because that's where the lighthouses are and the things that I've gotten to see through doing that. So one of the reasons that I've gotten into those sort of challenges rather than the pure and endurance is just because it does reward that exploration. While, at the same time, being fairly directed because the directed part of it is researching and planning at home, like finding where are the lighthouses, where are the national parks I need to go visit? What are the hours are things open? Making that plan versus executing on the plan and the execution plan, getting to explore things, I think it's really a lot about the framing of the trip for me. In February, I'm going down to San Diego and then I'm going to, what's called a 50cc, which is coast to coast in 50 hours. So I'll be leading San Diego and within 50 hours, I'm going to be in Jacksonville Beach, Florida. Aha. Somehow, I'll do that. I'm not going to be able to stop and see anything along the way, but because I know that's the kind ride I'm embarking on, it becomes okay. It's this weird personal permission structure to give a pass to things that I would really like to see along the way versus say, if I'm doing a lighthouse trip – I did one several months ago down to Disneyland, but I went down the California coast and I found myself like, “Oh, I'm not making any miles. This is so slow. Why is this taking me 3 days to get down to Los Angeles when it normally takes me 1 and a half at most?” So I had to stop and I ended up stopping in this little tiny town. I can't even remember the name of the place, but it's somewhere in Northern coast, California, and there's a little tiny coffee shop there. It's like Two Girls Coffee, or something like that. I just stopped, I got a coffee, and I sat outside. They had a table, it was a nice day, and I was just like, “I'm just going to sit here for 30 minutes and I'm just going to recenter myself and really think about what am I doing here? What do I want to be accomplishing and what set of skills do I need to bring to this moment to maximize how much fun I'm going to have? If I'm not having fun, then why am I doing it?” So just being able to sit there in sunshine for a little bit and just say, “The point of what I'm doing here is to explore and it's to have this experience. It's not get someplace fast. It's not to get someplace far away. It's to explore and see things.” I was so much happier after that and I had a great conversation with a hippie in the parking lot so that was pretty great. MANDY: Bonus. [laughs] Well, we usually end this conversation with reflections. I know, for me, I just want to say that everything you described just makes me feel so happy. I've been on a really big journey to improve my life and just what you said in the last few minutes about just taking time to enjoy, not being in a hurry, slowing down, and recentering yourself. That is all just so important to remember the whole cliché of stopping and smelling the roses. Like just enjoying your life even if it's a quarter tank at a time. JAMEY: I keep thinking about this map that Kerri says that she has, which I actually legitimately would really like to see. But a lot of what Kerri was talking about was resonating with me. I also like to explore and I think about keeping track of places, but I don't have a map and I've been thinking about it for a while. I think it's one of these sunk cost things where I'm like, “Well, if I wanted to do a map, I should have been like doing it already,” but that's not how that works in real life. So if I want to have a map, I should start it now and I think that's my call-to-action. [chuckles] KERRI: When people ask my advice like, “Oh, what motorcycle should I get,” or “What's the best motorcycle to do this, or that?” I always say like, “Oh, well the best motorcycle to do the ride you want to do is the one you have.” I think that's really true of so many things in life is that the trick is just to get started and it's not about the fancy equipment. It's not about the gear. You could just do it. If you just give yourself permission to go do a thing, you can just go do it. CORALINE: I was thinking about how that kind of philosophy relates to how my life circumstances, job situation has changed so much for the past year since I retired from software engineering and the relief of not having to be productive, not having to hit goal, not having to have constraints that I'm not in control of, governing things, and permission to go down rabbit holes. So when you were talking about the giant cow, I was liking that to well, if you were in a hurry to get somewhere, you wouldn't have stopped there. But because you weren't, you had a richer experience. You saw something you hadn't seen before. You hadn't experienced before. I really think that's a lesson we can take all over the place and give ourselves permission, like you said, to wander aimlessly and to explore. That's something that I definitely intend to do in my life and your story of doing that is very inspirational so thank you, Kerri. AARON: I was just latching onto two bits that I really liked. First off, if I'm not having fun, then why am I doing this is probably life lessons to live by. [chuckles] But I also appreciated the moment of resetting your expectations to your purpose. Like, why am I doing this thing? Let me remember, because I had a reason I'm doing it and if I'm not enjoying it right now, where's the mismatch? I like that. Because so often, it's easy, for me anyway, to stumble into doing something and finding yourself like, “Why am I doing this?” and then stepping back and be like, “Okay. All right. I chose to do this because of this and if this is my purpose, then I can let go of this other pressure that I'm putting on myself to go further every day when that's not the reason I'm here.” It doesn't make sense to put that pressure on myself then. KERRI: I feel like that chain, that returning to the beginning point is also a good career skill. You have to get serious about it, or bring this into work realm. But as a senior engineer, staff engineer, and principal, blah, blah, blah, so often, it's not how efficient can I make this loop. It's also going back, is this doing the right thing to do? Like, “Why are we doing this? Is there a better way to solve this sort of problem?” So it's that lesson of what I learned on the road coming back into work, but it's also because work is life as well and if work isn't fun and whatever, then why am I doing it? But that skill comes back into my personal life so there's this free flow of influence going back and forth. AARON: Yeah. That purpose revisit thing is something that I've just been thinking about from events standpoint from doing conferences over the past couple years, like so much had to go back to first principles because it was like, okay, well what was the reason for us doing this? Just recreating the same motion in a different environment isn't necessarily going to get us the same results. What is the reason we're doing this? Let's revisit that and make sure we're still in alignment with it all. I think we can do that more often in our lives, too. Like, “What is the reason I'm doing this thing?” [chuckles] “Okay, it's not accomplishing that anymore. Let's get rid of this practice and try something else,” or not. Maybe the answer is to keep it. CHELSEA: Yeah. One of the things that I think about apropos of what a couple of other folks were mentioning about how easy it is to get caught up in the details when trying to start something as opposed to just picking early anything and getting started. Occasionally, folks will ask me questions like that about blogging and one of the things that I like to do is keep some URLs on hand of some of my earlier pieces, just because it makes it really clear that it didn't always look like this. I just started and it wasn't what people see. I think folks sometimes see someone who's several years down the road of having started something and feeling like they can't start because it won't look like that immediately and it won't. [laughs] But I imagine that having those kinds of stories on hand, what I'm thinking about is how to make those sorts of stories more accessible to folks. Because a lot of what we see understandably about how to do something is from the folks who have mastered it to some degree and it's not as clear where to look to find folks who also are just starting and what to expect your journey to look like right at the beginning. MANDY: Kerri, do you want to leave a us with any parting thoughts? KERRI: A lot of people, when I tell them I rode a 1,000 miles in a day, they're like, “You can't do that.” It's like, “I've done it 12 times.” It's like, “What are you talking about?” But to kind of carry on to Aaron and to what Chelsea just said, it's a marathon. You can't do a lot of big things in a single step. You have to make that first step and then the second step and then the third step and then you're walking and you're doing the thing. I don't really talk about motorcycling with people who don't motorcycle and everybody who I motorcycle would talk about this. We all do it and so, it's not remarkable. Sometimes I think it's important to realize that what we do accomplish in our lives is fairly remarkable and magic to a lot of people. As software engineers, what we do is frankly, astounding some days and it's important to remember that we have traveled far from where we began when we first started doing this sort of stuff and we may return to that when we change careers, or jobs, or languages, or technologies. Return to that place of not knowing and that can be uncomfortable, but there is so much joy and discovery you can have if you just take that time, and stop and understand and pay attention to your story of where you started, where you're going, and how far along you've actually come. You can't look up the mountain and be intimidated by that. You should turn around and look back down the mountain to see how far you've come. MANDY: That was lovely. Thank you so much and thank you so much for coming back on the show and telling us yet another few stories. The first time you were on the show, I distinctly remember the title being Story Time with Kerri Miller and you never disappoint. I'm so glad that you took time to join us and talk about your motorcycling adventures with us [chuckles] non-motorcycling people. It is super fascinating and it's definitely an awesome topic outside of – that we can relate a lot of the concepts to the tech field, software engineering, development, and all that. So dear listener, if you have a cool hobby like Kerri that you want to come on the show and talk about, we'd love to talk to you because this has frankly been amazing and I really enjoyed this episode. So thank you again and we'll see you all next week. Special Guest: Kerri Miller.

How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) Why has trust become so rare in the software industry? Developers don't trust their own ability to program, teammates don't trust each other to write quality code, and organizations don't trust that people are working hard enough to deliver on time. This talk by Justin Searls is a reflection on the far-reaching consequences distrust can have for individuals, teams, and organizations and an exploration of what we stand to gain by adopting a more trustful orientation towards ourselves and each other. 01:57 - Justin's Superpower: Having Bad Luck and Exposing Software Problems 04:05 - Breaking Down Software & Teams * Shared Values * Picking Up on Smells to Ask Pointed Questions * Beginner's Mindset * RailsBridge (https://www.bridgetroll.org/) 12:49 - Trust Building * Incremental Improvement * What Got You Here Won't Get You There: How successful people become even more successful by Marshall Goldsmith (https://www.amazon.com/What-Got-Here-Wont-There/dp/1846681375/ref=asc_df_1846681375/?tag=hyprod-20&linkCode=df0&hvadid=312118059795&hvpos=&hvnetw=g&hvrand=6049806314701265278&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9006718&hvtargid=pla-525029467829&psc=1) * Credibility * Reliability * Intimacy * Selfless Motivation * Authenticity * Detecting Authenticity * Laziness Does Not Exist (https://humanparts.medium.com/laziness-does-not-exist-3af27e312d01) 29:14 - Power Politics & Privilege * Leadership Empathy * Safety * Exposure; “Don't Cross The Net” * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 42:06 - Personal Growth & “Bring Your Whole/True Self” * RubyConf 2019 - Keynote: Lucky You by Sandi Metz (https://www.youtube.com/watch?v=c5WWTvHB_sA) How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers based in the United States and Canada. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JACOB: Hello and welcome to Episode 270 of the Greater Than Code podcast. My name is Jacob Stoebel and I'm joined with my co-panelist, Mae Beale. MAE: And I'm joined with another panelist, Chelsea Troy. CHELSEA: Hi, I'm Chelsea and I'm here with our guest, Justin Searls. He's a co-founder and CTO at Test Double, a consulting agency on a mission to improve how the work writes software. His life's work is figuring out why so many apps are buggy and hard to use, why teams struggle to foster collaboration and trust, and why it's so hard for organizations to get traction building great software. The Test Double Agents work with clients to improve in all of these ways and more. Hi, Justin! How are you today? JUSTIN: Hello. I'm great. Thank you so much for having me. CHELSEA: Of course. So we like to kick off our sessions by asking you, what is your superpower and how did you acquire it? JUSTIN: Well, one superpower might be that I like to give counterintuitive answers to questions and [laughs] my answer to this would be that I have really, really bad luck software and hardware. My entire life has just fallen over for me left and right. Bugs come and seek me out. In college, I was in the computer science program and so, I was around a lot of computers, like Linux data centers and stuff, and I think I went through either personally, or in the labs that I used 20 hard drive failure years in 4 years. People started joking that I had an EMP around me. So I started to just decide to lean into that not so much as an identity necessarily, but as a specialty of root cause analysis of like, why do things fail? When I see a bug, what does that mean? And to dig in to how to improve quality in software and that then extended to later in my career, when I was working on delivery teams, like building software for companies and institutions. That meant identifying more root causes about what's leading to project failure, or for teams to break down. Now I'm kind of moving, I guess, popping the stack another layer further. I'm starting to ask what are the second and third order consequences of software failing for people having for others? I see this in my family who are non-software industry family members, when they encounter a bug and I'm watching them encounter a bug, their reaction is usually to think that they're the ones who screwed up, that they're stupid, that they just can't figure it out. I'm literally watching software that somebody else wrote far away just fail and that's just no good, right? So I think that the fact that I just so easily expose problems with software and sometimes the teams that make it almost effortlessly, it's really given me a passion and a purpose to improve and find opportunities to just make it a little bit better. MAE: When you talk about software and/or teams breaking down and you're mentioning bugs. So I'm assuming that that's mostly what you mean by breaking down? I'm curious if you have kind of a mental model of software always breaks down these four ways. Teams always break down these three ways. I don't know if you have any reference texts, or things that you've come across as far as like a mental model for what is the world of breaking down? How do we characterize it? JUSTIN: That's a great question and I feel like having been basically doing this for 15 years now, I should be prepared with a better answer. I've always resisted building I guess, the communicative version of an abstraction, or a framework for categorizing, simplifying, and compartmentalizing the sort of stuff that I experience. In some ways, my approach [laughs] is the human version of machine learning where I have been so fortunate, because I've been a consultant my entire career, to be exposed to so many companies and so many teams that that has developed in me a pattern recognition system that even I don't necessarily understand—it's kind of a black box to me—where I will pick up on little smells and seemingly incidental cues and it'll prompt me to develop a concern, or ask a pointed question about something seemingly unrelated, but that I've come to see as being associated with that kind of failure. I think your question's great. I should probably spend some time coming up with quadrants, or a system that distills down some of this. But really, when I talk about bugs, that is a lagging indicator of so many things upstream that are not necessarily code related. One of the reasons I want to be on the show here and talk to you all the day is because I've been thinking a lot about trust and interpersonal relationships starting with us as individuals and whether we trust the work that we're doing ourselves, or trust ourselves to really dive in and truly understand the stuff that we're building versus feel like we need to go and follow some other pattern, or instructions that are handed to us. To kind of try to answer your question more directly, when I see teams fail, it usually comes down to a lack of authentic, empathetic, and logical targeted relationships where you have strong alignment about like, why are we in this room? Why are we working together? How do we best normalize on an approach so that when any person in any role is operating that is consistent with if somebody else on the team had been taking the same action that they would operate in the same way so that we're all marching in the same direction? That requires shared values and that requires so many foundational things that are so often lacking in teams as software is developed today, where companies grow really fast. The pay right now is really, really high, which is great, but it results in, I think a little bit of a gold rush mentality to just always be shipping, always be hustling, always be pushing. As there's less time for the kind of slack that we need to think about—baking in quality, or coming back to something that we built a couple weeks ago and that maybe we've got second considerations about. Because there's that kind of time, there's even less time sometimes for the care and feeding that goes into just healthy relationships that build trust between people who are going to be spending a third of their life working together. CHELSEA: You mentioned picking up on little smells that then lead you to ask pointed questions. I think that's really interesting because that kind of intuition, I've found is really essential to being a consultant and figuring out how to ask those questions as well. Can you provide some examples of situations like that? JUSTIN: Yeah. I'll try to think of a few. I had a client once that was undergoing—this is 10 years ago now—what we called at the time, an agile transformation. They were going from a Waterfall process of procuring 2 year, $2 million contracts and teams to build big design upfront systems that are just thrown over a fence, then a team would go and work on it, and then it would go through a proper user acceptance testing onto something more agile, I guess. Adopting Scrum and extreme programming, interpersonal process, and engineering practices. That was just meant to be more, I guess, iterative of course, innovative, collaborative, more dynamic, and able to let the team drive its own destiny. All that sounds great and you walk into the team room and they just invested millions of dollars into this beautiful newly restored historic building. I sit down with everyone and I look at them and they've got the cool desks at the time and cool open office because those were still considered cool. I sat down and I couldn't help, but—[chuckles] this is real silly. I couldn't help but notice that there was a pretty strong smell, [laughs] body odor throughout the whole room and it wasn't one person. I'm not picking on somebody here. It was that the interpersonal relationships were so afraid, the fear of failure was so strong, and the deadline pressure that had been exerted from on high was so overwhelming that there was no safety in the room. People were just scared at their job all day long and it was having a material impact that only an outsider who's walking in at 2:00 PM on a Friday detect because everyone else had acclimated. So I walked in and I was like, “Well, what do I –?” [laughs] Obviously, I'm not going to be like, “Hey, it stinks in here.” I've got to figure out a way to understand why do people feel unsafe and maybe I didn't have that sentence go through the voice in my head, but it definitely put me on a path towards to maybe the less privileged people in the room, the people who are not the managers to understand what's really going on, what pressures are they under? MAE: I love that the example includes legit real smell. So many times, especially in our industry and part of what this podcast is counteracting, is getting in touch with the fact that we are people and humans. Anyway, I love that you brought [chuckles] that home that way. Also, I wanted to say from earlier, I wasn't trying to corner you into expecting to have a philosophy. I thought you might and it was worth asking. But I recently got asked a similar question about my management philosophy and which authors do I appreciate most, or something. I've been a manager for 25 years and I'm like, “Uh. I don't know. I figure out what is needed and then I deal with that.” I don't understand how to answer. So I just want to give some – pay you back and apologize. I didn't mean to get you – [overtalk] JUSTIN: Not at all and it becomes one of those you know it when you see it. I struggle with this a lot because somebody introduced the concept years ago of beginner's mindset to me where sometimes if I'm a beginner at something, the best person to help me is not the expert—the person who's been doing it for 20 years. It's somebody who's just a few hours, or a few days, or a year, or two ahead of me because they can still remember what it felt like to be where I am right now. Because I talk a lot, because I tweet a lot, because I show up in a lot of places, and I have an outward facing sales role to potential clients and candidates, I meet a lot of people who come to me and they're like, “How do I learn how to code?” And I'm like, “I can tell you the 15-year version of this story, but it's probably going to be really depressing.” I've taken as a responsibility to like try to—and I need to do a much better job of this—be armed with either resources, or people that I trust, that I can refer folks to so that I'm not totally leaving them hanging. MAE: I love that and yes. Speaking of teaching people how to code and what you said, there's a name for it that I'm forgetting about being a teacher. If you are closer to the student, you actually are a more effective teacher. So there's just two comments. The first one is I'm a part of RailsBridge I helped found the Southeast regional chapter. So if anybody, any listeners out there still want to learn how to code, or are having that same, I don't know how to tell you about my [chuckles] zigzag story and ideally, they wouldn't all be depressing, [laughs] but I'm sure they all include some real low moments. But RailsBridge, which is bridgetroll.org, has recurring events where people can go all over the country and obviously, in pandemic times it's not as much in person, but yeah. And on the comment about teaching and when you mention talking to the people with the least privilege in the room, I'm just really sensitive and appreciative of your sensitivity to power politics and how much they impact so much of what is happening and trust. So for anybody out there who's being asked to help new people and you feel like you're still the new person, you're probably in a better position to help. So just want to offer some encouragement there. I have personally found a lot more confidence in helping people who are just behind me and that anytime you're teaching, you're learning. So just want to put those in. I love that actually your answer, instead of a quadrant, is really just the one word of trust and I appreciated the ways in which you were mentioning trust can be different things. Trust in what you're building. Trust in who's asking you to do it. Chelsea asked for a couple examples and I interrupted. So I apologize, but what are some trust building exercises that you have encouraged, or examples? Maybe even continuing that same story. Six months later, was it a fresher air in there and what are some things they did to make that happen? JUSTIN: Yeah, that story, like so many teams and companies in our industry, didn't undertake the redemption arc that I wish I could convey. I think in fact, to see a big picture problem and the desire to connect that with a big picture tidy solution, a future state where it's all rainbows and unicorns and everyone really getting along well. Sometimes that sets, for me personally and when I see consultants who are less experienced, who can see that end state in mind and they know maybe the top three hit list of stuff that needs to happen to help that organization get to where they need to be. We can sometimes set the bar so high for ourselves in terms of expectations of like, what does it mean to help them become better, that we can't help, but lose sight of the value of just incremental improvement. If I can just help restore relationship between two people on a team. I had one client years and years ago, [laughs] they were also undergoing a pretty big transition and they brought me in a – I think that what they thought they were hiring me for was to be a test-driven development coach to teach them that particular practice of TDD. They got, instead on day one, there was a room of 30 interdisciplinary cross-functional teams—some developers, some non-developers, and stuff—and I could just tell that they were like, it was a big epic rewrite from a Perl codebase that, I think they were moving to no JS and Angular as well as a chewing of cloud infrastructure at the same time, as well as Agile software practices at the same time. They were overwhelmed, they've seen this fail before, they felt a ton of pressure from the business, and they didn't even really understand, I don't think, the future business model. Even if they were successful, it wasn't clear this was going to solve systemic problems for the company. And I'm like, “Well, I can teach you all TDD. [laughs] But instead what my commitment to you all will be is that six months from now, you'll either have been successful and learned all of these things and built the thing as the business has asked you to do and then the business takes off, or I will have helped equip you with skills and ways of thinking about this industry and our work that will set you up to get much better jobs next time.” Again, the company didn't totally come together. It didn't take off like a rocket ship. The team was successful in the rewrite, which doesn't happen very often. But then you saw almost a diaspora of dozens of highly skilled people—and this was in Central Ohio—who then went to venture backed startups, some went to big, established enterprise-y kind of companies, some left the region and went elsewhere. That turned into, if I had to count, probably eight, nine additional Test Double clients [laughs] down the road where they came in and they could spot in a minute, this is a way that an outside perspective, who is here to help us at a moment of tremendous need, can move the needle just a little bit. By setting expectations realistically, being humane about it, and focused on what's best for the people involved because at the end of the day, all companies are is collections of humans. That was, I guess, more my orientation. CHELSEA: So Justin, I'm interested in your thoughts on this. I appreciate what you just shared. I worked at Pivotal Labs for a while—original labs when it was sort of a generalist's enablement. JUSTIN: Sure. CHELSEA: Very heavy on that kind of thing. One of the things that we ran into relatively frequently was similar to what you've just described wherein one of two things would happen. Either the clients were successful and there was a vastly improved, I guess, software delivery culture among the people that we were working with, or if that didn't work out, then there were individuals who took to it very well and had gained variety of skills that allowed them to go elsewhere. It happened enough times that then we would have to establish trust with potential new clients around this whole additional access, which was effectively, is this going to cause a diaspora of all of these engineers, designers, and PMs that I've managed to scrape together for this project? Do you find Test Double ever facing that, or how do you address either beforehand if product owners are aware of it, or after it happens, how do you address that with clients? JUSTIN: That's a fantastic question. Pivotal Labs was one of the companies that we looked at. We started Test Double 10 years ago. I was at the time, just starting to speak at user groups and conferences and I spent a lot of time with the people at the Boulder office at Pivotal Labs. Great people. I really appreciated the focus and the rigor and in fact, made to answer a question earlier about process, or abstraction about like, “Hey, boil it down for me.” Pivotal Labs sold a very branded, very discreet process for like, this is the way to build software and, in a sense, some of the decisions that we made when we started Test Double were a response against that. Just to say we trust the people closest to the work to make the right decisions based on tremendous experience and skills. Frankly, as we get bigger and more successful, having some somebody like me at the top of an organization who only talks at the beginning of a client relationship, which is the moment that we know the least and I've got the least amount of context, for me to go and say, “Well, this is the way that we got a test,” or whatever it is would just be ineffective and inappropriate. So to answer your question, Chelsea. Fortunately, our brand power, isn't nearly as strong as Pivotal Labs so no client has ever come to us in advance with that as a question to say, “Hey, I'm worried that you're going to train our people in this particular methodology and then they're going to leave for higher paying jobs,” or something. That's never come up in advance. In fact, one of the things that we talk a lot about is that because our consultants join client engineering teams to work with them inside of their own process, using their own tools, and their own system is we just try to be model citizens of somebody on that team. We trust our clients like, “Whatever your process is, it's apparently working for you. So let's just try it and if we have ideas for how to make that better, we will listen, we'll write them down.” But then only once we've built trust and rapport with the people on that team, will we start to share, “Hey, I've got a rainy-day list of a few things that you might want to try.” What that's actually done is has a detoxifying effect where from a context of high trust, the incongruity, the distrust, the kind of backchannel frustrations that our people pick up on because we're kind of “in the trenches” with our client folks, we're able to have multiple pathways into that client organization to help make it a better place to work. We got one of the best poll quotes that I've ever seen on our website recently. One of our clients is Betterment. They're a great financial management firm in New York where it's kind of an autopilot savings vehicle. The director of engineering, Katelyn, there said that she saw on the teams where testable people were deployed, attrition actually went down and I think it's because we help those teams to perform better. An old friend of mine named Leon Gersing, he used to have a thing he'd say. He'd said, “You can either change where you work, or you can change where you work.” Meaning you can either make the place that you're at better, or you can go find gainful employment elsewhere and we're in the make the place where people work better business, wherever possible as a first avenue. MAE: You're reminding me of a book that I'm reading right now called What Got You Here Isn't Going to Get You There. Are you all familiar with it? JUSTIN: I was so proud of my wife, because she asked for that on Audible earlier this week because I'm the person with the Audible credit and I'm like, “Oh, this is quoted in business leadership contexts left and right and all over the place. So it'll give us a touchstone to talk about.” MAE: Yeah. Well, the TLDR is so much of especially management focused and leadership focused thought is about things that you should do and this book is probably along your lines, Justin of giving the counterintuitive answer. This is here's 20 things that you might want to consider not doing and then replace it with the good behavior because that is such a stretch in real life to actually do that. It's how about you just pick a couple of these that you're a repeat offender and just stop. Just try to not do it. That's the main first thing and I've found that, a refreshing take on how to think about how to guide in ways that are building more trust and offering more safety. So definitely recommend that book. I don't know that it came out of this book, but the person who recommended it to me, my VP Scott Turnquist, who is amazing, shared that there are really four categories of things that can help build trust and it's definitely all done incrementally. So picking up on that word you said earlier, Justin, too. But the four kind of axes are credibility, reliability, intimacy, and selfless motivation. If you can demonstrate those recurringly, that is how to establish and/or course correct into a state of increased trust. So anyway, that was partly why my original statement was like, do you have this down? Because I've heard some things lately that I've been thinking about. JUSTIN: I really appreciate your perspective there and it makes me feel better because one of my commitments in life is to never write a book. But if I were to write a book, I'd probably have to come up with a tidy quadrant, a Harvard Business Review two by two, or something like that to I guess, support the good work at the people at CliffsNotes and Blinkist to boil down years' worth of work into a 13-minute podcast. I think that the advice as you expressed, it is completely valid and there's one thing that I think is a core ingredient to trust. Trust of ourselves, trust of people that we work with directly, and then trust of leadership and the people who run the organizations that we're a part of. The hardest, in my opinion, is authenticity. If you're not, I think you said credible. If you combine credible, intimacy, vulnerability, those are really useful words to prompt what I mean when I say authenticity. If I'm talking to somebody and I can lock eyes with them and I believe that what they're saying is what they actually feel and it's their true self and they believe it, then all sorts of other background processes in my head of trying to read the tea leaves of what's going on here, all the passive analysis I might do to try to understand what's the subtext that this person's operating from. That's just the form of kind of armor, or a guard that it depletes my cognitive ability to talk to the person. Authenticity is a signal that we pick up on as humans and this is why it's a miracle that we have video chat in this era and it's why I really relish one-on-one in-person interactions when I can have them. Authenticity is a signal that I can drop that guard a little bit. It's that I can really look and really listen to what the person's saying and take it at face value. The problem with just saying, “Oh, okay, well just be authentic. Just be your true self,” is that that is useless advice and way more likely to trigger somebody's defenses, or their self-doubt. When I think about authenticity in the context of a team, or an organization is that the people who are maybe not in a position of power, people who report up the chain, if they don't come across as authentic to their leaders, the leaders should not look at that as a failing of the person, but as a failure of their ability to figure out how to promote and draw out authenticity from the people who report to them. Maybe they don't have safety in the room to speak their true mind. Maybe they feel like the things that make them different from the other people that they work with are a liability, or a risk and so, they can't really bring their true self to work. It's the leader's job, when they spot inauthenticity, rather than go on a hunt like a political backchannels to try to figure out why is this person lying. What's under here? Figuring out what is it about the person's context, the environment, kind of the system that they are operating in. What could possibly be an explanation for why I can't develop an authentic connection with this person? And until you run out of every single possible explanation in that investigation, including self-reflection of what is it that I'm individually doing and how I communicate to this person that's getting in the way. Only then is it really useful to start thinking about maybe this person's not a good actor, maybe they're being duplicitous, or something. Because once you've hit that button, it is really hard to go back. So when we talk about authenticity, we often talk about the individual's responsibility to present it, to be it. If you can fake authenticity, then you can do anything, right? That is advice. It's fine. I hope that everyone feels the safety. Like I'm a cishet white dude who's pretty powerful in my little corner of the small pond. I have no problem just spouting off and being my true self and so, I should just tell other people to do that too. That's not fair. I think that what is better advice for people who are maybe not in positions of power is to be really good at detecting authenticity. When you detect authenticity and people are making their true selves known to you and you're feeling a connection with them, whether they're peers, or managers, spend more time with them, invest into those relationships, and use those people as anchors of trust. So that when you're failing to make that connection elsewhere, when you have doubts about others in the organization, you can have more points of perspective on how to best address it. MAE: I read an article yesterday that says, “Laziness Doesn't Exist.” That's the title of it and it essentially says that that same thing of what's the context in which this is happening. People don't procrastinate for fun. In fact, it usually takes more work and starting from a place of what shoes are you in, but I especially love the in what way am I impacting that person's ability to be themselves? Also, I must have said the word authenticity, because this list is credibility, reliability, intimacy, selfless motivation, but authenticity and credibility in all of these things do also have to do with the thing that I loved you bringing up about identity, power politics, and what happens and your environment is not allowing you to be credible. So another way in which people can as good peers, mentors, managers, and above can do is in what way am I bolstering these people's credibility? So always flipping it back to how are we the perp [laughs] and that's very similar to social justice, racial justice. The more we see how we are perpetuating and disenfranchising, regardless of our identity, that's where there's some hope for the humans in my mind. CHELSEA: Yeah. One of the things that I appreciate that you've both brought up, Justin and Mae, is the degree to which power gradients play a role in the way that we deal with these things. There are demographic power gradients with regard to race, with regard to gender. There are also power gradients with regards to our position in the company, with regard to technical privilege, with regard to our level of skill, with regard to the size of our network. We also, I think live in this individualist culture that has a tendency to place the responsibility on individuals to do what they can to resolve. For example, what you were saying, Justin, about how we effectively coach people to just be authentic. Maybe that coaching works fine in some context, but that's a subset of the context in which we're asking people to apply it and asking individuals to resolve this from the bottom up sometimes as opposed to looking for the systemic reasons why this is a thing that has to be solved in the first place. I'm curious as to whether you have thoughts on what a person can do, who finds themselves in a position of power, in a position of leadership in a company, for example, to address those sorts of questions with other folks who are working there. JUSTIN: I think one thing that can be helpful – and I realize your question is about what can a leader do. One thing that can be helpful is for those leaders to empathize and put themselves in the shoes of people who might not have the same privileges as you described and what would it take to—I'm waiting outside my area of expertise here—would be to think about what are the things that are in a given person's sphere of direct control, what isn't, what am I setting up, and what am I communicating in terms of expectations that I have of them? An example that came up a lot in our industry was the number of drink up events in tech in the early 2010s where there was sort of an assumption that everyone likes alcohol and when people in public drink alcohol, good things happen, which turns out isn't true, but it can also be the case. There are invisible expectations that we communicate because I'm a big fan of granting people autonomy to solve problems in their own way, to approach work the way that they feel is best. Our company has been remote from day one and a big part of that was we want people in control of everything from where they work to their home network, to the computers that they use. Because when I had that control pulled away from me in the role as developer, it just sapped my motivation, my drive, my engagement, my sense of control over the stuff that's right in front of me. When I now in a role of influence over other people, whenever I speak, I have to think about the negative space of what are the expectations that I might be conveying that are not explicit. I need to be careful of even expressing something like hobbies, or shows that I like, or stuff – especially in this remote world, we want to develop connectedness. But a challenge that I keep running into is that our ability to find mutual connection with people about stuff other than work, it rides the line really closely of communicating some other allegiance, or affiliation whether that's we talk about sports a lot because that's an obvious one, but even just interest in hobbies. So I find myself – and I realize Chelsea, I'm doing a really poor job, I think of answering the question as you asked it. I find myself only really able to even grapple with like what can leaders do to set the tone for the kind of environment that's going to be inclusive and safe for other people by really digging in, empathizing with, calling up, and dredging up what their own experience was when they were not in a position of power. If I have a secondary superpower, is I had a real rough start to my career. I was in really, really, really rough client environments that were super hostile. I had a C-level executive at a Fortune 500 company scream at me until his face was red in a room one-on-one with a closed door on a regular basis. The sorts of stuff that developed callus on me, that I look back at a lot of those experiences and I'm like, “I learned a bunch.” It's supercharged my career as an individual because it strengthened me. So the challenge that I have is what can I take from those really, really harsh experiences and translate them for people who are coming up in a way that they don't have to go through the same trials and tribulations, but that they can take away from it the lessons that I learned. And for me, it's all about not just safety for the sake of safety, but safety by which myself and others can convey the useful growth that people want to see in themselves, their skills, and their abilities that isn't diluted. That can convey the truth, the difficulty, and the challenge and how hard – Programming is really, really hard for me and I've been doing it for a long time. A lot of stuff about this is just not easy. The relationships are not easy. Like you're going to run into situations where there's massive differences between where people stand on stuff and what those perspectives look like. Navigating that is hard enough without adding a whole layer of toxicity and hostile work environment. So what's a way to promote that learning environment without just totally insulating somebody from reality. That's been, I think a challenge and attention that I see a lot of other like-minded leaders in tech trying to figure out how to create. MAE: You reminded me of a meme that someone shared with me that says, “What doesn't kill you can just regulate your nervous system, trap itself in your body, steal your sense of self, make you wish it did.” I don't know what makes you stronger means, but let's stop glorifying trauma as a life lesson we've been blessed with. [chuckles] Definitely along the same lines. JUSTIN: Yeah. Relatable. MAE: There's a thing, too about putting oneself in another's shoes and this is a place where I'm someone that can read people really well, but that makes that tricky. Because I start to trust my sense of it and I have a similar architecture going if I don't feel like I'm getting the whole story. So what's the read between the lines thing. But without a lot of exposure to a lot of very different people, and most people have not had a lot of exposure to a lot of different people, when they put themselves in the other person's shoes, they come up with a different conclusion. So I will feel hurt by people who do things that were I to put myself in their shoes would not have done that to me, or if they did, it's because of X, Y, Z about who they are, or what they think, or what is their whole context and environment. All of that is there's a tactic that we use at True Link Financial called “don't cross the net.” So you say and claim the story I tell myself about that is dot, dot. When leaders, who haven't had a lot of exposure to a lot of different people and a lot of different ideas, try to empathize and find themselves limited in that, there are other options which include one of the things you said earlier. Making it so that people can say the things on their mind so whether, or not that's persons being their authentic self this is a whole another level, but creating a place where we expect that we're all messing up and that it's okay to talk about uncomfortable things is one of my real soapboxes. It's totally okay. Yes, we are all racist. We are all sexist. We are all homophobic. There is no way to not be as a result of being in the culture we're in. We could do things to mitigate it. We can do things to name it. But if we just start from yes, we're all failing. This for me, it lowers the stakes because so many people feel that if someone brings up, “Hey, that's kind of sexist,” or “This is not supporting me in this way,” or “My credibility is not being seen because of this.” In the absence of already, yo, we're going to talk about some negative stuff sometimes, that's an introduction of negativity to the “positive, happy rainbow unicorn workplace” that you were talking about before. So one of my hopes and dreams is that we get some clouds to rain on the land to allow things to actually grow [chuckles] and this includes, yo, we are not perfect. And we are definitely doing things we don't intend all the time. JACOB: That made me think about authenticity again, because sopen about imperfection. I'm a neurodiverse person so I probably am autistic. If someone were to say to me at work, “We really want you to bring your authentic self,” probably the thing I would think is you don't want that person, [laughs] or at least without getting to know me a lot better. There's a concept called masking where it's basically, there are behaviors and traits that are exhibited by neurotypical people that just come naturally to them. By learning the hard way, I've sort of learned to do them, even if they don't feel natural at all like making eye contact, smiling at people when talking, things like that. So I think that complicates authenticity for me, which is that I'm intentionally not hiding, but choosing what parts of myself to show and what parts I just don't want to bring to work. [laughs] I don't have a clean answer for that, or a solution to that, but I think that just complicates things for me. JUSTIN: I thank you so much for sharing that and I think it's a really important perspective to bring, which is I talked earlier about sure, plenty of people's true, authentic selves, even if they were to bring them, they might be in a job, or in a space, or in a team where that wouldn't be understood as such, or appreciated, or literally safe. It's hard to tell people, “Hey, you should feel safe” when the truth when spoken would be an unsafe thing. That would be setting people up for risk, for danger, and it would be a seed of distrust, which is what we're all here to talk about avoiding. So I really appreciate you sharing that. When I talked about empathy earlier, Mae, in my brain, all that really comes through it is the E-M part of that word, like the root for emotion. I never really have been able to assume that I can get somebody's context, their perspective, and the moment that they're in into my brain well enough to role play and do a re-dramatization in black and white, sepia tones and slow motion, like this is what Justin would do if he was here. That's one reason why we trust people at our company to just do the work, because we know that they're going to have such a richer amount of data and context than we'll ever have. But one thing that I'm grateful for is that I've been able to experience what I feel like is a pretty broad range of emotion. [laughs] I'm a real emotionally volatile person. I go super high highs, super low lows and I'm just like, it's how I've been. I can't help it. So when I'm empathizing with people, I'm just trying to get in the mindset of how do they likely feel right now so that I can understand and try to do a better job, meeting them where they are. A big part of that is learning there are differences and so Jacob, of course, it's like if I worked with you, I understand that it might not be productive to bring all of yourself to work all the time. But I would hope to develop a trusting relationship with you where you can share enough so that I can know what are the boundaries that are going to be productive for you, productive for me so that we can make a connection and it's something – To make this a little bit more personal. I don't know where my career is going to go next. I founded Test Double with my partner, Todd. I was only 26 years old and we've been doing this for 10 years now. 2 years ago, we embarked on a journey of transferring a 100% of the equity of the company to our employees. So we're on an employee stock ownership plan now, it's ESOP, or any of the stuff, it is complicated because it's well regulated. We have to have outside auditors, a valuation firm, we have a third-party trustee to make sure that our people and the value of the company is transferred appropriately, treated right, and managed well. So it's naturally raised, especially in my circle of friends and family who realize that, this means that there's not an end date, but there's a moment at which I can start thinking about what my life is going to be next. The people who knew me when I was 25, 26, who look at me now, it's not that I've changed radically, or my identities are radically different, or anything. It's like, I am a very different kind of person than I was at 26, than I was at 20 before I got into this industry. I have changed in healthy ways and in maladaptive ones and in response to maybe drama and stress such that the ideal retirement that I would've imagined earlier in my life looks a lot different now where I've just kind of become habituated. I'm a really, really different person than I used to be and I'm grateful for that in almost every way. I feel like I've grown a lot as a person, but the thing about me that I really look at as an area of change is that I just work too much. [chuckles] I'm online all the time. I'm very focused on – I've optimized productivity so much that it's become ingrained in me. I understand that whatever I do next, or even if it's just changing my role inside my company, I need to find a way to create more space for slower paced asynchronous thought and learning how to, in the context of a career, not just bring your true self – I'm kind of curious Chelsea, Mae, and Jacob's perspectives. That true self might be changing [laughs] intentionally. There's a directionality and the growth isn't just learning new skills necessarily, but it might be changing core things about ourselves that will alter the dynamic of the relationships that we bring to work. CHELSEA: Yeah. I have two thoughts on that, that I can share. The first is the extent to which bringing my true self is a productive thing to do at work. So for example, my career prior to tech, I did a variety of different things to make ends meet, really a wide variety of things. I graduated directly into one of the bigger recessions. I won't tell you the exact one, because I don't feel like being aged right now, but [chuckles] it wouldn't take too much research to figure it out. I was trained to do a government job that was not hiring for the next 18 months at a minimum. I needed to figure out what to do and was trying to make ends meet. In my first year of employment, I got laid off/my job ended/something like that on four separate occasions in my first year of work and that resulted in, I do not trust when managers tell me that everything is fine. I have not ever effectively and that is something that I don't foreground that in work discussions for a variety of reasons. I don't want to scare other people. I don't want them to think I know something that they don't know about what's going to happen because I don't usually. When managers tell me, “Oh, everything's great, we're doing great,” all that kind of stuff, I just don't listen. I don't. My decisions do not take that's statement into account and I find that that's the kind of thing that I think about when I'm asked to bring my whole self, my authentic self to a place is that there are things that just sort of similar to what Jacob is saying. I'm like, “Trust me, trust me on this you don't want that.” So that's kind of the first thought in that realm. The second thought that I have around this is the degree to which work should really encompass enough of our lives to require, or demand our authenticity. So I had a variety of full-time jobs in tech and then I quit one of those full-time jobs and I was an independent consultant for a while bolstered chiefly, and I was lucky for this, by folks who had read my blog and then folks who had worked with me when I was at Pivotal. So the consulting effect of people knowing what it's like to work with you is real. That experience felt very different from a full-time position insofar as at the external validation of my work was naturally distributed in a way that it's not in a full-time position and I found that distribution is extremely comforting. Such that even though I now have a full-time job, I also continue client work, I continue teaching, and I continue writing and doing workshops and those kinds of things. This is not the chief reason that I do that, but one of the nice things about it is the diversification of investment in the feedback that I'm receiving and validation that I'm receiving. In order to do that, I have an amount of energy that I put to each of the things in my life and part of it is work, of course. But another reason that I think it works for me is that I no longer have to expect all of my career fulfillment from any one position, from any one employer, from any one place, which has worked out very well because I think that we pedal this notion implicitly that you bring your whole self to work and in return, work provides for your whole career fulfillment. But most places really kind of can't and it's not because they're terrible places to work. It's just because the goals of a company are not actually to fulfill the employees, they're just not. That's not the way that that works. So it has allowed me and I think would allow others to approach the role that a given employment situation plays in their life, from what I think is a more realistic perspective that ends up helping keep me more satisfied in any given work relationship. But it doesn't necessitate that I – I guess, for lack of a better term, it limits the degree of emotional investment that I have in any one thing, because I'm not expecting all of my fulfillment out of any one thing. But I think that to say that explicitly sometimes runs at best, orthogonal and at worst, maybe contraindicates a lot of what we talk about when we talk about bringing our whole selves to work and looking for those personal connections at work. I think there is pragmatic limit past which we maybe impose more guilt than we need to on ourselves for not doing that. JUSTIN: Yeah. Thank you so much for sharing that. I think Mae used the phrase “lower the stakes” earlier and I think that one of the problems with authenticity, the phrase “bring your whole self-trust” is that the stakes are super high because it seems like these are bullion contracts between parties. For example, you said that you don't trust managers. If I was filling out a form, like a personality inventory, or something, it's like, “Do you trust managers?” I'd say no and I think 90% of people would say no. It's sort of the economy right now. I think the economy approval rating of is the economy good, or bad is at 23%. But individuals are saying at roughly 60% levels, that they are individually doing okay in this economy. I would say the same. Like, do I trust my manager? Oh, hell yeah. I completely trust my manager right now. And to lower the stakes even further, when I've been talking about trust, it's not so much about where do I find fulfillment, or who what's my identity, or who am I being, it's about a snap orientation. It's the most immediate sphere. “Oh man, this PostgreSQL query is really slow and I can't figure it out.” Is my snap reaction, or my orientation to think, “I believe in myself enough to dig into this to figure it out”, or is it doubt myself and just kind of get lost in a sea of a thousand Stack Overflow tabs and just slowly lose my whole evening? When in a team, maybe working with them and we were in planning, or something, or maybe we're in a higher stake, let's say, a code review session and somebody makes a comment about something that I did. Is my snap reaction to doubt their motivations and think “Ah, they're just trying to passive aggressively shoehorn in their favorite architecture here,” or this is politics and gamesmanship, or is my snap reaction is to be like, “Nope, let's try to interpret the words that they're saying as literal words and take it on its face”? Like I said, I'm a highly emotionally volatile person, the weather vane shifts with me all the time and sometimes I can control it and sometimes I can just merely observe it. But the awareness of the out has been really helpful to understand [chuckles] when I hear a leader say something about the company, my reaction is I think that they've got ulterior motives and that they are probably not speaking in literal truth. If that's my snap reaction, I'm just trying to communicate that as that's a potential blind spot. Because I have a long rut of past companies that I worked for that had mission statements and vision statements that were kind of bullshit and that no one really believed in, that were just in a bronze plaque on a wall, or whatever. That's baggage that I carry. I just have to acknowledge that baggage and try to move forward. The best I can do is just be present in every moment that I'm in and to understand when I have a snap reaction, am I oriented towards what might lead me to a good outcome, or a bad one? MAE: Holy moly, so many amazing things have been shared today and Jacob, especially kudos to you for walking us into a deeper level of authenticity. Love it. Thank you. I'm, to answer some of your questions, Justin very similar to Chelsea in that tech was not my first rodeo. I didn't become a programmer until I was 37 years old and I am now 45. I'm totally fine with aging myself. Prior to tech, I did put a lot more of my identity in my job and I would usually do that job pretty much all of the hours possible and I've always worked for mission driven organizations. A lot of the things that we're talking about as far as job fulfillment and whether, or not it's a good environment, or if it's a toxic environment, there's a lot of privilege in what we're talking. My parents were paper mill workers and it was not pretty. They had me when they were 19, so they didn't have another option. That was the highest paying gig in our region and they had no education. So it was never an option to even change that. So I am someone who wants to put my whole self into what I do. It's a very working-class mode and gaining identity through what it is I'm able to do. It's also a pretty capitalist [laughs] mentality that I work to move around. But as a manager, when I am a manager, or in management, or managing managers, I'm never encouraging this everybody needs to bring their whole self to work. Although, I had this really instructive experience where one person truly did not want to have any of their self at work, that they truly only wanted to talk about work at work. We're not a family, nicely nice. I don't want to crochet together, or whatever. That is the most challenged I've ever been as a manager because my natural things are always to figure out what people need and want, and then amalgamate that across the group and see how we can do some utilitarian math and get it so that people are being encouraged in ways they would like, they are not being disadvantaged, and they have space to say when that's happening. But even still, I'm always going with the let's be buddies plan and it's not for everyone. So figuring out how to not have all of your eggs in any basket, no matter how many hours the job is, is definitely a tactic that has been successful for me. But what happens is I then am involved in so many things [chuckles] in all of the moments of life. So I still do that, but I do it by working more, which isn't necessarily the best option. The thing about the mission that I just wanted to pivot for a second and say is, we are no longer in a world where we allow failure. This is a little bit back to my earlier soapbox. The energetic reality is whatever anybody's mission statement is, that is the thing they are going to fail at, like the seamstress never has the best hemmed clothes. So when we write off anyone, or any company based their flawed attempt at the mission, we're discounting that flaws exist, [chuckles] contradictions exist. It's about where are we orienting and are we incrementally moving toward that, or away from it and not in this moment, are we this thing that we have declared because it's more of a path is how I see it than the declaration of success. JUSTIN: Yeah. Thank you so much for that, too. Because I think that one thing we didn't touch on is the universe – and we're talking a Greater Than Code podcast so it's software industry adjacent at least. The universe of people who got to stay home during this whole pandemic. The universe of people who are “knowledge workers”, or “white collar”, especially if you look at the population of the world, is vanishingly small. There was a season in my life where I was the person that you just described managing, where I just viewed myself as I was burnt out. I always wanted to be a mercenary. I had this mindset of I show up at work. “You want some great code? I'll sling you some great code.” Like I was a short-order cook for story points and feature development and that was the terms, right? I didn't want to bring my feelings to work. I didn't want to make friends with people because then God forbid, it would be harder to leave. I didn't have that available to me as a capacity at that time, but I went long enough and I realized it's not that I was missing something, or not being fed in some way by not having this emotional need filled at work. It was that I was failing to acknowledge when you say privilege, the literal privilege, that I get to wake up in the morning and think for a job [laughs] and the impact that I can have when I apply all of the skills, capabilities, and background asynchronous thoughts that are not literally in my job description. When I can bring those things to bear, I'm going to have a much, much bigger impact because what am I except for one person thinking and staring at a matted piece of glass all day, but somebody who is in a small community, or a group of a bunch of people who are in the same mode. So when I'm in a meeting, I can just be the mercenary jerk who's just like, “Hey, I'm just doing this,” and feeling like that's an emotionally neutral thing. When in fact, that negativity can be in an emotional contagion that could affect other work negatively, or and I'm not exactly – My friends who know me, I'm a stick in a mud, I'm a curmudgeon, I'm super negative. I complain constantly and I have taken it upon myself to strive to be a net increase in joy in the people that I talk to and that I interact with at work. Because it is a resource that is draining all of us all day long on its own and it needs to be filled up somehow. I have the capacity right now to take it upon myself to try to fill that tank up for the people that I interact with. So I want to touch on that because I just think it's super lucky that I get to work on a computer and talk out of a screen all day long. If I didn't have that, we wouldn't be having this conversation, I suppose, but I'm just here to make the most of it, I guess. MAE: I love that. And you reminded me of Sandi Metz's closer, Lucky You. JACOB: Tell us about it. MAE: She gave the closing talk a couple years ago and it's called Lucky You and it goes through how did we all come to be sitting in this room right now and what about redlining? What about the districting? What about all of these things that led to us to experience being here as lucky? I know you weren't saying it in that way, Justin, but it reminded me of that piece, too, which is relevant, but the talk is completely amazing and I definitely recommend it. JUSTIN: I think I mentioned it once before. The thing that brought me and our marketing director, Cathy, to think that this would be a great forum to talk a little bit about trust at work is that we're about out to – and I think that actually the day that this podcast publishes is the day that we're going to publish a new conference talk that I've prepared called How to Trust Again and we're going to post it to Test Double's YouTube channel. So we might not have a direct link for the show notes necessarily, but it'll probably be at the top of that as well as the top of our blog when the show goes live. I hope that anyone [laughs] who enjoyed this conversation will also enjoy the kind of high paced, frenetic, lots of keynote slide style that I bring to communicating about a lot of these topics while still understanding that it's just like n equals one. I'm sharing my experience and hopefully, as food for thought to maybe help you look back at your own experience and understand what connects from my experiences, my perspectives, and my context that might be useful and I hope that you'll find something. Special Guest: Justin Searls.

00:36 - Panelist Consulting Experience and Backgrounds * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) * Happy and Effective (https://www.happyandeffective.com/) 10:00 - Marketing, Charging, and Setting Prices * Patreon (https://www.patreon.com/) * Chelsea's Blog (https://chelseatroy.com/) * Self-Worth by Salary 28:34 - GeePawHill Twitter Thread (https://twitter.com/GeePawHill/status/1478950180904972293) - Impact Consulting * Casey's Spreadsheet - “Matrix-Based Prioritization For Choosing a Job” (https://docs.google.com/spreadsheets/d/1qVrWOKPe3ElXJhOBS8egGIyGqpm6Fk9kjrFWvB92Fpk/edit#gid=1724142346) * Interdependence (https://www.merriam-webster.com/dictionary/interdependence) 38:43 - Management & Mentorship * Detangling the Manager: Supervisor, Team Lead, Mentor (https://dev.to/endangeredmassa/detangling-the-manager-supervisor-team-lead-mentor-gha) * Adrienne Maree Brown (https://adriennemareebrown.net/) 52:15 - Explaining Value and Offerings * The Pumpkin Plan: A Simple Strategy to Grow a Remarkable Business in Any Field by Mike Michalowicz (https://www.amazon.com/Pumpkin-Plan-Strategy-Remarkable-Business/dp/1591844886) * User Research * SPIN Selling: Situation Problem Implication Need-payoff by Neil Rackham (https://www.goodreads.com/book/show/833015.SPIN_Selling) 55:08 - Ideal Clients Reflections: Mae: The phrase “indie”. Casey: Having a Patreon to help inspire yourself. Chelsea: Tallying up all of the different things that a given position contributes to in terms of a person's needs. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: CHELSEA: Welcome to Greater Than Code, Episode 267. I'm Chelsea Troy, and I'm here with my co-host, Mae. MAE: And also with us is Casey. CASEY: Hi, I'm Casey. And today's episode, we are our own guests. We're going to be talking to you about our experiences in consulting. To get this one started, how about we share what got us into consulting and what we like, don't like about it, just high-level? Chelsea, would you mind going first? CHELSEA: Sure. So I started in consulting, really in a full-time job. So for early in my programming career, I worked for several years for a company called Pivotal Labs and Pivotal Labs is chiefly, or was chiefly at the time, a software engineering consulting organization. My job was to pair program with folks from client teams, various types of clients, a lot of health insurance companies. At the time, there was a restaurant loyalty app that we did some work for. We did some work for General Motors, various clients, a major airline was also a client, and I would switch projects every three to six months. During that time employed by Labs, I would work for this client, pair programming with other pivots, and also with client developers. So that was my introduction to consulting and I think that it made the transition to consulting later, a little bit easier because I already had some consulting experience from under the Labs' umbrella. After I worked for Labs, I moved on to working at a product company for about 2 years and my experience at that product company burned me out on full-time programming for a little while. So in my last couple of months at that job, I realized that I was either going to have to take some time off, or I was going to have to find an arrangement that worked better for me for work, at least for the next little while. And for that next little while, what I decided I wanted to try to do was work part-time because I was uncomfortable with the idea of taking time off from programming completely. I felt that I was too early in my career and the skill loss would be too great if I took time off completely, but I knew I needed some space and so, I quit my full-time job. After I quit the full time—I probably should have done this before I quit the job, but I didn't—I called an organization that I had previously done some volunteer work with, with whom I discussed a job a couple of years prior, but for a couple of different reasons, it didn't work out. I said to them, “I know that you're a grant-funded organization and you rarely have the funding and capacity to bring somebody on, but just so you're aware, I like working with you. I love your product. I love the stuff that you work on. All our time working together, I've really enjoyed. So if you have an opening, I'm going to have some time available.” The director there emailed me that same day and said, “Our mobile developer put in his two weeks' notice this morning. So if you have time this afternoon, I'd really like to talk to you,” [chuckles] and that was my first client and they were a part-time client. I still work with them. I love working with them. I would consider them kind of my flagship client. But then from there, I started to kind of pick up more clients and it took off from there after that summer. I spent that summer generally working 3 days a week for that client and then spending 4 days a week lying face down in a park in the sun. That helped me recover a little bit from burnout. And then after that, I consulted full-time for about 2 years and I still consult on the side of a full-time job. So that's my story. Is anyone feeling a penchant for going next? MAE: I can go. I've been trying to think how am I going to say this succinctly. I've had at least two jobs and several club, or organization memberships, or founding, or positions since I was 16. So wherever I go, I've always been saying, “Well, I've done it these 47 ways already [laughs] even since I was a teenager.” So I've sort of always had a consulting orientation to take a broader view and figure out ways in which we can systematize whatever it is that's happening around me. Specifically for programming, I had been an administrator, like an executive leader, for many years. I just got tired of trying to explain what we as administrators needed and I just wanted to be able to build the things. I was already a really big Microsoft access person and anybody who just got a little [laughs] snarky in there knows I love Microsoft Access. It really allowed me to be able to offer all kinds of things to, for example, I was on the board of directors of my Kiwanis Club and I made a member directory and attendance tracker and all these things. Anyway, when I quit my executive job and went to code school in 2014, I did it because I knew that I could build something a lot better than this crazy Access database [laughs] that I had, this very involved ETL things going on in. I had a nonprofit that I had been involved with for 15 years at that point and I had also taken a database class where I modeled this large database that I was envisioning. So I had a bunch of things in order. I quit my full-time job and went to an income of $6,500 my first year and I hung with that flagship customer for a while and tailored my software. So I sort of have this straddling of a SaaS situation and a consulting situation. I embed into whoever I'm working with and help them in many ways. Often, people need lots of different levels of coaching, training, and skills development mixed with just a place to put things that makes sense to them. I think that's the brief version [laughs] that I can come up with and that is how I got where I am and I've gone in and out of also having a full-time job. Before I quit that I referenced the first year I worked a full-time job plus at least 40 to a 100 hours on my software to get it ready for prime time. So a lot of, a lot of work. CASEY: Good story. I don't think I ever heard these fuller stories from either of you, even though I know roughly the shape of your past. It's so cool to hear it. Thanks for sharing them. All right, I'll share about me now. So I've been a developer, a PM, and I've done a lot of design work. I've done all the roles over my time in tech. I started doing programming 10, 15 years ago, and I'm always getting burnt out everywhere I go because I care so much and we get asked to do things that seem dumb. I'm sure anyone listening can relate to this in some organization and when I say dumb, I don't use that word myself directly. I'm quoting a lot of people who would use that word, but I say either we're being asked to do things that don't make sense, aren't good ideas, or there are things that are we're being asked to do that would make sense if we knew why and it's not being communicated really well. It's poor communication. Either one, the other, or both. So after a lot of jobs, I end up taking a 3-month sabbatical and I'm like, “Whatever, I got to go. I can't deal with caring so much anymore, and I'm not willing to care less either.” So most recently, I took a sabbatical and I finished my book, Debugging Your Brain, which takes together psychology ideas, like cognitive behavioral therapy and programming ideas and that, I'm so proud of. If you haven't read it yet, please check it out. Then I went back to my job and I gave them another month where I was like, “All right, look, these are things need to change for me to be happy to work here.” Nothing changed, then I left. Maybe it's changing very slowly, but too slowly for me to be happy there, or most of these past companies. [laughs] After I left, this last sabbatical, I spent three to six months working on a board game version of my book. That's a lot of fun. And then I decided I needed more income, I needed to pay the bills, and I can totally be a tech consultant if I just deal with learning marketing and sales. That's been my… probably six months now, I've been working on the marketing in sales part, thinking a lot about it. I have a lot of support from a lot of friends. Now I consult on ways to make teams happier and more effective and that's my company name, Happy and Effective. I found it really easy to sell workshops, like diversity, equity, and inclusion workshops to HR departments. They're pretty hungry for those kinds of workshops and it's hard to find good, effective facilitators. It's a little bit harder to get companies to pay for coaching for their employees, even though a new EM would love coaching and how to be a good leader. Companies don't always have the budget for that set aside and I wish they would. I'm working with a lot of companies. I have a couple, but not as many as I'd like. And then the hardest, my favorite kind of client is when I get to embed with the team and really work on seeing what's going on me on the ground with them, and help understand what's going on to tell the executives what's happening and what needs to change and really make a big change. I've done that once, or twice and I'd love to do that more, but it's the hardest. So I'm thinking about easy, medium, hard difficulty of selling things to clients. I would actually make plenty of money is doing workshops, honestly, but I want the impact of embedding. That's my bigger goal is the impact. MAE: Yeah. I basically have used my software as a Trojan horse for [laughs] offering the consulting and change management services to help them get there because that is something that people already expect to spend some money on. That, though has been a little problematic because a few years in, they start to think that the line item in the budget is only for software and then it looks very expensive to them. Whereas, if they were looking at it as a consultant gig, it's incredibly inexpensive to them. CASEY: Yeah. It's maybe so inexpensive that it must not be a quality product that they're buying. MAE: Yes. CASEY: Put it that way implicitly. MAE: Definitely, there's also that. CASEY: When setting prices, this is a good general rule of thumb. It could be too low it looks like it'll be junk, like a dollar store purchase, or it can be too high and they just can't afford it, and then there's the middle sweet spot where it seems very valuable. They barely can afford it, but they know it'll be worth it, and that's a really good range to be in. MAE: Yeah. Honestly, for the work that I do, it's more of a passion project. I would do it totally for free, but that doesn't work for this reason you're talking about. CASEY: Yeah. MAE: Like, it needs to hurt a little bit because it's definitely going to be lots and lots of my time and it's going to be some of their time and it needs to be an investment that not hurt bad [laughs] but just be noticeable as opposed to here's a Kenny's Candy, or something. CASEY: I found that works on another scale, on another level. I do career coaching for friends, and friends of friends, and I'm willing to career coach my friends anyway. I've always been. For 10 years, I've reviewed hundreds, thousands of resumes. I've done so many interviews. I'm down to be a career coach, but no one was taking me up on it until I started charging and now friends are coming to me to pay me money to coach them. I think on their side, it feels more equitable. They're more willing to do it now that I'm willing to take money in exchange for it. I felt really bad charging friends until I had the sliding skill. So people who make less, I charge less for, for this personal service. It's kind of weird having a personal service like that, but it works out really well. I'm so happy for so many friends that have gotten jobs they're happy with now from the support. So even charging friends, like charging them nothing means they're not going to sign up for it. MAE: Yes, and often, there is a bias of like, “Oh, well, that's my friend.” [laughs] so they must not be a BFD.” CASEY: Yeah. But we are all BFDs. MAE: Exactly! How about you Chelsea? How did you start to get to the do the pricing thing? CHELSEA: Yeah, I think it's interesting to hear y'all's approaches to the marketing and the pricing because mine has been pretty different from that. But before I get off on that, one thing I do want to mention around getting started with offering personal services at price is that if it seems too large a step to offer a personal service to one person for an amount of money, one thing that I have witnessed folks have success with in starting out in this vein is to set up a Patreon and then have office hours for patrons wherein they spend 2 hours on a Sunday afternoon, or something like that and anyone who is a patron is welcome to join. What often ends up happening for folks in that situation is that people who are friends of theirs support their Patreon and then the friends can show up. So effectively, folks are paying a monthly fee for access to this office hours, which they might attend, or they might not attend. But there are two nice things about it. The first thing about it is that you're not – from a psychological perspective, it doesn't feel like charging your friends for your time with them. It feels more indirect than that in a way that can be helpful for folks who are very new to charging for things and uncomfortable with the idea. The second thing is that the friends are often much more willing to pay than somebody who's new to charging is willing to charge. So the friends are putting this money into this Patreon, usually not because they're trying to get access to your office hours, but because they want to support you and one of the nice things about Patreon is that it is a monthly amount. So having a monthly email from Patreon that's like, “Hey, you we're sending you—” it doesn't even have to be a lot. “We're sending you 40 bucks this month.” It is a helpful conditioning exercise for folks who are not used to charging because they are getting this regular monthly income and the amount is not as important as receiving the regular income, which is helpful psychological preparation for charging for things on your own, I think. That's not the way that I did it, but I have seen people be effective that way. So there's that. For me, marketing was something that I was very worried about having to do when I started my business. In fact, it was one of those things where my conviction, when I started my consulting business, was I do not want to have to sell my services. I will coast on what clients I can find and when it is no longer easy, I will just get a full-time job because selling traditionally conceptualized is not something that I enjoyed. I had a head start on the marketing element of things, that is sort of the brand awareness element of things, my reputation and the reason for that is that first of all, I had consulted at Labs for several years, which meant that every client team that I had ever worked with there, the director remembered me, the product owner remember me. So a lot of people who had been clients of Labs – I didn't actually get anybody to be a client of mine who was a client of Labs, but the individuals I had worked with on those projects who had then changed jobs to go to different companies, reached out to me on some occasions. So that was one place that I got clients from. The other place that I gotten clients from has been my blog. Before I started my business, I had already been writing a tech blog for like 4, or 5 years and my goal with the tech blog has never actually been to get clientele, or make money. My goals for the blog when I started it were to write down what I was learning so that I would remember it and then after that, it was to figure out how to communicate my ideas so that I would have an easier time communicating them in the workplace. After that, it became an external validation source so that I would no longer depend on my individual manager's opinion of me to decide how good I was at programming. Only very recently has it changed to something like, okay, now I'm good enough at communicating and good enough at tech that I actually have something to teach anybody else. So honestly, for many years, I would see the viewership on my blog and I would be like, “Who are all these people? Why are they in my house?” Like, this is weird, but I would get some credibility from that. CASEY: They don't expect any tea from me. CHELSEA: Yeah. I really hope. I don't have enough to go around, [laughs] but it did help and that's where a lot of folks have kind of come from. Such that when I posted on my blog a post about how I'm going to be going indie. I've quit my job. I didn't really expect that to go anywhere, but a few people did reach out from that and I've been lucky insofar is that that has helped me sustain a client load in a way that I didn't really expect to. There's also, I would be remiss not to mention that what I do is I sling code for money for the majority of my consulting business, at least historically and especially in the beginning was exclusively that, and there's enough of a demand to have somebody come in and write code that that helped. It also helped that as I was taking on clients, I started to niche down specifically what I wanted to work on to a specific type of client and to a specific type problem. So I quickly got to the point where I had enough of a client load that I was going to have to make a choice about which clients to accept, or I was going to have to work over time. Now, the conventional wisdom in this circumstance is to raise your rates. Vast majority of business development resources will tell you that that's what you're supposed to do in this situation. But part of my goal in creating my consulting business had been to get out of burnout and part of the reason for the burnout was that I did not feel that the work that I was doing was contributing to a cause that made me feel good about what I was doing. It wasn't morally reprehensible, but I just didn't feel like I was contributing to a better future in the way that my self-identity sort of mandated that I did. It was making me irritable and all these kinds of things. MAE: I had the same thing, yeah. CHELSEA: Yeah. So it's interesting to hear that that's a common experience, but if I were to raise my rates, the companies that were still going to be able to afford me were going to be companies whose products were not morally reprehensible, but not things that coincided with what I was trying to get out of my consulting business. So what I did instead was I said, “I'm specifically looking to work with organizations that are contributing to basic scientific research, improving access for underserved communities, and combating the effects of climate change,” and kept my rates effectively the same, but niche down the clientele to that. That ended up being kind of how I did it. I find that rates vary from client to client in part, because of what you were talking about, Casey, wherein you have to hit the right price in order to even get clients board in certain circumstances. CASEY: Right. CHELSEA: I don't know a good way to guess it. My technique for this, which I don't know if this is kosher to say, but my technique for this has been whoever reached out to me, interested in bringing me on as a consultant for that organization, I ask that person to do some research and figure out what rate I'm supposed to pitch. That has helped a lot because a lot of times my expectations have been wildly off in those circumstances. One time I had somebody say to me, this was for a custom workshop they wanted. I was like, “What should I charge?” And they were like, “I don't know, a few thousand.” I was like, “Is that $1,200? Is that $9,000? I don't know how much money that is,” and so they went back and then they came back and they were able to tell me more specifically a band. There was absolutely no way I would've hit that number accurately without that information. CASEY: Yeah, and different clients have different numbers. You setting your price standard flat across all customers is not a good strategy either. That's why prices aren't on websites so often. CHELSEA: Yeah. I find that it does depend a lot. There's similarly, like I said, a lot of my clients are clients who are contributing to basic scientific research are very often grant funded and grants funding is a very particular kind of funding. It can be intermittent. There has to be a skillset on the team for getting the grant funding. A lot of times, to be frank, it doesn't support the kinds of rates that somebody could charge hourly in a for-profit institution. So for me, it was worth it to make the choice that this is who I want to work with. I know that my rate is effectively capped at this, if I'm going to do that and that was fine by me. Although, I'm lying to say it was completely fine by me. I had to take a long, hard look in the mirror, while I was still in that last full-time job, and realize that I had become a person who gauged her self-worth by the salary that she commanded more than I was comfortable with. More than I wanted to. I had to figure out how to weaken that dependency before I was really able to go off and do my own thing. That was my experience with it. I'm curious whether y'all, well, in particular, Casey, did you find the same thing? CASEY: The self-worth by salary? CHELSEA: Yeah. CASEY: I felt that over time, yeah. Like I went from private sector big tech to government and I got a pay cut and I was like, “Ugh.” It kind of hurt a little and it wasn't even as much as I was promised. Once I got through the hiring process, it was lower than that and now I'm making way less. When I do my favorite impact thing, the board game, like if I made a board game about mental health for middle schoolers, which is something I really want to do, that makes less than anything else I could with my time. I'll be lucky to make money on that at all. So it's actually inverse. My salary is inversely proportional to how much impact I can have if I'm working anyway. So my dream is to have enough corporate clients that I can do half-time, or game impact, whatever other impact things I'm thinking about doing. I think of my impact a lot. Impact is my biggest goal, but the thing is salary hurts. If I don't have the salary and I want to live where I'm living and the lifestyle I have, I don't want to cut back on that and I don't need to, hopefully. CHELSEA: Right. CASEY: I'm hoping eventually, I'll have a steady stream of clients, I don't need to do the marketing and sales outreach as much and all those hours I kind of recoup. I can invest those in the impact things. I've heard people can do that. I think I'll get there. CHELSEA: No, I think you absolutely will. Mae, I'm curious as to your experience, because I know that you have a lot of experience with a similar calculation of determining which things are going to provide more income, which things are probably going to provide less income, and then balancing across a bunch of factors like money, but also impact, time spent, emotional drain, and all that stuff. MAE: Well, Chelsea. [laughter] I am a real merry go round in this arena. So before I became a programmer, I had a state job, I was well paid, and I was pretty set. Then I was a programmer and I took huge pay cut because I quit. I became a programmer when I was 37 years old. So I already had a whole career and to start at the beginning and be parallel with 20-year-old so it's not just like my salary, but also my level and my level of impact on my – and level of the amount of people who wanted to ask me for my advice [laughs] was significantly different. So like the ego's joking stopped and so when you mentioned the thing about identity. Doing any kind of consulting in your own deal is a major identity reorganization and having the money, the title, the clout, and the engagement. Like a couple years, I have spent largely alone and that is very different than working at a place where I have colleagues, or when I live somewhere and have roommates. But I have found signing up for lots and lots of different social justice and passion project things, and supporting nonprofits that I believe in. So from my perspective, I'm really offering a capacity building grant out of my own pocket, my own time, and my own heart and that has been deeply rewarding and maybe not feel much about my identity around salary. Except it does make me question myself as an adult. Like these aren't the best financial decisions to be making, [chuckles] but I get enough out of having made them that it's worth it to me. One of the things probably you were thinking of, Chelsea, we worked together a little bit on this mutual aid project that I took on when the pandemic started and I didn't get paid any dollars for that and I was working 18 hours a day on it, [chuckles] or something. So I like to really jump in a wholeheartedly and then once I really, really do need some dollars, then I figure something else out. That is kind of how I've ebbed and flowed with it. But mostly, I've done it by reducing my personal overhead so that I'm not wigged about the money and lowering whatever my quality-of-life spending goals [chuckles] are. But that also has had to happen because I have not wanted to and I couldn't get myself to get excited about marketing of myself and my whole deal. Like I legit still don't have a website and I've been in operation now since 2014 so that's a while. I meet people and I can demonstrate what it is and I get clients and for me, having only a few clients, there's dozens of people that work for each one. So it's more of an organization client than a bunch of individuals and I can't actually handle a ton. I was in a YCombinator thing that wanted me to really be reporting on income, growth rates, and all of these number of new acquisition things, and it just wasn't for me. Those are not my goals. I want to make sure that this nonprofit can help more people this year and that they can get more grant money because they know how many people they helped and that those people are more efficient at their job every day. So those are harder to measure. It's not quite an answer to your question, [laughs] but I took it and ran a little. CHELSEA: No, I appreciate that. There is a software engineer and a teacher that I follow on Twitter. His name is GeePawHill. Are y'all familiar with GeePawHill? MAE: No. CHELSEA: And he did a thread a couple of days ago that this conversation reminds me of and I found it. Is that all right if I read like a piece of it and paraphrase part of it? MAE: Yes, please. CHELSEA: Okay. So this is what he says. He says, “The weirdest thing about being a teacher for young geek minds: I am teaching them things…that their actual first jobs will most likely forbid them to do. The young'uns I work with are actually nearly all hire-able as is, after 18 months of instruction, without any intervention from me. The problem they're going to face when they get to The Show isn't technical, or intellectual at all. No language, or framework, or OS, or library, or algorithm is going to daunt them, not for long. No, the problem they're going to face is how to sustain their connection to the well of geek joy, in a trade that is systematically bent on simultaneously exploiting that connection while denying it exists and refusing any and all access to it. It is possible, to stick it out, to acquire enough space and power, to re-assert one's path to the well. Many have done it; many are doing it today. But it is very hard. Very hard. Far harder than learning the Visitor pattern, or docker, or, dart, or SQL, or even Haskell. How do you tell people you've watched “become” as they bathed in the cool clear water that, for some long time, 5 years or more, they must…navigate the horrors of extractive capitalist software development? The best answer I have, so far, is to try and teach them how and where to find water outside of work. It is a lousy answer. I feel horrible giving it. But I'd feel even more horrible if I didn't tell them the truth.” CASEY: I just saw this thread and I really liked it, too. I'm glad you found it. MAE: Oh, yeah. I find it honestly pretty inspiring, like people generally who get involved in the kinds of consulting gigs that we three are talking about, which is a little different than just any random consulting, or any random freelancing. CASEY: Like impact consulting, I might call that. MAE: Yeah. It's awesome if the money comes, but it's almost irrelevant [chuckles] provided that basic needs are meant. So that's kind of been my angle. We'll see how – talk to me in 20 more years when I'm [chuckles] trying to retire and made a lot of choices that I was happy with at the time. CASEY: This reminds me of a conversation I had with a friend who's an executive director of an orchestra in the nonprofit space and he was telling me that so many nonprofits shoot themselves in the foot by not doing enough fundraising, by not raising money, and that comes from not wanting to make money in a way because they're a nonprofit, money is not a motive, and everybody's very clear about that. That's noble and all, but it ends up hurting them because they don't have the money to do the impactful things they would as a nonprofit. Money is a necessary evil here and a lot of people are uncomfortable with it. Including me a lot of the time. Honestly, I have to tell myself not to. What would I tell a friend? “No, charge more money.” Okay, I guess I'll tell myself to do that now. I have this conversation with myself a lot. MAE: Yeah. I've been very aware that when I become anti-money, the well dries up. The money well. [laughs] CASEY: Yeah. MAE: And when I am respectful of and appreciative of money in the world, more comes my way. There is an internal dousing, I think that happens that one needs to be very careful about for sure. CASEY: One of the techniques I use with myself and with clients is a matrix where I write out for this approach, this thing that I'm thinking about how much money will it make, how much impact will it have on this goal, and all the different heuristics I would use to make the decision, or columns and all the options arose. I put numbers in it and I might weight my columns because money is less important than impact, but it's still important. It's there. I do all this math. In the end, the summary column with the averages roughly matches what's in my head, which is the things that are similar in my head are similar on paper, but I can see why and that's very clarifying for me. I really like being able to see it in this matrix form and being able to see that you have to focus on the money some amount. If you just did the high impact one, it wouldn't be on the top of the list. It's like, it's hard to think about so many variables at once, but seeing it helps me. CHELSEA: It is. GeePaw speaks to that some later in the thread. He says, “You've got to feed your family. You've got to. That's not negotiable. But you don't got to forget the well. To be any good at all, you have to keep finding the well, keep reaching it, keep noticing it. Doesn't matter whether it's office hours, or after hours. Matters whether you get to it. The thing you've got to watch, when you become a professional geek, isn't the newest tech, and it sure as hell isn't the org's process. You've got to watch whether, or how you're getting to the well. If you're getting to the well, in whatever way, you'll stay alive and change the world.” I think I'm curious as to y'all's thoughts on this, but like I mentioned earlier, I have a full-time job and I also do this consulting on the side. I also teach. I teach at the Master's program in computer science at University of Chicago. I do some mentoring with an organization called Emergent Works, which trains formerly incarcerated technologists. The work situation that I have pieced together for myself, I think manages to get me the income I need and also, the impact that I'm looking for and the ability to work with people and those kinds of things. I think my perspective at this point is that it's probably difficult, if it's realistic at all, to expect any one position to be able to meet all of those needs simultaneously. Maybe they exist, but I suspect that they're relatively few and far between and I think that we probably do ourselves a disservice by propagating this idea that what you need to do is just make yourself so supremely interview-able that everybody wants to hire you and then you get to pick the one position where you get to do that because there's only one in the entirety of tech, it's that rare. Sure, maybe that's an individualist way to look at it. But when we step back and look more closely, or when we step back and look more broadly at that, it's like, all right, so we have to become hypercompetitive in order to be able to get the position where we can make enough while helping people. Like, the means there seem kind of cutthroat for the ends, right? [laughs] CASEY: This reminds me of relationships, too and I think there's a lot of great parallels here. Like you shouldn't expect your partner to meet all of your needs, all of them. MAE: I was thinking the same thing! CASEY: Uh huh. Social, emotional, spiritual, physical, all your needs cannot possibly by one person and that is so much pressure to put on that person, CHELSEA: Right. CASEY: It's like not healthy. CHELSEA: Right. CASEY: You can choose some to prioritize over others for your partner, but you're not going to get a 100% of it and you shouldn't. CHELSEA: Well, and I find that being a conversation fairly regularly in monogamous versus polyamorous circles as well. Like, how much is it appropriate to expect of a partner? But I think it is a valid conversation to have in those circles. But I think that even in the context of a monogamous relationship, a person has other relationships—familial relationships, friend relationships—outside of that single romantic relationship. CASEY: Co-workers, community people, yeah. CHELSEA: Right. But even within that monogamous context, it's most realistic and I would argue, the most healthy to not expect any one person to provide for all of your needs and rather to rely on a community. That's what we're supposed to be able to do. CASEY: Yeah. MAE: Interdependence, not independence. CHELSEA: Right. CASEY: It's more resilient in the face of catastrophe, or change in general, mild, more mild change and you want to be that kind of resilient person for yourself, too. Just like you would do a computer system, or an organization. They should be resilient, too. MAE: Yes. CASEY: Your relationship with your job is another one. MAE: Totally. CHELSEA: Right. And I think that part of the reason the burnout is so quick – like the amount of time, the median amount of time that somebody spends at a company in tech is 2.2 years. MAE: I know, it's so weird. CHELSEA: Very few companies in tech have a large number of lifers, for example, or something like that. There are a number of reasons for that. We don't necessarily have to get into all of them, although, we can if you want. But I think one of them is definitely that we expect to get so much out of a full-time position. Tech is prone. due to circumstances of its origin, to an amount of idealism. We are saving the world. We, as technologists, are saving the world and also, we, as technologists, can expect this salary and we, as technologists, are a family and we play ping pong, and all of these things – [laughter] That contribute to an unrealistic expectation of a work environment, which if that is the only place that we are getting fulfillment as programmers, then people become unsatisfied very quickly because how could an organization that's simultaneously trying to accomplish a goal, meet all of these expect for everybody? I think it's rare at best. CASEY: I want to bring up another example of this kind of thing. Imagine you're an engineer and you have an engineering manager. What's their main job? Is it to get the organization's priorities to be done by the team, like top-down kind of thing? We do need that to happen. Or is it to mentor each individual and coach them and help them grow as an engineer? We need that somewhere, too, yeah. Or is it to make the team – like the team to come together as a team and be very effective together and to represent their needs to the org? That, too, but we don't need one person to do all three of those necessarily. If the person's not technical, you can get someone else in the company to do technical mentorship, like an architect, or just a more senior person on, or off the team somewhere else. But we put a lot of pressure on the engineering managers to do that and this applies to so many roles. That's just one I know that I can define pretty well. There's an article that explains that pretty well. We'll put in the show notes. MAE: Yes! So what I am currently doing is I have a not 40 hours a week job as an engineering manager and especially when I took the gig, I was still doing all of these pandemic charity things and I'm like, “These are more important to me right now and I only have so many hours in the day. So do you need me to code at this place? I can, but do you need me to because all those hours are hours I can go code for all these other things that I'm doing,” and [laughs] it worked. I have been able to do all three of the things that you're talking about, Casey, but certainly able to defer in different places and it's made me – this whole thing of not working full-time makes you optimize in very different ways. So I sprinkle my Slack check-ins all day, but I didn't have to work all day to be present all day. There's a lot that has been awesome. It's not for everyone, but I also have leaned heavily on technical mentorship happening from tech leads as well. CASEY: Sounds good. MAE: But I'm still involved. But this thing about management, especially in tech being whichever programmer seems like the most dominant programmer is probably going to be a good needs to be promoted into management. Just P.S. management is its own discipline, has its own trajectory and when I talk to hiring managers and they only care about my management experience in tech, which is 6 years, right? 8, but I have 25 years of experience in managing. So there's a preciousness of what it is that we are asking for the employees and what the employees are asking of the employer, like you were talking about Chelsea, that is very interesting. It's very privileged, and does lead a lot of people to burnout and disappointment because their ideas got so lofty. I just want to tie this back a little bit too, something you read in that quote about – I forget the last quote, but it was something about having enough to be able to change the world and it reminded me of Adrienne Maree Brown, pleasure activism, emergent strategy, and all of her work, and largely, generations of Black women have been saying, “Yo, you've got to take care [chuckles] of yourself to be able to affect change.” Those people have been the most effective and powerful change makers. So definitely, if you're curious about this topic, I urge you to go listen to some brilliant Black women about it. CASEY: We'll link that in the show notes, too. I think a lot about engineering managers and one way that doesn't come up a lot is you can get training for engineering managers to be stronger managers and for some reason, that is not usually an option people reach for. It could happen through HR, or it could happen if you have a training budget and you're a new EM, you could use your training budget to hire coaching from someone. I'm an example. But there's a ton of people out there that offer this kind of thing. If you don't learn the leadership skills when you switch roles, if you don't take time to learn those skills that are totally learnable, you're not going to have them and it's hard to apply them. There's a lot of pressure to magically know them now that you've switched hats. MAE: And how I don't understand why everyone in life doesn't have a therapist, [laughs] I don't understand why everyone in life doesn't have multiple job coaches at any time. Like why are we not sourcing more ideas and problem-solving strategies, and thinking we need to be the repository of how to handle X, Y, Z situation? CASEY: For some reason, a lot of people I've talked to think their manager is supposed to do that for them. Their manager is supposed to be their everything; their boss. They think the boss that if they're bad, you quit your job. If they're good, you'll stay. That boss ends up being their career coach for people, unless they're a bad career coach and then you're just stuck. Because we expect it so strongly and that is an assumption I want everyone listening to question. Do you need your manager at work to be that person for you? If they are, that's great. You're very fortunate. If not, how can you find someone? Someone in the community, a friend, family member, a professional coach, there's other options, other mentors in the company. You don't have to depend on that manager who doesn't have time for you to give you that kind of support. CHELSEA: So to that end, my thinking around management and mentorship changed about the time I hit – hmm. It was a while ago now, I don't know, maybe 6 years as a programmer, or something like that. Because before that, I was very bought into this idea that your manager is your mentor and all these types of things. There was something that I realized. There were two things that I realized. The first one was that, for me, most of my managers were not well set up to be mentors to me and this is why. Well, the truth is I level up quickly and for many people who are managers in a tech organization, they were technologists for 3 to 5 years before they became managers. They were often early enough in their career that they didn't necessarily know what management entailed, or whether they should say no based on what they were interested in. Many managers in tech figure out what the job is and then try to find as many surreptitious ways as possible to get back into the code. MAE: Yeah. CHELSEA: Additionally, many of those managers feel somewhat insecure about their weakening connection to the code base of the company that they manage. MAE: Yeah. CHELSEA: And so it can be an emotionally fraught experience for them to be mentor to someone whose knowledge of the code base that they are no longer in makes them feel insecure. So I learned that the most effective mentors for me – well, I learned something about the most effective mentors for me and I learned something of the most effective managers for me. I learned that the most effective managers for me either got way out ahead of me experience wise before they became managers, I mean 10 years, 15 years, 20 years, because those are not people who got promoted to management because they didn't know to say no. Those are people who got promoted to management after they got tired of writing code and they no longer staked their self-image on whether they're better coders than the people that they manage. That's very, very important. The other type of person who was a good manager for me was somebody who had never been a software engineer and there are two reasons for that. First of all, they trended higher on raw management experience. Second of all, they were not comparing their technical skillset to my technical skillset in a competitive capacity and that made them better managers for me, honestly. It made things much, much easier. And then in terms of mentors, I found that I had a lot more luck going outside of the organization I was working for mentors and that's again, for two reasons. The first one is that a lot of people, as they gain experience, go indie. Just a lot of people, like all kinds. Some of my sort of most trusted mentors. Avdi Grimm is somebody I've learned a lot from, indie effectively at this point. GeePawHill, like I mentioned, indie effectively at this point. Kenneth Mayer, indie effectively at this point. And these are all people who had decades of experience and the particular style of programming that I was doing very early in my career for many years. So that's the first reason. And then the second reason is that at your job, it is in your interest to succeed at everything you try—at most jobs. And jobs will tell you it's okay to fail. Jobs will tell you it's okay to like whatever, not be good at things and to be learning. But because if I'm drawing a paycheck from an organization, I do not feel comfortable not being good at the thing that I am drawing the paycheck for. MAE: Same. CHELSEA: And honestly, even if they say that that's the case, when the push comes to shove and there's a deadline, they don't actually want you to be bad at things. Come on! That doesn't make any sense. But I've been able to find ambitious projects that I can contribute to not for pay and in those situations, I'm much more comfortable failing because I can be like, “You know what, if they don't like my work, they can have all their money back.” And I work on a couple projects like that right now where I get to work with very experienced programmers on projects that are interesting and challenging, and a lot of times, I just absolutely eat dirt. My first PR doesn't work and I don't know what's wrong and the whole description is like somebody please help and I don't feel comfortable doing that on – if I had to do it at work, I would do it, but I'm not comfortable doing it. I firmly believe that for people to accelerate their learning to their full capacity for accelerating their learning, they must place themselves in situations where they not only might fail, but it's pretty likely. Because that's what's stretching your capacity to the degree that you need to get better and that's just not a comfortable situation for somewhere that you depend on to make a living. And that ended up being, I ended up approaching my management and my mentorship as effectively mutually exclusive things and it ended up working out really well for me. At this particular point in time, I happened to have a manager who happened to get way out ahead of me technically, and is willing to review PRs and so, that's very nice. But it's a nice-to-have. It's not something that I expect of a manager and it's ended up making me much more happy and manage relationships. MAE: I agree with all of that. So well said, Chelsea. CHELSEA: I try, I try. [laughs] Casey, are there things that you look for specifically in a manager? CASEY: Hmm. I guess for that question, I want to take the perspective inward, into myself. What do I need support on and who can I get that from? And this is true as also an independent worker as a consultant freelancer, too. I need support for when things are hard and I can be validated from people who have similar experiences, that kind of like emotional support. I need technical support and skills, like the sales I don't have yet and I have support for that, thank goodness. Individuals, I need ideally communities and individuals, both. They're both really important to me and some of these could be in a manager, but lately, I'm my own manager and I can be none of those things, really. I'm myself. I can't do this external support for myself. Even when I'm typing into a spreadsheet and the computer's trying to be a mirror, it's not as good as talking to another person. Another perspective that I need support on is how do I know what I'm doing is important and so, I do use spreadsheets as a mirror for that a lot of the time for myself. Like this impact is having this kind of magnitude of impact on this many people and then that calculates to this thing, maybe. Does that match my gut? That's literally what I want to know, too. The numbers aren't telling me, but talking to other people about impact on their projects really kind of solidifies that for me. And it's not always the client directly. It could be someone else who sees the impact I'm having on a client. Kind of like the manager, I don't want to expect clients to tell me the impact I'm having. In fact, for business reasons, I should know what the impact is myself, to tell them, to upsell them and continue it going anyway. So it really helps me to have peers to talk through about impact. Like that, too types of support. What other kinds of support do you need as consultants that I didn't just cover? MAE: I still need – and I have [laughs] hired Casey to help me. I still need a way to explain what it is that I am offering and what the value of that really is in a way that is clear and succinct. Every time I've gone to make a website, or a list of what it is that I offer, I end up in the hundreds of bullet points [laughs] and I just don't – [overtalk] CASEY: Yeah, yeah. MAE: Have a way to capture it yet. So often when people go indie, they do have a unique idea, a unique offering so finding a way to summarize what that is can be really challenging. I loved hearing you two when you were talking about knowing what kinds of work you want to do and who your ideal customer is. Those are things I have a clearer sense of, but how to make that connection is still a little bit of a gap for me. But you reminded me in that and I just want to mention here this book, The Pumpkin Plan, like a very bro business book situation, [chuckles] but what is in there is so good. I don't want to give it away and also, open up another topic [laughs] that I'll talk too long about. So I won't go into it right now, but definitely recommend it. One of the things is how to call your client list and figure out what is the most optimal situation that's going to lead toward the most impact for everybody. CASEY: One of the things I think back to a lot is user research and how can we apply that this business discovery process. I basically used the same techniques that were in my human computer interaction class I took 10, or 15 years ago. Like asking open ended questions, trying to get them to say what their problems are, remembering how they said it in their own words and saying it back to them—that's a big, big step. But then there's a whole lot of techniques I didn't learn from human computer interaction, that are sales techniques, and my favorite resource for that so far is called SPIN selling where SPIN is an acronym and it sounds like a wonky technique that wouldn't work because it's just like a random technique to pull out. I don't know, but it's not. This book is based on studies and it shows what you need to do to make big ticket sales go through, which is very different than selling those plastic things with the poppy bubbles in the mall stand in the middle of the hallway. Those low-key things they can manipulate people into buying and people aren't going to return it probably. But big-ticket things need a different approach than traditional sales and marketing knowledge and I really like the ideas in SPIN selling. I don't want to go into them today. We'll talk about it later. But those are two of the perspectives I bring to this kind of problem, user research and the SPIN selling techniques. I want to share what my ideal client would be. I think that's interesting, too. So I really want to help companies be happier and more effective. I want to help the employees be happier and more effective, and that has the impact on the users of the company, or whoever their clients are. It definitely impacts that, which makes it a thing I can sell, thankfully. So an organization usually knows when they're not the most happy, or the most effective. They know it, but my ideal client isn't just one that knows that, but they also have leadership buy-in; they have some leader who really cares and can advocate for making it better and they just don't know how. They don't have enough resources to make it happen in their org. Maybe they have, or don't have experience with it, but they need support. That's where I come in and then my impact really is on the employees. I want to help the employees be happier and more effective. That's the direct impact I want, and then it has the really strong, indirect impact on the business outcomes. So in that vein, I'm willing to help even large tech companies because if I can help their employees be happier, that is a positive impact. Even if I don't care about large tech companies' [chuckles] business outcomes, I'm okay with that because my focus is specifically on the employees. That's different than a lot of people I talk to; they really just want to support like nonprofit type, stronger impact of the mission and that totally makes sense to me, too. MAE: Also, it is possible to have a large and ever growing equitably run company. It is possible. I do want to contribute toward that existing in the world and as much as there's focus on what the ultimate looking out impact is, I care about the experience of employees and individuals on the way to get there. I'm not a utilitarian thinker. CASEY: Yeah, but we can even frame it in a utilitarian way if we need to. If we're like a stakeholder presentation, if someone leaves the company and it takes six months to replace them and their work is in the meantime off board to other people, what's the financial impact of all that. I saw a paper about it. Maybe I can dig it up and I'll link to it. It's like to replace a person in tech it costs a $100K. So if they can hire a consultant for less than a $100K to save one person from leaving, it pays for itself. If that number is right, or whatever. Maybe it was ten employees for that number. The paper will say much better than I will. CHELSEA: I think that in mentioning that Casey, you bring up something that businesses I think sometimes don't think about, which is some of the hidden costs that can easily be difficult to predict, or difficult to measure those kinds of things. One of the hidden costs is the turnover costs is the churn cost because there's how much it takes to hire another person and then there's the amount of ramp time before that person gets to where the person who left was. CASEY: Right, right, right. CHELSEA: And that's also a thing. There's all the time that developers are spending on forensic software analysis in order to find out all of the context that got dropped when a person left. CASEY: Yeah. The one person who knew that part of the code base, the last one is gone, uh oh. CHELSEA: Right. CASEY: It's a huge trust. And then engineering team is often really interested in conveying that risk. But if they're not empowered enough and don't have enough bandwidth time and energy to make the case, the executive team, or whoever will never hear it and they won't be able to safeguard against it. MAE: Or using the right language to communicate it. CASEY: Right, right. And that's its own skill. That's trainable, too thankfully. But we don't usually train engineers in that, traditionally. Engineers don't receive that training unless they go out of their way for it. PMs and designers, too, honestly. Like the stakeholder communication, everybody can work on. MAE: Yeah. CASEY: That's true. MAE: Communication. Everyone can, or not. Yes. [laughs] I learned the phrase indie today. I have never heard it and I really like it! It makes me feel cool inside and so love and – [overtalk] CASEY: Yeah, I have no record label, or I am my own record label, perhaps. MAE: Yo! CASEY: I've got one. I like the idea of having a Patreon, not to make money, but to have to help inspire yourself and I know a lot of friends have had Patreons with low income from it and they were actually upset about it. So I want to go back to those friends and say, “Look, this prove some people find value in what you're doing.” Like the social impact. I might make my own even. Thank you. MAE: I know I might do it too. It's good. That's good. CHELSEA: Absolutely. Highly recommended. One thing that I want to take away is the exercise, Casey, that you were talking about of tallying up all of the different things that a given position contributes in terms of a person's needs. Because I think that an exercise like that would be extremely helpful for, for example, some of my students who are getting their very first tech jobs. Students receive a very one-dimensional message about the way that tech employment goes. It tends to put set of five companies that show remain unnamed front and center, which whatever, but I would like them to be aware of the other options. And there is a very particular way of gauging the value of a tech position that I believe includes fewer dimensions than people should probably consider for the health of their career long-term and not only the health of their career, but also their health in their career. CASEY: One more parting thought I want to share for anyone is you need support for your career growth, for your happiness. If you're going to be a consultant, you need support for that. Find support in individuals and communities, you deserve that support and you can be that support for the people who are supporting you! It can be mutual. They need that, too.

Catch Dave on Episode 006 of Greater Than Code! Getting Technology Into the Hands of Children with David Bock (https://www.greaterthancode.com/getting-technology-into-the-hands-of-children) 02:10 - Dave's Superpower: Ability to Reevaluate and Drop Ideas – Onto The Next! * Star Trek: The Next Generation (https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation) * Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 07:10 - The Acceptance of Ruby; Using Ruby as a Teaching Language * Teaching Ruby Makes Approaching Computer Science Approachable * Intro To Programming Skill Tree.md (https://gist.github.com/caseywatts/93cba34cd882a05b3107) * Computational Thinking (https://en.wikipedia.org/wiki/Computational_thinking) * Object-Oriented Programming (https://en.wikipedia.org/wiki/Object-oriented_programming) * Functional Programming (https://en.wikipedia.org/wiki/Functional_programming#:~:text=In%20computer%20science%2C%20functional%20programming,by%20applying%20and%20composing%20functions.&text=When%20a%20pure%20function%20is,state%20or%20other%20side%20effects.) * Primer on Python Decorators (https://realpython.com/primer-on-python-decorators/) 18:01 - Mobile Development * Accessibility * FingerWorks (https://en.wikipedia.org/wiki/FingerWorks) * Teaching Performance; Linear Algebra (https://en.wikipedia.org/wiki/Linear_algebra) * Star 26 Math Puzzle (https://www.puzzlemaster.ca/browse/wood/otherwood/12292-star-26-math-puzzle) * Aristotle Number Puzzle (https://www.amazon.com/s?k=aristottles+number+puzzle&ref=nb_sb_noss_2) 24:10 - Teaching Remotely * WatchDOG Dads (https://www.pickerington.k12.oh.us/violet-elementary/watch-dog-dads/) * Cameras On/Off * % of Women Went Up / Gatekeeping and Gender Bias * Grace Hopper (https://en.wikipedia.org/wiki/Grace_Hopper) 34:25 - Computer Science Education Week (https://www.csedweek.org/) + Teaching/Volunteering * Hour of Code (https://hourofcode.com/) * Code.org (https://code.org/) * Scratch (https://scratch.mit.edu/) “Computers aren't smart. They're just dumb really, really fast.” Understanding the Pareto Principle (The 80/20 Rule) (https://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/) Zero: The Biography of a Dangerous Idea (https://www.amazon.com/Zero-Biography-Dangerous-Charles-Seife/dp/0140296476) Plimpton 322 (https://en.wikipedia.org/wiki/Plimpton_322) 56:39 - Handling Time Management and Energy * Ted Lasso (https://en.wikipedia.org/wiki/Ted_Lasso) * Getting Positive by Looking at the Negative Reflections: Casey: Motivating students to learn algorithmic efficiency. Feeling the problem. Mae: Becoming more involved in the community. Chelsea: What are people in the tech world ready for? Dave: How much talking about computer science education is invigorating and revitalizing. Seeing problems through beginners' eyes. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Special Guest: Dave Bock.

Some of you may recognize Chelsea Troy from her popular blog of the same name or as a keynote speaker for the March 2021 Code BEAM conference. Chelsea is an instructor in the Master's Program in Computer Science at the University of Chicago and currently works as a staff software engineer at Mozilla, where she specializes in machine learning and backend systems. In our conversation with Chelsea, we discuss some of the unique aspects of coding as a career. Chelsea outlines how programming can be more accessible than other careers because it doesn't have the same financial burden when it comes to education. She also emphasizes the importance of allowing a more diverse range of people access to the field and unpacks the type of person the internet was originally built for, explaining how it had favored privileged affluent individuals from the Bay Area. We hear from Chelsea about how she became a programmer out of a desire for job security rather than passion and why she believes it's so important to have a broader representation of different narratives when it comes to careers in programming and coding. Later Chelsea shares the story of how she became an educator and why she is so passionate about teaching. For all this and much more, join us today! Key Points From This Episode: Introducing today's guest Chelsea Troy Why Chelsea believes it's important to privilege multiple narratives of why people choose to pursue programming as a career. There is less of a financial burden with becoming a programmer than other higher-paying professions. The benefits of a diverse group of people having access to programming as a career. What first prompted Chelsea to start her blog and how her goals for it have changed over time. Why Chelsea struggles to give advice on how to market a blog. How being able to draw parallels between different coding languages has strengthened Chelsea's teaching and writing pursuits. Why Chelsea is so enthusiastic about teaching. How teaching allows Chelsea to have a more meaningful impact in the field of tech. How Chelsea prioritizes which jobs and clients to pursue as a consultant. How having two parents who taught for living influenced Chelsea's passion for teaching. Chelsea shares how she earned her position at Chicago University, despite expecting not to. The challenges and benefits of teaching remotely. The pros and cons of functional languages versus object-oriented languages. How students tend to react to learning functional languages versus object-oriented languages. Mini-feature segment: hear from Rosemary about how she became a software engineer. How Rosemary built websites as a side hustle while studying English. Rosemary shares how she transitioned from working with Java and Blu-ray discs to doing back-end web development and writing in Elixir. How RentPath, the company Rosemary is currently working for, is transitioning from Ruby to Elixir. An outline of RentPath and what they do. Rosemary's many hobbies and pursuits, including wildlife photography. Links Mentioned in Today's Episode: Chelsea Troy on Twitter — https://twitter.com/HeyChelseaTroy Chelsea Troy on LinkedIn — https://www.linkedin.com/in/chelseatroy/ Chelsea Troy Blog — https://chelseatroy.com/ Upcoming Code BEAM Conferences — https://codesync.global/ Chelsea Troy on Youtube — https://www.youtube.com/channel/UCIwpdjmSUJmqJ8HwvIGNqig Ruby — https://www.ruby-lang.org/en/ Mozilla — mozilla.org/en-US/ Pocket — https://getpocket.com/ Rosemary Ledesma — https://www.linkedin.com/in/rosemary-ledesma-b6198717/ RentPath — https://www.rentpath.com/ RedFin — https://www.redfin.com/ Special Guest: Chelsea Troy.

On this week's episode, Steph and Chris are joined by fellow thoughtbotter, Joël Quenneville, to discuss all things debugging. Joël is helping publish a weekly debugging blog series and in this conversation they discuss how the series got started, technology agnostic debugging strategies, writing less bug-prone software, and speculate if Joël moonlights as a hockey coach. Debugging Blog Series 2021 (https://thoughtbot.com/blog/tags/debugging-series-2021) Classical Reasoning and Debugging (https://thoughtbot.com/blog/classical-reasoning-and-debugging) Monodraw (https://monodraw.helftone.com/) An Elm debugging story (https://thoughtbot.com/blog/elm-debugging-story) Chelsea Troy - PoSD 2: What causes insidious bugs? (https://chelseatroy.com/2019/12/30/posd-2-what-causes-insidious-bugs/) Follow Joël Quenneville on Twitter (https://twitter.com/joelquen) Joël Quenneville on the thoughtbot blog post (https://thoughtbot.com/blog/authors/joel-quenneville) Transcript: STEPH: All right. And then who will be editing this episode will be Mandy. So as we run into blunders, which we never do, but if we do, then we can talk to Mandy and ask her to edit things for us. So I will try very hard to do that because I will likely still talk to Thom. [chuckles] CHRIS: Hello, Mandy. It is a pleasure to meet you. In the last recording that will be going through you, I was referring to you indirectly as our next producer. But now that we know your name, I'm so excited to have you on the team and to know who is on the other side of these, hopefully not too nonsensical recordings. So pleasure to meet you. 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. So, hey Chris, today is an extra special day as we have a guest today. Joining us is Joël Quenneville, a thoughtbot developer extraordinaire and a previous Bike Shed guest. Welcome, Joël! JOËL: Hi. CHRIS: It's a pleasure to have you. JOËL: It's good to be on the show. STEPH: So, Joël, you and I are on the same client project. And during the past few weeks, we have encountered some very challenging bugs. In fact, if I look back at my developer journal, the last five or so of my entries begin with a very cheesy mystery title that's like the case of the missing data or Harry Potter and the chamber of errors. But in addition to spending your time bug hunting with me on this project, I understand that you and other thoughtboters, Jesse Bailey and Louis Antonopoulos, have been publishing weekly blog posts specifically about debugging. JOËL: Yes, that's correct. This has been a project that we've been doing for a little while. We spent about three months doing research, conducting a bunch of interviews, and gathering a lot of material on debugging. And then, starting in April and through the middle of the summer, we are publishing an article every week on the topic of debugging and exploring different aspects of it. STEPH: I'm really curious; what prompted y'all to start talking about debugging? I'm really excited to talk about the specific topics that are included in the series. And then also you mentioned all the research. I'd love to know how you went about that research. But before we go there, what prompted this conversation and then led to the creation of the series? JOËL: Within thoughtbot, we spend a lot of time trying to improve ourselves, improve the broader community as well. And there was a conversation that got started about how we could get better at debugging. It's a thing that, as developers, we do all the time, and it's not something that's often taught explicitly. Many of us our experience with debugging has been very much just learning on the job and picking it up by osmosis and trial and error. And when you're more junior, a lot of that is just random stuff and changing random lines of code and maybe copying something from the internet and hoping things go well. And as you build experience, you tend to start becoming a little bit more methodical because you've seen what works and what doesn't. And so we wondered within thoughtbot, we have all these different people who've come up with their own experience. Can we meld that together and share the summary of all thoughtbot debugging knowledge combined and help everybody level up? Initially, we were wondering could this be just an internal workshop or something where we get together and exchange on the different ways that we've learned or different techniques that each of us uses? But then this evolved into a project that we wanted to share not just within thoughtbot but with the wider world. And so its final form, or at least its current form, has been a blog post series that's going to run over the course of three to four months. STEPH: I appreciate how you've taken the opportunity to take all of this knowledge and then turn it outward-facing, so it's available to the public as well. And it really wasn't until you were talking about the series and then I started reading the weekly blog posts that are being published how little I read about concrete strategies around debugging. I think you said it very well earlier in terms of it as something that you pick up on the job, and you learn different strategies as you go. It's really hard to know exactly how to go about debugging unless you've had experience with that type of bug before. CHRIS: I've been also reading the blog posts as they come out. And I'm similarly very grateful for both the general theme of thoughtbot of hey, let's take this thing and actually make it a shared resource for the world. But specific to debugging, it really is this interesting intersection of practical steps that you can take but also almost an art form. There's like, oh, I use Pry, and I put a debugger statement here, and that's a mechanical approach that we have. But then there's also the more general how do I think about code, and how do I build a model in my head and compare that to the thing that's running on my screen? And that is really so much more something that you learn in passing, or at least it typically is. And this idea of trying to be a little more purposeful and share more of that with the world is something that I absolutely love because it is both the harder aspects of the job but also probably one of the more common. I'm spending a lot of time being like, why isn't that working the way that I thought it would? I don't know, maybe 90% of my time as a developer, maybe I'm a bad developer, but it's so much of the time that I spend. And so any amount that I can get better at this or learn from others, I'm super open to that. So thank you for producing this and for sharing all the secrets. JOËL: I liked your example of saying you drop in and you drop Pry to put a debugger at a particular location. And I think that maybe that's something that most people are familiar with and might use. But even something like that sounds like a fairly simple, basic concept. I think someone with a lot of experience, if you're pairing with them, you might ask, "Why did you put the Pry here and not there?" And that might make the difference between spending all day versus spending half an hour to find the bug. And that's, I think, a lot of where the experience comes in and where being a little bit more structured, having a strategy can really make the difference in being efficient. Because oftentimes, you're using the same tools and doing roughly the same techniques, but one can be totally flailing and doing random stuff, hoping you'll get lucky with a solution. And the other one is very methodically working towards finding the problem. CHRIS: I love that framing of the question, but I also love the idea of you ask that to someone, and they're like, "Huh? I don't actually know. But now that I think about it…" and then they sort of discover the answer. But it's very much they're operating from intuition and just like, well, obviously I put the debugger right before the line that I think has this going on. But that's not necessarily something that's top of mind. So when you ask the question, you almost help them to formalize it. So yeah, there's gold in those hills. JOËL: Absolutely. Definitely. I think gaining self-awareness about why you do what you do is always such a rich exercise, at least in my experience. STEPH: There's an interesting comparison here where people will ask me how to do something in Vim. And I'm like, oh, let me do it first because I need the muscle memory for it, and then I can tell you how to do it. And I feel like debugging is often the same way where I'm like, well, let me hear about the problem, and then I can work through it with you, but I can't necessarily tell you off the top of my head all the different strategies that I would apply. So I really liked the idea of becoming more self-aware as to how you would approach that so then you can provide those tips to someone else. You mentioned earlier about the research for creating the series, and I'd love to hear more about that. Because I imagine there's so much that you could talk about in terms of debugging but then still wanting it to be helpful to people that are working in different technologies. So how did that research go? What did that look like? JOËL: Initially, this was focused on experience within thoughtbot. So we focused a lot on more internal research. We had a survey where people just shared their debugging thoughts, tips, and tricks. And then, we also set up a bunch of interviews with multiple thoughtboters across varying levels of experience to get their thoughts on debugging, and that was incredibly rich. So we did, I think, 10 or 12 interviews within the company. We captured all of that and then synthesized the output of those interviews, the survey with all of the random tips and tricks, existing thoughtbot blog content. And then, we also pulled some external resources that we had found as well as some podcasts, some other blog posts elsewhere. And we have tried to mix all of that together to come up with 10 or 12 high-level topics that we thought were particularly valuable to talk about and then turn those into blog posts. STEPH: That's really awesome. I love how you took that approach of interviewing different people to take that instinctual knowledge that we have around how we're debugging but then helping people put that into words and then capturing that and then sharing it. What type of questions did you ask people to help people walk through what are their debugging strategies? JOËL: That was actually pretty fun because we came up with a list of questions ahead of time, not that it was a strict list to be adhered to, but we wanted to have something to have a little bit of commonality between the interviews and then let them go where they will. Most of them we opened up with just asking people, "What does the word debugging make you feel?" What is your personal connection to debugging?" And I expected most people to be like, "Oh, dread or frustration," And that was not the case. Most people said, "Actually, I like debugging. It's a challenge. It's a puzzle. It appeals to the analytical side of me." One person mentioned that it's like the code equivalent of an escape room and that escape rooms are one of their favorite things, and so they actually really enjoyed it. Where a lot of the frustration comes in is when you have deadlines, and this bug is unexpected and therefore is taking time away from things you really need to be doing now or yesterday. And so the timeline can cause pressure, but the bug itself most people seem to enjoy finding the bug. STEPH: I love so much that you just used the comparison of an escape room because I was just chatting with someone recently about how my week has been going, and I'm like, I am in an escape room. That is my job this week is to figure out how to get out of this or to understand what is happening in the system. So that's really funny. That's also very encouraging to hear that so many people have a positive association with debugging. But I certainly understand that it's more the deadline, the timeline that is then putting pressure on us to solve something quickly, but we actually enjoy the hunt is what it sounds like. CHRIS: And in my experience, when it goes well, it can be really fun. But then there are those days where not just under deadline pressure but just sort of I lost a day to blah. I couldn't figure out what was going on. And especially when it turns out to be something relatively simple, that feeling is somewhat crushing. But when there's this like, oh no, things are not working the way I expect it, and then I'm able to dig in, read a bunch of Stack Overflow, put a bunch of debug or put statements and crack that, that is a fantastic feeling. And there is the optimum flow level of where it's just at the edge of your knowledge and skill set, and it doesn't take too long, but it's not too easy. Because, like you said, the thrill of the hunt is there. So there is a sweet spot, I think, and there are ways that it can go wrong on either side. But I definitely resonate with the idea that a medium-scale bug that I'm able to tackle that's a good day, actually. I feel good at the end of that day. STEPH: There's a delightful blog post by Chelsea Troy where they share a graph that talks about the time spent debugging versus the probability of a one-line fix. And so the more hours that you've invested into fixing a bug -- Joël, I think I found this particular blog post thanks to the Debugging Series. It's like two in one of those posts. And so the more hours that you sink in finding a bug, the more likely that it's going to be just a one-line fix. And those are the ones that feel the most painful to me. It's something that is small and comes down to an incorrect assumption about the system. And those are the ones that feel good that I solved it, but I didn't really enjoy the hunt for that one. There's a specific time window in which I'm enjoying myself, which then just becomes stressful and frustrating. JOËL: Sometimes, it almost feels like the number of lines of code for the solution needs to match the amount of effort it took to find the bug. And so if I spend a day searching for the bug, it's frustrating that it's only one line and that the solution took 30 seconds, but the search took eight hours. CHRIS: I think my measure would be the length of the commit message associated. I'm fine with a one-line change as long as there is a couple of paragraphs of explanation of the journey that I went on and not just self-serving like, hey everyone, listen, because this was rough for me. But the look at all the things I learned, let me capture that knowledge here because there's actually a bunch that this one code line change encapsulates. But it's actually looking at the history of HTTP and the way that the different headers are handled in different browsers and, for many reasons, this one-line change. But if it's a one-line change and the commit message is like, "Oh, typo, sorry," then I feel bad. That's a bad day for me. [chuckles] JOËL: This reminds me of the project, Steph, that you and I are on where I've definitely had several bugs that I've gone through to fix where the commit message is definitely quite a bit longer than the actual diff. And the commit message includes ASCII diagrams showing the structure of certain database tables and why I had to change a particular query. And it's weird. And you would never understand why without realizing the schema. So yeah, I definitely feel you there, Chris, where sometimes you go on a journey, and it's very important to record that for the next person. STEPH: Yeah, your commit messages have been phenomenal. And I love all the diagrams that you've included because that has helped me have context for what exactly you understand about the system and what appears to be wrong with the system. That has been wonderful. Speaking along those lines, as we were just talking about how it can feel very ephemeral in terms of the strategies that we use for debugging, I'm really curious what strategies do y'all use for debugging? Do you have particular tools that you use? I know Joël, you are a fan of diagrams. Is there a particular tool that you use for that? JOËL: There's a variety of tools that I'll use. Recently I've been using Monodraw, which is a tool for macOS that allows you to make diagrams that can be exported as text using various ASCII characters, which means that you can then draw an entity-relationship diagram of your database and include that in a commit message where it needs to be text. You can also export it as an image. But the fact that I can use it as text in a commit message has made it particularly valuable recently. So that's my latest go-to diagramming tool. STEPH: That's really nice. I haven't used that, but I've been seeing you use it so extensively that I've added it to my list of things to check out very soon. Are there any other particular strategies that you use, since we're on the topic of concrete strategies, for debugging and how you approach debugging? JOËL: I am a big fan of binary search, which sounds like a fancy computer science term. But I think from a very practical standpoint; it's just a process of elimination. Sometimes finding where the bug is, is harder than where it's not. And so can I eliminate roughly half of this file or this project or whatever and know that it's not a concern and then keep repeating that until I have a pretty small surface area to actually find the bug itself. And this can be as simple as just commenting out lines of code. And so, like, I'm going to comment out roughly half the lines in this method and see can I still reproduce the bug? If so, then I know it's in the ones that haven't been commented repeat, repeat until I find the bug. And because you remove so much code every time that you have, it takes relatively few steps until you find a very narrow area in which the bug likely is. CHRIS: I love that. Binary search is definitely one of my favorite approaches. And I think that was a very welcoming and friendly introduction to the topic for anyone that might not be familiar. But it really is such a simple and yet effective tool for narrowing down the scope. Because when you look at an entire application, you're like, ah, something's wrong, and you start from the outside, that's overwhelming. But if you can start to narrow it down, especially, like you said, in this more methodical, purposeful approach, that is really wonderful. I think one of the tactics that I have been reaching for more and more is using minimal reproduction cases. So rather than actually working in the context of the full application -- This is especially true if I'm working on, say, a JavaScript app or Svelte is the most recent example. Svelte has a REPL on the svelte.dev website. And I find myself more and more reaching for that and just trying to very minimally reproduce code that just isolates that bug. And then I try and tease away the pieces, but now I'm left with this minimal reproduction there in an executable format, and that ends up being really useful. The same sort of thing if I'm on the Ruby side, I might actually do in a Spec just because that's a really nice way to harness execution and be like, I want to do these things. Here's the setup. And it's one of the reasons we love Specs, but I find it's actually a really great tool for setting up some data, executing the app in a certain way, and then testing it. And I find particularly with RSpec and Rails; I feel like I have good control over getting the system into a certain shape. Other applications I find that's a little more difficult, so other techniques may be necessary. But yeah, that's definitely one of the things that I've been leaning on more and more is minimal reproduction so that I can really narrow down the scope of what I'm looking at. JOËL: I like that example, Chris. And that actually is a variant of probably one of my favorite approaches, which is reasoning by analogy. So you have a hard problem, and you can't figure out a way to solve it. So you find a similar easy problem, find the solution to that, and then try to backport the solution to your hard problem. Oftentimes, the easy problem is just a simplified version of your hard problem, such as stripping out all the unnecessary detail, then you can backport that. But sometimes, it's just something in a different domain that you understand more easily, and then you can take that solution and backport it. And I had a magical experience a while back. For those of you who know me, I'm a big fan of the Elm language. And I spend a lot of time in their Slack just helping out people. And someone ran into a situation with random generators, which are a concept in that language that can generate random values. And they're trying to combine a bunch of them and having really weird bugs. And I tried a bunch of different techniques to figure out what was going on, and I couldn't figure it out. But the thing that I did figure out is that random generators in this particular dimension we were trying to understand work very similarly to functions, which are a much more simple concept. And the moment I realized, oh, in this very particular way, generators and functions are the same, all of a sudden, that unlocked in my mind; wait, I can reason by analogy here because I know how to solve this problem with functions. I don't know how to solve it with random generators. So I went and solved it by saying, "I don't know how to compose a bunch of generators. I do know how to compose a bunch of functions, figure that out and then take that solution and bring it back to generators." And I followed that process through, and it worked, and it was amazing. I came in to work the next day, and I was really excited about this. And I was talking with some colleagues, and everyone's like, "You should write about that." So there's a blog post from a year or two ago where I walked through my whole process and all the different debugging strategies I used, including reasoning by analogy to solve what was a pretty tricky bug. STEPH: I love how the typical response from talking to a thoughtboter about going through something like that is often, "Oh, you should write about it." CHRIS: And I'll help you edit it, not just "Please go write that." And Joël, you live that to the extreme. You have been an absolutely prolific author on the thoughtbot blog. And you bring some of the images and things like that that you're talking about. You really, I think, provide such a great example of paying knowledge forward and sharing better. So if anyone wants to learn about blogging on the internet, just go follow Joël's, work for a while, and you'll learn some great things. STEPH: Yeah, that is so true. I love how much you publish, and I'm a big fan of everything that you write. One of the debugging strategies that was mentioned in the blog post that really rang true for me was talking about identifying assumptions because that is one that I typically fall into where I will read about a problem, and then I will say, "Okay, I understand exactly what problem they're running into." And once I start troubleshooting, if I'm unable to reproduce -- Because I follow a similar strategy, Chris, that you just mentioned where I will try to replicate the issue either if I'm doing it locally or ideally if I'm writing a test, so then I can write a test that fails and then I can then make that test pass. But if I'm unable to reproduce, then I'm forced to go back and say, "Okay, am I making an incorrect assumption about what's being reported?" And that has been so helpful. Like, there are just little things where I realize I'm on autopilot for where it's like, the user downloads a report, and I'm like, oh well, they mean this report. And then I find out that they actually meant something else. Also, assumptions in the codebase, and that's one that you and I, Joël, have run into so much with this past week in regards to assumptions in the codebase as to how many associations a record can have. Is it one? Is it many? It has many, but it really only wants one record. So assumptions from the perspective of when someone is reporting an issue and then also assumptions in the codebase. For the first one, I have found that, especially when I'm new to a team when someone reports an issue, I often like to hop on a quick call with them and say, "Hey, are you able to reproduce this for me? And so I can watch you, and I can understand your workflow." And I have found that typically speeds me up drastically. JOËL: One of the things that was mentioned in the article on listing assumptions which is maybe a bold claim, but it opens by saying that all bugs are a form of miscommunication. And this might be human-to-human communication where you didn't understand the requirements or what was trying to be done. But code is also communication between us and computers. We want computers to do a thing. And if the computer doesn't do what we're telling it to, it's not doing that just to show us who's boss; it's because we didn't communicate correctly what we wanted. And so yeah, trying to better understand ourselves what we mean and our assumptions is a key part of debugging. And that's the thing that came up over and over and over in all the interviews was one, build self-awareness about the assumptions you have, and there's a bunch of different techniques for doing that. And then once you have self-awareness of what your assumptions are, never trust anything, validate, validate, validate, because yeah, you're often wrong. CHRIS: There's an interesting parallel to that in my mind of we often end up with these systems, and it's behaving in an odd way. And so we have to build this mental map of okay; what are all of the different states and workflows that can get us into those various states? And having now debugged a handful of times in my life, I'm trying as much as possible to flip the script and go with an ounce of prevention is worth a pound of cure. And this is why one of the most common things that I say in a pull request is, "Hey, can we make that null false on that new database column? Hey, can we change this type constraint so that instead of it being a Boolean and then another attribute, it's actually a three-state enum?" and et cetera, et cetera. How can I collapse the states down so that when I'm in debugging mode, I actually can take some things as givens? Still, maybe validate from time to time, but the more I can learn to trust a type system or the database or things like that, things that are a little more trustworthy than I am or other humans, I'm increasingly loving that. And there's obviously a gentle balance there, but that's something that I've been leaning into more and more. And I think it's directly informed by the years of my life that have gone into debugging at this point. Is that accurate? That seems like a high estimate, but it's a lot. It's a bunch of weeks at a minimum. JOËL: I felt that really strongly. I'm kind of disappointed as an industry that we default things to be nullable so often. I wish database columns were non-nullable by default, and you had to opt in to make them nullable. I wish GraphQL didn't make columns nullable by default. And I think oftentimes, when you're working in a dynamic language, you don't care about that distinction. And so you just let it go by. And let's say with GraphQL, again, I hang out a lot in the Elm Slack channel, and I spend a lot of time helping people integrate Elm in GraphQL. And when you get a schema and try to load that into Elm because it has a type system, it will read your schema and wrap everything in maybes because it's as though this field is optional, this thing is optional, this thing is optional. And then people come to the Slack, and they're like, "Why is there maybe everywhere with deeply nested -- This is a terrible mess in Elm. What went wrong?" And then I have to tell them, "It's not the Elm tool that's wrong. If your schema has this implicitly, the default thing was to make it null." And so it just looks normal, and you want to put all those exclamation marks everywhere. And a lot of time people don't believe me. And I have to say, "No, no, you're right. It really is the schema that's the problem. Please go put all these exclamation points." I'll give an example of a non-null schema, and then they try it, and they're like, "Wow, this makes such a difference." STEPH: Joël, the defender of Elm. JOËL: [laughs] STEPH: And I am with you, and it is interesting. And I've been there myself, too, where there's a fear of over-restriction in terms of if I make this not null and something blows up, then that feels like a bad outcome. And so I've seen a number of projects where we let nil get through so easily because then we just always handle the nil versus having that restriction earlier and making that decision. It's like we're pushing off that decision of like, well, that'd be nil for now, and then we'll figure it out later. Versus starting with that decision upfront and saying, "No, let's go ahead and make that decision now. What do we do if this is nil?" And I agree that it would be wonderful if we had more restriction upfront and then we loosened the requirements as we find out that we need to versus starting with the loose requirements because walking that backwards is incredibly difficult. JOËL: Yes, having to backfill nullable columns that we don't have values for in the database because now we want to restrict it, but for years we didn't collect that value. And so what do we do now? That becomes really tricky. STEPH: Chris, a minute ago, you were mentioning prevention, which I love so much because then we can avoid a number of these debugging discussions, although this is also delightful. But there's an opposite end of that spectrum that has taken me a while to gain comfort with, and it is when you don't know enough about the bug, and you can't reproduce, and then you essentially have to let it go. And there are other ways that you can debug, but you can't fix it in the moment. So let's say that you have an error or something that happens every once in a while, but you can't actually find the reasons that it's happening or if you have data that's getting created in a certain state, but you don't know what in your application is creating that state. So instead of spending what could be hours and days triaging how your system got in that state is instead perhaps adding some logging around it to say, "Hey, this is the moment where we are causing this to happen," or maybe it's adding a constraint, so something fails very loudly whenever the system tries to put data in a particular state. And in those cases, it took me a while to become comfortable with the idea that I can't solve this today. I can't solve it now, but I can take steps to then know how this is happening. So then, in the future, we can actually prevent this or apply the fix. But initially, that always felt like a really bad outcome for a ticket that's reporting a bug where it's like, hey, I can't fix this today. I don't know exactly what's happening, but I've added some logging, or I've added something that's going to raise when this happens. So when we do get notified of it again, then we can more quickly triage and put the right fix in. CHRIS: Yeah. If anything, I feel like there can be a -- Like we were talking about earlier, there's almost an enjoyment to solving a bug where it's a puzzle. It's a thing that may capture our attention, but sometimes, actually, perhaps often, the correct answer is that's actually not the most important thing right now, or the cost is too high to try and solve it given the information that we have. It's affecting a very small number of users. Maybe we can make that experience better. It's not just a generic 500-page, but we turn it into a, "Hey, sorry, you got into a…" like a more explicit error state but defer the actual debugging because there are other things that are slightly more pressing, affecting more users, or again, we just don't have enough information. And I feel like that actually can be a difficult thing to be like, no, but I want to solve the puzzle now. This is a fun puzzle. Please let me solve the puzzle. But sometimes, we don't get to solve the puzzle today. JOËL: One of the articles in our series that I'm really excited about takes a look at classical philosophy and various categories of reasoning identified in classical philosophy and how we can apply them to debugging to debug in a more strategic and methodical manner. And one of those categories is inductive reasoning, which is very similar to, say, the scientific method where you gather a lot of information. And then, based off of those cases, you try to come up with a pattern, have a hypothesis for it, test it. And then if you can show that it's actually the case, then you're likely correct. But of course, that depends on having enough test cases for there to actually be a pattern and for it to be statistically significant. And so for some bugs, if there's only one instance of it happening and you just say, oh, somehow a bad value made it from our front end UI into the database, and we don't know how. But it's not happening to every user. Like, there's only one use case, and we can't figure out how that happened. We don't have enough information to build up those test cases to try to find a pattern. And so that's where getting more test cases becomes really important. As Steph mentioned, logging can be really helpful here, raising whatever you need to do. Maybe it's adding a constraint or a validation to say, "Blow up the next time this happens." But once you have enough test cases, then you can start seeing patterns. And that's your inductive reasoning to solve the bug. STEPH: Something that we touched on earlier but I don't think I've given enough credit to but is something that I really appreciate is the fact that all of these strategies that are being talked about in each blog post are applicable across technology stacks, across languages. Because you really highlighted a point just a moment ago around how most of the bugs that we're working with are all bespoke. They're all special little bugs in their own special way. And so it's really hard to have a blanket strategy that then applies to each one because they are unique. And the fact that y'all are creating so much content that has general strategies that people can apply when debugging is really impressive to me. So I'm really curious how are y'all doing that? JOËL: When we came up with a series idea, we laid down a few principles for how we wanted the outcome to be. And one thing that came up pretty early was it's important for this to be language agnostic. We don't want to just teach like, here are some very specific Ruby tools you can use, which that's a very helpful article, but that's not really the kind of information that we were looking for. So we were trying to find what are some higher-level techniques and strategies that are usable throughout your career? And then secondly, we wanted to focus on finding bugs rather than how do you solve them or how do you prevent them? Chris mentioned a little bit earlier about techniques for preventing bugs from happening in the first place, and we might have a bonus episode or article on how to write bug-resistant code. But the focus of the series is what are some language agnostic ways that we can improve your search to find the root cause of a bug? And a lot of that has just been synthesis, so saying okay, here's a bunch of different things that different people told us. And we were fine with having language-specific examples in the interviews. But how can we then find what's common and what's not? One thing that I think was really interesting was talking how different people gain information about a particular point in code, and debuggers are a pretty common way of doing this. But print line debugging is also a really common way to do that. And every language does this slightly differently. And you can even do this, not just via text, but visually. So if you're writing CSS and you are trying to figure out when a particular rule triggers, you might put a 1-pixel red border around something. And that's CSS' equivalent to print here or console.log in JavaScript or Ruby or some other language. So the idea is to see all what different people told us and then see can we extract a general principle out of this? And walking a fine line between we want the theories to have practical advice for people that they can use but also zoom out just a little bit so that we have some of the big picture so that you can make some of these big connections and see some of the patterns that can help you apply in different situations that you run into for debugging without necessarily getting head in the clouds, you know, what is debugging? And I'm sure there's a really fascinating philosophy article, not the classical philosophy article I mentioned; that one's actually good. But you can philosophize about debugging in a way that's too abstract to be useful. So we want just a touch of the philosophy to keep it big picture while also giving very concrete, useful tips and techniques that are language agnostic that folks can use. STEPH: That's fabulous how y'all are able to separate that thought process away from the direct, specific action that someone takes. So when someone is dropping in that console.log statement or that print statement, it's like, okay, but what thought process took you there to the point that then you were trying that action? I really like that. There's one other trick that was mentioned in one of the articles that I also really enjoy. It's the analogy of taking a ball of yarn with you, so you're always tracking where you've been. And that is the other thing that I do heavily when I'm debugging is that I always have a note-taking application that's open because I always document what I've looked at, what were my findings. And then I think through what do I want to look at next? And sometimes I'll write down a list of three or four different questions of it could be this, it could be that. And then, I will prioritize those based on what's the quickest to look at? What can I replicate the fastest? What can I remove from this list? Back to earlier, when you were talking about the process of elimination and then walk through each one. So that way, when I do find the bug, I also have those steps that I can look back. So in case, someone has a question about it, in case they're like, "Well, what about this?" I can say, "Well, yes, I also checked that," or there just may be extra helpful tidbits that fall out of that process. At least they prevent me from checking something twice. JOËL: I've been pairing with you, Steph, on several bugs recently, and I've really appreciated the notes that you keep. They're very thorough, and that's something that I've tried to bring into my own practice by seeing you do that. CHRIS: That's something I've been iterating on in my own workflow of late is having a directory of notes associated with each project. And as I'm working on each, it's almost not even just bugs at this point but any new feature anything that I'm exploring. Because often, initial exploration of integrating with a library feels a little bit like debugging, sort of poking at the edges and what's true and what's not and writing up little reproducible steps of okay, run this code, then this code, then this code. And I've now just taken to keeping those forever because it turns out like, oh, I know I integrated that, but what was the step? I feel like there was something I did. And being able to go back and have that artifact now is so useful. And it's actually something that I've only really gotten in the habit of over, I'd say, the last two years, but that archive of notes is now very useful even to this day. STEPH: So I think we've covered a number or hinted at a number of the wonderful topics that are included in the series, including some of the different ways that we can identify our assumptions or ways that we can get unstuck. That was one of my favorite ones on all the different ways to get yourself unstuck when you are in the throes of debugging. There's also the idea of when you encounter a bug that if you can't fix it right away, but then some of the steps that you can take to then be able to fix it in the future. I would love to know, if you don't mind sharing some spoilers, as to some upcoming topics that will be in the unpublished but soon-to-be-published blog posts. JOËL: Yeah. So for all of The Bike Shed listeners who want the inside scoop, there are a few that I'm really interested in. So we opened the series by talking about mindset issues, how to approach a bug, how to think about assumptions, and now we're moving into some more concrete techniques and tooling. One that I'm really excited for is ways you can use Git more effectively. There are a couple of people that we interviewed who mentioned just how important it was to their workflow. And we've got some really interesting notes on that. There are also some really interesting ideas around areas in our codebase where bugs tend to accrue that are more likely to be, particularly around the nebulous concept of boundaries. This was a conversation that we had with one of our interviewees where we had our initial list of questions, and then we ended up completely throwing them away and going down this long, random tangent about boundaries; it was so good. We decided to dedicate a whole article to it because there are really interesting things around that. STEPH: All of that sounds really exciting. I love that you mentioned Git because even in the conversation that we've been having right now, that didn't cross my mind, but yeah, that is such an incredible debugging tool. So I'm really looking forward to that and also the one that's going to dive into boundaries. All of that sounds really exciting. JOËL: One thing that I think is really fun with digging into Git is that generally, when we think of debugging, we're trying to find where the bug is. But oftentimes, the real question we need to answer is not just where is the bug it's when is the bug? So not just debugging through space but debugging through time, and Git is the tool to do that. STEPH: Oh, that made me laugh but also made me depressed: when is the bug? [laughs] JOËL: And I feel like this is going to turn into a cheesy sci-fi TV series. CHRIS: It doesn't need to be cheesy. JOËL: True. CHRIS: Yeah, it does. [laughter] STEPH: For it to be good, I think it has to be a little cheesy. Sci-fi bugs coming to your application next summer. CHRIS: Everybody hop in the Tardis. We're going to find the bug. JOËL: I feel like there's some variation of that line that shows up in a lot of time travel series. Like not where is X, but when is X? STEPH: On that delightful note, thank you, Joël, so much for coming onto The Bike Shed and chatting with Chris and I about debugging. For everyone that would like to follow along for the Debugging Series, where can they find those articles? JOËL: So you can go to the thoughtbot blog. There is a tag we created specifically for that, Debugging Series 2021. And I'm sure that you'll link to that. All the articles are also going to be linked from the first article of the series, and I'm sure that will be included in the notes as well. STEPH: Perfect. And where can people follow your work? CHRIS: People can follow me on Twitter @joelquen, J-O-E-L-Q-U-E-N. It's not the hockey coach, although I can neither confirm nor deny that the two are the same person. We've never seen them in the same room together. STEPH: I didn't know you were a hockey coach in your spare time. Oh wait, this is the part that you can't confirm, right? JOËL: [laughs] Well, that would be letting the secret out. STEPH: All right. We will try to maintain your secret identity or whichever one that is. CHRIS: It's a really terrible secret identity if it's actually the same name. Joël, you really should have put more effort into this, coach Q. JOËL: [laughs] STEPH: Coach Q. I'm going to start calling you Coach Q. That's wonderful. Well, with your permission. JOËL: That's the real nickname. For those who don't know, Joël Quenneville is or formerly was the coach of the Chicago Blackhawks NHL hockey team, one of the best coaches ever in the National Hockey League. And a couple of years ago, I got to give a talk in Chicago, a conference talk. And everybody asked me, "Ooh, any connection to the coach?" STEPH: To which you replied? JOËL: Oh, I had a whole slide about the conspiracy that we may or may not be the same person. STEPH: That's really fun. Well, thank you again so much for coming on our show, Coach, and walking us through the wonderful Debugging Series. The show notes for this episode can be found at bikeshed.fm. CHRIS: This episode was produced and edited by Mandy Moore. STEPH: If you enjoy listening, one really easy way to support the show is to leave us a quick rating or a review on iTunes as it helps other people find the show. CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @ _bikeshed on Twitter. And I'm @christoomey. STEPH: I'm @SViccari. JOËL: And I'm @joelquen CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye.

This is part three of the crossover project. Part 1 is here and part 2 is here. I met William at Deconstruct 2019.1 We were walking back from the pre-party—too loud for my comfort level—and I took the chance to interview him. He knew about my project and wanted to share his memories of mechanical engineering. “Most of my skills transferred seamlessly. There’s one book, Sketching User Experiences, that’s aimed at software engineers. https://www.hillelwayne.com/post/crossover-project/what-we-can-learn/ herehereDeconstruct 2019Sketching User ExperiencesThe First Snap-Fit HandbookRebase 2020DeconstructPycon!!conStrangeLoopprogramming language theoristsenterprise engineersorigami artistsdiff CAD fileslockout-tagoutweekly newsletterTwitterChelsea TroyWill CraftDan Luu

This is part two of the crossover project. Part 1 is here. No one thinks about moving the starting or ending point of the bridge midway through construction. -Justin Cave I had to move a bridge. -Anonymous1 Carl worked as a mechanical verification engineer: he tested oil rigs to see how much they vibrated. Humans work and live on oil rigs for long stretches of time, and if they vibrate too much it can be impossible to sleep. https://www.hillelwayne.com/post/crossover-project/we-are-not-special/ herelast essayNoEstimates movementAgile ManifestoSpiral ModelV Modelfull clay replicaAustrian TunnelingNick Coghlanbridge plansFastenal labs pageOne of their pagesaerodynamic profilescrew conveyorRSSjoin my newslettertwitterChelsea TroyWill CraftDan Luu

I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking pictures on Twitter, the kind that made me envious of suburbanites and their 75,000 BTU woks. But now he was the test subject for my new project, to see if it was going to be fruitful or a waste of time. “What’s your job?” “Right now I’m working on microservices for a social media management platform. https://www.hillelwayne.com/post/crossover-project/are-we-really-engineers/ The Coming Software ApocalypseA Bridge to NowhereCodeless Code storiesGlenn Vanderburgin the Intrado softwareunfairly sent people to jailWyomingSoftware Craftsmanship: The New ImperativeSoftware CraftsmanshipRSSjoin my newslettertwitterChelsea TroyWill CraftDan Luu

In this episode of Ruby Rogues, Chelsea Troy teaches us to hone our debugging skills to a razor-sharp edge. We learn how to actively improve debugging skills, train troubleshooting instincts and practical strategies for tackling brain-bending bugs. Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Chelsea Troy Links https://chelseatroy.com/2020/01/13/a-framework-for-debugging/ Picks Luke Stutters: https://rclone.org/ John Epperson: Large Mouse Pads The Coding Den – A place where people ask and answer questions about coding, etc. Charles Wood:: Logi wireless mouse he Wheel of Time https://mostvaluable.dev Chelsea Troy: The New Education: How to Revolutionize the University to Prepare Students for a World In Flux http://rubyconf.org/ Follow Ruby Rogues on Twitter > @rubyrogues

In this episode of Ruby Rogues, Chelsea Troy teaches us to hone our debugging skills to a razor-sharp edge. We learn how to actively improve debugging skills, train troubleshooting instincts and practical strategies for tackling brain-bending bugs. Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Chelsea Troy Links https://chelseatroy.com/2020/01/13/a-framework-for-debugging/ Picks Luke Stutters: https://rclone.org/ John Epperson: Large Mouse Pads The Coding Den – A place where people ask and answer questions about coding, etc. Charles Wood:: Logi wireless mouse he Wheel of Time https://mostvaluable.dev Chelsea Troy: The New Education: How to Revolutionize the University to Prepare Students for a World In Flux http://rubyconf.org/ Follow Ruby Rogues on Twitter > @rubyrogues

In this episode of Ruby Rogues, Chelsea Troy teaches us to hone our debugging skills to a razor-sharp edge. We learn how to actively improve debugging skills, train troubleshooting instincts and practical strategies for tackling brain-bending bugs. Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Chelsea Troy Links https://chelseatroy.com/2020/01/13/a-framework-for-debugging/ Picks Luke Stutters: https://rclone.org/ John Epperson: Large Mouse Pads The Coding Den – A place where people ask and answer questions about coding, etc. Charles Wood:: Logi wireless mouse he Wheel of Time https://mostvaluable.dev Chelsea Troy: The New Education: How to Revolutionize the University to Prepare Students for a World In Flux http://rubyconf.org/ Follow Ruby Rogues on Twitter > @rubyrogues

03:36 - Chelsea’s Superpower: Software Detective Work * Grant-funded Organizations * Context Loss * Forensic Software Analysis * Software (Initially) Never Works ‼️ 08:27 - Coding in Investigation Mode * Lucifer (https://en.wikipedia.org/wiki/Lucifer_(TV_series)) (TV Series) * Setting Up a Debugging Environment (Includes a Velociraptor Example!) 15:05 - Chelsea’s Techtivism Blog Series (https://chelseatroy.com/category/techtivism/): Engineers Considering the Actions and Impact of Their Work Systematically * Techtivism 1: Eyes on the Mountain (https://chelseatroy.com/2019/10/30/eyes-on-the-mountain/) * Techtivism 2: The Four Levers (https://chelseatroy.com/2020/08/24/techtivism-2-the-four-levers/) * Techtivism 3: Biding Time, Boycotts, and Beyond (https://chelseatroy.com/2020/09/23/techtivism-3-biding-time-boycotts-and-beyond/) 20:20 - The Power of Influence (See Techtivism 2 (https://chelseatroy.com/2020/08/24/techtivism-2-the-four-levers/)) * Patronage: buying from or donating to an organization * Patronage Advocacy: convincing others to buy from/donate to an organization * Talent: devoting time and energy to an organization * Talent Advocacy: convincing others to devote their time and energy to an organization 26:57 - Making a Connection Between Values and Your Work as an Engineer * Privilege * The Status Quo * Incumbency 37:08 - Individual vs Collective Action ”A man convinced against his will is of the same opinion still.” (https://quotationcelebration.wordpress.com/2017/02/20/a-man-convinced-against-his-will-is-of-the-same-opinion-still-unknown/#:~:text=In%20other%20words%2C%20the%20argument,being%20argued%20against%20is%20CONVINCED) Confrontation Avoidance Reflections: Amy: The ways people can be both confrontational and avoidant at the same time. Damien: How what we do impacts larger systems and how we can move entire societies. Chelsea: The degree to which our fallibility creates the positions we get to occupy and what that means about the grace that we need to have about the fallibility of other people. Jessica: Chelsea is awesome! This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Special Guest: Chelsea Troy.

In this episode I talk with Chelsea Troy regarding the debugging techniques she shared in her recent RailsConf talk, "Debugging: Techniques for Uncertain Times". Chelsea and I talk about "progress mode" vs. "investigation mode", binary search, tests as scientific experiments, and, naturally, outer space.

In this episode, I sit down with Chelsea Troy, a Chicago-based software engineer, to talk about giving and receiving feedback, something you have to do quite often when working on software, but which you don’t always get to do as a student. Besides talking about code reviews, the most common situation where you have to give or receive feedback, we also explore how to solicit good feedback and how to take feedback constructively. Chelsea has written extensively about this subject (and many, many others) and you can find all her writings, as well as videos of her talks, at chelseatroy.com.

Feedback is an integral part of work performance across all industries. Effective feedback can help an employee improve at a job or skill. But at the end of the day, feedback is universally dicey. Emotions can run high and people can take feedback too hard. Chelsea Troy, an engineering consultant at RigorWorks, has given talks on her guidelines for effective feedback. Today, she joins Peter to offer a rundown of her process.Chelsea explains how feedback can go awry, what the best methods are for giving feedback, and offers tips on how to handle negative feedback directed at you. This episode has practical advice no matter your industry.[00:26] - What does Chelsea do as an engineering consultant?[02:30] - Foundation practices when going into a new org[05:07] - Facilitating getting help [07:01] - Where documentation should live[13:07] - Giving and receiving feedback[18:28] - Why bother with feedback?[19:34] - Mitigating the risk[23:46] - Soliciting feedback[32:22] - When feedback feels badCTO Connection is where you can learn from the experiences of successful engineering leaders at fast-growth tech startups. Whether you want to learn more about hiring, motivating or managing an engineering team, if you're technical and manage engineers, the CTO Connection podcast is a great resource for learning from your peers!If you'd like to receive new episodes as they're published, please subscribe to CTO Connection in Apple Podcasts, Google Podcasts, Spotify or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.This podcast episode was produced by Dante32.

Chelsea Troy is a self-taught and informally educated software engineer and data scientist who also specializes in machine learning. Chelsea also blogs regularly at www.chelseatroy.com. In this conversation, we discuss the process of self-educating in a variety of software-related disciplines, the state of machine learning and whether or not its going to swallow our society, and how technology companies can improve diversity in their workforces - both in terms of tangible actions for employees and managers as well as higher-level organizational changes. Check out more from Chelsea here: Instagram: @misschelseatroy Website: www.chelseatroy.com If you're enjoying the show, the best way to support it is by sharing with your friends. If you don't have any friends, why not a leave a review? It makes a difference in terms of other people finding the show. You can also subscribe to receive my e-mail newsletter at www.toddnief.com. Most of my writing never makes it to the blog, so get on that list. Show Notes: [0:07] Self-educating in software development and data science through a project-based approach – and the strengths and weaknesses of project-based learning vs a formal academic model [08:48] Almost all of your time in software development is spent at the margin of what you know how to do, so you have to be comfortable with being uncomfortable. Improvement often comes through bettering your ability to solve the inevitable problems that you will run into. [19:12] Reduce the feedback loop as much as possible and create testing scenarios in order to rapidly iterate on software. One weird trick to learning software development: copy the changes that more experienced developers make to their code by hand [30:30] The best learning comes from realizing that you’ve made a mistake. Having a generalist approach and understanding multiple programming languages enables solving problems in non-traditional ways. [37:42] Should we believe the hype on machine learning? What will be the future of machine learning and how will humans work with this technology as we are able to automate more and more tasks and better recognize patterns in data? [48:02] The dangers of algorithmic recommendations and the amount of resources going into increasing advertisement clicks through machine learning. Can we have machine learning algorithms make their decisions and categorizations “human legible”? [1:03:07] How can tech companies move the needle on diversity in hiring? What actionable communication and management behaviors can individuals employ in terms of making technical companies more welcoming to underrepresented folks? [1:14:07] How do we get more viewpoint diversity in the upper echelons of technology companies? Viewpoint diversity seems to clearly help companies improve performance, but can be painful and create more conflict within the organization. Links and Resources Mentioned John Conway's Game of Life Deliberate practice What is the difference between FragmentPagerAdapter and FragmentStatePagerAdapter? GitHub Pivotal Labs “Leveling Up Skill #6: Commit Tracing” from Chelsea Troy Zooniverse Hubble Telescope Hanny's Voorwerp Janelle Shane “Try these neural network-generated recipes” from Janelle Shane “Do neural nets dream of electric sheep?” from Janelle Shane “Metal band names invented by neural network” from Janelle Shane “The neural network has weird ideas about what humans like to eat” from Janelle Shane (this one kills me) Decision tree learning Game of Thrones

Panel: Charles Max Wood Guest: Rae Krantz This week on My Angular Story, Charles speaks with Rae Krantz (Akron, OH) who works remotely with the Toll Wave company (Phoenix, AZ). She does Angular work there with a small team. She specializes in information technology and services. Rachel (Rae) and Chuck talk about Angular and how she got her amazing job through a Twitter connection! In particular, we dive pretty deep on: 1:30 – Hello! 1:35 – Rae, please give us your background. 2:25 – Chuck: Tina’s interview will go live later on another episode. It’s interesting How did you get into coding? 2:50 – Rae: I started on a course 4 or 5 years ago. I moved to Akron, Ohio with the WOMEN and TECH group here, and got involved with the group. Free code camp and so on. Through meeting this Meetup I found a new position. This led to Angular development. I enjoyed the DevOps, but this Toll Wave is awesome! I have been working there for 9-10 months. 4:45 – Chuck: Why Angular and not Vue or Java? 4:52 – Rae: I started a side project with Angular with friends. They had a strong view with Angular, because Angular dealt with a lot of security issues. Since then I am pretty solid on the Angular side. The React side, I guess, is cool. 5:53 – Chuck: People tend to go towards technologies that they can get help with. It makes sense why you went with Angular. Is there anyone specific that got you into Angular? 6:23 – Rae: I didn’t have a network at the time. The 2 people that got me into Angular actually weren’t developers. I started with Docs and the Heroes actually were a great resource. It covers these pieces that are necessary to know how it works. I used early on NG docs, too. 7:24 – Chuck: Actually that is organized by... 7:42 – Chuck: Getting your job is very interesting. I a m writing a book on how to find a job as a software developer. I see that people are struggling with this. What did you have in place to show them that you were capable for the job? 8:18 – Rae: The interview was very conversational. It wasn’t algorithm tests; nothing super fancy. It really got into the work I’ve done and my thought process. I appreciated that the interview was realistic. I can go back to other traditionally other interview were “tougher.” I had to do an algorithm test. I sat down and I was terrified for that. It was more “simple” for the entry-level people. The saving grace is if you are frozen – just talk about the process. They want to see how you would talk through the process – they want to see that. You just have to know people. This Twitter job happened because of a network effect. 10:19 – Chuck: Yes, very true. It is a lot easier to get a job that someone can just introduce you to the company then trying to do it all yourself. Creating those opportunities through the people you know. 10:56 – Chuck: What are you doing now? 11:01 – Rae: Financial management application. It’s secret right now. In my free time, it is very hard to push through one thing. The latest thing I have been doing lately is the Rust Programming Book. I have talked with my director that I enjoy Angular but I don’t want to do just frontend. He’s been really great about it. He’s talking with other program managers to get involved with other projects that are coming in. I have tried to look at React. I cannot make myself do it. If you are good at one, then why would you learn the other one? Only reason to learn React is if I want a React job. 13:12 – Chuck: People say to me that they want to stay current and also job availability. If my current situation changes then I can adopt any technology that they change to. 13:58 – Rae: I have been wanting to look at Vue. I don’t know anything about Vue other than the inventor of it. It would be fun to play with the differences. 14:42 – Chuck adds his comments. 14:50 – Rae: There are so many different things out there to learn! Different languages – it’s hard to limit myself to limited languages within a 40-minute talk. I spoke at the following conferences recently: 1.) Codemash in Ohio 2.) Meetups in Grand Rapids (Software Craftsmanship) 3.) Self Conference in Detroit (no recordings) 4.) Full Stack Fest in Barcelona – the best conference ever because it was so well organized. The attention to detail was amazing. 17:09 – Chuck adds his comments. Yeah we will encourage people to look into your talks! 17:24 – Rae: Neat! Rae talks about workshops and typical Meetups. Cleveland area – October 6th – learn how to code – it will be fun! 18:25 – Chuck: ngGirls.org 18:40 – Chuck: Any advice for someone getting into tech? 18:50 – Rae: Do it before you have kids. Your energy is at a low when you have kids and you don’t have the energy to work on the things you want to work on. If you don’t have kids then use your Netflix time now and STUDY! If I can get through a chapter a day – that is fantastic – with life with kids. I work through lunches a lot. I try to use my day care time with care. It’s great to be at a conference without a kid. 22:06 – Chuck: I have 5 kids. My oldest is 12 – so that is fine, but my youngest is 3. The way we do it is I travel more than my wife. She’s a trooper to take care of the kids. I send her on a trip to see her best friend in North Carolina. 22:52 – Chuck: People are paying attention to people have different circumstances. 23:06 – Chuck: The last thing I want to ask is anything you are looking forward to in the future? Where do you want to wind-up? 23:25 – Rae talks about her hopes and dreams. Rae: The puzzle aspect, I like. I like making things work together. The larger scope is what I like. In terms of the languages I take as they come. Rust, yes, I would like to use that a few years down the line. It’s funny – I would learn React if I had to use it. I want to get in-depth in a few areas of Angular. 24:43 – Chuck: Check out these technologies through these podcasts. I echo what you are saying on these 3 frameworks. I am having fun with Vue right now. It really depends on what you want and what you need. Go play with them all! Chuck talks about Vue, Angular and Java. 25:31 – Chuck: Picks! Links: jQuery Angular JavaScript Vue Meetup Coursera Angular – Tour of Heroes Rae’s Website Rae’s GitHub Rae’s Medium Sponsors: Get A Coder Job Code Badges Cache Fly Picks: Charles Max Wood Screenflow 8 Rae Krantz Rust Book Women in Technology NG Girls Chelsea Troy’s Blog “Leveling Up” Medium – Snowflake – How They Assess Levels Supportive spouse My Work Team Cleveland Tech on Slack

Panel: Charles Max Wood Guest: Rae Krantz This week on My Angular Story, Charles speaks with Rae Krantz (Akron, OH) who works remotely with the Toll Wave company (Phoenix, AZ). She does Angular work there with a small team. She specializes in information technology and services. Rachel (Rae) and Chuck talk about Angular and how she got her amazing job through a Twitter connection! In particular, we dive pretty deep on: 1:30 – Hello! 1:35 – Rae, please give us your background. 2:25 – Chuck: Tina’s interview will go live later on another episode. It’s interesting How did you get into coding? 2:50 – Rae: I started on a course 4 or 5 years ago. I moved to Akron, Ohio with the WOMEN and TECH group here, and got involved with the group. Free code camp and so on. Through meeting this Meetup I found a new position. This led to Angular development. I enjoyed the DevOps, but this Toll Wave is awesome! I have been working there for 9-10 months. 4:45 – Chuck: Why Angular and not Vue or Java? 4:52 – Rae: I started a side project with Angular with friends. They had a strong view with Angular, because Angular dealt with a lot of security issues. Since then I am pretty solid on the Angular side. The React side, I guess, is cool. 5:53 – Chuck: People tend to go towards technologies that they can get help with. It makes sense why you went with Angular. Is there anyone specific that got you into Angular? 6:23 – Rae: I didn’t have a network at the time. The 2 people that got me into Angular actually weren’t developers. I started with Docs and the Heroes actually were a great resource. It covers these pieces that are necessary to know how it works. I used early on NG docs, too. 7:24 – Chuck: Actually that is organized by... 7:42 – Chuck: Getting your job is very interesting. I a m writing a book on how to find a job as a software developer. I see that people are struggling with this. What did you have in place to show them that you were capable for the job? 8:18 – Rae: The interview was very conversational. It wasn’t algorithm tests; nothing super fancy. It really got into the work I’ve done and my thought process. I appreciated that the interview was realistic. I can go back to other traditionally other interview were “tougher.” I had to do an algorithm test. I sat down and I was terrified for that. It was more “simple” for the entry-level people. The saving grace is if you are frozen – just talk about the process. They want to see how you would talk through the process – they want to see that. You just have to know people. This Twitter job happened because of a network effect. 10:19 – Chuck: Yes, very true. It is a lot easier to get a job that someone can just introduce you to the company then trying to do it all yourself. Creating those opportunities through the people you know. 10:56 – Chuck: What are you doing now? 11:01 – Rae: Financial management application. It’s secret right now. In my free time, it is very hard to push through one thing. The latest thing I have been doing lately is the Rust Programming Book. I have talked with my director that I enjoy Angular but I don’t want to do just frontend. He’s been really great about it. He’s talking with other program managers to get involved with other projects that are coming in. I have tried to look at React. I cannot make myself do it. If you are good at one, then why would you learn the other one? Only reason to learn React is if I want a React job. 13:12 – Chuck: People say to me that they want to stay current and also job availability. If my current situation changes then I can adopt any technology that they change to. 13:58 – Rae: I have been wanting to look at Vue. I don’t know anything about Vue other than the inventor of it. It would be fun to play with the differences. 14:42 – Chuck adds his comments. 14:50 – Rae: There are so many different things out there to learn! Different languages – it’s hard to limit myself to limited languages within a 40-minute talk. I spoke at the following conferences recently: 1.) Codemash in Ohio 2.) Meetups in Grand Rapids (Software Craftsmanship) 3.) Self Conference in Detroit (no recordings) 4.) Full Stack Fest in Barcelona – the best conference ever because it was so well organized. The attention to detail was amazing. 17:09 – Chuck adds his comments. Yeah we will encourage people to look into your talks! 17:24 – Rae: Neat! Rae talks about workshops and typical Meetups. Cleveland area – October 6th – learn how to code – it will be fun! 18:25 – Chuck: ngGirls.org 18:40 – Chuck: Any advice for someone getting into tech? 18:50 – Rae: Do it before you have kids. Your energy is at a low when you have kids and you don’t have the energy to work on the things you want to work on. If you don’t have kids then use your Netflix time now and STUDY! If I can get through a chapter a day – that is fantastic – with life with kids. I work through lunches a lot. I try to use my day care time with care. It’s great to be at a conference without a kid. 22:06 – Chuck: I have 5 kids. My oldest is 12 – so that is fine, but my youngest is 3. The way we do it is I travel more than my wife. She’s a trooper to take care of the kids. I send her on a trip to see her best friend in North Carolina. 22:52 – Chuck: People are paying attention to people have different circumstances. 23:06 – Chuck: The last thing I want to ask is anything you are looking forward to in the future? Where do you want to wind-up? 23:25 – Rae talks about her hopes and dreams. Rae: The puzzle aspect, I like. I like making things work together. The larger scope is what I like. In terms of the languages I take as they come. Rust, yes, I would like to use that a few years down the line. It’s funny – I would learn React if I had to use it. I want to get in-depth in a few areas of Angular. 24:43 – Chuck: Check out these technologies through these podcasts. I echo what you are saying on these 3 frameworks. I am having fun with Vue right now. It really depends on what you want and what you need. Go play with them all! Chuck talks about Vue, Angular and Java. 25:31 – Chuck: Picks! Links: jQuery Angular JavaScript Vue Meetup Coursera Angular – Tour of Heroes Rae’s Website Rae’s GitHub Rae’s Medium Sponsors: Get A Coder Job Code Badges Cache Fly Picks: Charles Max Wood Screenflow 8 Rae Krantz Rust Book Women in Technology NG Girls Chelsea Troy’s Blog “Leveling Up” Medium – Snowflake – How They Assess Levels Supportive spouse My Work Team Cleveland Tech on Slack

Panel: Charles Max Wood Guest: Rae Krantz This week on My Angular Story, Charles speaks with Rae Krantz (Akron, OH) who works remotely with the Toll Wave company (Phoenix, AZ). She does Angular work there with a small team. She specializes in information technology and services. Rachel (Rae) and Chuck talk about Angular and how she got her amazing job through a Twitter connection! In particular, we dive pretty deep on: 1:30 – Hello! 1:35 – Rae, please give us your background. 2:25 – Chuck: Tina’s interview will go live later on another episode. It’s interesting How did you get into coding? 2:50 – Rae: I started on a course 4 or 5 years ago. I moved to Akron, Ohio with the WOMEN and TECH group here, and got involved with the group. Free code camp and so on. Through meeting this Meetup I found a new position. This led to Angular development. I enjoyed the DevOps, but this Toll Wave is awesome! I have been working there for 9-10 months. 4:45 – Chuck: Why Angular and not Vue or Java? 4:52 – Rae: I started a side project with Angular with friends. They had a strong view with Angular, because Angular dealt with a lot of security issues. Since then I am pretty solid on the Angular side. The React side, I guess, is cool. 5:53 – Chuck: People tend to go towards technologies that they can get help with. It makes sense why you went with Angular. Is there anyone specific that got you into Angular? 6:23 – Rae: I didn’t have a network at the time. The 2 people that got me into Angular actually weren’t developers. I started with Docs and the Heroes actually were a great resource. It covers these pieces that are necessary to know how it works. I used early on NG docs, too. 7:24 – Chuck: Actually that is organized by... 7:42 – Chuck: Getting your job is very interesting. I a m writing a book on how to find a job as a software developer. I see that people are struggling with this. What did you have in place to show them that you were capable for the job? 8:18 – Rae: The interview was very conversational. It wasn’t algorithm tests; nothing super fancy. It really got into the work I’ve done and my thought process. I appreciated that the interview was realistic. I can go back to other traditionally other interview were “tougher.” I had to do an algorithm test. I sat down and I was terrified for that. It was more “simple” for the entry-level people. The saving grace is if you are frozen – just talk about the process. They want to see how you would talk through the process – they want to see that. You just have to know people. This Twitter job happened because of a network effect. 10:19 – Chuck: Yes, very true. It is a lot easier to get a job that someone can just introduce you to the company then trying to do it all yourself. Creating those opportunities through the people you know. 10:56 – Chuck: What are you doing now? 11:01 – Rae: Financial management application. It’s secret right now. In my free time, it is very hard to push through one thing. The latest thing I have been doing lately is the Rust Programming Book. I have talked with my director that I enjoy Angular but I don’t want to do just frontend. He’s been really great about it. He’s talking with other program managers to get involved with other projects that are coming in. I have tried to look at React. I cannot make myself do it. If you are good at one, then why would you learn the other one? Only reason to learn React is if I want a React job. 13:12 – Chuck: People say to me that they want to stay current and also job availability. If my current situation changes then I can adopt any technology that they change to. 13:58 – Rae: I have been wanting to look at Vue. I don’t know anything about Vue other than the inventor of it. It would be fun to play with the differences. 14:42 – Chuck adds his comments. 14:50 – Rae: There are so many different things out there to learn! Different languages – it’s hard to limit myself to limited languages within a 40-minute talk. I spoke at the following conferences recently: 1.) Codemash in Ohio 2.) Meetups in Grand Rapids (Software Craftsmanship) 3.) Self Conference in Detroit (no recordings) 4.) Full Stack Fest in Barcelona – the best conference ever because it was so well organized. The attention to detail was amazing. 17:09 – Chuck adds his comments. Yeah we will encourage people to look into your talks! 17:24 – Rae: Neat! Rae talks about workshops and typical Meetups. Cleveland area – October 6th – learn how to code – it will be fun! 18:25 – Chuck: ngGirls.org 18:40 – Chuck: Any advice for someone getting into tech? 18:50 – Rae: Do it before you have kids. Your energy is at a low when you have kids and you don’t have the energy to work on the things you want to work on. If you don’t have kids then use your Netflix time now and STUDY! If I can get through a chapter a day – that is fantastic – with life with kids. I work through lunches a lot. I try to use my day care time with care. It’s great to be at a conference without a kid. 22:06 – Chuck: I have 5 kids. My oldest is 12 – so that is fine, but my youngest is 3. The way we do it is I travel more than my wife. She’s a trooper to take care of the kids. I send her on a trip to see her best friend in North Carolina. 22:52 – Chuck: People are paying attention to people have different circumstances. 23:06 – Chuck: The last thing I want to ask is anything you are looking forward to in the future? Where do you want to wind-up? 23:25 – Rae talks about her hopes and dreams. Rae: The puzzle aspect, I like. I like making things work together. The larger scope is what I like. In terms of the languages I take as they come. Rust, yes, I would like to use that a few years down the line. It’s funny – I would learn React if I had to use it. I want to get in-depth in a few areas of Angular. 24:43 – Chuck: Check out these technologies through these podcasts. I echo what you are saying on these 3 frameworks. I am having fun with Vue right now. It really depends on what you want and what you need. Go play with them all! Chuck talks about Vue, Angular and Java. 25:31 – Chuck: Picks! Links: jQuery Angular JavaScript Vue Meetup Coursera Angular – Tour of Heroes Rae’s Website Rae’s GitHub Rae’s Medium Sponsors: Get A Coder Job Code Badges Cache Fly Picks: Charles Max Wood Screenflow 8 Rae Krantz Rust Book Women in Technology NG Girls Chelsea Troy’s Blog “Leveling Up” Medium – Snowflake – How They Assess Levels Supportive spouse My Work Team Cleveland Tech on Slack

02:03 – Chelsea’s Superpower: Pushing through and enduring discomfort to accomplish things 06:24 – The Act of Writing and Reflection: Journaling as a Tool for Learning; Commit Tracing Coxswain (https://en.wikipedia.org/wiki/Coxswain) 14:27 – Getting and Dealing with Feedback 17:44 – Measuring Participation in Meetings Why are there always technical problems in remote meetings? (https://chelseatroy.com/2018/03/22/why-are-there-always-technical-problems-in-remote-meetings/) Why do remote meetings suck so much? (caucus checklist) (https://chelseatroy.com/2018/03/29/why-do-remote-meetings-suck-so-much/) How do we make remote meetings not suck? (follow-up post) (https://chelseatroy.com/2018/04/05/how-do-we-make-remote-meetings-not-suck/) 23:51 – Implementing Structure in Meetings Valerie Aurora: Meeting Skills (https://frameshiftconsulting.com/meeting-skills/) 31:58 – Cultivating Questions Kindly Without Assumption or Judgement No Feigning Surprise: The Recurse Center User’s Manual (https://www.recurse.com/manual) xkcd: Ten Thousand (https://www.xkcd.com/1053/) SOAP (https://en.wikipedia.org/wiki/SOAP) 39:03 – The Problem with Claiming “Self-Taught” “The common industry accepted term to describe how I learned programming is “self-taught” but I’ve always found that so strange, considering all of the resources and communities that have helped me along the way.” – Jacob Stoebel Reflections: Jamey: Extending empathy to other people. Chelsea: The story of where things come from and the people they come from can make them both much more interesting and much more accessible. Coraline: The value of history. Sam: One of the best ways to understand a tool is to understand the context that existed before the tool existed. The nature of a caucus penalizes people for listening. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Chelsea Troy.