Podcasts about avdi grimm

Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they've read and loved, and other highlights of 2023 (projects, conferences, etc). Olive Oil Sugar Cookies With Pistachios & Lemon Glaze (https://food52.com/recipes/82228-olive-oil-sugar-cookies-recipe-with-pistachios-lemon) thoughtbot's Blog (https://thoughtbot.com/blog) Episode 398: Developing Heuristics For Writing Software (https://www.bikeshed.fm/398) Episode 374: Discrete Math (https://www.bikeshed.fm/374) Episode 405: Sandi Metz's Rules (https://www.bikeshed.fm/405) Episode 391: Learn with APPL (https://www.bikeshed.fm/391) Engineering Management for the Rest of Us (https://www.engmanagement.dev/) Confident Ruby (https://pragprog.com/titles/agcr/confident-ruby/) Working with Maybe from Elm Europe (https://www.youtube.com/watch?v=43eM4kNbb6c) Sustainable Rails Book (https://sustainable-rails.com/) Episode 368: Sustainable Web Development (https://www.bikeshed.fm/368) Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Simplifying Tests by Extracting Side Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) The Math Every Programmer Needs (https://www.youtube.com/watch?v=wzYYT40T8G8) Mermaid.js sequence diagrams (https://mermaid.js.org/syntax/sequenc) Sense of Belonging and Software Teams (https://www.drcathicks.com/post/sense-of-belonging-and-software-teams) Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) Digging through the ashes (https://everythingchanges.us/blog/digging-through-the-ashes/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat. It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it. JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want? STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see. And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them. JOËL: Hearing you talk about this gave me an absolutely terrible idea. STEPHANIE: Terrible or terribly awesome? [laughs] JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops. STEPHANIE: [laughs] JOËL: You're on a network, and then you swap browser cookies randomly. STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one. JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see. STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party? JOËL: I 100% agree. STEPHANIE: [laughs] JOËL: I'm curious: where do you stand on raisins in oatmeal cookies? STEPHANIE: Ooh. JOËL: This is a divisive question. STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles]. JOËL: That is the correct answer. STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs]. JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies. STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world? JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done. I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why. STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result. JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created. STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog. JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like. STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes. JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun. I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out. STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that. You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one. Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk. And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs]. JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year? STEPHANIE: Yeah, absolutely. JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out. STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs]. JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested. So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023? STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool. So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values. And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that. JOËL: Would you recommend this book to others who are maybe not considering a management path? STEPHANIE: Yeah. JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people. STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in. Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool. JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things. But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody. STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer. JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there. STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year? JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps. And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise. STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working. JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book? So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea. STEPHANIE: Yeah, absolutely. JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening. STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts. JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that? STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there. So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year. JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk. And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it. STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023? JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar? STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years. And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great. And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river. JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled. STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs]. JOËL: What was the topic of your talk? STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change. JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference. STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there. One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024. I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of. So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year? JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience. Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore. The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO. And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn. STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun. JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team. And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live. And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that. STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat. JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people? STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool. She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported? And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles] JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot. So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item. Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation. STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs]. JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing? STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break. And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right? And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs]. JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there? STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too. JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that. So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work." STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January. JOËL: Cheers to a new year. STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024. JOËL: On that note, shall we wrap up the whole year? STEPHANIE: Let's wrap up. 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: Byeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/ referral. Or you can email us at referrals@thoughtbot.com with any questions.

Avdi Grimm is the founder of Graceful.Dev, where he helps developers grow their programming practice. We talk with him about feedback loops. The post TechChat Tuesdays #63: Feedback Loops with Avdi Grimm appeared first on Chariot Solutions.

What does it mean to build a cost-free feature in the software, and are cost-free features even possible? Today we talk with Avdi Grimm. Avdi is a software developer with more than twenty years of experience. During his career, Avdi worked on everything from aerospace embedded systems to enterprise web applications. He is the author of Confident Ruby: 32 Patterns for Joyful Coding and a recipient of the Ruby Hero Award. Currently, he spends his time helping developers deepen their coding practice at Graceful.Dev. He tells us about practices that increase software maintenance costs and how to avoid them.  When you finish listening to the episode, connect with Avdi on Twitter or LinkedIn, visit his website, and check out his training courses at Graceful.Dev.  Mentioned in this episode: Avdi on Twitter at https://twitter.com/avdi  Avdi on LinkedIn at https://www.linkedin.com/in/avdigrimm/  Avdi's training courses at https://graceful.dev Avdi's website at https://avdi.codes  Avdi Grimm, Confident Ruby: 32 Patterns for Joyful Coding at https://www.amazon.com/Confident-Ruby-Patterns-Joyful-Coding-ebook/dp/B00ETE0D2S/?_encoding=UTF8&pd_rd_w=Vvn53&content-id=amzn1.sym.22f5776b-4878-4918-9222-7bb79ff649f4&pf_rd_p=22f5776b-4878-4918-9222-7bb79ff649f4&pf_rd_r=135-0405864-9131715&pd_rd_wg=PIKbJ&pd_rd_r=01acffe0-cfc0-46a5-b78a-9679fb0ebfcb&ref_=aufs_ap_sc_dsk 

Happy New Year! It's 2023

This week, Steph and Joël discuss investment time and keeping track of things they want to learn. How do you, dear listener, keep track of things you want to learn? When investment time rolls around, what do you reach for, or how do you prioritize that list? Are there things you actively decide not to focus on when choosing where to develop deep expertise? Are there things you wish you could spend time on if you could? 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. Bloom's Taxonomy (https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/) thoughtbot's interview (https://thoughtbot.com/playbook/our-company/hiring#interviewing) 3 categories of learning (https://thoughtbot.com/blog/what-technologies-should-i-learn) Four Thousand Weeks: Time Management for Mortals (https://www.amazon.com/Four-Thousand-Weeks-Management-Mortals/dp/B08XZY5ZF7/ref=sr_1_1?gclid=CjwKCAiA9qKbBhAzEiwAS4yeDZvBGi9yS1YkifUNcf0j8jx3s-NKc1pw5itLKSjI1vOfzlYJCuRNFRoC7ioQAvD_BwE&hvadid=599682518804&hvdev=c&hvlocphy=9006718&hvnetw=g&hvqmt=e&hvrand=3741098155096216457&hvtargid=kwd-1661352592925&hydadcr=28547_10703911&keywords=the+four+thousand+weeks&qid=1667835268&sr=8-1) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I was recently having a conversation with another colleague at thoughtbot, and they brought up Bloom's Taxonomy, which is a taxonomy of different phases of learning. It's often visualized as a pyramid with a broad base that starts with remembering facts and then expands up to understanding and then up to applying, and then analyzing, evaluating, and then finally creating. So it's a way to kind of quantify progression of someone who is trying to master a topic. And what really struck me when I saw this diagram was I immediately thought about how the tech industry interviews and a lot of our interviews are focused on the base of that pyramid. It's all about did you memorize certain facts, or APIs, or things like that? But a lot of the value that we create as developers...but to be good at our jobs, we have to actually be active much higher up in that pyramid in the analyze, evaluate, and create layers. But unfortunately, I feel like interviews often don't go that far; they're really just focused on the base. So that was a really interesting realization. We were not talking about interviewing, but this colleague shared the diagram. I looked at it, and the first thing I thought was like, oh, this is the problem with a lot of tech interviews these days. STEPHANIE: Yeah, I think a lot about how in interviews, we want to be showing off our best selves in a sense. Like, we want our interviewers to see the version of ourselves that we bring to work, which is usually like you were saying, at that top layer and isn't recalling particular facts about how our framework works or things we might have learned in computer science class in college. And one thing I actually really like about thoughtbot's interview...even in the job application, I think it says, "We want to see your strengths and see you at your best self." And it asks what can we, as thoughtbot, interview you on in a way that gives you the opportunity to display those skills? And so I really like that. I think I remember when I submitted that application, I might have said something along the lines of debugging a problem because I think that's where I personally shine. I don't know if it ended up being a conscious thing. But I do remember when I was doing the pairing interview, there was an aspect of debugging, and I was like, yes, this is where I can show off what I would normally do in a real-life work situation. So that really resonates with me. JOËL: Debugging is such a core developer skill, and yet I feel it's not often something that we dig into in a process like an interview. Sometimes you have almost like a code review style where you've got, oh, there is one bug hidden in here, find it, and it's almost like a gotcha sort of thing. I don't like those. But a real situation where you could show off your problem-solving and debugging skills sounds like a really good way to play to your strengths. STEPHANIE: Yeah. Where else do you think that higher level of critical analysis and creative output shows up in your day-to-day work? JOËL: I think it has to pervade the day-to-day work. The majority of my job is not remembering what method from enumerable is used to sort an array; it's trying to find a way to translate a problem that the business has into code or a code solution that will satisfy quite a lot of different constraints. This might be something that is doable in one or two days because that's all we have to allocate to this problem. So a lot of that work could be scoping down a problem. There might be some performance-related constraints where it needs to be faster than X. There are certainly some correctness constraints as well that you're trying to work within. So all of that, I think, is much more at that analysis, evaluation, and creation layers of the pyramid. STEPHANIE: Yeah, that's a really good point. I think sometimes I've seen interviews try to replicate that or recreate it in an interview question, even though they may be genuinely based off of real-life experiences that companies might have had. But most often, it's really hard to be evaluated on that situation until you're really just doing that work. JOËL: It is really hard to translate that into an interview format. I think one aspect that I do appreciate, and maybe that's just the consultant in me but having a conversation about trade-offs in a situation where there isn't a single correct answer. And so, maybe the interviewer and the candidate have different conclusions. But as long as they can show their reasoning down that path of why they came to the conclusion that they did, I think that's the important part of that. The hard thing is if the interviewer has their preferred solution, and they're just like, "No, you didn't come to my conclusion," then that's not a good interview. But a situation where a candidate gets to demonstrate their critical thinking skills, their analysis skills, their ability to make difficult decisions to balance trade-offs, I think that's a great way to show off some of those high-level skills that honestly we use on a daily basis. STEPHANIE: Yeah, I agree 100%. JOËL: So that's what I've been kind of excited about recently, just seeing this diagram and having that moment of clarity about interviewing. What's something new in your world, Stephanie? STEPHANIE: That's really interesting that you brought that up because it's kind of related to what I was going to say about what I've been working on on my client project, which is the ambiguity of the rewrite. So I mentioned last week that I've been rewriting some Rails views. And we're working on a pretty old legacy application, so there are a lot of things that, as we're rewriting, we need to figure out whether or not we want to include it in the new version. So it's been a little more challenging than just copying over the functionality that you want because there are a lot of things in this legacy app that were written 10-12 years ago that we don't have any context on, especially as consultants and even the people we're working with on this team, the code might even predate them. So we do our best to ask them questions about, hey, is this still necessary? Do you think we want it in this rewrite? And they don't always know the answers. And so we have to make our best judgment and make a lot of micro-level decisions about what we think is important to bring into this rewrite without a ton of that historical context. So when you were talking about those analytical, critical thinking skills, that seemed like a very relevant experience that I would say has been utilizing those aspects of learning. JOËL: Definitely, especially for a codebase that is that old. I feel like ten years is almost like a generation in software developer terms. Ten years ago would be what? 2012. That's Rails 3 still. I forget when Rails 4 came out. But yeah, that's a long time ago when you talk about technology. And at a company, even the odds of someone sticking around for that long are very low. STEPHANIE: Absolutely. And so sometimes we just choose to leave the code as it is, and we will just copy and paste it. But other times, we might try to rewrite it in a more modern way. One thing that we did recently was migrate a hand-rolled form builder to use Simple Form. And we did our best to retain most of the original functionality. But there were aspects of it, things like browser validation and stuff like that, that had to change because we made the conscious decision to use a more modern form builder. But then there were always going to be some differences, and so we had to reconcile those with the product team, have a lot of communication around what was important to keep and what wasn't. And yeah, really, just try to get the code in a better spot if we can while also acknowledging that some things have been working for ten years, and that's okay too. JOËL: So you're talking about a lot of old code that you're working with and seeing how much things have changed over ten years. And I feel like, as software developers, we're constantly having to learn and hone our skills, but it can really be overwhelming because there's so much to learn. How do you prioritize what you want to learn next? STEPHANIE: At thoughtbot, we're lucky enough to have investment times. So typically, on Fridays, most of us will not be working on client work, but we'll be working on things to improve thoughtbot internally or improve ourselves professionally. So I'm really grateful that I have dedicated learning time, and figuring out how to spend it has been both fun and also fraught in a way because like you were saying, there are so many things I want to learn about, and we internally have so much lively discussion about really cool technical things. But I've kind of accepted that I'm not going to be able to learn it all. And so when Friday does roll around, I do have to figure out, okay, how do I want to spend my precious investment time today? For me, it honestly feels really dependent on how I'm doing that Friday. So I do have a bit of a backlog of talks and articles that I've collected along the way or bookmarked that I might come back to if that is the mode I'm in. I also have bigger themes, I think, around frameworks and technologies that I want to dig a little more deeply into. I've been trying to work through a TypeScript tutorial for a while now, especially because it's not something that I've gotten a chance to spend a ton of time on in client work. And so in some ways, it's like, well, if I want to work on a client project using TypeScript, then I feel like I should brush up on TypeScript first. So that's kind of in the back of my head is just a more nebulous goal. But I also think that it really changes depending on how I'm feeling throughout the year. It could be very well that the TypeScript thing never comes to fruition and maybe something else will grab my attention. JOËL: I'm sure there are lessons, though, that you would learn from TypeScript that you could then use to improve your day-to day-work on a Rails project, for example. STEPHANIE: Yeah, absolutely. I think that's the really cool thing is that everything I learn in some way can connect to other things that I do know, or experience, or come across during my everyday work. So none of it ever feels like a waste of time. I think the best feeling is when you can make that connection as you are experiencing something in the codebase that reminds you of something you read about in a blog post or something like that. JOËL: Connections are one of the most crucial parts of, I think, knowledge creation. And in a past episode on note-taking, we had a whole deep conversation about how sometimes making connections between some of your notes is almost more valuable than taking a note by itself. STEPHANIE: Joël, how do you prioritize your learning? JOËL: I have three broad categories of technical learning that I like to do. The first is anything related to my core language and framework, and as of right now, that is Ruby, Rails. And maybe a little bit more broadly, anything related to the paradigms related to that, so object-oriented design, patterns related to that, all things that will help me to write better Ruby and Rails code. Then there are evergreen skills that are always great to invest in, things like getting better at Git, learning a little bit of SQL, getting better at doing things on the command line. Those are all things that I look to level up every now and then. And then, finally, just whatever interests me right now. I find that the return on investment for the amount of time you put in versus the amount of knowledge you get out is much higher when I'm personally interested. So it might be something completely unrelated to maybe more strategic elements of tech that I'm trying to get, but if I'm interested, it's worth putting a little bit of time into that. And so, for me, several years ago, that was functional programming types. Elm, I went really deep into that. And I think that really unlocked a whole other way of thinking about software for me and helped me...like we were saying earlier, I was able to bring that back to the way I think about Rails applications, the way I think about test-driven development. And that really rounded out my thinking, I think. STEPHANIE: Yeah, I think focusing your energy into where you're interested in makes it easier, for sure. It makes it more fun. I think like you're saying, your learning gets accelerated. And I think it's also really cool that people have different interests that they do like to go deep on. So maybe you might be thinking that you should focus your energy on this other aspect of development that you think would be really cool or useful in your work but doesn't necessarily interest you that much. Chances are that there's someone else who loves learning and talking about it, and you can use them as a resource when you want to know more. JOËL: That is a really important aspect because learning is not necessarily a solo activity. So sometimes, maybe I'm not even just prioritizing things that I think are strategically good for me or even things I'm just interested in. It might be things that my colleagues are interested in. So we have a book club that we run at thoughtbot. We've been going through the book Ruby Science, and there have been some great discussions around that. Recently, we've also been doing watch parties for episodes of I know it is RubyTapas by Avdi Grimm, but I think it rebranded recently, and I forget the new name of it, Graceful...I think Graceful.Dev. STEPHANIE: Graceful Devs, I think, yeah. JOËL: So we've been watching some of these together as a team and then having a conversation afterwards, so that's also been great. STEPHANIE: That's really cool. Yeah, I think getting other people involved makes it a lot more fun. And you have an accountability buddy. And you can have those deep, thoughtful conversations about the things you've learned. 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! STEPHANIE: I'm curious, have you ever made a conscious effort to not focus on something super deeply? JOËL: I don't know that I've made a decision to be like, I will not spend time here. But I've definitely made a decision to I will invest here and maybe not care quite as much there. So I've done quite a bit of different front-end technologies, starting with jQuery and Backbone.js and moving through a lot of the frameworks. Somehow I have not yet done much React. It's sort of a big hole in that list of frameworks that I have worked with. It's just not something that I've prioritized. I've done other things. I've learned concepts that I think mirror a lot of what React does, but that's not been something that I've dug into. STEPHANIE: That's really interesting because I think a lot of people think that they need to learn React because it's the popular front-end framework of the time. And so they think that it's something that they should know, or if they do ever have to work on a project with React, that kind of contributes to that feeling. But I like what you were saying earlier about how you have experience with other front-end frameworks. And that can help inform you if you ever do have to work in it. And also, there are so many great expert React devs out there. Like, we don't have to all be that dev. JOËL: Yeah. I think there can definitely be a pressure to feel like you have to know it all. And a lot of these tech stacks are changing so quickly that it becomes overwhelming to try to just keep up with everything. STEPHANIE: For sure. I remember having to write some tests for a React app, and the things that I had learned several years ago using Enzyme or something were no longer as relevant today, and having to pick up on the new best practices for writing Jest tests and React Testing Library. It was a lot, even though I was able to identify aspects of it that lined up with what I knew. It can be overwhelming, for sure. And people spend a lot of time digging deep into this framework and like I said, becoming those experts and accepting that I probably won't be that person [laughs] was also a little bit liberating, I think. JOËL: It's also important, I think, to accept that these sorts of labels of I'm that person, or I'm not that person are not permanent. It's I'm not that person now because that's not where I want to prioritize my time. Maybe in two or three years, it will make sense for me to become that person. And I can become that person if I put in the time, but today is not the day for me to be that person. STEPHANIE: That's a really good way of putting that. I like that a lot. JOËL: One struggle that I have, and I've seen a lot of people too is that it's easy to get very scattered in your learning that you'll have a lot of different things you're trying to learn at the same time or you feel like you want to do a little bit of this and a little bit of that. And then maybe you don't go very deep in any of them and feel like you're not being very effective with your time. Do you ever feel that, and do you have any strategies you like to use to make the most out of your learning time? STEPHANIE: I really relate to that. And I think one resource that helped me reframe that conundrum if you will, was this book called Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman. It was really interesting because it kind of turned productivity culture around a bit on its head because his whole thesis is that you won't achieve at all and that by trying to hack your own productivity, what you're really preventing yourself from doing is accepting the fact that time is finite. And that you have to make hard decisions about where to focus your time in a way that will enrich your life the most. And sacrifice the idea that you will get to do everything on your to-do list, that you will learn every framework that you want to learn. And it's still hard for me to totally accept that. But I think I'm inching towards the idea that if I do drop a ball on something that I have had bookmarked for at this point, you know, a year, I'm probably never going to get around to reading that. And that's okay because I'm still getting by with the things that I am learning and applying them in the aspects of my work that are relevant to me today. JOËL: That sounds like a really refreshing take on productivity culture, maybe with some hard truths in there as well. Is 4,000 weeks the human lifespan? STEPHANIE: [laughs] Yeah, it is. It's really funny because I think he even starts off in the book quizzing one of his friends, like, how many weeks do you think we have to live? And his friend very naively answered, "Oh, must be, you know, 500,000 or so," or something like that. But he used that as an illustration of how we inflate how much time we think that we might have in a day, a week, our lifespan. [laughs] JOËL: I'm a big history nerd in my personal time. You see this theme that comes up a lot in medieval European art and the 1400s after a lot of these big plagues have happened where they feature a lot of death or skeletons or those sorts of motifs that are much more prevalent than maybe an earlier art, and this idea that comes with a Latin phrase Memento Mori (remember death). And I think there's maybe an element of that that comes back into this book at least the way you were describing it, the idea that you only have 4,000 weeks, roughly, in your life, so make the best use of it. STEPHANIE: Yeah, absolutely. It's nothing new, for sure. I think it's just one of those things that we've been grappling with as a species for as long as we've existed. [laughs] So I don't know if anyone out there feels slightly relieved that it's okay for them not to get through their list of bookmarked articles about technical things. I hope that feels slightly better for you. JOËL: We give you permission for you, the audience, to go to your bookmarks and those articles that you've been meaning to read for two years and you haven't got to; it's okay to remove them. You will be okay. STEPHANIE: Agreed. So we've talked about how we spend our investment time. But I'm curious, do you have any strategies for people who do most of their learning in their everyday work? JOËL: You know, I think that applies to me as well. We've been heavily emphasizing investment time, but that's only one day a week. And four days a week, I am doing regular application development for clients. And so the majority of my hours in a week are going to be dedicated to that. I find that being very self-aware for the things that you do and trying to notice when I learn something new or when I interact with something new has really helped me get more out of my day-to-day work. And a way to level that, I think, is to be on the lookout for opportunities to share with others. And that can be as small as just put a today I learned message in a group chat, maybe in thoughtbot's Slack developer channel, and just say, "Hey, today I learned this interesting thing about a particular method." Or "Today I learned this weird thing about time zones." Or "Today I learned this interesting fact about testing." And then that might start a discussion, or it might not. But the fact that I took the time to take it out of my head and write it out, I think, makes that more concrete, and it helps me hold on to it. STEPHANIE: I've noticed you are really good about doing that, about sharing things that you encounter in your everyday work in a very low-stakes kind of way. I am not so good at doing that. I tend to be so steeped in client work, and I have to really intentionally, after a project is over, think about what I learned along the way. And oftentimes, they're not as small, incremental atomic bits of information but bigger picture things about, oh, I learned how to navigate this aspect of ambiguity. And maybe the next time, I can point to a past experience or lean on a little bit more on my gut instinct to guide me towards making the right decision. And I think that's an important aspect of learning too, even if it wasn't necessarily a technical tidbit. It is part of becoming a better developer, just as equally as gaining that more concrete technical knowledge. JOËL: Intuition, I think, is really important as developers, and honing that intuition is something that is really valuable. One way that I found helpful is dialogue, just a conversation with one other person, maybe it's asynchronous over Slack, maybe it's a call in person, and just talking through an idea that I have. A recent one and I think I mentioned this on the previous episode of The Bike Shed, was talking about RSpec matchers. And does your choice of matcher impact the sorts of design that will come out of the code that you write? Does EQ tend to push you in a direction maybe where you're less strongly encapsulating data? And so that's just a thought, and then you have a conversation about it. And then that can help sharpen your intuition so that the next time you're writing a test you're not just thoughtlessly bringing in a matcher because whatever; it's the thing to do. And initially, maybe it's not intuition; it's much more explicit. You're thinking, ooh, do I want EQ, or do I want not? But I imagine that after six months of me being hyperaware of that, I will have built up some intuitions to be like, oh, this is the place where we want a custom matcher, or here's the place where I want EQ. And my hope is that that will eventually come to the point where it's so natural. Someone would almost have to stop me and say, hey, wait, why are you choosing that? And then I have to think a little bit and be like, oh, it's because of these things. But I'll have started with a conversation, which then turned into just hyperawareness thinking about it every time I do that action which then turns into intuition. STEPHANIE: Yeah. I think you can also call that experience. I remember having a conversation with someone, and I told them that I could inject their brain with all of the knowledge and information that I had. But that isn't quite the same as having really experienced the process of gaining that knowledge through more conventional learning methods but also that day-to-day client work that you're doing. So I totally agree with you there. JOËL: You took this whole long thing I had to say and were able to condense it down to one word: experience. STEPHANIE: [laughs] JOËL: Which I think, yeah, exactly describes what I'm trying to say. And with that, shall we wrap up? STEPHANIE: Let's wrap up. JOËL: The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. 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. If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

This episode is sponsored by Tonic.ai – where your data is modeled from your production data to help you tell an identical story in your testing environments.[00:01 - 07:22] Opening Segment Need to generate fake data that looks, acts, and behaves like production data for your test environments? Check out Tonic.ai!Head over to https://www.tonic.ai/ and sign up today for a free two weeks trial sandbox!From full-time employment to consultancyOn why he calls his business the banana stand“There's always money in the banana stand.”[07:23 - 21:54] Doing His Own Thing and Gaining IndependenceAvdi on the difference between consultancy versus the banana stand modelWriting his e-book and getting into screencastsHow he managed a startup business, consultancy, and being a new father at onceThe reason behind the rebrand: From RubyTapas to Graceful.DevWhy Avdi is done subscribing to the corporate cultureThe unconscious bias in recruitment[21:55 - 31:42] Building on WordPressWhy Avdi chose WordPress as the platform for his businessWhat are the advantages over the other platforms?WordPress plugins: What you need to knowKeeping track of the changes and updates on the platform[31:43 - 41:46] Closing SegmentWhat's next for AvdiHis advice on delegating and building your email listFinal wordsTweetable Quotes“There's always the risk. There are no guarantees in this industry. There are no  guaranteed retirement plans.” - Avdi Grimm“I think a lot of people in software are completely focused on either financial scaling or on like user scaling. The kind of scaling you need to plan for is devolving stuff from yourself, removing yourself as a bottleneck” - Avdi Grimm“Anything that I'm thinking of delegating or automating, always do it manually first, and do it manually for a while first and get a really good idea of what it is that I'm either delegating or automating.” - Avdi GrimmResources Mentionedhttps://www.tonic.ai/ - Sign up now for a two-week free trial!Exceptional Ruby by Avdi Grimm - Get a copy of Avdi's e-book at https://store.avdi.codes/l/NWtnkWordPressConvertKitLearnDashMemberPressWooCommerceConnect with Avdi on his site and on Graceful.Dev! Follow him on LinkedIn, too!Let's Connect! You can connect with me, Dr.  McKayla on Instagram, Twitter and Youtube to look into engineering software, and learn from experienced developers and thought leaders from around the world about how they develop software!LEAVE A REVIEW + help someone who wants to know more about the engineering software world. Your ratings and reviews help get the podcast in front of new listeners. _______Transcription[00:00:00] Dr. McKayla: Hello, and welcome to the Software Engineering Unlocked podcast. I'm your host, Dr. McKayla and today after pleasure to talk to Avdi Grimm. But before I start, let me introduce you to an amazing startup that's sponsoring today's episode, Tonic.ai, the fake data company. So what does Tonic.ai do? I'm sure you know how complex and cumbersome it is to create quality test data.[00:00:27] Dr. McKayla: It's a never-ending chore that eats into valuable engineering resources. Random data doesn't do it and production data is neither safe nor legal for developers to use. What if you could mimic your entire production database to create a realistic dataset with zero sensitive data? That sounds amazing, right? Tonic.ai does exactly that. [00:00:50] Dr. McKayla: With Tonic.ai, you can generate fake data that looks, acts, and behaves like production data because it's made from production. Yet, Tonic.ai guarantees privacy so your data sets are safe to share with developers, QA, data scientists, heck, even distributed teams around the world. Visit Tonic.ai to sign up today or click the link in the show notes to get a free two weeks trial sandbox.[00:01:14] Dr. McKayla: But now back to Avdi. Avdi has been a developer for over 20 years and runs, similar to me, a training and consulting business. The main difference is that he has been doing this already for over 10 years. So I'm super thrilled to pick his brain today around everything business-related. He's also a consulting pair-programmer and the author of several popular Ruby programming books and has several courses on this subject on his website, Graceful.Dev, formerly RubyTapas.com. So I'm super thrilled that he's here with me today. Avdi, welcome to my show. I'm very excited. [00:01:51] Avdi Grimm: Thank you so much. I'm excited to be here. [00:01:53] Dr. McKayla: Yeah, I'm super excited. So I've been following your journey on Twitter and so on for quite some time. Very inspirational as well. And I have a lot of questions around how you run your business and why you're running the business and what we can learn from you, right, a seasoned entrepreneur and self-employed person to also maybe get a little bit more independence in our life, right? So this is probably the main goal for myself, for everything that I do is flexibility and independence. So why are you running your own business and how does this come about? Why are you not a software developer in a company somewhere?[00:02:32] Avdi Grimm: Right, yeah. I mean, to some degree, I feel like it's almost an inevitable career arc for somebody in software. You know, I know people who have avoided it, but a lot of the people that I kind of looked up to over the years went through, you know, they went through the full-time employment phase and then they gradually kind of moved out to becoming consultants and having various other side businesses.[00:02:55] Avdi Grimm: And, you know, come to think of it, I never really thought about this much before. I had the example of my dad who worked in software and hardware design, and he was an independent consultant I was growing up. So that was kind of normalized to me to, like, have your own thing [00:03:08] Dr. McKayla: Yeah, for me was quite different. Yeah. [00:03:11] Avdi Grimm: I think that I, I saw that on the horizon maybe from earlier than some people do, just because it was, it was normalized for me, you know? And it just seemed like that's what a lot of my heroes did in the industry was eventually they became consultants. [00:03:26] Dr. McKayla: Yeah. Yeah, it's good if you have like role models. For me, it was quite the difference. I always saw it that I will work at the company for a really long time and, you know, climb the career ladder somewhere. Actually, I started a family that I saw, oh, this is not working out as I expected. And as I would like it to work out, right? And so this was a little bit why I changed the thing. So you call it a banana stand. You don't call it like an enterprise or something. Why do you call it the banana stand? And what's your philosophy for your business? How do you run it? [00:04:00] Avdi Grimm: So, yeah., I've started using the term banana stand recently, especially as I've been kind of reflecting back on, you know, over a decade of doing this and, like, my style of, of running the business and writing a little bit more about that. So the, the term banana stand, it comes from, the show Arrested Development in which one of the characters says to another, this character is trying to save the family business and his dad who is in prison keeps telling him there's always money in the banana stand, which he completely misinterprets the message and winds up, burning down a banana stand that's full of literal money in the walls. I apologize if I've spoiled the show for you, but it's been out for a while. But you know, like, that phrase stuck with me. There's always money in the banana stand and that's kind of the way that I look at it.[00:04:48] Avdi Grimm: So there's kind of two sides to this, this independent business for me. There's the consulting side. And then there's the product side, product being kind of a broad term for selling books, selling courses, selling workshops. It's kind of a loose definition of product, but it's definitely distinct from the consulting side of my business, which is more like, you know, hourly consulting on people's projects.[00:05:12] Avdi Grimm: And I definitely look at the product side as a banana stand as like something that I kind of run casually, even if I'm putting most of my time into it now. I still run it kind of like lazily and you know, and it's my own banana stand to putter around in. I'm not, like, beholden to any, like, schedules and I'm not on any kind of like track of, I have to, you know, make this much money.[00:05:35] Avdi Grimm: I have to, like, make sure that my VCs get a payoff and stuff like that. It's just kind of like, you know, I get the putter around in the banana stand and work on whatever I feel like. And, you know, that phrase there's always money in the banana stand is kind of like that has informed the way I think about employment a lot, because, for me, if I'm in between jobs, I used to think of it as in between jobs, I don't think of it that way anymore, but if I'm in between jobs, quote, unquote, that's not like a time to panic and, you know, and, like, do all the interviews and freak out about how I'm unemployed. That's time to just focus on the banana stand.[00:06:12] Avdi Grimm: And until something comes along, that makes sense. And I think that's been helpful to have that. And, yeah, that side of my business, really like, so we talked about consulting, but that side really came from early on, getting into e-book sales, which we can talk about how that story went if you want. [00:06:28] Dr. McKayla: So if I understand that you would say there's the consulting, which is, you know, it's something that you have continuously to invest in and also make some contracts around that.[00:06:37] Dr. McKayla: I'm also doing some consulting, which means like now I'm dedicating, let's say 30 hours for this project for three months, right? And so you are more or less sold out for that time? [00:06:48] Avdi Grimm: It's kind of like a real job.[00:06:49] Dr. McKayla: Yeah. It's like a real job, only that you have all the risks as well, which is even worse.[00:06:58] Avdi Grimm: But there's a lot more, even there there's a lot more independence. And honestly, you know, one of the things that I value on the consulting side is that, I mean, yeah, you have the risk, but there's always the risk. There are no guarantees in this industry. There are no guaranteed retirement plans.[00:07:13] Avdi Grimm: And what I don't have to do is I don't have to buy into a lot of corporate mission and values BS that I don't believe in. [00:07:22] Dr. McKayla: Yeah. So you have your consultancy and then in between those consultancy gigs, right, when there are no consultancy gigs, you're not freaking out, you're working on your banana stand and you grow that, right? And the good thing it's about the products and, you know, this mindset, I think, is that even a little bit of work on them pays off, right? So it's a little bit like an investment. So you create another free course, maybe, and you have like a, you know, a good lead magnet, have people that are interested in your work.[00:07:53] Dr. McKayla: Then you create a paid course when you have time and so on. And it stays, right? It's something that's there for longer, whereby the consulting, it comes, it brings normally quite good money, from my experience, right? In a very short amount of time, but then it goes away as well. While the banana stand, maybe it's a little bit, it's not this boom, now we have like all this money. But it's also not going away, right? Yeah, exactly. It's a snowball. It's a flywheel somehow, right? Yeah. [00:08:20] Avdi Grimm: Yeah. I mean, you know, a consulting gig is one big blizzard that, you know, that melts the next week and a banana stand is a snowball that you just kind of gradually roll over the years.[00:08:32] Dr. McKayla: And so how long did it take for you to have this banana stand where you could say, well, I have some predictable income that, you know, makes me sleep at night? . [00:08:43] Avdi Grimm: So actually I think, you know, my trajectory there probably was a little different from a lot of people's. I kind of, you know, I put along having the book, the e-book business on the side for a few years, and that really just fell out of speaking.[00:08:58] Avdi Grimm: It happened because I was giving talks at software conferences. And I was pouring a ton of time and energy into researching these talks. And I was like, you know, I wonder if there's a way to kind of recoup. You know, I have all this material that I put together. I can't fit it all into a talk.[00:09:14] Avdi Grimm: And I wonder if there's a way to like recoup the energy that I've been putting into this. And that was really the origin of the first book, which was Exceptional Ruby, which is about error handling and failure management and I made a book out of like the, all the extra material that I put together for that.[00:09:29] Avdi Grimm: And that was that kind of launched things. And so that was kind of a side business. It was a nice little side business for a couple of years. And then what changed was I decided to get into screencasting. I've been doing the books, I've been doing some podcasting and this was around, you know, this was like 20, maybe 2010, 2011, 2012.[00:09:52] Avdi Grimm: A lot of programming screencasts started taking off. And I decided to get into that business. And I had a vision of like, what if we did that only much shorter and more focused? And, you know, just do like five minutes or less. You know, get one idea across at a time. And so, unlike most banana stand efforts, that was really like a do or die, not do or die.[00:10:13] Avdi Grimm: I don't like that terminology that was a go big or go home. That's the phrase I'm looking for, go big or go home because I knew how much energy went into video production and it is a lot. And so it was like, okay, this is a project that I'm going to test the waters. If it does well, I'm going to try, you know, the only way this works is if I can make it into my full-time job, otherwise I'll just stop. And yeah, I got really lucky. I was coming in at a good time. People really liked the format. And so within, I think around a year or two, I was able to say, I don't actually need other jobs right now with the RubyTapas screencasts. [00:10:49] Dr. McKayla: Oh, yeah. That's nice. [00:10:51] Avdi Grimm: Yeah. So that was, that was kind of like line goes up. That was less, you know, slowly rolling snowball.[00:10:56] Dr. McKayla: Yeah. And how much time did you spend in this line goes up phase? You know, because somehow when you're focusing on something, like doing the screencasts, you're not having an income, right? And then if you go to consulting, you don't have the time. So you have to switch between those boats of not having time or not having money. So how did you handle that at that time? [00:11:17] Avdi Grimm: I didn't sleep. I had at least one new baby at the time, too. And, like, I was working consulting gigs. I don't know. It's kind of a blur at this point. I don't think that I could do that kind of thing again, unless it was a great need. 'Cause I was also, at that point at the beginning, I was producing three episodes a week. [00:11:41] Dr. McKayla: Wow. Yeah, that's a lot. [00:11:43] Avdi Grimm: Yeah. I was doing a lot at once and it was kind of nuts. [00:11:46] Dr. McKayla: Yeah. And I actually really liked, with the whole style also, when I look through your blog posts and everything, right, you have your own style. You didn't call it like Professional Ruby screencast, you call it RubyTapas, right? And the tapas probably transport the message of it's small pieces of very digestible, tasty things, right? [00:12:09] Avdi Grimm: And I feel like some of that probably also fell out of just like the Ruby, like, the community has always been super whimsical and kind of silly. And so, you know, I can't take full credit for that approach. [00:12:22] Dr. McKayla: Yeah. But recently, I don't know exactly when, but you rebranded your whole RubyTapas into Graceful.Dev, why is that? For me, it seems like it's now broader and there can be more happening, but what's your strategic vision behind, you know, going from RubyTapas to...[00:12:40] Avdi Grimm: I do not do strategic visions. I used to, but, man, I avoid strategy as much as possible now. I mean, that's okay. That's not true. I do a little, I do a little. But I try not... [00:12:54] Dr. McKayla: You definitely have some reasoning behind it, right? [00:12:56] Avdi Grimm: I try not to have five-year goals. Let's put it that way. I don't do goals. There's definitely some reasoning there. There's a direction there. I mean, the direction was one that I've honestly had in the back of my mind for a really long time. A lot of people don't know that, like, the same day in, like, 2011 or whenever it was that I registered RubyTapas.com and associated addresses. I also registered CodeTapas.com.[00:13:20] Dr. McKayla: Okay.[00:13:21] Avdi Grimm: So like, you know, I never wanted to completely limit myself to Ruby, strictly Ruby content. You know, I've worked in, God, like a dozen languages over the course of my career. And Ruby was just an area that I wound up focusing on a lot and wound up making a lot of money in. And enjoying, I really, really enjoy the language still and the community as well.[00:13:42] Avdi Grimm: But I always had in the back of my mind, you know, that I would expand, but, you know, I didn't wound up not using as you'll notice. I wound up not using CodeTapas as the branding 'cause I was really, like, moving in a different direction, broadening not just in, like, in the technologies that I want to cover, but also I just spend a lot more of my time thinking about broader topics like, the sustainability of the development that we do and systems thinking, understanding the systems in which we work and the systems that cause the work that we have to exist. And yeah, so just, for a lot of reasons, it made more sense to me. And in some of my talks, I've been really focusing on the concept of grace.[00:14:21] Avdi Grimm: So it just made more sense to me to move in that, that branding direction. And then recently I had the opportunity to finally, like, do a lot of the heavy lifting of moving content over. And so I took that. [00:14:33] Dr. McKayla: Where did this opportunity come from? [00:14:35] Avdi Grimm: Well, so I had a point a few years back where I was like, okay, you know what? I've been sort of off on my own, doing my own thing for a long time. I would like to get back into, like, the hustle and bustle of being part of a big team that's making something real in the world. And I spent, I don't know, a year or so interviewing pretty seriously at a bunch of different places. And that did not go as expected.[00:15:00] Avdi Grimm: And I finally decided that I, wasn't going to focus on that anymore after all. And I was just going to get back to the banana stand 'cause there's always money in the banana stand. And that has been actually an immensely satisfying experience, kind of coming back to it with a fresh, fresh, like maybe this is my calling perspective.[00:15:18] Dr. McKayla: Yeah, I actually followed this journey a little bit on your Twitter, you were sharing it with us and also the hassle of the whole, you know, getting naked in front of strangers, you know, and really selling yourself. And I mean, you have been in the industry for so long, you have shared your learning.[00:15:38] Dr. McKayla: You know, you have some portfolio online. It's not like somebody comes and has no idea about you, but still, it felt like at least what I got out of the tweets, right. What I read into them was that every interview was a little bit, it wasn't really like keeping your dignity, right? So you had really to get naked in front of them to do all these silly things.[00:16:03] Avdi Grimm: You know, I wouldn't, I actually, I would argue that it's not, it wasn't really about being naked. It wasn't really being, about being transparent. It was about people wanting you to do a very special dance for them that strokes their ego and me being at a point in my career and life where I'm just like, I'm not going to do that. Why would I do that? Looking back I got some actually really nice offers from some, you know, well, large companies anyway, but in the end I was not comfortable taking any of them. And in part, because of what I saw during the interview process.[00:16:39] Dr. McKayla: Okay, what did you see? [00:16:41] Avdi Grimm: Well, you know, so actually, let me tell you about something I just heard recently from a friend of mine, because I hear the same story over and over again. Like my story, what I've realized is my story is not at all unique. So just the other day I heard the story again of like, basically, you know, an extremely senior well-respected brilliant engineer gets asked by a friend that works at a FAANG, you know, works at one of these giant unicorn Silicon valley darlings, gets asked to come interview there. It's like, we'd love, you know, I'd love to work with you here, which is basically what happened to me, a number of different places. And, you know, so they kind of go into the interview silo and then they go through this process where in, you know, in this particular case, like they got interviewed by someone who was totally unrelated to the group that wanted to hire them because this is the way the process works. You know, we don't want bias in the system. There's a lot in these processes that are supposedly about eliminating bias, it's actually creating it.[00:17:42] Avdi Grimm: We can talk about that more in a minute, but, you know, was interviewed by someone totally unrelated to that team. And basically, they were like, you know, show that, you know, by heart, my favorite algorithm,[00:17:55] Avdi Grimm: I happen to have a favorite algorithm. You're going to show me that you can, you can identify that I'm thinking of this algorithm and then you can write it by heart. And like that wasn't an algorithm that this engineer had used before. And so it wasn't one they thought of, you know, I've got a lot of stuff in my background where it's like, I know of algorithms that probably most engineers haven't heard of because they happen to be useful for networking middlewares and I hear this all the time.[00:18:18] Avdi Grimm: Anyway, they got flunked out because they couldn't, you know, reproduce somebody's favorite algorithm from, by heart. And this is somebody with, like, close to my level of experience. It's nuts. And I keep hearing this. It's actually, you know, I've heard this from a lot of people, with my, lot of friends of mine, with my level of experience in the industry, that these systems, they're really tuned to find people that are exactly like the people who designed the system in as many ways as possible. [00:18:47] Dr. McKayla: Yeah. [00:18:48] Avdi Grimm: Like, for me, I don't care. I am a white guy with plenty of opportunities and a banana stand. You know, I can fall out of a process like that and be fine. But what I'm seeing is that these processes are also, I mean, they're very gatekeep-y and they're very clicky. They're very in-crowd, they're very, very, like, we are expecting people that sort of show the secret insignia of a very select group of Silicon Valley insiders, basically. [00:19:18] Dr. McKayla: I think one of the problems is also that they often require a tremendous amount of preparation, right? And if you think you are an experienced engineer, maybe at that point, you have a family, for example, around, right.[00:19:33] Dr. McKayla: And some other commitments, it gets really hard to study some, you know, lead code examples, just to be as fast as, you know, somebody else, right? And I think this is also something that I criticize a lot when I'm thinking, and then you don't even need that, you know, you don't need that knowledge. You could really solve real-world problems.[00:19:51] Dr. McKayla: You have some experience and background, right, that you have worked on. And it's probably also super challenging. So looking really at what that person has already achieved in the last, let's say 15 years would be, you know, and then really let them explain that in-depth, which shows that they probably can learn, you know, whatever problem or solve whatever problem you throw at them. It would be a much better way than, you know, getting back to bubble sort and, you know, and linked list or something, right?[00:20:19] Avdi Grimm: And this, this is a big part of where the bias is in the system, and this is why I get sort of morally outraged by it, you know? I don't do well in these, you know, I might not do well in these because I'm at a point where I just can't be arsed to do that much homework of like learning somebody's arbitrary favorite algorithm.[00:20:36] Avdi Grimm: But what they're implicitly biasing towards is the sort of stereotypical young white dude that has all the time in the world and doesn't have a family to support and doesn't have any disabilities. And, you know, I could list off a lot of, you know, a whole lot of privileges there that go into that sort of their really looking for that person who has nothing else going on in their life.[00:20:59] Dr. McKayla: Exactly. [00:21:00] Avdi Grimm: You know, so that they can then like induct them into the cult of your passion is your software career. And that bugs the heck out of me, you know, and I see this really like, you know, who is really hurting is people that come from backgrounds that aren't like mine and have other stuff. They have people that they're taking care of. They have kids, they have elderly parents, they have families that they're sending money to, and they can't afford a, you know, a break in their income while they spend six months, you know, doing nothing but the interview game. You know, there are so many things, and the people that are, you know, so many minorities in this country already have, in the world or, you know, minoritized people, I shouldn't say have so many other calls on their time because of the way society is already stacked against them. That it makes it impossible to jump through these. [00:21:48] Dr. McKayla: Yeah, I totally agree. I totally agree. Yeah. [00:21:51] Avdi Grimm: Sorry, I get worked up.[00:21:53] Dr. McKayla: No, I want to come back a little bit to your banana stand again because this is the way out for, for you. And it's a little bit the way out for me as well, right? So with Graceful.Dev, I don't know if you had that before. You had RubyTapas and you had like the courses, but Graceful.Dev is now a full-fledged membership site, right? So you have different courses and you build it on top of WordPress. Why did you go this route? I mean, you could have like your courses on some third-party platform, right? From, I don't know, Teachable or whatnot, you know, many, many different PODR and so on. But you host it yourself and then you have the membership site as well. And you do that. Why does choice, like, I'm also thinking about right now, awesomecodereviews.Com for example, runs on, I switched from WordPress to Gatsby. So it's a static side and I'm thinking on how to give it a membership capabilities.[00:22:49] Dr. McKayla: And I looked at SurplusCI and so on, but why did you go for WordPress? And are you happy with it? And what's the philosophy behind it? What do people get from this membership? What do you want to build? Probably there's a community behind, right? And some, some visions that you have for that.[00:23:06] Avdi Grimm: This is an opinion I've kind of come to over years of using many different systems. And there's continuum here because you know, a lot of people running, particularly running education sites for developers have rolled their own system from scratch. They've built their own servers or their own applications.[00:23:26] Avdi Grimm: And so, you know, there's that continuum all the way from roll your own to, you know, use a completely hosted service, like Podia, Thinkific, whatever, you know, and I've, I've tried a lot of these different things. I started Ruby topis out on somebody else's platform.[00:23:39] Avdi Grimm: And it was super limiting. You know, there would be things that people were asking for for years and they just, that feature wasn't a priority for the platform because you're competing, you know, you're competing with all the other people who use the platform. And for, you know, whose feature is most important.[00:23:54] Avdi Grimm: So it was very limiting to use a hosted platform, and I've periodically I try them again and they're always, there's always like something pretty early on, it's like, wow, I really need this feature. And I don't have it. But I've also toyed with building my own. I did that for a few years and you know, what I realized was, if I did that, my show was going to become about building an app to support the show, because that's what I was going to be spending all my time on, because it's a lot of work to build.[00:24:23] Dr. McKayla: It's a lot of work, yeah. [00:24:25] Avdi Grimm: People don't realize, you know, how many features are expected in an application that sells content and serves content and keeps track of people's progress in the content, et cetera, et cetera, et cetera.[00:24:38] Avdi Grimm: And yeah, I just, that was not the show that I wanted to be doing was, you know, I didn't want to be like here's videos about how to build a place that hosts these videos. So WordPress has turned out to be a really happy medium kind of between those two extremes. WordPress is just incredibly mature software.[00:24:56] Avdi Grimm: There's a lot of people in, particularly, the developer world that are kind of biased against WordPress and sadly against like the PHP ecosystem entirely, which I think is really undeserved. There's a lot of really, really good people working in this space. And the ecosystem is just amazing because you can kind of build anything you want and you can get as little or as much support as you want.[00:25:20] Avdi Grimm: You know, it's easy enough to build your own plugins for WordPress to just do a little tweak here, a little tweak there. You know, the architecture of it really supports the idea of exposing everything it does as hooks. And then you can hook your own stuff into those hooks, which is why it has this great plugin ecosystem.[00:25:36] Avdi Grimm: But one of the really cool things about the plugin ecosystem around WordPress is A, there is a plugin for everything, like, anything you might want to do. Somebody has got a plugin for it. And B, usually they have, like, a premium version, which comes with support. And I have had the best experience with premium plugins for WordPress.[00:25:55] Avdi Grimm: Like, you know, people just like being very responsive to the people that are giving them money and coming back and, you know, with bug fixes or like going into the, you know, going into your site and making, figuring out why it's not working. And so it's like, it's one of the rare places I've seen that people are putting out a ton of open-source software, but also getting paid for their work.[00:26:16] Avdi Grimm: Because all these plugins, like the base version at least, is always open source. And then basically you're paying them for maybe some premium features, but mainly for a support contract and, you know, and so people are making their living, creating open-source software. And I think that's pretty cool. And it's also, it also has done really well for my business. [00:26:32] Dr. McKayla: Yeah, and it's true. And so when I'm thinking about your course software, did you get a plugin for that? Or did you have to write it yourself or do you have like a plugin and then extend that on your own? How does that work? You're hosting your videos, but then they're also like, you know, questionnaires, for example, some quizzes, you know, as you said, you see that people, you know, it somehow tracks the progress of the people. It has to know that you're a member that can access that course, the other course. All of that functionality, does it come out of the box with some plugins for WordPress? Or did you have to implement that yourself or was it a mixture that you're actually getting a plugin and then you can, you know, enhance that with your own code?[00:27:15] Avdi Grimm: Great question. So, there are two to three categories of plugins that go into a site like this. I mean, my website has a lot more plugins than that, but there's sort of maybe three basic pieces. And one is  learning management system LMS, otherwise known as courseware. So that's a category of plugins I could probably reel off maybe six of them off the top of my head, I'm personally using LearnDash, which is one of the older ones and one of the more, probably the most popular one in WordPress right now. And it's very mature. It's a little clunky for me sometimes because it's really targeting in many ways, it's targeting like serious learning institutions where they have like accreditation concerns and certificates.[00:27:59] Avdi Grimm: And like, you can't take this course until you take this other course, lot of stuff that I don't care about. On the flip side, it's very mature. They handle all the things that I might want to put into it. They just also, also a lot of stuff that I don't care about. And then, so you've got, like, there's learning management, that's one. There's membership, which is like another whole category of plugins, which are generally focused around, given this account, what material does this person have access to? And that includes courses, like what courses does this person have access to. [00:28:28] Dr. McKayla: So they work nice together, LearnDash and the membership thing. [00:28:30] Avdi Grimm: Yeah, so generally what you see, so I'm using LearnDash on the LMS side, I'm currently using MemberPress, which is one of the more popular membership management plugins.[00:28:39] Avdi Grimm: Generally these plugins, they work hard to work with each other, you know, different teams usually, but they work hard to work with each other because that's where a lot of the value comes from. And so they have explicit support for each other. And then the third piece often is like your e-commerce, how you sell the thing.[00:28:56] Avdi Grimm: And that is often a separate plugin as well. Like in the WordPress ecosystem, it's usually WooCommerce. Sometimes it's EDD, Easy Digital Downloads. Now I've reeled these off like they are distinctly separate categories, but actually almost everyone in each of these spaces will happily give you like all of the above kind of in one.[00:29:18] Avdi Grimm: Because they all kind of, they'd grow, all gradually expand out to include each other's features. So like LearnDash, you can do a pretty basic membership management using the groups that are built into LearnDash. You can sell courses directly. Like they have Stripe integration and stuff directly from LearnDash if you want to, it's kind of basic, but it's totally there.[00:29:36] Avdi Grimm: MemberPress recently introduced their own courseware plugin for MemberPress. You can just like stick with that company if you want, as long as you're okay with like a more basic courseware offering. They also have the storefront part built in if you want to use it. So there's a lot of blur between these plugins as well.[00:29:54] Avdi Grimm: Yeah. [00:29:55] Dr. McKayla: Yeah. Okay, cool. And so are you then enhancing that, is that possible, especially if you have like the paid version, could you just write that? And then how do you keep track of your own changes and new updates that are coming from the team? How do you integrate those things? [00:30:09] Avdi Grimm: So one of the marks of a good industrial strength WordPress plugin is that they have well-defined hooks. You know, I was talking about like, WordPress is built on the concept of hooks. They have well-defined hooks that are documented. And so, like the ones that I work with do, they have good documentation sites and they have all these hooks that you can like, here's how you change this, you know, here's how you hook your own thing into this particular part of the interface or this particular process.[00:30:36] Avdi Grimm: And then, so what I have is what they call a site-specific plugin that I keep under version control, and I have a deployment system for that pushes it out to my way. And my site-specific plugin, basically just very selectively has a few, there's a few hooks where I want to customize something in one of those other plugins.[00:30:54] Avdi Grimm: And it just like hooks its own handler into just the, like the very specific hook that is one tiny piece that I care about changing. It's very small. The site-specific plugin is very small. I try to keep it very small and very focused. [00:31:07] Dr. McKayla: Okay. But so it has a valid defined API or hooks that you can really enhance. You're not going in and hacking in their, in their code base, right? So you're on the outside, whatever they allow you to change. [00:31:18] Dr. McKayla: Yeah. And if you're going to really get into this ecosystem, that's one of the things you want to keep your eye out for is like, does it seem like these people are really supporting that kind of external hooks?[00:31:28] Dr. McKayla: Yeah, it sounds very interesting. And I know quite a couple of people that are running WordPress websites and have a lot of, you know, like you said, WooCommerce, or like a membership sites and they're very, very happy with it. Maybe my last question for you is around, you said you are not going to plan for five years and so on, right? But I think everybody has some, some vision you know, some, some reasons why you'd be doing things like transitioning from RubyTapas to Graceful.Dev, right? What do you see yourself, do you want to do, is there a possibility that Graceful.Dev is really your full time thing and that you're not doing any consulting or do you want to keep doing consulting on the side? Or, you know, where are you heading towards, what's your ideal case?[00:32:16] Avdi Grimm: I wish I had a good answer for you. You know, I want to keep being able to do what feels right at the time, which is kind of what I'm doing right now. You know, Graceful.Dev is supporting me pretty decently along, you know, that alongside of my other, you know, other products and things. You know, I take consulting gigs as they look interesting.[00:32:35] Dr. McKayla: Yeah, and are you a solopreneur or do you have, like, a team that really helps you? [00:32:39] Avdi Grimm: Oh yeah. Good question. I don't have any full-time employees for years and years. I've employed people very part-time here and there, only ever like a handful only ever like maybe three to five at most, at any given time. Actually five is probably more than I have, but like I have somebody that's I've worked with for a long time, that handles kind of first line of support.[00:32:59] Avdi Grimm: So support emails first go to them and then they escalate them to me. I have somebody I'm working with now who's doing a lot of, like, helping me with content, like doing video editing or fixing up blog posts that have become, like their formatting has gone wonky or is out of date or something like that. Yeah. So I have a few people that just like very part-time helpers.[00:33:21] Dr. McKayla: Yeah. I'm currently right now in this position of getting people and I find it really difficult finding the right people because, you know, if you're already in this, okay, I need help now. I don't know how you overcame that stuff, but for me, it's like, I need help now, and I can't grow, you know, without this help. But I also can't really make the time to find the right people and to teach them and do onboarding. [00:33:44] Avdi Grimm: And that is, that is the classic catch-22. And there's no easy way out of it. You know, the point where you absolutely don't have, like, you don't have the overhead space to train somebody, but you need to train somebody in order to get the overhead space.[00:34:00] Avdi Grimm: Yeah, I wish I had an easy answer for that one, like that parts of slog. And eventually you kind of pull your head above it, but it's hard because, yeah, like the effort involved in like getting through that catch-22 is exhausting. I will say this about it. And, and this has informed my work for a long time.[00:34:20] Avdi Grimm: This is the most important kind of scaling to plan for. I think a lot of people in software are completely focused on either financial scaling or on like user scaling, you know, the, your user base scaling up like our, will our code base support unicorn scale. That is by far like the least common form of scaling that you have to support.[00:34:42] Avdi Grimm: The kind of scaling you need to plan for is devolving stuff from yourself. Taking, removing yourself as a bottleneck. That is the most urgent and immediate form of scaling that you're going to face. And so one of the reasons, I have a lot of reasons, but one of the reasons that I use WordPress is because it is the dominant player.[00:35:02] Avdi Grimm: Like, it powers like half the web now, and there is this huge ecosystem. And if I need somebody to do like copy editing, I don't need to teach them how to use GitHub and like commit things, you know, I don't need to find a copy editor, but then teach them how to use my special, precious bespoke system.[00:35:20] Avdi Grimm: They know how to use WordPress, whoever they are, they know how to use WordPress. And you know, if I need to get somebody, you know, if I want some help with my site because I don't have time to diagnose one particular bug, it's really easy to find WordPress consultants, and there's just so many things there where it's easy to find people that can do the thing that you need help with.[00:35:44] Avdi Grimm: And that's just as a general kind of policy. That's one of my biggest considerations when choosing anything is not, you know, not is this going to scale up, but can I scale it away from me? Can, you know, can I remove myself as the bottleneck for this in the future? [00:36:00] Dr. McKayla: Yeah. Yeah. That's such a good mindset. And I'm currently learning a lot with it and you know, it takes much more time and much more energy than I thought, but I also see that, you know, if you have already one person, right, so finding this one person, it means that you have to work with six different people. And then you realize, oh, it's, you know, it's, it's making more trouble that what I'm getting out of.[00:36:23] Avdi Grimm: Yeah. And I should say here, like, use my bad example for learning. I hit a crash at one point where I really wasn't like I was, my outgo was bigger than my income. And a big piece of that was that I had, I had tried to devolve too much of myself. You know, I tried to become too big and pay too many people to do too many different things.[00:36:45] Avdi Grimm: And the funny thing about what was happening there was that I was still swamped. I still had too little time. And it was because I had basically, you know, installed myself as a manager and I was spending all of my time helping people get unstuck and managing things. And so, yeah, it's really easy, like once you, once you kind of start going down that delegation road, it's really easy to go too far. [00:37:10] Dr. McKayla: Yeah. Yeah. I think, I think one step at a time and keeping the focus like I really would like to create more content, have more of this really quality time doing what I love to do like teaching, thinking about content, writing blog posts, right?[00:37:25] Dr. McKayla: This is really what gives me energy and less about the administrative stuff. But then, as you say, I have to be real careful not to get people adding to my administrative stuff. So, yeah. But yeah, very, very good.[00:37:38] Avdi Grimm: I think it's important to always know that like you can do the thing. One of my personal policies is like, anything that I'm thinking of delegating or automating, always do it manually first and do it manually for a while first and get a really good idea of what it is that I'm either delegating or automating.[00:37:55] Avdi Grimm: And usually what I discover is that I can automate less of it than I was planning. And it's enough. Or I can delegate less of it than I was planning and it's enough, but yeah, as it's always very tempting to be like, man, there's this one aspect of my business. I just don't want to think about at all. And so I want to delegate, delegate that part of it.[00:38:13] Avdi Grimm: And I think that's really dangerous though, that leads down that road of like now I'm just jammed up managing everyone and paying too much, you know, not balancing my books. [00:38:22] Dr. McKayla: Yeah. I think that's true. [00:38:25] Dr. McKayla: Do the thing the hard way for a while, figure out the smallest piece of it that you can automate or delegate.[00:38:31] Dr. McKayla: Yeah, cool. So Avdi, thank you so much for sharing all your insights. Is there something like, if there are developers out there that think, oh, I would like to have some side hustle, you know, get a little bit more independence or maybe even go full in, what do you think what is a, is a good strategy nowadays?[00:38:50] Dr. McKayla: You know, when there are already so many, screencasts, when they're already, you know, so many other things, so many blog posts, so many podcasts and so on. What do you think? How should people start doing it? Is a blog still a good first outlet? [00:39:04] Avdi Grimm: There's no going wrong with blogging. Honestly, like, it really doesn't matter like what your plan is. Get good at writing about things. Like, practice writing. It's just that I feel like that skill has informed, has improved so many other aspects of my business and of my career. I mean, writing about what you learn is such great practice for even if you just stay a regular developer, you're going to be a better developer because you are better at explaining and documenting your work to other developers. And so like, yeah, there's just no downside to getting in the habit of writing all the time about the work that you're doing. [00:39:46] Dr. McKayla: Yeah, that sounds good. Yeah, I think so too. I think that's a such a good advice. There's I think there's so many positive things that can come, be that job opportunities or maybe you have to jump on, you know, you get better as, as you said, in your communication skills, better at communicating with your colleagues and so on. So yeah, I think this is a great, this is really a great insight. Thank you so much, Avdi. [00:40:09] Avdi Grimm: Oh, I have one other thing on that, on that note that I should include. Start building your, your mailing list now. [00:40:16] Dr. McKayla: Mailing list, yeah. Good idea. Independent mailing list, I would say.[00:40:20] Avdi Grimm: You know, do that blog thing and then slap, you know, go with ConvertKit or something and slap a mailing list, subscribe on that thing, and just start collecting that snowball now, because that, it takes a long time, but oh my gosh, the opportunities that come out of having a good mailing list. There's nothing else like it.[00:40:38] Dr. McKayla: Yeah, that's true. Yeah. I think that's a great add, great addition to what you said before. So Avdi, thank you so much for taking the time and talking with me and sharing everything with my listeners and yeah, have a good day.[00:40:53] Avdi Grimm: Thank you so much for this. I really enjoyed it. [00:40:55] Dr. McKayla: I enjoyed it too. Thank you so much. Bye bye. [00:40:58] Dr. McKayla: This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send the episode to a friend via email, Twitter, LinkedIn, well, whatever messaging system you use. Or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks. Bye.

Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Emma Bostian (https://twitter.com/EmmaBostian) Ladybug Podcast (https://www.ladybug.dev/) Gerrit (https://www.gerritcodereview.com/) Gregg Tobo the Magician (https://astonishingproductions.com/) Sean Wang - swyx - better twitter search (https://twitter.com/swyx/status/1328086859356913664) Twemex (https://twemex.app/) GitHub Pull Request File Tree Beta (https://github.blog/changelog/2022-03-16-pull-request-file-tree-beta/) Sam Zimmerman - CEO of Sagewell Financial on Giant Robots (https://www.giantrobots.fm/414) TypeScript 4.1 feature (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) The Bike Shed: 269: Things are Knowable (Gary Bernhardt) (https://www.bikeshed.fm/269) TSConfig Reference - Docs on every TSConfig option (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess) Rails I18n (https://guides.rubyonrails.org/i18n.html) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard. And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well. But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful. It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience. But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too. CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this. STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on. Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it. And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it. CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that. The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang. And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well. STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden. CHRIS: It's like they're hiding it. STEPH: Yeah, one of those. [laughs] CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much. STEPH: [laughs] CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now. STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services. So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel. But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that. But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it. CHRIS: You vented a little into the yelling channel; maybe not everything, though. STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through. And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out. CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up. I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well. And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting. But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that. STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with. So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it. CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here. It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me. STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with. CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes. STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know. Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you? CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one. The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat. But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point. So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you. ... STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it. But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly. So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing. But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things. But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings. STEPH: Did you fire everybody? [laughs] CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go. The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that. STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs] CHRIS: Life's tricky, is all I'm going to say. STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better? CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it. STEPH: [laughs] CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up? And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one. STEPH: This is The Bikeshed. We can live up to that name. [laughs] CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind. But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world. But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you. STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle. I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with. CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult. STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us. CHRIS: Prant for life. That's my stance. STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic. I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate? CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript. So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is. And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array. TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array. So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer. And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad. But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this. We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice. STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on. CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct. But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life. STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice. CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct. STEPH: [laughs] That's how that song goes. CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline. But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left. STEPH: [singing] Everything you own in the box to the left. CHRIS: Thank you for doing the needful work there. STEPH: [laughs] Mid-roll Ad And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free. STEPH: I have a question for you that I'd really love to get your opinion on because I myself I'm waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this. So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone. In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test." So this goes with the idea that if you're writing tests and then you're testing text, but it's on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by. And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea. But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test? So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string. I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string. So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see. The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either. So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff? CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that. I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests. This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true. That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined. Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works? STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist. So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see. CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question. And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I've nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend. But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it. STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure. So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text? CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you. STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it. It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys. But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Robby has a candid conversation with Avdi Grimm, a software developer, consultant, coach, speaker, and author of the books, “Confident Ruby” and “Exceptional Ruby” He is also the creator and head gardener of Graceful.Dev. Avdi's opinion on well-maintained software is that it's more about teams than code and the fact that more attention need to be paid on documentation. He emphasizes the value of useful commit messages and conveying the why over the how. He also shares examples of executable documentation. Robby and Avdi dive into what technical debt looks like for different teams and how it can either be taken as a serious course of action or just as a term for areas of friction in a codebase. Avdi shares his experience in organizing technical debt-type tasks and highlights the importance of teams being able to articulate and quantify friction. As organizations continue to adopt the DevOps mindset, there is lingering debate as to whether it is more of a philosophy or a role. Avdi believes that DevOps is less a role and a philosophy, an approach to lifecycle management and how teams are organized around that outlook. Stay tuned to sample more of what Avdi had to share in this resourceful 44-minute episode.Book Recommendations:The Hidden Life of Trees: What They Feel, How They Communicate – Discoveries from a Secret WorldResources Mentioned:The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford Team Topologies - by Matthew Skelton and Manuel PaisThe Field Guide to Understanding 'Human Error'  by Sidney DekkerConfident Ruby By Avdi GrimmExceptional Ruby By Avdi Grimm Helpful LinksAvdi's LinkedInAvdi's TwitterAvdi on GitHubAvdi on YouTubeGraceful.DevSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

00:44 - Pandemic Life * Politics * Healthcare * Society * Work 13:58 - Jay, Happiness, and Fulfillment * Personal Development and Self-Discovery * Brené Brown (https://brenebrown.com/) * Glennon Doyle (https://momastery.com/) * Elizabeth Gilbert (https://www.elizabethgilbert.com/) * Nihilism (https://en.wikipedia.org/wiki/Nihilism) * Manifestation * Gratitude & Daily Journaling * Morning Pages (https://juliacameronlive.com/basic-tools/morning-pages/) * EarlyWords (https://earlywords.io) 29:09 - Witchcraft & Magic * Intention and Ritual * Terry Pratchett (https://en.wikipedia.org/wiki/Terry_Pratchett) * Franz Anton Mesmer (https://www.britannica.com/biography/Franz-Anton-Mesmer) * The Placebo Effect (https://www.webmd.com/pain-management/what-is-the-placebo-effect) * Zenify Stress Relief Drink (https://zenifydrinks.com/) * Effort and Intention Reflections: Mandy: Everyone should journal. Reflect on the past and bring it to the present. Damien: Bringing magic into non-magical environments. Aaron: Ritual, intention, reflection, alignment. 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: DAMIEN: Welcome to Episode 277 of Greater Than Code. I am Damien Burke and I'm joined with Aaron Aldrich. AARON: Hi, I am Aaron and I am here with Mandy. MANDY: Hello, everybody. I'm Mandy Moore and today, it's just the three of us! So if you came expecting more than that, I'm sorry. [laughter] We're what you get today, but hopefully, we can have a great conversation and we were thinking that we would talk about all the things. I'm doing big hand gestures right now because there's been so many things happening since 2020 that are still happening and how our perspectives have changed. For one, I, myself, can tell you I have grown so much as a person in 2 years. And I'm curious to hear how the two of you have been living your lives since the pandemic. DAMIEN: [chuckles] Where to begin. AARON: I know. It's such a good topic because I feel like everyone's had so much to change, but at the same time, it's like, okay, so 2 million years ago at the beginning of this pandemic. I'm now my third place, third job since the beginning of the pandemic as well and wow, I came out as non-binary in the middle of the pandemic [laughs]. So that was a whole thing, too. I think the question I asked earlier is how much have you radicalized your politics over the course of the past 2 years? [laughs] DAMIEN: Yeah, yeah. That's been bouncing around in my head since you said it off mic. Every time I hear the word pandemic now, I think about, “Oh man,” I hesitate on how far to go into this. [laughs] Because I look at the techno-anarchist crypto bros and I can I say that disparagingly and I will say that disparagingly because I was like them. [laughs] I filled out a survey today and they asked like, “How do you rate yourself as on a conservative and liberal scale?” I'm like, “Well, I think I'm super conservative.” And I still do and every time I align with any political policy, it's always an alignment with people who call themselves socialists and leftists and why is that? [laughs] Hmm. [laughter] But anyway, that was the part I was trying not to go back into. [laughs] One of the big realizations in living in a pandemic is that healthcare is not an exclusive good. MANDY: What? [laughter] DAMIEN: That is to say that I cannot, as an individual, take care of my own health outside of the health of the community and society I live in. Didn't know that. In my defense, I hadn't thought about it, [laughs] but that was an amazing realization. AARON: No, I think that was a big thing. I think so much of the pandemic exposed the way our systems are all interconnected. Exposed the societal things. Like so much we rely on is part of the society that we've built and when things don't work, it's like, well, now what? I don't have any mechanism to do anything on my own. What do we do? DAMIEN: Yeah. It's so fundamental in humanity that we are in society. We are in community. We only survive as a group. That's a fundamental aspect of the species and as much as we would like to stake our own claim and move out to a homestead and depend on no one other than ourselves, that is not a viable option for human beings. AARON: Right, yeah. Even out here in rural Vermont with animals and things, we're still pretty dependent on all of the services that are [chuckles] provided around. I'm still on municipal electric service and everything else. There's still dependence and we still rely on our neighbors and everyone else to keep us sane in other ways. DAMIEN: Yeah, and I feel like people in rural areas—and correct me if I'm wrong, I haven't lived in a rural area in maybe ever—have a better understanding of their independence. You know your neighbors because you need to depend on them. In the city—I live in Los Angeles—we depend on faceless institutions and systems. AARON: Yeah. DAMIEN: And so, we can easily be blind to them. AARON: Yeah. I think it mixes in other ways. I get to travel a bit for work and visit cities, and then I end up coming back out into the rural America to live. So I enjoy seeing both of it because in what I've seen in city spaces is so much has to be formalized because it's such a big deal. There are so many people involved in the system. We need a formal system with someone in charge to run it so that the average everyday person doesn't have to figure out how do I move trash from inside the city outside the city. [laughter] We can make that a group of people's job to deal with. Here, it's much more like, “Well, you can pay this service to do it, or that's where the dump is so can just take care of it yourself if you want.” “Well, this farm will take your food scraps for you so you can just bring this stuff over there if you want.” It's just very funny. It just pops up in these individual pockets and things that need group answers are sometimes like pushed to the town. You get small town drama because like everyone gets to know about what's happening with the road and have an opinion on the town budget as opposed to like, I don't know, isn't that why we hire a whole department to deal with this? [laughs] DAMIEN: Yeah, but small town drama is way better than big town drama. The fact that half of LA's budget goes to policing is a secret. People don't know that. AARON: Yeah. DAMIEN: Between the LA Police Department and LA Sheriff's Department, they have a larger budget than the military of Ukraine. That's the sort of thing that wouldn't happen – [overtalk] AARON: Don't look at the NYPD budget then. DAMIEN: Which is bigger still, yeah. [laughter] That's not the sort thing that would happen in a small town where everybody's involved and in that business. AARON: Yeah. It happens in other weird ways, but it's interesting. This is stuff that I don't know how has, if it's changed during pandemic times. Although, I guess I've started to pay attention more to local politics and trying to be like, “Oh, this is where real people affecting decisions get made every day are at the municipal levels, the city level.” These are things that if we pass a policy to take care of unhoused, or to change police budget, this affects people right now. It's not like, “Oh, wow, that takes time to go into effect and set up a department to eventually go do things.” It's like, “No, we're going to go change something materially.” It's hard to compare the two because the town I'm in rents a police officer part-time from the next [laughs] municipality over. So the comparison to doesn't really work. [laughter] DAMIEN: Everybody knows exactly how much that costs, too. AARON: We do. I just had to vote on it a couple Tuesdays ago. [laughter] DAMIEN: So then I think back to how that has impacted – I'm always trying to bring this podcast more into tech because I feel guilty about that. [laughs] About just wandering off into other things. But I think about how that impacts how I work in the organizations I work in. Hmm. I recognize I'm learning more about myself and how much I can love just sitting down with an editor and churn out awesome code, awesome features, and awesome products. That brings me so much joy and I don't want to do anything else. And what we do has impact and so, it's so beneficial to be aware of the organization I'm in what it's doing, what the product is doing, how that's impacting people. Sometimes, that involves a lot of management—I do a lot of product management with my main client now. But also, in other places, you would look at, “Well, okay, I don't need to manage the client's finances”. Not because that's not as important, it's because other people are doing it and I trust how they're doing it. That's something I haven't had elsewhere. The advantage of being with a very small organization is that I have these personal relationships and this personal trust that I couldn't get at one of the vampire companies. What'd they call them? FAANG? AARON: Yeah, FAANG. We've been talking about this because FAANG, but Facebook and Google changed their name. So now, is it just MAAN? DAMIEN: Yeah. AARON: I mean Meta, Alphabet, Apple, Amazon, Netflix, right? DAMIEN: I'm all for the right of individuals to choose what they're called; I don't know if I'm willing to extend that to Facebook and Google. AARON: [laughs] Yeah. DAMIEN: Remember, was it Altria? AARON: Oh, Philip Morris. DAMIEN: Philip Morris, right? AARON: Yeah. DAMIEN: They were just like, “Oh, everything we've been doing is so horrible and harming to society for the past several decades, we'll just change our names and people will forget about it.” AARON: That was Philip Morris. Altria didn't do any of that. DAMIEN: Yeah. Altria didn't do any of that. [chuckles] Yeah, I remember that. AARON: Yeah. I'm curious because I think it's changed for me a bit over this time, too. But I'm curious for folks that have had a sensitivity change to the types of company, not necessarily types of companies, but like, I'm more sensitive to who I'm working for. I think my list of no, I won't work for the X company [chuckles] has probably grown throughout the pandemic and I'm definitely much more critical. Part of it's probably because as in tech we're sort of at an advantage, it is high demand right now and we can be a bit picky about where we work, but I definitely have been [laughs] lately. Much more careful about I'm not just willing to work with anyone. I want someone that's got reasonable values. I interview other companies a lot more and I want to make sure product is not causing harm generally speaking and make sure I get a lot more value alignment out of leadership team and things like that. I don't know if other people have had a similar experience. MANDY: Unfortunately, I haven't had that experience. I'm still working for whoever will give me money. [laughter] But I wish I could do that and I'm currently looking. I mean, I've been trying to break into a full-time DevRel career for I guess, 2 years now and I guess, I'm actively looking. Oh, here we go. If you're hiring, let me know. [laughter] I guess I am. I'm looking for that job that I'm really feeling fulfilled in is right now I'm not feeling that and I think it's because of the pandemic, I've really stopped to think about what I want in my life and how I want to feel. I want to be happy, I want to be passionate about my job, and I want to wake up and not feel scared to open my computer because – [overtalk] DAMIEN: Wow. MANDY: Are they going to tell me they no longer need my service? DAMIEN: Right. MANDY: And it's been demoralizing really, for me recently, especially because I tried to join a developer relations Slack group just a few months ago and they rejected me flat out and they're like, “You do not work in dev full time. You cannot be a part of our group,” and I'm like, “Oh.” So now I'm like, “Hmm, what do I do in tech?” [laughter] I thought I'd been doing DevRel before DevRel was cool. I'm going to humble brag for a minute, but I have single-handedly put this podcast together and put you people together that you didn't even know and you love each other. You get that vibe. I can tell who's going to get – you're going to love this person and you're going to like – [overtalk] DAMIEN: Oh man, you not only put this podcast together, but you are the sustaining force. You are the heart of it. You are the thing where that all the panelists that are connected to. You are one who gets all of the mechanical, everything besides talking in mics. You do everything else and you're maintaining all these relations with these developers. [laughter] MANDY: I never even wanted to be on mic. I just started doing it because everybody was busy and I was like, “I guess I have to step up.” [laughs] DAMIEN: Whatever it takes to get it done, right? MANDY: Well, yeah. I feel like the topics on this show that we talk about are important and they're even important outside of tech that hence, the whole name: Greater Than Code. There are more things out there than our jobs and our work and I just want to be happy. I want to be fulfilled and I want to be passionate about something and so does my dog. AARON: That was a shift for me, too. That was definitely one of the roles I was in during the pandemic and realized my struggle with it so much was it was clashing with that. It wasn't fulfilling for me, it was clashing with my core values, and it was just like, “You know what, I can't do this anymore.” [chuckles] I'm no longer in a place where I have the energy to do a thing I don't like doing, or don't have some care for. There's always something you don't like doing. There's always some crap around every job that like don't like to do or you have to deal with something, but I'm no longer at a place where I can have a whole job that rubs me the wrong way. MANDY: Yeah. It's hard for me. I should feel great about this, but I'm known as the podcast girl. If you have a tech podcast, you should talk to Mandy, but I'm not just a podcast editor! I do so much more than that. I do operation, I do product management, I do writing; there's so much more that encompasses who I am in tech than the podcast girl. I feel like not a lot of people know that and maybe that's my fault because I guess, I haven't really done a good job of putting myself out there to be like, “Hey wait. But I'm –” because for me, it's still a hustle as a single mom. I have to pay the bills. So it's like, I wish I could be more discerning with the jobs that I take and who I work for, but I don't know. I'm just one of those people of the universe. What will be, will be and if it's meant to be, it'll come to me. [laughs] So I don't ever really actively seek and that's probably half of my problem. DAMIEN: Mm. That's funny because I didn't know all those things about you. I pitch you as a podcast producer and again, I live in a LA, I'm involved in the entertainment industry at a slight level, and the word producer there is very, very powerful and very important. A producer is an executive. A producer is person who gets things done, who makes it happen. I'm not entirely sure what a producer does, even though I've done it. MANDY: I'm not even sure what a – [laughs] DAMIEN: Right, because it's never the same thing. MANDY: No. DAMIEN: It's whatever it takes and that skill. AARON: Yeah. DAMIEN: That being able to be know enough about a movie, or theatrical production, or a podcast, to know what it takes, to be able to manage, and sustain and get it done. That's really what it comes down to: get it done. MANDY: That's why it's so hard for me. Everyone's like, “Do you have a resume?” And I'm like, “I don't know what to put on it!” Like, you tell me you need this done, I'll get it done. If I don't know how to do it, I'll figure it out because that's what I've done for 13 years. Like I got hired as Avdi Grimm's virtual assistant because an Indeed.com ad came out and was like, “I need somebody to answer emails for me,” and I'm like, “Don't know why you can't do that yourself, but sure.” [laughter] And then from there, he had a podcast and was like, “Can you edit my podcast?” And I was like, “Sure,” and then I'm Googling what is a podcast. [laughter] I had no clue. So I got here, I think a lot out of luck from being at the right place and talking to the right person at the right time. But I have busted my ass to just learn what people need me to learn and do what people need me to do. I guess, that's maybe what I should just put on the resume. I'll do what you need me to do. I make it happen. DAMIEN: No, no, no. You put on the resume what your next job is going to be doing. MANDY: [laughs] Yeah, so, it's hard when people ask me for my resume. I have like three resumes and I'm like, “This does not, no.” AARON: It's almost more a portfolio at this point, right. I made this thing happen. I made this thing happen. Here's this other thing that I did. Here's another thing I made happen. DAMIEN: Resumes are horrific. They're not good for anybody and the only people who use them are people who need to filter quickly out of large groups and they're not even good for that. I've long aspired to be at a place in my career where I don't need a resume and I might be there. Steve Jobs didn't have a resume. Didn't need a resume. He didn't send his resume to the board to get that job at Apple back. It's ridiculous. MANDY: Well, that's the thing for me. I get most of my work from word to mouth. DAMIEN: Right. MANDY: So until I really lost a big client and I was like, “Oh, I don't have a resume. Don't you know who I am?” [laughter] DAMIEN: But like, they should. [laughter] AARON: Just say the portfolios level. I mean, it's kind of the same thing, right? This is... MANDY: Yeah. AARON: [laughs] Kind of the same thing. It's sort of how my resume is morphed in DevRel proper. It's gone from I still kind of have the resume that's like, “Yeah, I worked into these things internally that might not surface otherwise, but also, here's my speaking portfolio and all the things that I have done over the past 3 years. [laughs] You might know me from all of this stuff instead of what's on this resume.” [laughter] MANDY: Yeah. Of course, once I was getting comfortable enough to want to speak, that's when the whole world shut down. DAMIEN: Yeah. MANDY: So I have no videos of myself speaking anywhere whatsoever. DAMIEN: Well, I think there might be a few podcasts that you appear on. MANDY: There's a few episodes as of late that I have ventured to be on out of keeping the show alive. DAMIEN: And every episode of this podcast, and I think several others, are shits near portfolio, right? [laughter] MANDY: Then I'd have a really wrong resume. [laughs] AARON: We'll figure it out. DAMIEN: Yeah. AARON: You just need the highlights. MANDY: But I don't know, a lot of other things have changed for me over the course of the past 2 years. Just in my personal life, I've gotten sober and that was a really hard thing to do during a pandemic. AARON: Yeah. MANDY: When everybody else was out hoarding toilet paper, I was like, “Oh my God, I need beer,” [laughs] and actually, I did. While everybody was stocking up on those other necessities, I was buying cases of beer and putting them in my garage because I was like, “Oh great, the world's ending and I guess, if that's going to happen, I might as well be drunk.” And then – [overtalk] AARON: I mean, it's a fair argument in your defense. MANDY: But then it became a bad problem because when you're home all day and I was home, I worked from home before this. But everything is so damn depressing and you keep the news on the television and next thing you know, it's lunch time and cracking a beer and I'm like, “Whoa, this is… [laughs] where did this come from?” So no, I got sober and I don't drink anymore and honestly, I have never felt better. I've also become a runner. I got a treadmill and I run a 4, or 5 miles a day and I've lost a good amount of weight, probably a lot from alcohol bloat. DAMIEN: [chuckles] Yeah. MANDY: But it's more for me. It's not even about losing a weight because I don't even own a scale because it's more about how I feel. DAMIEN: Yeah. MANDY: It's what is about how I feel. So when I went to the doctor's office for my yearly checkup on Monday and I got on the scale because they make you, I said, “Whoa,” [laughs] because I didn't even know. For me, it's about how I feel and I think that that's really, what's brought a lot of things into perspective for me is that at our time here on earth is fine. I want to be here for my daughter especially. She's 13 and I want to be healthy for her. I want to be here for my friends. I ask myself why I'm still in York, Pennsylvania and I haven't left because I do have people around here that I care about. DAMIEN: Yeah. MANDY: And other than that, I could take it, or leave it. But because the people who I love are here, that's why I haven't left. DAMIEN: Yeah. MANDY: So that's another thing, the things like the pandemic has just really set me into a lot of personal development work and self-discovery. I journal every day. I read self-help books, which is so weird to me because I was one of those people that were like, “Who are those people that read self-help books?” and now I'm one of them. [chuckles] I want to be Brené Brown and Glennon Doyle's best friend. [laughter] Those two women are my people. Elizabeth Gilbert. I can give you so many names of people and great authors that just inspire the hell out of me and 2 years ago, I was not that at all. AARON: Yeah, I think there's a lot to be said for getting at our time on earth is finite and so, in refocusing on what matters to us. Another way I had a friend put it to me, it's like optimistic nihilism. Look, at the end of the day, we're all going to be dead and none of this matters. So you might as well do what makes you happy, right? [laughs] You might as well do the things that are fulfilling and meaningful and try to make other people have a good time, too. You might as well. DAMIEN: I always thought it was ridiculous that nihilism had such a negative connotation. It was like, “No. Okay. I can believe that and be –” [overtalk] AARON: No pressure. At the end of the day, we're all going to die so, no pressure. Do what do what you need to do. Doesn't matter if you succeed, or fail. MANDY: That's like, I'm one of those people that would rather spend their money on experiences. AARON: Yeah. MANDY: Because I don't care how much money I die with. [laughter] I'd rather use it now and take my kid Disney world, which I did 3 years ago. DAMIEN: Nice. MANDY: And enjoy those experiences rather than have a bank account full of dollars that I can't use. DAMIEN: High score. MANDY: Yeah, high score. DAMIEN: Shout out to thriving in hand wavy. I feel embarrassed about this and I don't talk about it much because so many people are suffering. People I love are suffering. People I work with and deal with on a daily basis are suffering, and bad things are happening. This is the best year of my life. This is better than last year and last year was better than the year before. I just keep getting better and my life just keeps getting more awesome. I don't know if I was going anywhere with that, but solidarity with Mandy, I guess. You bought a treadmill. I bought a rower. MANDY: I feel like honestly, the universe gives back what you put out and I guess, I've become real – a lot of people are like, “You're like, woo-woo witchy now,” and I'm like, “Aha, yeah.” I kind of like that. So I feel like if you manifest things, you can make that happen and yes, there's things happening. Yes, yes, there are so many bad things happening, but sometimes out of self-preservation, you just have to tune all of that out and just be in your immediate dwell. For me, sometimes I'll go a week without watching news and I feel guilty about that a lot, but it's just like, you know what, if something's going to happen, it's going to happen. AARON: I think the best way someone put that to me was anxiety is not activism. MANDY: Yeah. DAMIEN: Yeah. AARON: Right, so just sitting around making yourself anxious and stressed out about everything and whatever emotion you have, making yourself feel bad doesn't improve the situation, it just also makes you feel bad. So it's okay to take a step back and do the self-care that you need to do because just feeling bad isn't fixing the problem either. So step back, find what you can do. Maybe there's stuff you can do here, in your immediate space that you can take action on. MANDY: Exactly. And also, for drinking other people's problems away, – [overtalk] [laughter] AARON: You can't drink other people's – disassociating from other people's problems isn't effective. [laughter] MANDY: No. Let me tell you, I tried. [laughter] DAMIEN: That's such a great statement. Anxiety is not activism, but also the opposite is true. Joy is activism, rest is activism, thriving in a world that doesn't want you to thrive is an act of resistance and activism. Shout out, living a good life. AARON: That's been a good conversation. I think that's easy to forget and I've seen it come up a couple times over the past couple years of what they have been of taking those moments for joy are really important. They can be radical in and of themselves. MANDY: Keep a gratitude journal. There are so many great apps that every day before I go to sleep, I just write one sentence and it gives you an option even to have a picture. So you can snap a picture. Even if it's just like this candle, this candle is burning right here and it smells so good and it's making me happy today. So I'm grateful for the candle. DAMIEN: Yeah, I'm up to approximately 2 years of daily journaling. A buddy of mine got together. We built a daily journaling app based on Morning Pages from The Artist's Way. It's called Early Words. Shout out earlywords.io if you want to join and journal with me. But every day, 750 words. I do it first thing in the morning most days. Stream of consciousness. It has absolutely changed my life. It makes me feel good. It made me a better writer. Not because the writing is good, but because it's taught me to turn off the editor. Writing does have to be good for me to write it. MANDY: Yeah. Big proponent of journaling. AARON: I believe in it. I just don't remember to do it. But that's my own problem. [laughter] DAMIEN: Can we go back? Can we talk about witchcraft? AARON: All right, I'm in. DAMIEN: A friend of mine asked me oh my God, maybe it was a year ago. Maybe it was several months ago. I have no idea. She asked me like, “Do you actually believe in witchcraft? Those magic woo-woo stuff?” It's like, “Well, let me tell you something. Every morning when I wake up in the morning, I make a potion with dried leaves that energizes me. At night, I make a different potion with dried flowers that calm me down and helps me sleep. My literal job is making sand think. Do I believe in witchcraft? I mean, yeah.” [chuckles] MANDY: I mean, it's a full moon today so I have a whole jug of water out charging. I do. I literally have a jug of water on my deck charging for full moon water energy and I use it like, I'll put a little bit in my bath water. I'll put it a little bit of it – I'll cook with it. When I boil some water, put it in there. Does it help? I don't know, but it makes me feel better! DAMIEN: Okay. Wait. It makes you feel better? AARON: Sounds like it's helping. DAMIEN: Doesn't that means it helps? MANDY: Yeah. It does. AARON: Yeah. I think that's a good point. I believe in the power of intention and ritual. There's a reason why humans developed rituals over time and sometimes, it's just for us to feel the right thing. But like, feelings are important? DAMIEN: [laughs] But like, feelings are important. AARON: I don't want to say something controversial on the Greater Than Code podcast such as feelings are important. But they are. Sometimes, while you go through a certain step and it centers you, or you go through a certain set of steps and it makes you feel better, or it helps you process the anxiety you're feeling, or it's like, nope, I need to get centered in my five senses again so I can come back into my body and be here instead of going off on an anxiety spiral. MANDY: Absolutely. AARON: What is witchcraft? I actually love this from Terry Pratchett, one of my all-time favorite authors who does the Discworld series of novels, as a very specific approach to witchcraft, which is like, yeah, yeah, yeah, magic and whatever. But their daily thing is checking on all the people of the village and doing all the work that nobody wants to do. So it's like, how are the elderly doing? Do they need help with anything? Making sure and so takes their bath, making sure this person's animals are taken care of, making sure this sort of thing. Sometimes, it's about appearances and going through the ritual to make sure the community is coming along. Sitting with the dead, all that kind of stuff. And that's witchcraft, that's the bread and butter of witchcraft is knowing the right herbs and poultices to put together, being the heart and soul of the community and being able to get people and helping each other, and move the resources around as needed and that sort of thing. So yeah, I believe in that. [laughs] DAMIEN: Yeah. There was there's a great story and about Anton Mesmer, I learned this shout out to Mary Elizabeth Raines who taught me hypnosis. I learned this when she told me this story when I was doing my hypnosis training about Anton Mesmer, who's considered the [31:10] of hypnotism. He introduced hypnotism to the to the white people. The word mesmerism and magnetic person, magnetic personality, all this comes from Mesmer. He had salons where people would hold onto metal rod that he had “magnetized” and be healed and fall out and screaming have spirit and all that. But Mesmer was very popular and very powerful and the king of France did not like this. The king of France put together a blue-ribbon commission. I don't know if he called it a blue-ribbon commission. Probably not because he spoke French, but put together a commission of scientists to discredit Mesmer. One of these scientists was Ben Franklin, by the way. So they did a double-blind study. They did a proper double-blind test. They had Mesmer come out and magnetize a tree. That was a thing he did. He would magnetize trees, people would come out and hug the trees and then they'd be healed. So they did a study. They had to magnetize the tree and they brought people out who were sick and they said, “Hug that tree. That's magnetized and you'll be healed.” Some of the trees Mesmer had magnetized, some he hadn't and it turns out it didn't matter. People were still healed and so, they all came to conclusion, “All right. See, Mesmer's not doing anything. It's all placebo effect.” Mesmer was run out of town and lived in exile for the rest of his days. Nobody bothered to ask why were the people healed? Everybody knows placebo effect is a real effect. Nobody's like, “How do we make it more effective? Why is it working this way? What do we do it? What do we do with that? How can we use that?” MANDY: Yeah. AARON: No, I think it's a super interesting thought. The placebo effect is a powerful and interesting concept overall. We did ourselves a disservice to not understand it. DAMIEN: Yeah. To dismiss it as if it doesn't exist. Not only does it exist, it's increasing. AARON: Hmm. DAMIEN: Because people are getting more powerful. MANDY: Yeah. I'm drinking this Zenify Stress Relief Drink. [chuckles] And does it work? I don't know, but it's delicious and you know what? It makes me happy. You know why? Because it's not alcohol. [laughter] So it's not having a negative effect on me. I'm not getting drunk and doing stupid things. Is it taking away? My stress? Eh. I mean, but I love it. I love it and it makes me feel good. It's a treat. It's a special drink. I have one a day and it's one of those things that instead of missing my case of White Claw Seltzer. I know, I know, I wasn't even a bougie – well, I wasn't even a good drinker. That's what made it a problem. [laughs] AARON: This is far too affordable. MANDY: I was not a discerning drinker, so. [laughs] No, I have my one bougie drink that I have and it makes me feel good. Does it relieve my stress? I don't know, but I don't care either. DAMIEN: Yeah. If it works, it works. One of the great things about placebos is they don't – well, I was going to say they don't have to be expensive, but sometimes it works better when they're expensive. [laughs] MANDY: Moon water is free. DAMIEN: Moon water is, yeah. But, well, it's not free actually. You had to put an effort and intention. MANDY: True. DAMIEN: And I think if you didn't, it wouldn't be as effective. AARON: Effort and intention go a long way. DAMIEN: [laughs] That's a root of magic, isn't it? MANDY: Why can't I just get paid for effort and intention? [laughs] AARON: I mean, if I put my effort and intention into this money tree. [laughter] I've always thought it would be nice if real world jobs worked like Animal Crossing. Like, “Oh, so I can just go pick some stuff up and then you're just going to give money and then we can just move on? Great.” “Now look, I dug up a bag of money. If I just plant this bag of money, I'll get more money. It's fine.” [laughs] DAMIEN: I'm trying to bridge that gap. That's such a great question like when effort and intention is so well, literally magical, why does it seem to not have the impact we want in nonmagical environments, I'll call them? AARON: Mm. DAMIEN: I asked that question because I want to know what to do about that. I want to bring magic to nonmagical environment, to city council, to retail stores. I almost named an online retail store; I don't want to name it. [laughs] But it's a city council to corporate interactions. And there's no reason you can't. Corporations are people. Governments are people. I think requires dealing with them in individually in ways that we're not used to. AARON: Yeah. It's a good question. You've got to be really thinking about… MANDY: My wheels are turning. AARON: Yeah. I mean, I think part of it is effort and intention are always going to make the most effect for you because most of it is about aligning your thought processes. It's about taking the, I don't know, I'm just taking this into making the best decision I can to like, okay, if I can focus on this is my goal and my aim and what I'm after, suddenly all of the patterns emerge around that. Oh, now I'm ready for that opportunity, or oh, now this thing is working out, and oh, now this is what is working out because I've focused on my intentions and where I want to put my efforts. I think there's room for these things in other groups. Gets back to what I was thinking about ritual, about how humans are tuned for ritual to tell themselves story. We're tuned for storytelling and ritual and all this sort of thing. So I think there's room from a tech perspective, I'm thinking about what comes to mind quickly is incident management stuff. Sorry, I'm coming off of SRECon this week so, everything's going to be around that. DAMIEN: Our apologies. [laughter] It's all right. AARON: It was fantastic, but it's a different podcast. [laughs] But think about that, right? When you're coming in and doing instant reports, it's so powerful is it to set the intention of the meeting, or any meeting that you have and say, “We are here for this purpose. This is what we're looking to find. We're not looking to do –” Back when Chef had lots to say about this, they'd have those things like we're not here to determine what could have, or should have happened. We're here to find out what did and move the thing. So it's all about setting the intent of that gathering and what outcomes you're after and it focuses the whole conversation can make that meeting more powerful because you've set the focus right off the bat. I think there's room for that other places, too. DAMIEN: That's such a beautiful way of saying it. You described it as setting an attention. AARON: Yeah. S: Whereas, in corporate speak, I would describe it as setting an agenda. AARON: Right, and an agenda is one thing. It's kind of like, “Hey, here's kind of the stuff we're going to do,” but to be like, “We are gathered for this purpose to [laughs] cover this thing.” DAMIEN: No, no. AARON: Right. DAMIEN: Dearly beloved, dear colleague. AARON: Right? Yeah, right. DAMIEN: We are gathered here for this purpose. AARON: Yeah. I mean, we say it this way in personal stuff, why don't we –? Like, it's useful. [laughs] MANDY: It really is. DAMIEN: Because how are you ever going to get something done if you don't know what you're there for? AARON: Right. DAMIEN: Well, you're going to get something done. If you don't have a destination, any road you take is fine. AARON: If you don't have any intention set, it's a series of meetings that could have been emails. [laughter] And then maybe that's the power of it, in a nonmagical space, is forcing yourself to go through this thought process of why am I doing this? Why are we here? What do we want to accomplish? Can probably trim so much of the cruft from all of our meetings and engagements. DAMIEN: That was my favorite sentence as a product manager: what is it you're trying to accomplish? [chuckles] AARON: I say that a lot, DAMIEN: But it is a very, very powerful question. AARON: Especially when you have children asking to use dangerous tools. [laughter] What is it you're trying to accomplish? Maybe we don't need to bust out razor blades. [laughs] DAMIEN: So from an SRE standpoint, when you get together for – what do you call that meeting? An incident review postmortem? Postmortem is a bit – [overtalk] AARON: Yeah, yeah. Post-incident report. There's a handful of names for that reason, but post-incident review. MANDY: Retrospective. DAMIEN: Retrospective, yeah. So the question is, what is it you are trying to accomplish? AARON: Right. DAMIEN: I'm trying to find somebody to blame. AARON: And not blaming. DAMIEN: I'm trying to find somebody to blame so that I look good in my next performance review. AARON: Well, that's what was so important about doing that because that's the shift we're, largely as an industry, trying to make. Finding a person to blame doesn't learn anything about what happened and will teach us nothing for next time. So if we set the intention of like, we're trying to learn from this incident and how we can improve or what we can do better, or maybe there's nothing. Maybe this was just a fluke and let's find that out. That's what we're here to learn. But we're not here to point fingers, or find a root cause because root causes are for plants. [laughter] AARON: Again, that's a whole other podcast. [laughs] MANDY: At the beginning of the pandemic, I owned zero plants. Now, I think I'm the proud plant mother of 20? [laughs] DAMIEN: Wow. AARON: That's amazing. MANDY: I know. AARON: My problem is I can't keep things alive. MANDY: Well, mostly they're all thriving because I set the intention that I was not going to mess this up. [laughter] DAMIEN: There you go. Do you give them moon water? MANDY: I do. DAMIEN: Apparently, it's working. MANDY: I do. Do we want to do some reflections? DAMIEN: Sure. Let's do it. MANDY: I'll start us off. With this conversation, we were just having about the intention and stuff. This is why I think everybody should journal, including CEOs and leaders. Get out a journal, what do you want, and then look back at some of the stuff. I don't it often, but I go back and I'm like, “Oh yeah.” Just reflecting on what you've written in the past and bringing that to the present can really help you put stock in all the things that you want and should be accomplishing. DAMIEN: Yeah. This bringing magic into nonmagical environments and journaling is part of that. A shout out to journaling. Another plug for earlywords.io that I own. Come journal with me because it is a magical thing. It is a ritual I do daily. That clears my mind. That is a practice of the listening to myself. It is a practice of letting go and not controlling what's coming out. Along with that and all the other sort of ways I know of being that I can call magic, I can call hypnotism, I can call NLP, I can call ontological coaching I've done a lot, bringing that into environments where I haven't because they're so useful there and we talked about some of the ways they are and so, we really confirmed more ways of doing that. AARON: I think the things I'm thinking about after this conversation are ritual, intention, and reflection are the big things that are standing up. I think this pandemic, for instance, and how things have changed is because I've had just so much time to have to sit alone by myself and reflect on what's going on externally and internally. But yeah. Anyway, just about setting intentions, of understanding the directions you want to go before going, making sure you're aligned with your goals, and you're not just accidentally wandering down paths that you don't want to be down and turning around and finding out your miserable 10 months later. I think I've thought a lot about the power of even small rituals just to interrupt our standard thought processes and align ourselves with those kind of things. There's been a lot from basic health stuff of here are the rituals I can go through when I'm feeling anxious and I know they'll calm me down to writing in a journal, or directing a group to [laughs] let's align our thought processes. It can be super useful. DAMIEN: Absolutely. MANDY: Awesome. Well, this has been a really fun conversation. I'm glad we just had a panel only episode and I'd love to do more of these in the future. They're really cool. We didn't come to the show with much of an agenda and hopefully, you dear listener, appreciate it. If you would like to give us some feedback, we'd appreciate it. Tweet at us. Join our Slack. AARON: Hire Mandy. DAMIEN: Tell your friends. MANDY: DM me. [chuckles] Tell your friends. DAMIEN: Tell your enemies. MANDY: Tell your enemies, too! [chuckles] We'll see you all next week.

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.

On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and some specific tips for improving. Rails Autoscale (https://railsautoscale.com/) Rubular regex playground (https://rubular.com/) The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) Go Ahead, Make a Mess by Sandi Metz (https://www.youtube.com/watch?v=xi3DClfGuqQ) Confident Code - Avdi Grimm (https://www.youtube.com/watch?v=T8J0j2xJFgQ) Therapeutic Refactoring - Katrina Owen (https://www.youtube.com/watch?v=J4dlF0kcThQ) Refactoring, Good to Great - Ben Orenstein (https://www.youtube.com/watch?v=DC-pQPq0acs) Transcript CHRIS: There's something intriguing about the fact that we're having this conversation, but the thing that's recorded just starts at this arbitrary point in time, and it's usually us rambling about golden roads. But, I don't know; there's something existential about that. STEPH: It's usually when someone says something very funny or starts singing [laughs], and then that's when we immediately: record, record! CHRIS: I've never sung on the mic. That doesn't sound like a thing I would do. STEPH: [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So Steph, how's your week going? STEPH: Hey Chris, it's going really well. Normally I'm always like, wow, it's been such an exciting week, and it's been a pretty calm, chill week. It's been lovely. CHRIS: That sounds nice actually in contrast to the "Well, it's been a week," that sort of intro of "I don't know, it's been fine. It can be really nice." STEPH: By the time we get to this moment of the week, I either have stuff that I'm so excited to talk about and have a little bit of a therapy session with you or share something new that I've learned. I agree; it's nice to be like, yeah, it's been smooth sailing this whole week. In fact, it was smooth sailing enough that I decided to take on something that I've been meaning to tackle for a while but have just been avoiding it because I have strong feelings about this, which you know but we haven't talked about yet. But it comes down to managing emails and how many emails one should have that are either unread that are just existing. And I fall into the category of where I am less scrupulous about how many unread or managed emails that I have. But I decided that I'd had enough. So I used a really nice filter in Gmail where I said I want all emails that are before 2021 and also don't have a user label, so it's has:nouserlabels because then I know those are all the emails that I haven't labeled or assigned to a particular...I want to say folder, but they're not truly folders; they just look like folders. So they're essentially like untriaged or just emails that I've left hanging out in the ether. And then I just started deleting, and I got rid of all of those that hadn't been organized up until that point. And I was just like yep, you know if I haven't looked at it, it's that old, and I haven't given a label by this point, I'm just going to move on. If it's important, it will bubble back up. And I feel really good about it. CHRIS: Wow, that is -- I like how you backed me into a corner. Obviously, I'm on the other side where I'm fastidiously managing my email, which I am, but you backed me into that corner here. So, yeah, that's true. Although the approach that you're taking of just deleting all the old email that's a different one than I would have taken [chuckles] so, I like it. It's the nuclear option. STEPH: Okay, so now I need to qualify. When you delete an email, initially, I'm thinking it's going to trash, and so it's still technically there if I need to retrieve it and go back and find it. But you just said nuclear option, so maybe they're actually getting deleted. CHRIS: They're going into the trash for 30 days; I think is the timeline. But after that, they will actually delete them. The archive is supposed to be the place where you put stuff I don't want to see you anymore. But did you archive or delete? STEPH: Oh, I deleted. CHRIS: Oh, wow. Yeah. All right, you went for it. [laughter] STEPH: Yeah, and that's cool. And it's in trash. So I basically have a 30-day window where I'm like, oh, I made a mistake, and I need to search for something and find something and bring it back into my world; I can find it. If I haven't searched for it by then in 30 days, then I say, you know, thanks for the email, goodbye. [chuckles] And it'll come back if it needs to. CHRIS: I like the approach. It would not be my approach, but I like the commitment to the cause. Although you still have...how many emails are still in your inbox now? STEPH: Why do we have to play the numbers game? CHRIS: [laughs] STEPH: Can't we just talk about the progress that I have made? CHRIS: What wonderful progress you've made, Steph. [laughter] Like, it doesn't matter what I think. What do you think about this? Are you happy with this? Does this make you feel more joy when you look into your email in the Marie Kondo sense? STEPH: It does. I am excited that I went ahead and cleared all this because it just felt like craft. So I have taken what may be a very contentious approach to my email, where I treat it as this searchable space. So as things come in, I triage them, and I will label them, I will star them. I will either snooze them to make sure I don't miss the high actionable emails or something that's very important to me to act on quickly. But for the most part, then a lot of stuff will sit in that inbox area. So it becomes like this junk drawer. It's a very searchable junk drawer, thanks to Google. They've done a great job with that. And it feels nice to clear out that junk drawer. But I do have such an aversion to that very strong email inbox zero. I respect the heck out of it, but I have an aversion; I think from prior jobs where I was on a team, and we could easily get like 800 emails a day. My day all day was just triaging and responding to emails and writing emails. And so I think that just left a really bitter experience where now I just don't want to have to live that life where I'm constantly catering to what's in my inbox. CHRIS: That's so many emails. STEPH: It was so many emails. We were a team. It was a team inbox. So there were three of us managing this inbox. So if someone stepped away or if someone was away on vacation, we all had access to the same emails. But still, it was a lot of emails. CHRIS: Yeah, inbox zero in a shared inbox that is a level that I have not gotten to but getting to inbox zero and actually maintaining that is very much a labor of love and something that I've had to invest in. And it's probably not worth it for most people. You could convince me that it is not worth it for me, that the effort I'm putting in is too much effort for not enough reward. Well, it's one of those things where I find the framing that it puts on it, like, okay, I need to process my email and get it to zero at least once a day. Having that lens makes me think about email in a different way. I unsubscribe from absolutely everything. The only things that are allowed to come into my email are things that I will act on that actually deserve my attention, and so it forces that, which I really like. And then it forces me to think about things. I have a tendency to really hold off on decisions. So I'm like, ah, okay. I can go see friends on Saturday or I can do something else. Friends like actual humans, not the TV show, although for the past year, it's definitely more of the TV show than the real people. But let's say there's a potential thing that I could do on the weekend and I have to decide on that. I have a real tendency to drag my feet and to wait for some magical information from the universe to help this decision be obvious to me. But it's never going to be obvious, and at some point, I just need to pick. And so for inbox zero, one of the things that comes out of it for me is that pressure and just forcing me to be like, dude, there's no perfect answer here, just pick something. You got to just pick something and not wasting multiple cycles rethinking the same decision over and over because that's my natural tendency. So in a way, it's, I don't know, almost like a meditative practice sort of thing. There's utility there for me, but it is an effort, and it's, again, arguably not worth it. Still, I do it. I like it. I'm a fan. I think it's worth it. STEPH: I like how you argued both sides. I'm with you. I think it depends on the value that you get out of it. And then, as long as you are effective with whichever strategy you take, then that's really what matters. And I do appreciate the lens that it applies where if you are getting to inbox zero every day, then you are going to be very strict about who can send you emails about notifications that you're going to receive because you are trying to reduce the work that then you have to get to inbox zero. So I do very much admire that because there are probably -- I'm wasting a couple of minutes each day deleting notifications from chats or stuff that I know I'm not necessarily directly involved in and don't need action from me. And then I do get frustrated when I can't adjust those notification settings for that particular application, and I'm just subscribed to all of it. So some of it I feel like I can't change, and then some of it, I probably am wasting a few minutes. So I think there's totally value in both approaches. And I'm also saying that to try to justify my approach of my searchable inbox. [laughs] CHRIS: There are absolutely reasons to go either way. And also, to come back to what I was saying a minute ago, it may have sounded like I'm a person who's just on top of this. I may have given that impression briefly. I think the only time this has actually worked in my life is when Gmail introduced snooze both in the mobile app and on the desktop. So this is sometime after Google's inbox product came out, and that was eventually shut down. So it's relatively recent because, man, I just snooze everything. That is the actual secret to achieving inbox zero, just to reach the end of the day and be like, nah, and just send all the emails to future me. And then future me wakes up and is like, "You know, it's first thing in the morning. I got a nice cup of coffee, and this is what you're going to do to me, past me?" So there's a little bit of internal strife there within my one human. But yeah, the snoozing is actually incredibly useful and probably the only way that I actually get things done and the same within any task management system that I have; maybe future me will do this. STEPH: I think you and I both subscribed to the that's a future me problem. We just do it in very different ways. But switching gears a bit, how's your week been? CHRIS: It's been good, pretty normal, doing some coding, normal developer things. Actually, there's one tool that I was revisiting this week that I'm not sure that we've actually talked about on the show before, but it's Rails Autoscale. Have you used that before? STEPH: I don't think I have. It sounds very familiar, but I don't think I've used it. CHRIS: It's a very nice, straightforward Heroku add-on that does exactly what you want it to do. It monitors your web and worker dynos and will scale up. But it uses a different heuristic than -- So Heroku has built-in autoscaling, but theirs is based on response time, which is, I think, a little bit laggier of a metric. Like if your response time has gotten bad, then you're already in trouble, whereas Rails Autoscale uses queue time. So how long is a request waiting before? I think it's at the Heroku router; it goes onto the dyno that's actually going to process the request? So I think that's what they're monitoring. I may be wrong on that. But from the website, they're looking at that, and you can configure it. They actually have a really nice configuration dashboard for configure between this range, so one to five dynos at most, and scale in this way up and in this way down. So like, how long should it wait? What's the threshold of queue time? Those sorts of things. So they have a default like just do the smart thing for me, and then they give you more control if your app happens to have a different shape of data, which is all really nice. And then I've been using that for a while, but I recently this week actually just turned on the worker side. And so now the workers will autoscale up and down as the Sidekiq queue -- I think for the Sidekiq side, it's also the queue time, so how long a job sits in the queue before getting picked up. And there are some extra niceties. It can actually infer the different queue names that you have. So if you have a critical, and then a mailer, and then a general as the three queues that Sidekiq is managing, you really want critical to not back up. So you can tell it to watch that one but ignore the normal one and only use -- Like, when critical is actually getting backed up, and all the other stuff is taken over then -- Again, it's got nice knobs and things, but mostly you can just say, "Turn it on and do the normal thing," and it'll do a very smart thing." STEPH: That does sound really helpful. Just to revisit, so Heroku for autoscaling, when you turn that on, I think Heroku does it based on response times. So if you get into a specific percentile, then Heroku is going to scale up for you to then bring down that response time. But it sounds like with this tool, with Rails autoscaling, then you have additional knobs like the Sidekiq timing that you'd referenced. Are there some other knobs that you found really helpful? CHRIS: Basically, there are two different sides of it. So web and background jobs are going to be handled differently within this tool, and you can actually turn them on or off individually, and you can also, within them, the configurations are specific to that type of thing. So for the web side, you have different values that you can set as the thresholds than you do on the Sidekiq side. Overall, the queue name only makes sense on the Sidekiq side, whereas on the web side, it's just like the web requests all of them 'Please make sure they're not spending too much time waiting for a dyno to actually start processing them.' But yeah, again, it's just a very straightforward tool that does the thing that it says on the tin. I enjoy it. It's one of those simple additions where it's like, yeah, I think I'm happy to pay for this because you're just going to save me a bunch of money every month, in theory. And actually, that side of it is certainly interesting, but more of my app will be responsive if there is any spike in traffic. There's still plenty of other performance things under the hood that I need to make better, but it was nice to just turn those on and be like, yeah, okay. I think everything's going to run a little better now. That seems nice. But yeah, otherwise, for me, a very straightforward week. So I think actually shifting gears again, we have a listener question that we wanted to chat about. And this is one that both of us got very interested to chat about because there's a lot to this topic, but I'm happy to read it here. So the overall topic is improving as a developer, and the question goes, "How do you know you're improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I'm improving, I have no way of measuring the improvement. It's only a gut feeling. Thanks. Love the show." And this comes from Tom. Thank you, Tom. Glad you enjoy the show. So, Steph, are you improving as a developer? STEPH: I love this question. Thanks, Tom, for sending it in because it is one that I think about but haven't really verbalized, and so I'm really excited to dive into this. So am I improving as a developer? It comes down to, I mean, we first have to talk through definitions. Like, what does it mean to become a better developer? And then, we can talk through metrics and understanding how we're getting there. I also love the other questions, which I know we'll get to. I'm just excited. But are there any regressions? And also, in my mind, they already answered their own question. But I'm getting ahead of myself. So let me actually back up. So how do you know you're improving as a developer? There are a couple of areas that come to mind. And for me, these are probably more in that space of they still have a little bit of a gut feeling to them, but I'm going to try hard to walk that back into a more measurable state. So one of them could be that you're becoming more comfortable with the work that you're doing, so if you are implementing a new email flow or running task on production or writing tests that become second nature, those types of activities are starting to feel more comfortable. To me, that is already a sign of progress, that you are getting more comfortable in that area. It could be that time estimates are becoming more accurate. So perhaps, in the beginning, they're incredibly -- like, you don't have any idea. But as you are gaining experience and you're improving as a developer, you can provide more accurate estimates. I also like to use the metric of how many people are coming to you for help, not necessarily in hard numbers, but I tend to notice when someone on a team is the person that everybody else goes to for help, maybe it's just on a specific topic, maybe it's for the application in general. But I take that as a sign that someone is becoming very knowledgeable in the area, and that way, they're showing that they're improving as a developer, and other people are noticing that and then going to them for help. Those are a couple of the ones that I have. I have some more, but I'd love to hear your thoughts. CHRIS: I think if nothing else, starting with how would we even measure this? Because I do agree it's going to be a bit loose. Unfortunately, I don't believe that there are metrics that we can use for this. So the idea of how many thousand lines of codes do you write a month? Like, that's certainly not the one I want to go with. Or, how many pull requests? Anything like that is going to get gamified too quickly. And so it's really hard to actually define truly quantifiable metrics. I have three in mind that scale the feedback loop length of time. So the first is just speed. Like, how quickly are you able to do the same tasks? So I need to build out a page in Rails. I need a route; I need a controller. I need a feature spec, those sort of things. Those tasks that come up over and over: are you getting faster with those? That's a way to measure. And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster. And so the idea is you're doing the same work over time, but you just get a little bit faster, and you're always trying that edge of your capabilities. And so that idea of it never gets any easier, but you are getting faster. I like that framing. We should be doing the same work. We should never get too good for building a crud app. That's my official stance on the matter; thank you very much. But yeah, so that's speed. I think that is a meaningful thing to keep an eye on and your ability to actually deliver features in a timely fashion. The next one would be how robust are the things that you're building? What's the bug count? How regularly do you have to revisit something that you've built to change it, to tweak it either because it doesn't exactly match the intent of the feature that you're developing or because there's an actual bug in it? It turns out this thing that we do is very hard. There are so many moving pieces and getting the design right and getting the functionality just right and handling user input, man, that's tricky. Users will just send anything. And so that core idea of robustness that's going to be more on a week scale sort of thing. So there's a little bit of latency in that measure, whereas speed that's a pretty direct measure. The third one is…I don't know how to frame this, but the idea of being able to revisit your code either yourself or someone else. So if you've written some code, you tried to solve a problem; you tried to encode whatever knowledge you had at the given time in the code. And then when you come back three months later, how easy is it to revisit that code, to change it, to extend it either for yourself (because at that point you've forgotten everything) or for someone else on the team? And so the more that you're writing code that is very easy to extend, that is very easy to revisit and reload that context into your head, how closely the code maps to the actual domain context I think that's a measure as well that I'm really interested in, but there's the most lag in that one. It's like, yeah, months later, did you do a good job? And so the more time you spend, the more you'll have a measure of that, but that's definitely the laggiest of the measures that I have in mind. STEPH: I love that adage that you shared that it never gets easier, but you get faster. That feels so relevant. I really like that. And then I hadn't considered the robustness. That's a really nice one, too, in terms of how often do you have to go back and revisit issues that you've added? CHRIS: You just write code without bugs; that's why you don't think about it. STEPH: [laughs] Oh, if only that were true. CHRIS: Yeah, if only that were true of any of us. STEPH: To keep adding to the list, there are a couple more that come to mind too. I'd mentioned the idea that certain tasks become easier. There's also the capability or the level of comfort in taking on that new, big, scary, unknown task. So there is something on the Teams' board where you're like, I have no idea how to do that, but I have confidence that I can figure it out. I think that is a really big sign that you are growing as a developer because you understand the tools that'll get you to that successful point. And maybe that means persuading someone else to help you; maybe it means looking elsewhere for resources. But you at least know how to get there, which then follows up on your ability to unblock yourself. So if you are in that state of I just don't know what to do next, maybe it's Googling, or maybe it is reaching out for help, but either way, you keep something moving forward instead of just letting it sit there. Another area that I've seen myself and other people grow as developers is our ability to reason about quality and speed. It's something that I feel you, and I talk about pretty often here on the show, but it comes down to our ability to not just write code but then to also make good decisions on behalf of the company that we are working for and the team that we're working with and understanding what matters in terms of what features really need to be part of this MVP? Where can we make compromises? And then figuring out where can we make compromises to get this out to market? But what's really important then for circling back to your idea of revisiting the code, we want code that we can still come back and trust and then easily maintain and make updates to. And then I feel like I'm rambling, but I have a couple more. Shall I keep going? CHRIS: Keep going. Those are great. STEPH: All right. So for the others, there's an increase in responsibilities that I notice. So, in addition to people coming to you more often for help, then it could be that you are receiving more responsibilities. Maybe you are taking on specific ownership of the codebase or a particular part of the team processes. Then that also shows that you are improving and that people would like you to take leadership or ownership of certain areas. And then this one, I am throwing it in here, but your ability to run a meeting. Because I think that's an important part of being a good developer is to also be able to run a meeting with your colleagues and for that to be a productive meeting. CHRIS: Cool. I like that one. I think I want to build on that because I think the core idea of being able to run a meeting well is communication. And I think there's one level of doing this job where it's just about doing the job. It's just about writing the code, maybe some amount of translating a specification or a ticket or whatever it is into the actual code that you need to write. But then how well can you communicate back out? How well when someone in project management says, "Hey, we want to build an aggregated search across the system that searches across our users, and our accounts, and our products, and our orders, and our everything." And you're like, "Okay. We can do that, but it will be hard. And let's talk about the trade-offs inherent in that and the different approaches and why we might pick one versus the other," being able to have that conversation requires a depth of knowledge in the technical but then also being able to understand the business needs and communicate across that boundary. And I think that's definitely an axis on which I enjoy pushing on as I'm continuing to work as a developer. STEPH: Yeah, I'm with you. And I think being a consultant and working at thoughtbot heavily influences my concept of improving as a developer because as developers, it's not just our job to write code but to also be able to communicate and help make good decisions for the team and then collaborate with everyone else in the company versus just implement certain features as they come down the pipeline. So communication is incredibly important. And so I love that that's one of the areas that you highlighted. CHRIS: Actually speaking of the communication thing, there's obviously the very human-centric part of that, but there's, I think, another facet of technical communication that is API design. When you're writing your code, what do you choose to expose and make accessible to collaborators? And I don't just mean API in the terms of a REST API that people are heading, but I mean a class that you have in your system. What are the private methods, and what are the public methods? And how do you think about the shape of it? What data do you expose? What do you not expose? And that can be really impactful because it allows how can you change things over time? The more that you hide, the more you can change. But then, if you don't allow your collaborators to access the bits that they need to be able to work with your system, that's an interesting one that comes to mind. It also aligns with, I don't think you were saying this exactly, but the idea of taking on more amorphous projects. So like, are you working within a system and adding a new feature, or are you designing a system? Are you architecting? The word architect that role can sometimes be complicated within organizations, but that idea of I'm starting fresh, and I'm building a system that others will then work within I think this idea of API design becomes really interesting in that context. What shape do you give to the system that we're working within, and what affordances? And all of that. And that's a very hard thing to get right. So it comes from experience of being like, I used some stuff in the past, and I hated it, so when I am the architect, I will build it better. And then you try, and you fail, and you're like, well, okay, but now I've learned. And then you try it, and then you fail for different reasons. But the seventh time you try, it may be just that time you get the public API just right on the first go. STEPH: Seven times's a charm. That's how that goes, right? CHRIS: That is my understanding, yes. STEPH: I think something that is related to the idea of are you working in a structured space versus working in a new space and then how you develop that API for other people to work with. And then how do you identify when to write a test and what to test? That's another area that you were just making me think of is that I can tell when someone has experience with testing because they know what to test and what feels important to test. And essentially, it comes down to can I deploy with confidence? But there are a lot of times, especially if you're new to testing, that you're going to test everything, and you're going to have a lot of probably useless slow tests. But over time, you will start to realize what's really important. And I think that's one of the areas where then it does start to get harder to measure yourself as a developer because all of our jobs are different, and we work with different tech stacks, and we all have our unique responsibilities and goals. So it may be hard to say specifically like, "Oh, you're really good at X, Y, and Z, and that's how you know that you're improving as a developer." But I have more thoughts on that, which we'll get to in a moment where Tom mentioned that they don't have a way of measuring improvement. Shall I go ahead and jump ahead to I have no way of measuring that improvement, or shall we talk about regressions next? CHRIS: I'm interested in your thoughts on the regressions question because it's not something that I've really thought about. But now that he's asked the question, I'm thinking about it. So yeah, what are your thoughts on that? STEPH: My very quick answer is yes, [laughs] that there are regressions mainly because I respect that our brain can only make so much knowledge readily available to us, and then everything else goes into long-term storage. We can access it at some point, but it takes additional time, or maybe it takes some practice to recall that skill. So I do think there are regressions, and I think that's totally fine that we should be focused on what is serving us most at the moment and be okay with letting go of some of those other skills until we need to refine them again. CHRIS: Yeah. I think there's definitely a truth to true knowledge and experience with, say, a framework or a language that can fade. So if I spend a lot of time away from JavaScript, and then I come back, I'm going to hit my head on a few low ceilings every once in a while for the first couple of days or weeks or whatever it is. It was interesting actually that Tom highlighted the idea of he used to not write comments, and now he writes more comments, and so that transition -- I think we've talked about comments enough so our general thinking on it. But I think it's totally reasonable for there to be a pendulum swing, and maybe there's a slight overcorrection. And you read some blog posts that tell you the truth of the world, and suddenly, absolutely no comments ever that's the rule. And then, later on, you're like, you know, I could really use a comment here. And so you go that way, and then you decide you know what? Comments are good, and you start writing a bunch of them. And so it's sort of weaving back and forth. Ideally, you're honing in on your own personal truth about comments. But that's just an interesting example to me because I certainly wouldn't consider that one a regression. But then there's the bigger story of like, how do we approach building software? Ideally, that's what this podcast does at its best. We're not really a podcast about Rails or JavaScript or whatever it is we're talking about that week, but we're talking about how to build software well. And I think those core ideas feel like they're more permanent for me, or I feel like I'm changing those less. If anything, I feel like I'm ratcheting in on what I believe about good software. And there are some core ideas that I'm just refining over time, not done by any means, but it's that I don't feel like I'm fundamentally reevaluating those core ideas. Whereas I am picking up a new language and approaching a new framework and taking a different approach to what tools I'm using, that sort of thing. STEPH: Yeah, I agree. The core concepts definitely feel more important and more applicable to all the future situations that we're going to be in. So those skills that may fall into the regression category feel appropriate because we are focused on the bigger picture versus how well do I remember this rejects library or something that won't serve us as well? So I agree. I am often focused more on how can I take this lesson and then apply it to other tech stacks or other teams and keep that with me? And I don't want that to regress. But it's okay if those other smaller, easily Google-able skills fall to the side. [laughs] CHRIS: Wait, are you implying that you can't write rejects just off the top of your head or what's…? STEPH: I don't think I could write any rejects off the top of my head. [laughter] CHRIS: Fair. All right. You just go to rubular.com, hit enter, and then we iterate. STEPH: Oh yeah. I don't want to use up valuable space for maintaining that sort of information. Rubular has it for me. I'm just going to go there. CHRIS: I mean, as long as you have the index of the places you go on the internet to find the truth, then you don't need to store that truth. STEPH: A moment ago, you mentioned where Tom highlights that they have different views about code that they wrote, even code that they wrote just like a year ago. And to me, that's a sign of growth in terms that you can look back on code that you have written and be like, well, maybe this would be different, or maybe this is still a good idea, but the fact that you are changing and then reevaluating, I think that is awesome because otherwise, if we aren't able to do that, then that is just a sign of being stagnant to me. We are sticking to the knowledge that we had a year ago, and we haven't grown since then versus that already shows that they have taken in new knowledge. So then that way, they can assess should I be adding comments? When should I add comments? Maybe I should swing away from that idea of this is a hard line of don't ever do this. I think I just have to mention it because there is one that I always feel so deeply about, DRY. DRY is the concept that gives me the most grief in terms that people just overuse it to the point that they do make code very hard to change. All right, that's my bit. I'll get off my pedestal. But DRY and comments are two things [chuckles] that both have their places. CHRIS: I don't know if your experience was similar, but around DRY, I definitely have had the pendulum swing of how I feel about it. And I think again, that honing in thing. But initially, I think I read The Pragmatic Programmers, and they told me that DRY is important. And then I was like, absolutely, there will be no duplication anywhere, and then I felt some pain from that. And I've been in other systems and experienced places where people did remove duplication. I was like, oh, maybe it would have been better, and so I slowly got out of that mindset. But now I'm just in the place of like, I don't know, copy and paste not now, there was a period where I was like, just copy and paste everything. And then I was like, all right, I think there's a subtle line. There's a perfect amount of duplication, and that's the goal is to figure out that just perfect level. But for me, it really has been that evolution, and I was on one side, and then I was on the other side, and then I'm honing back in. And now I have my personal truth about duplication. STEPH: Oh, me too. And I feel like I can be a little more negative about it because I was in the same spot. Because it's a rule, it's a rule that you can apply that when you are new to software development, there aren't that many rules that are so easy to apply to your codebase, but DRY is one of them. You can say, oh, that is duplication. I know exactly what that is, and I can extract it. And then it takes time for you to realize, okay, I can identify it, but just because it's there, it doesn't mean it's a bad thing. Perfect duplication, I like it. CHRIS: Coming back to the idea of when we look back on our code six months, a year later, something like that, I think I believe the statement that we should always look back on our code and be like, oh, what was I doing there? But I think that arc should change over time. So early on in my career, six months later, I look back at my code, and I'm like, oh, goodness, what was happening there? I was very much a self-taught or blog internet-taught programmer just working on my own. I had no one else to talk to. So the stuff that I wrote early on was not good is how I will describe it. And then I got better, and then I got better, and I hope that I'm still getting better. And it's something that probably draws me to software development is I feel like there's always room to get a little bit better. Again, even back to that adage of it doesn't get any easier; you just go faster. Like, that's a version of getting better in my mind. So I hope that I can continue to feel that improvement and that ratcheting up. But I also hope that that arc is leveling off. There is an asymptotic approach to "good software developer." People in the audience, you can't see my air quotes, but I made air quotes there around good software developer. But that idea of I shouldn't look back probably this far into my career and look back at code from three months ago and be like, that's awful. That dude should be fired. I hope I'm not there. And so if you're measuring over time, what does your three months ago look back feel like? Oh, I feel like it's a little better. Still, you should look back and be like, oh, I probably would do that a little bit different given what I know now, what I've learned, but less so, I think. I don't know, what do you think about that? STEPH: Yeah, that makes sense. And I'm also realizing I haven't looked back at my code that much since I am changing projects, and then I don't always have the opportunity to go back to that project and then revisit some of the code. But I do agree with the idea that if you're looking back at code that you've written a couple of months ago that you can see areas that you would improve, but I agree that you wouldn't want it to be something drastic. Like, you wouldn't want to see something that was more of an obvious security hole or performance issue. I think there are maybe certain metrics that I would use. I think they can still happen for sure because we're always learning, but there's also -- I may be taking this in a slightly different direction than you meant, but there's also a kindness filter that I also want us to apply to ourselves where if you're looking back three months ago to six years ago and you're like, oh, that's some rough code, Stephanie. But it's also like, yeah, but that code got me to where I am today, and I'm continuing to progress. So I appreciate who I was in the past, and I have continued to progress to who I am today and then who I will be. CHRIS: What a wonderfully positive lens to put on it. Actually, that makes me think of one of -- We may be getting into rant territory here, but we talk a lot about imposter syndrome in the software development world. And I think there's a lot of utility because this is something that almost everyone experiences. But I think there's a corollary to it that we should talk about, which is a lot of people are coming into this industry, and they're like one year in, and the expectation that one year into a career that -- The thing that we do is not easy as far as I can tell. I haven't figured out how to make it easy. And the expectation that someone's going to be an expert that early on is just completely unreasonable in my mind. In my previous career, I was a mechanical engineer, and I went to school for four years. I actually went to school for five years, not because I was bad at school, but because I went to a place that had a co-op. And so I had both three different six months experiences working and four years of classroom education before I even got any job. And then I started doing things, and that's normal in that world. Whereas in the development world, it is so accessible, and I really feel like that's an absolutely wonderful thing. But the counterpoint of that is folks can jump into this career path very early on in their learning, and the expectation that they can immediately become experts or even in the short order I don't think is realistic. I think sometimes, when we talk about imposter syndrome, we may do a disservice. Like, it's not imposter syndrome. You're just new, and that's totally fine. And I hope you're working in an organization that is supportive of that and that has space for that and can help you grow in a purposeful way. In my mind, it's not realistic to expect everyone to be an expert a year in—end rant. STEPH: Well, I would love to plus-one your rant and add to it a little bit because I completely agree. I also love the phrasing that you just said where it's not that you have imposter syndrome; it's just that you are new and that team should be supportive of people that are new and helping them grow and level up. I also think that's true for senior developers in terms that you are very good at certain skills, but there's always going to be some area of the web or some area of software development that you are new to, and that is also not imposter syndrome. But it's fine to assess your own skills and say, "That's something that I don't know how to do." And sometimes, I think that gets labeled as imposter syndrome, but it's not. It's someone just being genuine and reflecting on their current skills and saying, "I am good at a lot of stuff, but I don't know this one, and I am new to this area." And I think that's an important distinction to make because I still want -- even if you are not new in the sense that you are new to being a software engineer, but you still have that space to be new to something. CHRIS: Yeah, it's an interesting, constantly evolving space. And so giving ourselves a little bit of permission to be beginners on various topics and for me, that's been an experience that's been continual. I think being a consultant, being a freelancer that impacts it a little bit. But nonetheless, even when I go into organizations, I'm like, oh, years in technology that only came out two years ago. That's pretty fresh. And so it's really hard to be an expert on something that's that new. STEPH: Yeah. I think being new to a team has its own superpower. I don't know if we've talked about that before; if we haven't, we should talk about, it but I won't do that now. But being new is its own superpower. But I do want to pivot back to where Tom mentioned that I have no way of measuring that improvement. And I think that's a really great thing to recognize that you're not sure how to measure something. And my very first honest suggestion if you are feeling that way is to go ask your manager and ask them how they are measuring your improvement because that is their job is to understand where you're at and to understand your path as a developer on the team and then helping you set goals. So since I'm a manager at thoughtbot, I'll go first, and I can share some ways that I help my team measure their own improvement. So one of the ways is that each time that we meet to discuss work, I listen to their challenges, and I take notes; I'm a heavy note-taker. And so once I have all those notes, then I can see are there any particular challenges that resurface? Are there any patterns, any areas where they continuously get stuck on? Or are they actually gaining confidence, and maybe something that would have given them trouble a couple of weeks ago is suddenly no big deal? And then I also see if they're able to unblock themselves. So a lot of what I do is far more listening, and I'm happy to then provide suggestions. But I am often just a space for someone to share what they are thinking, what they're going through, and then to walk through ideas and then provide suggestions if they would like some, and then they choose a suggestion that works best for them. And then we can revisit how did it go? So their ability to unblock themselves is also something that I'm looking for in terms of growth. And then together, we also set goals together, and then we measure that progress together. So it's all very transparent. And what areas would you like to improve, and then what areas would it be helpful for thoughtbot or as a consultant for you to improve? And then if I am fortunate enough to be on a project with them and see how they reason about quality and speed, how they communicate the type of features they're most comfortable to work on, and which tasks are more challenging for them, I also look to see do people enjoy working with them? That's a big area of growth and reflects communication, and reliability, and trust. And those are important areas for us to grow as developers. So those are some of the areas that I look to when I'm helping someone else measure their own improvement. CHRIS: I really like that, the structured framing of it, and the way that you're able to give feedback and have that as a constant, continuous way to evaluate, define, measure, and then try and drive towards it. Flipping things around, I want to offer a slightly different thing, which isn't necessarily specifically in the question, but I think it's very close to the question of how do we actually improve as developers? What are the specific things that we can try and do? I'm going to offer a handful of ideas. I'd be super interested to hear what your ideas are. But one of the things that has been really valuable for me is exploring different languages and frameworks. I, without fail, find something in every new language or framework that I then bring back to the core things that I'm working with. And I've continued to work with Rails basically throughout my career, but everything else that I'm doing has informed the way that I work with Rails and the way that I think about building code. As specific examples, functional programming is a really interesting frame of mind, and Elm as a language is such a wonderful, gentle, friendly, fun introduction to functional programming because functional programming can get very abstract very easily. I've also worked with Haskell and Scala and other languages like that, and I find them much more difficult to work with. But Elm has a set of constraints and a user-centric approach that is just absolutely wonderful. So even if you never plan to build a production Elm application, I recommend Elm to absolutely everyone. In terms of frameworks, depending on what you're using, maybe try and find the thing that's the exact opposite. If you're in the JavaScript space, I highly recommend Svelte. I think it's been very informative to me and altered a number of my opinions. A lot of those opinions were formed by React. And it's been interesting to observe my own thinking evolve in that space. But yeah, I think exploring, trying out, -- Have you ever used Lisp? Personally, I haven't, but that's one of the things that's on my list of that seems like it's got some different ideas in it. I wonder what I would learn from that. And so continually pushing on those edges and then bringing that back to the core work you're doing that's one of my favorite things. Another is… It's actually two-fold here. Teaching is one, and I don't mean that in the grand sense; you don't have to be an instructor at a bootcamp or anything like that but even just within your organization trying to host a lunch and learn and teach a concept. Without fail, you have to understand something all the better to be able to teach it. Or as you try and teach something, someone may ask you a question that just shakes the foundation of what you know, and you're like, wow, I hadn't thought about it that way. And so teaching for me has just been this absolutely incredible forcing function for understanding something and being able to communicate about it again, that being one of the core things that I'm thinking about. And then the other facet sort of a related idea is pairing, pair with another developer, pair with a developer who is more senior than you on the team, pair with someone who is more junior than you, pair with someone who's at the same level, pair with the designer, pair with the developer, pair with a product manager, pair with everyone. I cannot get enough pairing. Well, I can, actually. I read a blog post recently about 100% pairing, and I've never gotten anywhere close to that number. But I think a better way to put it is I think pairing applies in so many more contexts than people may traditionally think of it. People sometimes like to compartmentalize and like, pairing is great for big architecture design, but that's about it. And my stance would be pairing is actually great at everything. It is very high bandwidth. It is exhausting, but I have found immense value in every pairing session I've ever had. So, yeah, those are some loose thoughts off the top of my head. Do you have any how to get better protips? STEPH: Yeah, that's a wonderful list. And I'm not sure if this exactly applies because it's been a while since I have seen this talk, but there is a wonderful talk by Sandi Metz. I mean, all of her talks are wonderful, but this one is Go Ahead, Make a Mess. And I believe that Sandi refers to or highlights the idea of trying something new and then reflecting on how did it go? And that was one of the areas that I learned early on, one of the ways to help me progress quickly as a developer. Outside of the suggestions that you've already shared around lots of pairing that was one of the ways that I leveled up quickly is to iterate quickly. So I used to really focus on the code that I was writing, and I thought it needed to be perfect before my colleagues could review it. But then I realized that the sooner that I would push something out for feedback, then the faster I would get other more experienced developers' input, and then that helped me learn at an accelerated rate and then also ship more frequently. So I'd also encourage you to just go ahead and iterate quickly. We talk about with software in general, we want to iterate on the code that we are pushing up for other people to look at and then give us feedback on and then reflect on how did it go? What did we learn? What are some areas that we can improve? I feel like that self-evaluation is huge, and it's something that I know that I frankly don't do enough because one, it also prompts us to appreciate the progress that we have made but then also highlights areas where I feel strong in this area, but these are other areas that I want to work on. CHRIS: While we're on the topic of talks that have been impactful in our journeys of leveling up as developers, I want to quickly list three that just always come to mind for me: Avdi Grimm's Confident Code, Katrina Owen's Therapeutic Refactoring, and Ben Orenstein's Refactoring from Good to Great. There's a theme if you look across those three talks. They're all about refactoring, which is interesting. That tells you some stories about what I believe about how good software is made. It's not made; it's refactored. That's my official belief, but yeah. STEPH: Love it. That's also another great list. [laughs] For additional ways to level up, there are some very specific areas where it could be maybe do code katas or code exercises, or maybe you subscribe to certain newsletters, stay up to date with a language, new features that are being released. But outside of those very specific things, and if folks find this helpful, then maybe you and I can make a fun list, and then we could share that on Twitter as well. But I always go back to the idea of regardless of what level you're at in your career is to think about your specific goals, maybe if you are new to a team and you're new to software development, then maybe you just have very incremental goals of like, I want to learn how to write a test, or I want to learn how to get better at PR review or something very specific. But to have real growth, I think you have to first consider where it is that you want to go and then figure out a way to measure to get there. Circling back to some of the ways that I help my teammates measure that growth, that's one of the things that we talk about. If someone says, "Well, I want to get better at PR review," I'm like, "Great. What does that mean to you? Like, how do you get better at PR review? How can we actually measure this and make it something actionable versus just having this vague feeling of am I better?" I think I've ended up taking this a bit more broad as you were providing more specific examples on how to level up. But I like the examples that you've already provided around education and then trying something outside of your comfort zone. So what's coming to mind are more of those broad strategies of goal setting. CHRIS: I think generally, you need that combination. You need how do I set the measure? How do I think about improvement? And then also ideally a handful of tactics that you can try out. So hopefully, we provided a nice balanced summary here in this episode. And hopefully, Tom, if you're listening, you have gotten some useful things out of this conversation. STEPH: Yeah, this was fun. We managed to take this topic and make a whole episode out of this. So thanks, Tom, for sending in such a great topic. CHRIS: Frankly, when I saw the topic, I was certain this was going to happen. [chuckles] This was an obvious one that was going to fill up the time for us. But yeah, with that, I think we've probably covered plenty here. Should we wrap up? STEPH: I'm sure there's more, but sure, let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me @SViccari on Twitter. CHRIS: And I'm @christoomey. STEPH: Or hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. Both: Byeeeeeee. Announcer: This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Jennifer Riggins (@jkriggins) and Rich Gall (@richggall) talk to Mandy Moore, the producer and show manager of Greater Than Code - "a podcast that highlights the human side of technology" - as well as a range of other awesome podcasts. In this episode Mandy discusses her journey into the tech industry, including her first job working with Avdi Grimm, and explains why she thinks podcasting plays such an important role in the field, in helping the world talk about tech. She also highlights how podcasts can help cultivate more open communities and help make the industry more diverse and accessible to those who have been marginalised and pushed out in the past. Follow Mandy Moore on Twitter: @therubyrepFollow Greater Than Code on Twitter: @greaterthancodeListen to Greater Than Code: greaterthancode.com

On this week's episode, Steph and Chris discuss using JSONB to store survey responses and the differences between JSON and JSONB, using (or not using!) exceptions in Ruby and the fail keyword, the pros and cons of namespacing models in Rails to organize features, and a new recommendation for running tests from vim. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! Seagull Mic Drop (https://i.kym-cdn.com/photos/images/facebook/001/383/162/20c.jpg) vim-test (https://github.com/vim-test/vim-test) plugin for running tests vim-rspec (https://github.com/thoughtbot/vim-rspec) thoughtbot's plugin for running specs from vim JSON types in Postgres (https://www.postgresql.org/docs/9.4/datatype-json.html) Ruby fail keyword (https://apidock.com/ruby/Kernel/fail) Avdi Grimm and Jim Weirich on exceptions (https://avdi.codes/jim-weirich-on-exceptions/) The Zen of Python (https://www.python.org/dev/peps/pep-0020/) Idris programming language (https://www.idris-lang.org/)

Teaching Testing and Design Guests Betsy Haibel (https://twitter.com/betsythemuffin): CTO at Cohere (https://twitter.com/wecohere). Blogs at betsyhaibel.com (https://betsyhaibel.com/). Avdi Grimm (https://twitter.com/avdi): Head Chef at RubyTapas (https://www.rubytapas.com/). Blogs at avdi.codes (https://avdi.codes/). Penelope Phippen (https://twitter.com/penelope_zone): Works at Google, makes Rubyfmt (https://github.com/samphippen/rubyfmt), helps make RSpec (https://rspec.info/), and is on the board of Ruby Central (https://www.rubycentral.org/). Blog (https://penelope.zone). Summary After the discussions on testing and design in episodes 68 and 69, I had so much I still wanted to talk about in testing, design, and teaching testing and design. So I convened a panel with previous Tech Done Right Guests Avdi Grimm, Betsy Haibel, and Penelope Phippen to help me think through all these topics. I was very happy to have all of them on the show, and I think it's a great conversation. Stay tuned until the very end for an update about the show. Related Episodes with These Guests Avdi: 20 Years of Web Development (https://www.techdoneright.io/46), Ruby Tapas and Avoiding Code (https://www.techdoneright.io/24) Betsy: Diverse Agile Teams (https://www.techdoneright.io/38), How Set Design Can Inform Software Architecture (https://www.techdoneright.io/21) Penelope: Code Style and Community (https://www.techdoneright.io/54), Back in the Testing Weeds (https://www.techdoneright.io/33), In The Testing Weeds (https://www.techdoneright.io/004-testing-with-sam-and-justin) Notes 00:50 - Previously On: Re: Testing * Pragmatic Programmer at 20 with Dave Thomas and Andy Hunt (https://www.techdoneright.io/68) * Teaching and Learning with Sandi Metz (https://www.techdoneright.io/69) 02:53 - Testing and Design * 99 Bottles of OOP (https://www.sandimetz.com/99bottles) 05:43 - TDD Test Driven Development (https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/) Do We Need Constants (http://www.virtuouscode.com/2011/08/18/do-we-need-constants/) 09:36 - Testing, But Not Developer Testing + Sliming The Test * WikiWikiWeb (http://wiki.c2.com) 13:41 - Why + How Did You Learn TDD? 20:24 - TDD: Not a Robust Process 24:19 - Rails + Unit Testing 27:41 - Is TDD really dead? 35:06 - Keeping Code In Your Head 37:32 - Approaching the Testing and Design of Code 38:59 - What would convince you to stop doing TDD? Special Guests: Avdi Grimm, Betsy Haibel, and Penelope Phippen.

Cal Newport on Coaching For Leaders, Becoming Mr. Why on Troubleshooting Agile, Gary Pedretti and Jeff Gothelf on Agile For Humans, Thai Wood on Greater Than Code, and Jeff Campbell on Scrum Master Toolbox. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting April 15, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. CAL NEWPORT ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Cal Newport with host Dave Stachowiak. Cal talked about the inspiration for his new book Digital Minimalism having come from readers of his previous book Deep Work who liked what that book had done for their work lives and asked, “What about my personal life?” Dave and Cal talked about competitive Rock, Paper, Scissors, and how the top competitors in that sport are so good at understanding and taking advantage of the way our brains work. This took them to the main point of the book, which is that technologies like social media are not understood by our brains in the same way as true social interaction, so we can be interacting on social media all day long and still feel lonely. Dave asked about the impact the modern tendency to replace face-to-face conversation with virtual connection such as email, text, and social media likes, can have for leaders. Cal described the scenario in which a person in a leadership position with a remote component to it reads, say, an email and can’t put a finger on the emotional affect — she can’t tell whether the author of the email is really angry with her or really happy. He says we need the complex, social-processing part of the brain that relies on analog cues such as the back-and-forth of hearing a voice or seeing body language. It is how we understand people, connect with people, and coordinate with people towards common goals. Taking this kind of conversation out of the picture makes it difficult to be a leader. Dave asked what Cal learned from his readers and blog followers. Cal said he was surprised to learn from his readers and followers the degree to which digital distraction was filling a void for them. He had assumed that simply reducing or taming the digital distractions would allow us to immediately get back to the things we know are more important. He learned instead that, for a lot of people, it is unclear what they are going to do next once they have taken the lightweight distraction out of their lives. He says he is much more sympathetic now about the difficulty of figuring out what you want to do instead of just mindless swiping in every down moment. In the book, he asks people to take a 30-day period to limit social media use and he said, “People are often surprised by how little they miss things like Facebook during this process and also surprised by how much they’re at a loss to figure out what they should be doing instead.” iTune link: https://itunes.apple.com/ca/podcast/400-how-to-reclaim-conversation-with-cal-newport/id458827716?i=1000432139932&mt=2 Website link: https://coachingforleaders.com/podcast/400/ BECOMING MR. WHY ON TROUBLESHOOTING AGILE The Troubleshooting Agile podcast with hosts Douglas Squirrel and Jeffrey Fredrick spent an episode talking about someone they call “Mr. Why.” Squirrel told a story about a client who would get orders from on high that said, “Thou shalt do it this way.” He would also get orders with explanations that do not make any sense such as investors making technical decisions. Squirrel calls this client “Mr. Why” because most people in these types of environments eventually stop asking the why. The challenge for this client is not that he doesn’t ask why but that he only asks himself. Squirrel said that he tells Mr. Why that we want to be opposite of lawyers, who are carefully trained never to ask the question, “Why?” Jeffrey said that he thinks the legalistic type of question is the model that people often think is the proper way to analyze a situation: legalistically building a case rather than collaboratively trying to get to answers and this could be why people fall into communication patterns in which their goal is to win rather than to jointly discover. To me, this sounds exactly like the difference between constructive and deconstructive criticism described in the book, How The Way We Talk Can Change The Way We Work by Robert Kegan and Lisa Lahey. The constructive criticizer is making an airtight case about the behavior he or she is criticizing even when doing so constructively, while the deconstructive criticizer is seeking to jointly discover the truth with the help of the recipient of the criticism. iTune link: https://itunes.apple.com/ca/podcast/becoming-mr-why/id1327456890?i=1000432455338&mt=2 SoundCloud link: https://soundcloud.com/troubleshootingagile/becoming-mr-why GARY PEDRETTI AND JEFF GOTHELF ON AGILE FOR HUMANS The Agile For Humans podcast featured Gary Pedretti and Jeff Gothelf with host Ryan Ripley. Ryan asked a question that he hears a lot: how do we do UX activities and product discovery within a sprint? Gary says that from the developer community, he hears that design work takes too long. From the designer community, he hears that they think their work is strategic and sprints feel tactical or that they think developers don’t really care about design. Jeff pointed out that the fundamental values and principles of Scrum and UX are the same, but melding the processes in a way that respects both Scrum and UX has proved elusive for a lot of organizations. They talked about a 2007 paper by Desirée Sy and Lynn Miller on staggered sprints that was misunderstood as a series of mini-waterfalls. I believe Jeff was referring to the article named Adapting Usability Investigations for Agile User-centered Design. Jeff explained that they were actually describing two kinds of work being done by the same team, not by separate groups of designers and developers communicating by handoff.  Jeff described experimenting with his team’s processes back in 2008-09 and settling on a process in which designers were part of the Scrum team with engineers and product managers and work was prioritized not just on what needed to be delivered but also on what the team was trying to learn. Gary talked about how the separation of designers from the rest of the team is similar to the separation of database people and application architects from the rest of the team because of a belief that the work of the database designer or application architect needed to be completed before the work of the rest of the team could begin. In each case, people discovered patterns that overcame this limitation, like the patterns of Ambler and Sadalage’s Refactoring Databases book and the patterns of evolutionary or emergent architecture. iTune link: https://itunes.apple.com/ca/podcast/afh-106-exploring-user-experience-and-scrum/id991671232?i=1000433513601&mt=2 Website link: https://ryanripley.com/afh-106-exploring-user-experience-and-scrum/ THAI WOOD ON GREATER THAN CODE The Greater Than Code podcast featured Thai Wood with hosts Jessica Kerr, Sam Livingston-Gray, John K Sawers, and Avdi Grimm. They started with a discussion of resilience engineering and how it spun off of human factors and brought in cognitive systems. Jessica said that old-style human factors got mired in Taylorism whereas cognitive systems is about making systems that work with people in the way that people naturally work. Thai had gotten into tech coming from emergency medicine as an EMT. Jessica asked what he brought to software development from his EMT days. Thai responded that, in medicine, you are trained about burnout, how to identify it, and what resources are available to help with it. In software, despite similar stressors and similar problems, burnout is not talked about that much. Jessica asked Thai how to distinguish between reliability and resilience. Thai said that resilience encompasses the ability to continually adapt to change, whereas reliability might be consistently performing within the same state. He also said that he thinks of robustness as being able to survive certain inputs but not necessarily being able to adapt to them. iTune link: https://itunes.apple.com/ca/podcast/121-emergency-communication-with-thai-wood/id1163023878?i=1000431679618&mt=2 Website link: https://www.greaterthancode.com/emergency-communication JEFF CAMPBELL ON SCRUM MASTER TOOLBOX The Scrum Master Toolbox podcast featured Jeff Campbell with host Vasco Duarte. This episode was the first to be done in a Q & A format. The question for this episode was: Have you been able to break through the proverbial IT gate and start talking about wider Agile adoption together with management? Jeff answered that being able to communicate with management is probably one of the most important factors to success. He told the story of working at a company that went out of business. Reflecting on this period of his career, he arrived at the idea that, if he was unable to convince management that a particular behavior or practice was important, then that was his failing and not theirs. His recommendation for a person looking to influence management is that they should start doing public speaking and teaching. Exposure to teaching, he says, teaches you to be able to express yourself multiple different ways which is critical because not everybody comes to understand a topic the same way. iTune link: https://itunes.apple.com/ca/podcast/selling-agile-how-to-get-buy-in-from-management-q-jeff/id963592988?i=1000431928436&mt=2 Website link: https://scrum-master-toolbox.org/2019/03/podcast/selling-agile-how-to-get-buy-in-from-management-qa-with-jeff-campbell/ FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/channel/UCysPayr8nXwJJ8-hqnzMFjw Website:

Andy Hunt on Greater Than Code, David Sohmer on SPAMCast, Josh Seiden on Scrum Master Toolbox, Tim Herbig on The Product Experience, and Wyatt Jenkins on Product Love. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting April 1, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ANDY HUNT ON GREATER THAN CODE The Greater Than Code podcast featured Andy Hunt with hosts Janelle Klein, Avdi Grimm, and Jessica Kerr. Andy talked about the origin of his book The Pragmatic Programmer and his workshops on iterative and incremental development where he has students play Battleship while making all their shots upfront. He talked about one of my favorite iteration strategies, the walking skeleton, which he introduced back in 2000 in the same book. He talked about the need people have to be given an estimate and how it comes from a cognitive bias to have closure. He also talked about why scaling Agile doesn’t work at a lot of places: people are ignoring the context that made Agile work for the pilot teams. He suggests that instead of trying to “lock it down”, you should “open it up.” iTunes link: https://itunes.apple.com/ca/podcast/120-expect-the-unexpected-with-andy-hunt/id1163023878?i=1000431206698&mt=2 Website link: https://www.greaterthancode.com/expect-the-unexpected DAVID SOHMER ON SPAMCAST The Software Process and Measurement Cast podcast featured David Sohmer with host Tom Cagley. David started by saying that a key ingredient for an agile or lean transformation is to first help the organization understand the “why” of the transformation because things are going to get worse before they get better by design and when that happens, it is good to have already discussed the “why” so that the focus can always be on how to fix the problems that come up rather than falling back to the old way of doing things. This deeply resonated with me because I have seen people fall back to the old ways of working even after half-heartedly trying and even actually succeeding with more agile ways of working because their expectations were so different from reality, especially about the amount of work they would have to put in to see results. David also talked about the shift away from individual contributors and toward self-organizing multi-skilled teams and how this can be controversial in organizations that have weak teams and strong individual contributor heroes. He says part of the trick is getting people who actually want to be T-shaped rather than specialists. He went on to talk about intermediary groups who are not on the business side or the technology side but want to be the handoff between the two and create the documentation and have control and power in the organization and are quite destructive to the relationship between technology and the business. He talked about the things he aimed for during the transformations he has done such as ensuring XP technical practices are part of the transformation and he listed the things he tried to avoid. iTunes link: https://itunes.apple.com/ca/podcast/spamcast-536-executives-view-agile-transformations/id213024387?i=1000430995898&mt=2 Website link: http://spamcast.libsyn.com/spamcast-536-an-executives-view-of-agile-transformations-an-interview-with-david-sohmer JOSH SEIDEN ON SCRUM MASTER TOOLBOX The Scrum Master Toolbox podcast featured Josh Seiden with host Vasco Duarte. Josh talked about how, in the early days, there was a focus on producing beautiful deliverables: wireframes, research reports, personas and other work on paper that teams had to interpret and act on. He described Lean UX as way of working in the UX problem space with less focus on deliverables and more focus on results. Josh described the “lean” in Lean UX as coming from knowing that the work we do with technology is filled with uncertainty, so the best way forward in those environments is to test our assumptions continuously. The activities of Lean UX then become: declaring assumptions, writing hypotheses, and thinking about your work as tests and experiments to help you learn. The people doing the work of Lean UX, he says, are small, cross-functional, colocated, collaborative teams that minimize handoffs and get different points of view that build on each other’s ideas. Vasco asked Josh how he defines the minimum viable product. Josh prefers the Eric Ries definition in which it represents the least amount of work that one can do to learn what one needs to learn next. Vasco also asked Josh what he means when he uses the word experiment. Josh clarified the difference between an experiment in the product development sense from simply abdicating decision-making. iTunes link: https://itunes.apple.com/ca/podcast/bonus-josh-seiden-on-lean-ux-toolbox-for-product-owners/id963592988?i=1000431422661&mt=2 Website link: https://scrum-master-toolbox.org/2019/03/podcast/bonus-josh-seiden-on-lean-ux-a-toolbox-for-product-owners-and-agile-teams/ TIM HERBIG ON THE PRODUCT EXPERIENCE The Product Experience podcast featured Tim Herbig with hosts Lily Smith and Randy Silver. They discussed Tim’s new book, Lateral Leadership, and what he means by the title. He describes it as how to lead and influence people without formal authority. From conversations Tim had with product people, not many of them are aware that they have a leadership responsibility, but the implicit expectation from the environments and the stakeholders is that they step into leadership responsibility. He talked about how he recommends product people attend developer community-of-practice meetings to listen, learn how to ask better questions, show that they care, and gain credibility. Randy asked about warning signs of ineffectiveness as a lateral leader. Tim said a big warning sign is when people become resigned to just ask for more granular specs to simply get their job done. He says that this would show an unhealthy hierarchy in the team. Another potential warning sign is whether your peers feel safe about opening up about what really makes them struggle at work in the environment you have created. Lily asked about what tools Tim uses to set the mission or goal for the team. He referenced Stephen Bungay’s mission briefing idea from The Art Of Action. Tim likes the mission briefing because it helps you develop a shared language together and it lets product teams and the people within them have the autonomy to succeed in their specific job by improving the clarity you create up front. Randy compared the Bungay Mission Briefing framework to Teresa Torres’ Opportunity Solution Tree concept. Lily asked whether the mission briefing is defined by just the product manager and team or other stakeholders as well. Tim says that, in the early stages of an idea, he uses it to capture his own thoughts. He may then do another iteration with the team in which he holds back his input. Then he runs it by his boss and boss’s boss to ensure there is alignment and buy-in. Lily asked about what happens when you don’t get alignment. Tim started his answer by distinguishing between alignment and agreement. He then quoted Jeff Bezo’s statements on being able to disagree and commit. He sees reaching alignment as something that would allow you to get started with an idea that you can adjust along the way. He says alignment is much easier to obtain when you don’t feel the need to also get agreement before you start anything. iTunes link: https://itunes.apple.com/ca/podcast/how-to-influence-without-power-tim-herbig-on-product/id1447100407?i=1000431209799&mt=2 Website link: https://www.mindtheproduct.com/2019/03/how-to-influence-without-power-tim-herbig-on-the-product-experience/ WYATT JENKINS ON PRODUCT LOVE The Product Love podcast featured Wyatt Jenkins with host Eric Boduch. After a discussion of Wyatt’s career journey from disc jockey to product manager at Shutterstock, Optimizely, and now Patreon, they got into a discussion about the why and how of market-testing your features and ideas. For Wyatt, such tests are about understanding customers better and de-risking product ideas before rolling them out. Some of Wyatt’s favorite kinds of tests are the price tests that were popular at Shutterstock. Eric related how pricing seems to be particularly challenging for product managers. They got into a discussion of pricing tests like the painted door test and what to do for the customers who signed up for a service at prices lower and higher than the final chosen price at the end of the test. Eric asked what Wyatt would recommend to a product manager wanting to learn about pricing. Wyatt recommended the book Monetizing Innovation and he recommended reading up on the stories of the companies that have had some of the most successful pricing changes and some of most disastrous ones. iTunes link: https://itunes.apple.com/ca/podcast/wyatt-jenkins-joins-product-love-to-discuss-pricing/id1343610309?i=1000431181574&mt=2 Website link: https://productcraft.com/podcast/product-love-podcast-wyatt-jenkins-svp-of-product-of-patreon/ FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/channel/UCysPayr8nXwJJ8-hqnzMFjw Website:

In this episode, Jason and Chris chat with Avdi Grimm. Avdi, a well-known author, screencaster, and consultant shared how he got started in programming, how he subsequently started using Ruby, what he appreciates about Ruby, his transition into teaching, a brief section on object-oriented programming and functional programming, and public speaking. Avdi is a gem (no pun intended) in the Ruby community, and it was a thrill to have him on the show.

Avdi is a prolific Ruby developer with deep ties to the community. A well-known speaker and educator, he created Ruby Tapas and has led a successful career as a consultant. Avdi shared his experiences with imposter syndrome and talked about the importance of acknowledging privilege where it exists in the software industry. Avdi's internet home: https://avdi.codes

On this week's episode, Chris is joined by Ruby Hero Avdi Grimm. They discuss Avdi's history of guiding the Ruby and broader programming communities, his thoughts about where we're at with object-oriented programming, and where he's looking to next for our industry. This conversation touches on a variety of topics both technical and personal. Avdi shares some of his thinking around where we've failed with our approaches to object-oriented programming and viewing the world as transactional, and instead offers ideas around modeling our systems as processes. Avdi & Chris also chat about some of Avdi's my recent explorations into the world of JavaScript & React, as well as the growing "resilience engineering" mindset. Ruby Rouges Podcast Confident Code Avdi's Keep Ruby Weird Keynote Alan Kay - Creator of Object Oriented Programming Actor Model Kafka Ruby Tapas - Avdi's Weekly Ruby Screencast Series Greater Than Code Podcast Mastering the Object Oriented Mindset Pair Program With Me Avdi - Ruby Duck Sessions Avdi and Jess stumble through modern web development Glitch TypeScript Australian Disaster Resilience Conference Chaos Monkey from Netflix avdi.codes Thank you to One Month for sponsoring this episode.

Your First Open Source Contribution with VM Brasseur TableXI offers training for developers and product teams! For more info, email workshops@tablexi.com or go to http://tablexi.com/workshops. Guest VM Brasseur (https://twitter.com/vmbrasseur): Open Source consultant, Vice President of Open Source Initiative (https://opensource.org/), and Author of Forge Your Future with Open Source (https://pragprog.com/book/vbopens/forge-your-future-with-open-source). vmbrasseur.com (https://www.vmbrasseur.com/). Summary The Open Source world is large. It’s also complex and difficult to manage, especially for a novice. Our guest this week is VM Brasseur, who is the Vice President of the Open Source Initiative and the author of a new book from Pragmatic called Forge Your Future With Open Source. We talk how Open Source is different from free software, and how to get started in Open Source, how to pick a project, how to navigate a new project to make your first submission. We’ll also look at it from the other side, and talk about open source projects can make themselves more contributor-friendly. And we talk about the state of Open Source in general. We want to hear from you. What was your first open source experience like? Or, how do you handle new contributors on your project? Notes 03:40 - Misconceptions Keeping People From Contributing to Free and Open Source Software 05:27 - Overcoming Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 08:27 - Why Contribute to Open Source? 10:15 - What Project Do I Start With? - Valentia (https://valentinaproject.bitbucket.io) - Free Sewing (https://freesewing.org) 12:32 - Why NOT To Start With Documentation 14:24 - Getting Started With Your First Contribution - Code Triage (https://www.codetriage.com/) 20:20 - Advice For Navigating the Open Source Community 22:40 - The Importance Codes of Conduct 24:44 - The Evolution of Open Source - Open Source Initiative (https://opensource.org) - Open Source Definition (https://opensource.org/osd-annotated) - Updating GitHub From Rails 3.2 to 5.2 (https://githubengineering.com/upgrading-github-from-rails-3-2-to-5-2/) 35:29 - Join VM at the Seattle GNU/Linux Conference (https://seagl.org/) on November 9th & 10th! 36:33 - Advice For Maintainers Wanting to Make Projects Welcoming Related Episodes 20 Years of Web Development with Avdi Grimm and Sarah Mei (https://www.techdoneright.io/46) Open Source and Companies with Nell Shamrell-Harrington (https://www.techdoneright.io/28) The Social Responsibility of Coding with Liz Abinante (https://www.techdoneright.io/25) Open Source: The Big Picture with Nadia Eghbal (https://www.techdoneright.io/16) Open-Source Community Management and Safety With Coraline Ada Ehmke and Yana Carstens (https://www.techdoneright.io/8) Special Guest: VM Brasseur.

Joël Quenneville joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version. Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joël‘s recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable. Elm - A delightful language for reliable webapps. Elm 0.19 Release Notes Webpacker Elm 0.19 - Dead Code Elimination Scala.js The reasoning behind removing user-defined operators Minesweeper for JavaScript Equality WebAssembly Linus Torvalds - "I am going to take time off and get some assistance..." Also Linus, on the importance of "trivial patches" as entry points for new kernal developers Derek Prior - Implementing a Strong Code-Review Culture thoughtbot code review guidelines thoughtbot apprentice program How Elm Slays a UI Antipattern "Making Impossible States Impossible" talk by Richard Feldman "Working with Maybe" talk by Joël Quenneville "Confident Code" talk by Avdi Grimm "Nothing is Something" talk by Sandi Metz The Zen of Python Breakable Toys Joel's many posts on the Giant Robots blog Stop Coding and Start Drawing

20 Years of Web Development with Avdi Grimm and Sarah Mei TableXI is offering training for developers and product teams! For more info, visit http://tablexi.com/workshops. Guests Sarah Mei (https://twitter.com/sarahmei): Founder of RailsBridge (http://railsbridge.org/), Director of Ruby Central (http://rubycentral.org/), Software Architect at Salesforce (https://www.salesforce.com/). Avdi Grimm (https://twitter.com/avdi): Creator of the RubyTapas Screencast Series (https://www.rubytapas.com/) and author of Exceptional Ruby (http://exceptionalruby.com/) and Confident Ruby (http://www.confidentruby.com/). avdi.codes (https://avdi.codes/). Summary What has changed in web development in the last 20 years, and what do those changes say about the next 20? I recently realized that Avdi Grimm, the head chef of Ruby Tapas, Sarah Mei, of Ruby Central and Salesforce, and I all began our professional careers within a couple of weeks of each other in August 1998. I wanted to talk to them about what’s changed and what’s stayed the same. I was curious as to whether our different career paths led to similar observations. We talk about open source, agile, dynamic languages, distributed systems and how they’ve all changed or haven’t changed the developer’s experience. Notes 02:19 - First Software Job Education and Experiences 09:25 - What has changed? What is easier/harder? 20:16 - What has changed in Product Management? 27:22 - Processor Speed 32:24 - What has stayed the same? 40:20 - Typed Languages 42:48 - What is going to change over the next 5-10 years? - Code Complete: A Practical Handbook of Software Construction by by Steve McConnell (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) Related Episodes Rubyists in Other Languages with James Edward Gray II and Steve Klabnik (https://www.techdoneright.io/43) Ruby Tapas and Avoiding Code with Avdi Grimm (https://www.techdoneright.io/24) Livable Code With Sarah Mei (https://www.techdoneright.io/13) Special Guests: Avdi Grimm and Sarah Mei.

Rubyists in Other Languages with James Edward Gray II and Steve Klabnik TableXI is offering training for developers and product teams! For more info, email workshops@tablexi.com. Guests Steve Klabnik (https://twitter.com/steveklabnik): Blog (https://www.steveklabnik.com/) James Edward Gray II (https://twitter.com/JEG2): Blog (http://graysoftinc.com/) Summary Ruby is great. But it's not the best tool for everything. On this episode, I talk to James Edward Gray II and Steve Klabnik. Both James and Steve have made substantial contributions to the Ruby and Rails community, and they now both spend lots of time using other languages. We talk about what makes Rust and Elixir interesting for Ruby developers to learn, what some other interesting languages might be. Notes 01:48 - Moving Towards Other Programming Languages from Ruby: Why? 03:39 - Rust - The Rust Programming Language (https://www.rust-lang.org/en-US/) - The Elm Programming Language (http://elm-lang.org/) - The Rust Programming Language (Book) by Steve Klabnik (https://www.amazon.com/Rust-Programming-Language-Steve-Klabnik/dp/1593278284) 17:54 - Other Cool Programming Languages for Rubyists - Scratch (https://scratch.mit.edu/) - Logo (https://en.wikipedia.org/wiki/Logo_(programming_language)) - GameSalad (https://gamesalad.com/) - GameMaker Studio 2 (https://www.yoyogames.com/gamemaker/features) - Prograph (https://en.wikipedia.org/wiki/Prograph) - Abstract Syntax Tree (https://en.wikipedia.org/wiki/Abstract_syntax_tree) 29:22 - Elixir - The Elixir Programming Language (https://elixir-lang.org/) - Erlang (https://app.workte.am/timeoff/team) - Prolog (https://en.wikipedia.org/wiki/Prolog) - Pattern Matching (https://en.wikipedia.org/wiki/Pattern_matching) Related Episodes Programming Languages and Communication With Kerri Miller (http://www.techdoneright.io/34) React Native with Gant Laborde, Ed LaFoy, and Brent Vatne (http://www.techdoneright.io/32) Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) The Elm Programming Language With Corey Haines (http://www.techdoneright.io/17) Special Guests: James Edward Gray II and Steve Klabnik.

Panel: Charles Max Wood David Richards Eric Berry Catherine Meyers Dave Kimura Special Guests: Jared Norman In this episode of Ruby Rogues, the panel talks to Jared Norman about understanding your production apps. Jared has been programming since he was about 10 years old and for the past 7 years, he has been doing Ruby. These days, he runs a consultancy company called Super Good Software doing Ruby on Rails stuff and mostly eCommerce. They talk about his article You Can’t Save Everyone: Some Exceptions Should Be Left Alone, when capturing exceptions is the right way to go, developing with good visibility in mind, and more! In particular, we dive pretty deep on: Jared intro Founder of Super Good Software Article - You Can’t Save Everyone: Some Exceptions Should Be Left Alone Solidus and Spree Rescue_from Exception Injecting special error reporting Don’t necessarily want to rescue all exceptions Injecting an error reporting tool Trying to think of a good reason to rescue_from exception Loss of visibility Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 When is capturing exceptions the right way to go? Using an exception when something is legitimately broken project-honeypot When exceptions are in a state that you don’t expect Having enough information to attack problems when they arise Dig method for hashes Elegance of Ruby that allows you to not work as hard Developing code for better exception handling Developing with visibility in mind And much, much more! Links: Ruby Super Good Software Ruby on Rails Solidus Spree You Can’t Save Everyone: Some Exceptions Should Be Left Alone Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 project-honeypot Jared’s GitHub @SuperGoodJared @SuperGoodSoft Sponsors Sentry Digital Ocean FreshBooks Picks: Charles Home Depot tool rental Podcast Movement Framework Summit Chuck@devchat.tv Eric 'Resting bitch face' is real, scientists say – CNN article David Basin and Range by John McPhee Catherine Scott’s Cheap Flights Dave Configuring a Sentry Server on Ubuntu 16.04 by Dave Re-engage Jared Living Computers fzf fzy

Panel: Charles Max Wood David Richards Eric Berry Catherine Meyers Dave Kimura Special Guests: Jared Norman In this episode of Ruby Rogues, the panel talks to Jared Norman about understanding your production apps. Jared has been programming since he was about 10 years old and for the past 7 years, he has been doing Ruby. These days, he runs a consultancy company called Super Good Software doing Ruby on Rails stuff and mostly eCommerce. They talk about his article You Can’t Save Everyone: Some Exceptions Should Be Left Alone, when capturing exceptions is the right way to go, developing with good visibility in mind, and more! In particular, we dive pretty deep on: Jared intro Founder of Super Good Software Article - You Can’t Save Everyone: Some Exceptions Should Be Left Alone Solidus and Spree Rescue_from Exception Injecting special error reporting Don’t necessarily want to rescue all exceptions Injecting an error reporting tool Trying to think of a good reason to rescue_from exception Loss of visibility Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 When is capturing exceptions the right way to go? Using an exception when something is legitimately broken project-honeypot When exceptions are in a state that you don’t expect Having enough information to attack problems when they arise Dig method for hashes Elegance of Ruby that allows you to not work as hard Developing code for better exception handling Developing with visibility in mind And much, much more! Links: Ruby Super Good Software Ruby on Rails Solidus Spree You Can’t Save Everyone: Some Exceptions Should Be Left Alone Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 project-honeypot Jared’s GitHub @SuperGoodJared @SuperGoodSoft Sponsors Sentry Digital Ocean FreshBooks Picks: Charles Home Depot tool rental Podcast Movement Framework Summit Chuck@devchat.tv Eric 'Resting bitch face' is real, scientists say – CNN article David Basin and Range by John McPhee Catherine Scott’s Cheap Flights Dave Configuring a Sentry Server on Ubuntu 16.04 by Dave Re-engage Jared Living Computers fzf fzy

Panel: Charles Max Wood David Richards Eric Berry Catherine Meyers Dave Kimura Special Guests: Jared Norman In this episode of Ruby Rogues, the panel talks to Jared Norman about understanding your production apps. Jared has been programming since he was about 10 years old and for the past 7 years, he has been doing Ruby. These days, he runs a consultancy company called Super Good Software doing Ruby on Rails stuff and mostly eCommerce. They talk about his article You Can’t Save Everyone: Some Exceptions Should Be Left Alone, when capturing exceptions is the right way to go, developing with good visibility in mind, and more! In particular, we dive pretty deep on: Jared intro Founder of Super Good Software Article - You Can’t Save Everyone: Some Exceptions Should Be Left Alone Solidus and Spree Rescue_from Exception Injecting special error reporting Don’t necessarily want to rescue all exceptions Injecting an error reporting tool Trying to think of a good reason to rescue_from exception Loss of visibility Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 When is capturing exceptions the right way to go? Using an exception when something is legitimately broken project-honeypot When exceptions are in a state that you don’t expect Having enough information to attack problems when they arise Dig method for hashes Elegance of Ruby that allows you to not work as hard Developing code for better exception handling Developing with visibility in mind And much, much more! Links: Ruby Super Good Software Ruby on Rails Solidus Spree You Can’t Save Everyone: Some Exceptions Should Be Left Alone Exceptional Ruby by Avdi Grimm Ruby Rogues Episode 19 project-honeypot Jared’s GitHub @SuperGoodJared @SuperGoodSoft Sponsors Sentry Digital Ocean FreshBooks Picks: Charles Home Depot tool rental Podcast Movement Framework Summit Chuck@devchat.tv Eric 'Resting bitch face' is real, scientists say – CNN article David Basin and Range by John McPhee Catherine Scott’s Cheap Flights Dave Configuring a Sentry Server on Ubuntu 16.04 by Dave Re-engage Jared Living Computers fzf fzy

The creator of the popular series Ruby Tapas and MOOM shares how he determined what to delegate, the importance of taste when creating something, how he determines pricing of a product and how he markets is products.

Programming Languages and Communication With Kerri Miller TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Get your FREE career growth strategy information and techniques! (https://stickynote.game) Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) is updated, available, and shipping! Guest Kerri Miller (https://twitter.com/kerrizor): Senior Developer at TravisCI (https://travis-ci.org/) and Ruby Community Member. Co-Organizer of the Open Source and Feelings Conference (https://www.osfeels.com/). Blog (http://kerrizor.com/). Summary Why is Smalltalk the Elizabethan English of programming languages? Why has it been so influential, and how does the programming language you use affect the way you think about programming. On this episode, Kerri Miller and I talk about programming languages and communication, and what we've learned from our most recent programming language adventures. Notes 01:56 - Introduction Twitter Stream (https://twitter.com/kerrizor/status/974391130484752385) Creole Languages (https://en.wikipedia.org/wiki/Creole_language) Pidgin (https://en.wikipedia.org/wiki/Pidgin) 06:18 - SmallTalk is to Ruby as Elizabethan English is to Modern Day 08:11 - SmallTalk’s History Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age (https://amzn.to/2JxTtss) Squeak (http://squeak.org/) By the way, I did get the Squeak history partially wrong. The original work was done at Apple, and when they went to Disney after that, they downloaded their Apple work as Open Source to continue. (It is possibly named Squeak because they were being wooed by Disney). The technical details are basically right, though. 17:55 - Thinking About Programming and Software Projects in a Flexible Way Sapir-Whorf Hypothesis (http://www.dictionary.com/browse/sapir-whorf-hypothesis) 22:01 - Object-Oriented Programming, Thinking, and Design The Overton Window (https://en.wikipedia.org/wiki/Overton_window) 28:37 - Learning New Programming Languages, Concepts, and Techniques The Silmarillion by Tolkien (https://en.wikipedia.org/wiki/The_Silmarillion) Nothing is Something by Sandi Metz (https://www.youtube.com/watch?v=OMPfEXIlTVE) Much Ado About Naught by Avdi Grimm (http://www.virtuouscode.com/introduction-to-much-ado-about-naught/) Related Episodes Back in the Testing Weeds with Sam Phippen and Justin Searls (http://www.techdoneright.io/33) Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) The Elm Programming Language With Corey Haines (http://www.techdoneright.io/17) Special Guest: Kerri Miller.

Greater Than Code Episode 002: Neutralizing Impostor Syndrome with Avdi Grimm 01:52 – Avdi’s Superpower: The Power of Inspiration, RubyConf India (https://www.rubyconfindia.org/), and International Conferences vs Domestic 04:28 – The Pursuit of a Fixed Life: Achieving or Avoiding Stasis Blog Post: I was trying to end my life (http://journal.avdi.org/2017/12/31/i-was-trying-to-end-my-life/) 08:40 – Living in the Future and Having Goals 16:36 – Hitting Career Stasis vs Identity Stasis 25:23 – Becoming a Visible Person in Tech 31:27 – Encouraging and Inspiring People to Find Their Potential and Value 44:23 – Being Authentic and Transparent to the World Reflections: Coraline: Identity matters. Rein: How identity and society interact: Symbolic Interactionism. Also, having therapeutic relationships. Jessica: Two energies, internally, of being ‘grounded’ and ‘inspired’ and those feeding into ‘connection’, together. Also, we have identity in the now and in the future. The Lathe Of Heaven by Ursula K. Le Guin Janelle: Being present and listening, connecting, and internalizing to form new thoughts you wouldn’t have had otherwise. Avdi: Identity in the now and identity in the future forms an arrow. 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!

In Conversation With Avdi Grimm Avdi Grimm is in town(Bangalore) for RUBYCONF India 2018. Earlier today Atul Jha had a chance to sit with and talk about state of Ruby and other programming languages Links RubyConf India Avdi's Blog - Virtuouscode Twitter - @avdi

Marketing and Building an Audience With Suzan Bond Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right) Also, please leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2)! Guest Suzan Bond (https://twitter.com/suzanbond): Host of the Indiedoes Podcast (https://www.betonyourself.com/podcast), Founder of Bet On Yourself (https://www.betonyourself.com/) and Bet On Your People (https://www.betonyourpeople.com/). Summary Are you a developer that wants to create your own content and build an audience? Suzan Bond joins the show to talk about how to bet on your self. We talk about how to be comfortable marketing, how to present yourself as a credible source for developer-focused content, and how to build and maintain an audience. It's the kind of advice you'd normally have to pay a coach for, offered for free because that's how we build our audience here at Tech Done Right. Notes Sorry, Suzan's audio has some glitches in the source track. We did the best we could, but there's still some words dropped. We're sorry about that, but hope you still find the conversation interesting. 02:25 - Developers, Companies, and Personal Growth 06:56 - Taking the First Steps to Betting On Yourself (Working Independently) 10:57 - Marketing: Effective vs. Comfortable 15:16 - Selling Books is Hard - Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) 18:35 - Approaching Side Projects and Presenting Yourself as a Credible Source 21:59 - Understanding Your Audience and Incorporating Information Into Planning - Take My Money (https://pragprog.com/book/nrwebpay) 30:31 - Tools and Techniques for Connecting and Re-engaging with Your Audience - Paul Jarvis (https://pjrvs.com) Related Episodes Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) Building Trust and Building Teams with Jessie Shternshus and Mark Rickmeier (http://www.techdoneright.io/001-building-trust) Special Guest: Suzan Bond.

Ruby Tapas and Avoiding Code with Avdi Grimm Follow us on Twitter @techdoneright (https://twitter.com/tech_done_right), and please leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2)! Guest Avdi Grimm (https://twitter.com/avdi): Creator of the RubyTapas Screencast Series (https://www.rubytapas.com/) and author of Exceptional Ruby (http://exceptionalruby.com/) and Confident Ruby (http://www.confidentruby.com/). avdi.codes (https://avdi.codes/) Summary Avdi Grimm has been creating the RubyTapas screencast series for five years. In this episode Avdi and I talk about why he decided to do RubyTapas, and what makes a good episode. We also talk about the resources that helped us when we were learning to code. Then Avdi talks about his experience building the RubyTapas web site and explains how sometimes avoiding code can be the best business decision of all. Notes 01:20 - Starting and Sustaining RubyTapas 04:59 - Shorter Episodes Vs Longer Episodes 08:00 - Creating an Example for a Topic 10:49 - Future-proofing Episodes 12:51 - Helpful Resources When Avdi and Noel Were Learning How to Code - Programming Perl (The Camel Book) (https://en.wikipedia.org/wiki/Programming_Perl) - The Pragmatic Programmer (https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X) - Code Complete (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) - Smalltalk Best Practice Patterns (https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X/ref=sr_1_1?s=books&ie=UTF8&qid=1508781341&sr=1-1&keywords=smalltalk+best+practice+patterns) - Ruby Midwest 2011 Confident Code by Avdi Grimm (https://www.youtube.com/watch?v=T8J0j2xJFgQ) 18:31 - Learning New Things Now; Online Marketing - Copyblogger (https://www.copyblogger.com/) 26:12 - Avoiding Code

This week Ben Orenstein is interviewing guest Avdi Grimm, Founder of RubyTapas, which is a subscription service that provides screencasts of “gourmet” ruby programming. Avdi discusses the topic of his talk at Southeast Ruby in Nashville, which was the value of avoiding code and strategies to bypass the need to write unnecessary coding. Join us as he shares his advice on optimizing workflows and his experiences building RubyTapas. Today’s Topics Include: The value of avoiding code Hidden complexity in building out content platforms Using Wordpress for publishing content Code as a liability Episode production and future of RubyTapas Finding leverage in business and creative work Delegating workflows Views on side-hustling and product development If you’re enjoying the show please give us your ratings and reviews in iTunes. Links and resources: RubyTapas (https://www.rubytapas.com/) WordPress (https://wordpress.com/) Spacemacs (http://spacemacs.org/), Emacs (https://www.gnu.org/software/emacs/), Vim (http://www.vim.org/), Neovim (https://neovim.io/) Side-hustle mindset versus product-business mindset (http://www.virtuouscode.com/2017/02/08/side-hustle-mindset-versus-product-business-mindset/) by Avdi Grimm Avdi.codes (https://avdi.codes/) VirtuousCode.com (http://www.virtuouscode.com/) RefactoringRails.io (http://refactoringrails.io/)

00:16 – Welcome to “The Meta Four!” …we mean, “Greater Than Code!” 01:30 – Chef Avdi Grimm’s Introduction 02:19 – RubyTapas (https://www.rubytapas.com/); Production, Typing, and Editing 10:52 – Real World Programming: Episode #346 (https://www.rubytapas.com/2015/10/01/episode-346-user-model/): User; LiveCoding.tv (https://www.education-ecosystem.com/) 12:24 – Neutralizing Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 13:32 – Break time and getting to know our new panelist, Astrid Countee! "I've never met a junior who wasn't extremely senior in some area of life I know nothing about" @dbrady @greaterthancode— Jessica Kerr (@jessitron) October 5, 2016 24:15 – Neutralizing Imposter Syndrome (Cont’d) 25:42 – Live Coding 28:29 – What non-Ruby technologies have you been exploring lately? ~ Darin Wilson (https://twitter.com/darinwilson) 29:05 – PHP (https://secure.php.net/) 35:56 – Should a screencast series like RubyTapas also go beyond code? Talk about topics like dealing with frustration when programming, for example? ~Lucas Dohman (https://twitter.com/moonbeamlabs) “Programming can be an incredibly judgmental culture and environments can be really poisonous.” ~ Avdi Grimm Bias in Computer Systems (https://nissenbaum.tech.cornell.edu/) Carina C. Zona: Schemas for the Real World @ SCNA 2013 (https://vimeo.com/80375707) Carina C. Zona: Consequences of an Insightful Algorithm @ JSConf EU 2015 (https://www.youtube.com/watch?v=znwWYR1mzzw) Reflections: Sam: You can use your ego and your attachment to the code, but make it not about yourself. Instead, try to focus on what your code is bringing to other people and maybe that can help you try to figure out how to make it better without getting stuck. Coraline: We got to see a glimpse into the whole person behind a persona. Even heroes are people with vulnerability, human flaws, anxieties, and weaknesses. Astrid: Bring your whole self to everything. Jessica: What we show matters. Jay: Don’t be too quick to compare yourself to others. David: Put your ideas out there and get them in front of other people. That is how you manufacture authority. Avdi: Hidden Figures 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!

In which Nadia and Saron talk to Avdi Grimm about his book, Confident Ruby, how he came about creating it and what he hopes listeners get from reading it.

Guest: Avdi Grimm @avdi Full show notes are at https://developeronfire.com/podcast/episode-108-avdi-grimm-your-passion-is-yours-and-yours-alone

Ruby 2.3 is out! What are we looking forward to trying and what do we think of &. and try? Stick around after the credits for spoiler-filled discussion of Star Wars: The Force Awakens Star Wars Fruit What is Kerberos? Safe navigation operator (AKA the lonely operator) by Georgi Mitrev ActiveSupport's #try might not be doing what you think it's doing by Avdi Grimm The history of try in Rails a comment from Myron Marston In Ruby, &method Passes You! Hash#dig Hash Comparison in Ruby 2.3 by Olivier Lacan did_you_mean by Yuki Nishijima. Immutable Strings in Ruby 2.3 by Alexis Mas Multiline strings in Ruby 2.3 - the squiggly heredoc by Damir Svrtan

Show notes: http://betweenscreens.fm/episodes/89

Show notes: http://betweenscreens.fm/episodes/74

Show notes: http://betweenscreens.fm/episodes/50

Ruby developer and author Justin Weiss joins me to talk about his experience working with Avdi Grimm on a guest episode for Ruby Tapas, why he chose Rails, and his book. Then, Justin gives you his 30-second suggestion to help you become a better developer. Mentioned: Justin's book, Practicing Rails https://www.justinweiss.com/book/ Justin's Blog: http://www.justinweiss.com/ Sign up for Justin's awesome weekly newsletter: http://www.justinweiss.com/list/ If you are enjoying the show, would you consider buying me some tea? http://www.developertea.com/buy-me-tea

Show notes: http://betweenscreens.fm/episodes/37

Show notes: http://betweenscreens.fm/episodes/25

Show notes: http://betweenscreens.fm/episodes/13

Show notes: http://betweenscreens.fm/episodes/1

In this episode we bring you a special interview with two well-known podcasters: Dick Wall and Avdi Grimm. Dick Wall, also known as the sheriff of the Java Posse, works as a Scala trainer and consultant at Escalate Software. Avdi Grimm, one of the Ruby Rogues, is a Ruby code hacker, Chief aeronaut at ShipRise and head chef at RubyTapas.com. In the interview we cover a wide range of subjects like joy and courage in software development, siloing in the software community, an idea for a conference by Avdi that he'll never ever organise and working self-employed. This interview was recorded on the morning after the Joy of Coding conference in Rotterdam at March 7th.Interview by @freekl and @arnetim Links for this podcast: The slides of the presentations that Dick and Avdi gave at the Joy of Coding conference can be found on SpeakerDeck. Video recordings will follow soon on InfoQ. Avdi creates short screencasts for Ruby developers, twice a week: RubyTapas. Dick's talk on courage in software development can be seen on Parleys. A bunch of Ruby Koans that we mention in the podcast can be found here. The statement has to learn a new language every year stems from the Pragmatic Programmer book.   This podcast is in English - Deze podcast is in het Engels

Tarjolla on ensimmäinen erikoisjakso eli spesiaali. Jakson aiheena on RubySauna ja mukana on totutusta poiketen erikoiskokoonpano. Mukaan saatiin Tommi, Tuomas (@tuomasj) ja Florian (@polarblau). Erikoisjakson muodossa kieli vaihtuu lontoon murteelle. This time our podcast is a special. Topic revolves around RubySauna with Tommi, Tuomas (@tuomasj) and Florian (@polarblau). And this time we will speak english. A true special treat. Links RubySauna Sets on SoundCloud Speakers Ville Kolehmainen Adam Hawkins Avdi Grimm Annika Juvani

The Rogues talk to Avdi Grimm about his book Confident Ruby

The Rogues talk to Avdi Grimm about his book Confident Ruby

The Rogues talk to Avdi Grimm about his book Confident Ruby

Adam Stacoviak, Andrew Thorp, and Steve Klabnik talk about pair programming, distributed teams, workflows, Ruby and more with Avdi Grimm.

Adam Stacoviak, Andrew Thorp and fellow changelogger Steve Klabnik wrap-up The Changelog #90 with Avdi Grimm.

Adam Stacoviak, Andrew Thorp, and Steve Klabnik talk about pair programming, distributed teams, workflows, Ruby and more with Avdi Grimm.

Avdi Grimm 是 Ruby 社区知名的资深程序员，作者和社区领袖。在这期节目中我们请来 Avdi 来聊聊怎样突破“中级天花板”来达到更高的层次。 About Avdi Grimm: Avdi Grimm Avdi's Publications Ruby Rogues Growing Object Oriented Software Guided by Tests Practical Object Oriented Design in Ruby Smalltalk Best Practice Patterns Factoring How Developers Stop Learning: Rise of the Expert Beginner Go ahead and make a mess (Sandi Metz) Who I want to hire (Chad Fowler) I feel the opposite of burn out, interview with Chad Fowler Software Engineering Radio Pair Programming with me Corey Haines, Software Journeyman The hitchhiker's guide to the galaxy Wide Teams DivShot FantastiCal Domain Driven Design Destroy All Software RubyTapas Special Guest: Avdi Grimm.

Ben Orenstein is joined by Avdi Grimm, software developer, author, and podcaster. Ben and Avdi discuss Emacs, Avdi's personal assistant and delegating work. They also discuss naming and finding implicit concepts in your code, encoding processes as objects in their own right, his publishing and podcasting, the pronunciation of Parley, Ruby Tapas, education resources and the benefits of open source languages, his goals, the most civilized way to travel, and what we got wrong about the Law of Demeter. Mandy Moore, Assistance for Software Professionals Ruby Tapas MethodObject Objects on Rails Exceptional Ruby Confident Ruby Ruby Rogues podcast Wide Teams Ruby Rogues Parley GRSIOGR podcast on Law of Demeter, Episode 27: Fabulous new mistakes Follow @thoughtbot, @r00k, and @avdi on twitter.

Update 2013-03-16: Get the MP3 or Ogg Vorbis files, or listen to them on archive.org! Thanks to Matthew Darling’s comment on my post about code coaching, I came across Avdi Grimm’s work with pair programming – and was delighted to find that he uses Emacs too. =) Check out my Skype chat with Avdi about […]

Panel Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) Eric Davis (twitter github blog) Jeff Schoolcraft (twitter github blog) Avdi Grimm (twitter github blog book) Discussion RubyTapas Confident Ruby Error Handling in Ruby Dan Miller Time Spent Marketing Blogging Selling eBooks Writing - Research to Finished Product Document Formatting Speak, Publish Transcripts Free Content Destroy All Software Word of Mouth Build your own site or use an existing service for video? Picks Two Steps from Hell - Archangel, Invincible (Eric) If This, Then That (Jeff) Epic Soundtracks (Jeff) Learning GNU Emacs (Chuck) Emacs Rocks (Jeff) O'Reilly Pocket Guide for Emacs (Eric) Brother MFC7860DW Printer (Avdi) Good Strategy, Bad Strategy (Avdi)

Panel Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) Eric Davis (twitter github blog) Jeff Schoolcraft (twitter github blog) Avdi Grimm (twitter github blog book) Discussion RubyTapas Confident Ruby Error Handling in Ruby Dan Miller Time Spent Marketing Blogging Selling eBooks Writing - Research to Finished Product Document Formatting Speak, Publish Transcripts Free Content Destroy All Software Word of Mouth Build your own site or use an existing service for video? Picks Two Steps from Hell - Archangel, Invincible (Eric) If This, Then That (Jeff) Epic Soundtracks (Jeff) Learning GNU Emacs (Chuck) Emacs Rocks (Jeff) O'Reilly Pocket Guide for Emacs (Eric) Brother MFC7860DW Printer (Avdi) Good Strategy, Bad Strategy (Avdi)

Новости Стриминг в новой рельсе mortal-token travis-api Ransak Metaprogramming in Ruby BinUtils from funny-falcon bit.ly on Ruby Yet another JSON parser and discussion on reddit SublimeText package for generating Yardoc Narihiro Nakamura: Ruby’s GC Innovator Unexpected Ruby Behaviour Ruboto 0.8.0 Обсуждение Блоги Dr Nic Edge rails Ilya Grigorik Ivan Blinkov James Golick Jeff Kreeftmeijer Alexey Vasiliev plataformatec Блог Алексея Дмитриева Railscasts Ruby on rails Ruby in use rubysource Aaron Patterson Ivan Evtuhovich Alexey Vakhov Katz Got Your Tongue? Literate Programming Pat Shaughnessy Joe Damato Unlimited Novelty Avdi Grimm Про жизнь Сентябрьская конференция RailsClub Dell u2711

Ben Orenstein and Joe Ferris (and the surprise special guest Seana Quental) start the series off with a very technical discussion about Polymorphism vs. Conditionals. We also answer some of the audience questions we asked for last week. CVS SVN Git Feature branch code reviews Rebasing Composition over Inheritance Objects on Rails, Avdi Grimm NullObject Rails Refactoring Example: Introduce Null Object #try God objects Rich Hickey's Railsconf Keynote Kingdom of Nouns, Steve Yeggie Ruby blocks StrategyPattern CommandPattern Clearance Gang of Four Design Patterns

Special Guest: Russ Olsen.

It’s our dozenth ADDcast! Avdi Grimm dials in via the Windows virtual machine on his Linux box, making for a nifty stop motion animation effect. Avdi is a busy guy, juggling a consulting business, the conference circuit, and his recently released ebook entitled Exceptional Ruby. He shares his thoughts on how to be a good teammate and facilitator on a remote team, how he managed to write a book and still feed his four kids, and sets the record straight on the Law of Demeter. Dave uses code examples that might land him a coffee date with some FBI agents and demystifies chained enumerations. We also talk about when to refactor and how far to go, and wrap up with a quick discussion on becoming a better programmer (or anything, really) through experimentation and self-reflection.