Podcast appearances and mentions of katrina owen

Play Episode Listen Later Nov 16, 2021 39:33

Chris finally got his new computer!

297: We're Making A Pixar Movie!

Play Episode Listen Later Jun 22, 2021 48:57

Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey! Eric Bailey's bunny updates (https://twitter.com/ericwbailey/status/1389332217088851971) Katrina Owen's Therapeutic Refactoring Talk (https://www.youtube.com/watch?v=J4dlF0kcThQ) EnjoyHQ (https://getenjoyhq.com/) User research platform Aurelius (https://www.aureliuslab.com/) also a user research platform Dry Monad (https://dry-rb.org/gems/dry-monads/1.3/) (part of dry-rb (https://dry-rb.org/)) Previous Bike Shed discussing dry-monads (https://www.bikeshed.fm/243) Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/) Bike Shed "Seeking Calm" Episode (https://www.bikeshed.fm/279) Previous Episode Discussing Multi-Step Forms (https://www.bikeshed.fm/295) Discussion thread on Inertia repo re: back button cache (https://github.com/inertiajs/inertia/issues/247) Transcript: STEPH: Yes, I was getting text messages from you where you were like, “Go on without me.” CHRIS: [laughs] Leave me behind! STEPH: [laughs] No developer left behind!! 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 been a very busy week. There's been a lot going on. But the most delightful part of my week has been that Eric Bailey, another thoughtboter and also a former guest on this show, has a tiny, little baby bunny living in his backyard, and so he has been sharing updates about this little baby bunny. In fact, he's been sharing some pictures on Twitter as well. So I'll include a link in the show notes so other people can experience the joy. Also, the name of the bunny gets me every time. But they have named the bunny “Corndog.” CHRIS: Checks out. It seems like a very obvious name for a small bunny. STEPH: It gets me because that's such a big name. I don't know why it's a big name, but it feels like a big name for a little bunny. CHRIS: I can say yeah, it's a cornball. Yeah, that's a large name. And so a tiny bunny is a...it's like Little John from Robin Hood. It's perfect. STEPH: [chuckles] I kept referring to him as Corn Nugget, I guess, because of size. But yes, it's not corn nugget; it's Corndog. [chuckles] So watching Eric's little bunny has been delightful and a wonderful addition to the week. How about you? How has your week been? CHRIS: My week has been great. I was off on vacation last week (so you had a guest on), which was fun to just take a week off and reset the system. But actually, this week has been interesting. It was my first full-time week with a new startup that I have joined. I think, yeah, that seems to be the truth in the world. So a bit of a shift from what I've been doing for the last year and a half, almost something like that. The reason there's hesitance in my voice is because I've actually been working with this organization for six months-ish, depending on how you count it. I've been having conversations, and then it's slowly grown over time where it was just conversations, and then it was an afternoon a week, and then one day a week, and then two, and three. And finally, we decided we think we've got an idea. We've got a thing that we want to build. And so I am the developer on this team, but we are an early-stage startup trying to build something. I'm now full-time on the project. I rotated down the other projects that I was working on from a freelance consulting perspective, and now I'm trying something new. So it's a very different vibe. Even though I'd been working with the organization for a long time, this week just felt so much more real. And there was so much more space, so much more room for activities, having a full week to actually work on things. So yeah, it's very exciting, it's very new, it's very early stage, so all of those things are true. But there are a lot of great aspects to that, and I'm super excited about it. STEPH: That is some big news. That's a big change too. Well, I guess with consulting, there are the stresses that go into consulting and then changing projects and managing the projects that you're taking on. But then to joining a team and such an early startup team too...anytime, someone says startup life, I'm always like, well, tell me more. How calm is the startup life, or how uncalm is this startup life? CHRIS: It's somewhere between calm and uncalm, I would say, but in a, I would say purposeful and intentional way. I was looking for...this has largely been true over the entire time that I was freelancing, but freelancing was a way for me to keep the lights on, and stay engaged with tech, and continue working, and frankly, have more conversations and meet more organizations. But I was looking for something that I could engage with a bit more. I was looking for, largely, something like this. So it definitely is occupying a different space in my head than, say, any individual consulting client where with consulting, I was pretty rigid, you know, these are the hours that I'm working. When I'm off the clock, I'm really not thinking about it too much. I'm responsive if I see an incident or something like that or if the database falls over; I'm going to look at that on the weekend but otherwise, largely not doing anything. Whereas with this project, I'm somewhat purposefully allowing it to have a little bit more space in my head off-hours, that sort of thing. And I'm more invested in the work. It's not just a thing that I'm doing, but it's a project that I believe in. It's something that I want to exist in the world. And so, I'm engaged with it in a different way in that manner. I'm also engineer number one, so I'm choosing all of the technologies and setting the standards. Thankfully, there's a lot of good thoughtbot material out there that I can link to, which is great. But yeah, so it's mostly within the context of what I think startups can be. The expectations and the way that the team is working is very reasonable. And I think it's more for my own self. I'm allowing it to occupy a little bit more of my space, but in a fun way so far. STEPH: Well, along that line, in terms of choosing the tech stack and starting greenfield, I am curious to hear more about the type of project that you're going to be working on. But I'm also recognizing y'all may be in stealth mode. Is that where you're at, or can you talk a bit more about the type of work you'll be doing? CHRIS: We're stealth-ish right now, I would say, partly because we're likely in the process of rebranding, and renaming, and things like that. So partly it's just like, oh, I probably shouldn't say that. But at some point, this will become public, and so at that point, I can probably be a little bit more open about it. But at the end of the day, we're building a financial product, FinTech sort of thing. And the tech stack is relatively straightforward. I'm actually using my preferred tech stack is...I got to choose, so it's Rails, Inertia, and Svelte with some TypeScript because why not? And I love it, and it's fantastic. I continue to believe deeply in that tech stack. So, yeah, that's most of what I think is good to say now. But I think over the coming weeks, I'll be able to say more and share more. And I certainly will be able to talk about the details of building and growing a team and things like that. STEPH: Awesome. Yeah, you answered my other question too. I was going to ask what tech stack you chose. CHRIS: I chose the tech stack, the one with the acronym, which I don't even know...the STIR stack I think we went with or something. STEPH: I was about to say I don't remember the acronym. [laughs] CHRIS: I think I never committed to an acronym previously, and then that was the one that got thrown around on the internet. I think I just was like, in the next episode of The Bike Shed, I'll choose an acronym so STIR, why not? STEPH: I like it, causing a stir. CHRIS: But yeah, so it's a pretty sizable shift in my life. But frankly, I don't even know exactly the shape that the coming weeks will have. So it will be interesting to report back as things evolve and as new concerns and considerations come up. But, yeah, we'll save that for future weeks. For now, what else is up in your world? STEPH: Yeah, it's been an interesting week. There have been really two things on my mind, so one of them has been focused on writing a task that's going to process a sizable CSV. And then it's going to essentially enqueue a bunch of jobs and send off a bunch of data to other third-party systems. So that's been a big focus of the week. The other topic is what I'm going to call extracting an untrustworthy service into its own service. And I know that's a bit vague, but I've got both of those topics. So which one would you want to hear about first? CHRIS: I definitely want to hear about both. But because you veiled it in mystery and said, “An untrustworthy,” that one's just going to call to me a little bit more. So yeah, what about this extracting and untrustworthy service? What more can you say there? STEPH: Good question. I'm glad that you picked the mysterious one and started there. That feels right. So this is a part of our codebase, and it's very related to also the task that I'm writing. So to provide a bit of context, this particular portion of the codebase manages a big part of where we are sending data from our application over to third-party systems. And it's a very important feature of our application. And it's also probably one of the gnarliest sections of our application in terms of there are tons of conditionals based on which type of service we're sending to or the discreet customer that we're sending it to, and any particular preferences that they need and how we're sending that data. And then there's also just a lot of room for ambiguity and errors. And when we are sending that data, was it actually successful? And what if it was successful, but we still got back error messages? What does that mean? Is that successful with warning? And so there are just a lot of unknowns. It's also one of the less tested areas of the codebase. So even though it's important, we really don't feel confident making changes at this point until we've added some more test coverage. And testing it can be a beast because right now, we really just want to add some security around that section of the codebase. So we're often going for high-level tests, which are then our slower tests, but then also means it's hard to test the more granular aspects of that code. This is that untrustworthy section of the code in terms that we're a bit skittish to make changes, but yet it's a very active part of the codebase, so not the best place to be. But we also recognize that this part of the codebase would be really well-fitted to live outside of the application. It really doesn't need to live with the rest of the application. And there are other services that need to be able to talk to the service as well. So instead of having it grouped together, which -- It's funny. I see your eyebrows go up when I talk about -- For people who can't see, Chris raised his eyebrows when I talked about extracting this to another service. [chuckles] CHRIS: That doesn't sound like me at all. I don't ever… STEPH: [chuckles] And since we do have other services that need to be able to pull data or to talk to this particular portion of the codebase, we are looking to then move it out into its own application, so that way, it can stand alone. It can focus on this one task, and then other services can benefit from it as well. And there's been an interesting discussion around, well, we need to make changes to this codebase. And we also have some recognition that we need to make improvements. Do we go ahead and go heads down for a bit and improve the section of the codebase, add more test coverage, get to understand more of what this code does, where the risks are? Or do we go ahead and extract it in its current form to the new greenfield space and just essentially port it, and then we work on it from that space? And so, there's been a conversation around which one do we do first? And I'll tell you my thoughts, and then I'd love to hear yours. As one of the primary individuals that's been working in this codebase, my stance has been let's leave it in place for now because I want to build some confidence around what this does. So I really want to have some confident understanding about the requirements, about when we extract this, what is that going to look like? But also, I feel like I'm in a place where I'm starting to understand the beast enough that I want to continue that progress and add some testing around it before then we just move it to this new location. And I can't decide if that's one of those decisions where like, I just feel too close to it, and extracting it feels risky to me. So I feel like we're adding on this extra level of complexity. Like, this is already code that's hard to understand. And then we're going to add this network connection on top of that where then we have to talk to it in a different way. And in my mind, that's adding another level of risk and another level of having to debug this service. So my current approach is let's leave it in place. Let's try to identify some low-hanging fruit. Let's go ahead and add some more tests. And I feel pretty good about that decision. I'm curious, what are your thoughts? CHRIS: I have a bunch of them. The first is that the story that you're telling here feels like the hero's journey of software development. Like, all right, we got this gnarly bit of the code. It's super important. It's super complicated. It doesn't really have any test coverage for historical reasons that are complicated, but here we are. What do we do? That story feels so true. It feels like there are nine Pixar movies about it if Pixar made movies about writing code, and they would be great movies. STEPH: That's amazing. [laughs] I would watch those movies. CHRIS: I think of it like Katrina Owen's therapeutic refactoring, which I feel like is probably my most referenced...It's one of my two most referenced talks that I bring up on the show all the time, but it is almost exactly about that sort of thing. We've got this gnarly piece of code. It's super important, but nobody really knows how it works. But we know it does work, which is an interesting bit. And so to the question of would you extract as is or would you try and shore it up before you extract it? I am 100% on the side that you are on, which is let's shore this thing up before we move it over. Because moving it over, like you said, that's going to add the additional complexity and failure modes of network latency, network timeouts, async disconnects, whatever, any of those complexities. That's another set of failure modes that you'll be introducing or just complexity and things that you have to think about. So that feels complicated. Also, there's probably a poor analogy that I have in my head. But imagine that you're moving, and your bedroom is just a complete mess, and you're like, oh, there are some old to-go food containers over there. And I haven't done my laundry in a couple of weeks. I'm just going to throw it all on a blanket and take it to the new house, and I'll figure out what I want to keep on the other side. It's like, that doesn't feel like the right move. I would definitely throw some things out before I move to a new house. So I definitely lean in to let's clean this up and understand it so that when it's in the new place, we have a slightly more contained, understood, manageable version of the software to try and extract to a service. STEPH: I feel very judged for my moving style. CHRIS: [laughs] I mean, obviously, with software, you're doing the one thing. But did I just describe exactly how you move house? STEPH: [laughs] CHRIS: To each their own now, you know, whatever works for you. STEPH: No, I'm with you. I'm definitely the person that's going to clean up first before I put stuff in boxes. I'm going to try to give away as much stuff as possible. CHRIS: It's a great time to just figure out what's true in your life or what's true in your software. I am intrigued. So yes, I did raise my eyebrows when you mentioned extracting a service and other services talking to each other. In particular, the way you described this piece of the system, I would be surprised if there weren't data requirements and/or transactional consistency things that you wanted to uphold. And that's one of the main things that causes me concern when we're extracting services is if this thing still needs to know about a bunch of different pieces of data and if it's going to make multiple updates to different records where if one succeeds and the other doesn't, we should roll back the whole thing. You lose all of that by moving to a service. And so that's where my broad…like, I'm always going to question if we're going to surface this. So I'm intrigued. Is this thing a very functional piece of your system where some data comes in, some stuff happens, and you get data out at the end of the day? Or is it more operating on related data within your system and potentially updating records after the fact? STEPH: Yeah, that's a great point. For this area of the codebase, it does feel more functional in terms that we have data, and we essentially want to notify other people that we have this data, and then we want to share it with them. So there is still that coupling of where we need access to those values. So if we're sending it over to the new system, either that new system needs to be able to read from the same database, or we have to send all of those details over to the new system. So then it can build up the message and then send it over to the other third-party systems. So it feels more functional, but there are still some of those requirements that we need to think about. CHRIS: Okay. That definitely clarifies things. And I wouldn't say that I have a unified theory of services. But what you're describing feels like the type of service that I'm more open to. It sounds almost like a SendGrid where I want to deal with all of my application data. And then I send a bunch of structured data over to SendGrid, and their job is to send an email and retry as necessary or send a text message or even do a voice call if it's Twilio or something like that. And so they're really good at those weird things and the failure modes that exist in those communication channels. But that's not logic that I need to live in my app. And so what you're describing there definitely makes sense as something that could comfortably be extracted to a service and not have more complexity be introduced by that. You did mention something about services talking to services and other things. So is the idea that this would be extracted, then other parts of the system would also use it to communicate out messages or something like that. STEPH: Yeah, one of the motivations for extracting this is because we have another application that also wants to perform similar behavior. So now we have two applications that need to do similar work, and they feel more in that line of functional work where it would be great if we could share this. But it doesn't fit in the space that we want to extract it in regards to extract it to a gem and make it shareable. It feels more appropriate for it to be its own service and then also capture. Because the other nice thing that we want to include that we're doing now as well is we want to capture feedback from whenever we are sending that data over to other systems. We want to know, hey, how did it go? Did you give us back that successfully, but maybe with some warnings or some errors? Maybe you accepted the data, but then you also gave us a response about something else. I think one really important question to consider is when is it trustworthy enough to extract? Because we know we're headed down this path. So at what point are we ready to then go ahead and extract this over to its own service? And that was the more interesting conversation because I think those who were in favor of extracting it now had the concern that we can't add test coverage in its current form. So my first response was if I need to make changes and I can't add test coverage, I will sound the alarm, and we will reconsider. But my goal right now is to turn this untrustworthy service into a little more trust. Just dial up the trust a little bit further, and then we can port this over. So then, as we do add some network complexities on top of this, we will at least have more faith and understanding the underlying behavior of the system. But then we still want to understand that it's not going to be perfect. And we're not going to wait until it's perfect before we do extract it. But that's the tale or the mysterious extracting an untrustworthy service. So I think it will be an interesting journey. And it was a very interesting conversation that I was excited to have your thoughts because I know you and I often lean so far away from extracting stuff to a service that it was an interesting conversation to have around; well, this code is a bit of a mess. When do we start to tackle that mess? CHRIS: I like that you didn't even frame it necessarily in terms of that, but I still definitely got there. I was like, wait, wait, wait, but let's actually talk about whether or not. But this is definitely the sort of thing that I think makes sense to consider as a service extraction. I think the question that you're asking around when do we feel good enough in its current state to do the extraction? That's right on the line of art in the software world as opposed to the science of this is how we connect HTTP. So I'm very interested to see where you get to both with that question and how you actually make that decision and then how the extraction goes. And I imagine this will be the sort of thing that goes on for a bit of time. So it feels like we could make a mini-story arc that'll span a couple of episodes, and you can follow the characters on their journey. This is the Pixar movie. We're making a Pixar movie. STEPH: We're making a Pixar movie. They're missing an entire genre for their Pixar movies. If they just appeal to developers, that'd be wonderful. I'm so in for that. We should write Pixar. CHRIS: There are more developers every day, so think Hackers meets Up. That's what we're going for. We're just going to fuse those two together. It's going to pull at your heartstrings, but it's also going to talk about hacking the Gibson. It's going to be great. STEPH: Oh man, you reached for the most heartfelt one going for Up. That one has the toughest beginning. [laughs] CHRIS: That's what I'm going for here. STEPH: For anyone that hasn't seen Up, you can go watch the beginning of it. Just be prepared. CHRIS: And if anyone hasn't seen Hackers, also be prepared. [laughs] STEPH: Which is me. I haven't seen Hackers. CHRIS: All right. You still haven't. All right, that's a thing we need to work on. STEPH: [chuckles] CHRIS: But cool. Okay. So we're going to work on the Pixar movie. You're going to update us because we need to actually gather the information. But yeah, we'll come back to that in future episodes. But shifting gears just a little bit, actually, I have a couple of things, two small things, and then one more sizable thing that is more just like, I'm confused. So yeah, we're going to go in that order. Thing number one is, we are, again, it's a very early-stage startup that I'm working with. And part of what we're doing that I really like is that we are talking to potential customers, potential end-users of the application doing lots of user interviews, which is a thing that I have more from a distance seen often. But now, because we're actually working as a distributed team, we're remote because that's the nature of the world right now. We'll probably meet each other in person at some point, but that's down the road. But all of these conversations are happening over Zoom calls, all of these user interviews. And so I made the suggestion that we use a tool to actually manage those. And so we're using a tool called EnjoyHQ, I think is the name of it. There's another similar tool called Aurelius. We can put the links in the show notes for both of those. But what it does is it basically makes the video available after the fact. I think it automatically transcribes it, and then it allows you to annotate and add notes and things like that, which is great for aggregating this body of information that we're collecting over time as we do all of these user interviews and start to tag common themes that we're seeing. And bringing them together will also allow us to revisit them. But for me as the developer, I've been to a few of them, but not as many as the rest of the team. And what's great is I've now taken to...as I'm doing more mundane…cleaning up email or whatever sort of tasks, I will just put on one of these videos in the background at 2X. And what's great is I can now just hear literally the voice of the users of the application. What are the words that they're choosing? How are they talking about it? What matters to them? What doesn't matter to them? What do they get really passionate about? And it's been just such a wonderful thing to have available. It's almost like a podcast of our app that we're building, and it's like, that's awesome. STEPH: I love that. Yeah, I would love to be able to hear from people that are using the application. And like you mentioned, just turn it on in the background so that way I can process what they're saying. But then, I don't know, depending on what they're saying, maybe it needs full attention or otherwise, maybe you're able to just absorb little bits and pieces while you're hacking away on something else. And now I've got the word hacking stuck in my mind. [laughs] CHRIS: It's the best word to describe what we do. Yeah, there's definitely a version of someone should be reviewing...someone's actually doing the interview, so they're going to be very close to it. And then there maybe is a secondary someone's watching it closely and trying to glean, and categorize, and all of that. And I could potentially be any one of those, but I really like this version of this is just a background soundtrack that I'm exposing myself to so that I'm all the more immersed in the problem space that we are working on. And it's one of the things that I fundamentally believe about software development is developers shouldn't be hidden in the corner just writing code. We should always care about what the end-user wants, and what better way to get there than to actually hear their voice and hear the words that they're using. So this is a magical little trick that I have now found that I'm like, oh my God, this is amazing. STEPH: Funny enough, I had a similar experience this past week where I realized I was feeling very disconnected from the people that are using the application and also the people that are setting priorities for the work that our team is doing. And that is something that I'm very accustomed to with thoughtbot that we always want to be part of the team. We're not necessarily just we can churn through a backlog. But we also really want to be in touch with product decisions, and share opinions, and then also be in touch with users too. So I had some similar revelations this week where I realized I was feeling very disconnected where I was picking up tickets, and I was like, I don't really understand why this is great or how this is helpful. And so, I shared that with the team, and someone encouraged me to attend a specific meeting. And that was wonderful because then I got to hear from the people who were creating those tickets and then giving them a high priority because something was urgent and why it was urgent. And having that insight was huge to me. And I realized that it was incredibly motivational as well. Because then I'm like, yes, okay, I understand how this is going to impact someone. And I'm now very encouraged to get this done. CHRIS: I think that idea, that ethos of wanting to get into the user persona and understand that better is a very strong thoughtbot ideal. So it's unsurprising both of us share that. But yeah, that was a really great thing and particularly a tool that facilitated that in a really straightforward way, which I appreciated. Another thing that I used this week, which I've talked about at length in a previous episode, so we can link to that episode, but it's a project called dry-monad. So there's dry-rb is the collection of, I think, a set of gems, but dry-monad is one that allows for defining sequential tasks, so tasks that you have to do a bunch of steps in order and the outcome of a previous step will be the input of the next part of the process. So it can fail in a bunch of ways like, okay, fetch this thing from the network and then look up a user based on that. And then get the user's profile, which may or may not exist, and then assuming that all of that's gone well, actually persist to this new record, to the database. And they're really finicky to write that sort of sequential processing. And so I actually had written that thing manually. And part of it was I'd wrapped the whole thing in a database transaction, but I was trying to make it so that if something went wrong, I would manually roll back the transaction. And then I wanted to return an object to the caller that indicated that things had failed and an error message or something like that. And that was actually really hard to do because of the way transactions work. The mechanism that I was using was apparently deprecated in Rails. And so the whole thing was just kind of confusing, and it was a bit messy in the code. And I knew in the back of my mind that dry-monad exists. I've used it before. I've really enjoyed it. But I was trying to minimize the amount of new technologies that I'm bringing in this early on in the project. It's like, yeah, I'll bring that in when I need it. But finally, I was like, you know what? I think I've reached that point. I grabbed it, brought it in, and I haven't worked with it in a while, but I was very quickly able to refactor my class to use dry-monad. It cleaned it up immensely. The tests remained identical, which was really interesting. I didn't have to change anything on the test side. And one of my tests was failing before and then passed because of the introduction of dry-monad. And yeah, it was just like a win-win-win, and also the fact that I was able to revisit dry-monad as a library and just get running with it again was really interesting to me because it is a bit complicated and interesting in how it works. But again, I was able to just sort of pick it up and run with it. So that was wonderful. And I will now all the more staunchly suggest that folks reach for that when they have more complex, procedural type code that they need to write. STEPH: I remember you highlighting dry-monad before in previous episodes and talking about the pain of writing that sort of procedural code, but then we also want to return something helpful. And I looked at it briefly, but I haven't used it. But now that you are reminding me of it, I'm very interested in it because I agree that process is difficult to write, at least in Ruby it's difficult to write. I understand the hesitancy that you have around bringing something in that's new. But then if you recognize that it's going to be a theme in your application around this is something that we're going to do a fair amount, and we want to do it in a clean, efficient way, then it starts to feel more reasonable to say, “Okay, I'm bringing in something new, but it is representative of how we want to handle this step or this type of process in our application.” So it's not just bringing in a gem to handle one small area of the code, something that we could have written, but it is elevating our process and our system. CHRIS: Yup. Indeed. In this case, these are command objects within the system. That's actually the name that I got from the creator of the project. That was his suggestion on Twitter as to what to call these objects. And it's a pattern that I do want to encode and has become the standard within the application for any of these more complex processing tasks. So, again, we'll link to the previous episode. I talked about it in more depth and the ideas behind it. Railway Oriented Programming is a phrase that's used, which talks about how to sequence failures or successes and whatnot together. And there's some good material behind it, more general, but yeah, wonderful, little library. STEPH: What is Railway Oriented Programming? I'm not familiar with that term. CHRIS: That refers to the sequential processing that I was describing. So imagine that you have a bunch of different steps where first you fetch from the network to get this record, then using what you got back, you look up a user in your database, then you fetch that user's profile. Then you do something else. Each of those steps along the way could fail. And so the railway metaphor is the track is going forward, but if at any point you branch off the track because of a failure, then you're in the failure track, and that's a different thing. And so it's a very...the dry-monad or other similar Railway Oriented Programming or monads generally I think is the actual...it's the words in there. And I wish it wasn't in there because it's such a complicated word. But that idea is the fundamental, underlying thing that's going on there. And it is conceptually somewhat complicated, but if you don't try and think about the category theory behind it, and you're just like, well, I want to do a bunch of stuff, and it may fail at any point, and I want to return either a success message with everything having gone well or an error message at the point that it failed and stopped processing, then that's what this thing does, and it's fantastic at it. STEPH: Okay, cool. Thank you. CHRIS: You are welcome. And I think there's a bit more in the previous episode as well. So if that sounded interesting to anyone, I think I rambled more in a previous episode about it and probably better because I feel like I was more prepared that time than this time. STEPH: Well, along those lines of running a process and then being able to fail at any moment, I'm going to circle back to that other topic that I highlighted where most of my week has been focused on writing a task that is processing a CSV, something probably a number of us have done at some point in our career but processing a number of rows, and then sending and queuing jobs to then send data to a third party system. And it was really interesting less so because of the processing of the CSV and then enqueuing jobs. But it was more of the reporting that went behind it and the process that went into writing this task. So Joël and I were pairing on this task. Joël being another thoughtboter and also a former guest on this show. And we had an interesting process of where we started with one, let's do the simplest thing. Let's get it done. Let's also check through the CSV because you're often going to find stuff that doesn't align with what you expect it to when it's a CSV that's provided from an external source. One of the risks that we highlighted right away was how are we going to get the CSV on the server? Because we just have this one CSV that we need to run. We don't want to add it to the repo, and we can't generate it ourselves. So how are we actually going to get the CSV in a place that we can run this in a production mode? I learned that I could pass a CSV as standard input into the Rake task. So then I could actually run it locally because we're using AWS. So I could inform AWS to run this task, but then I could actually stream the CSV into the task that way. And that was really nice because then we no longer had the question of how are we going to get this file on the server? CHRIS: That's interesting. I didn't know...Yeah, the streaming of it from local to remote is an interesting one. On Heroku, I will typically open up a bash prompt, so Heroku run bash. And then, I will curl the file down onto the server and then run it locally. But that's an ephemeral dyno. It may die at any point. There are various things that could go wrong there. So that's always interesting. I imagine a similar thing could be done, but I don't know, actually, if you can directly stream into a Heroku dyno like that, which is an even more straightforward one because I end up having to bounce a file off of a random. Like, I'll often put it in a Gist or a Pastebin or something like that. And then I'll curl it down to the server, and yeah, this is interesting. STEPH: Yeah, I'm also not sure the specifics of how it would work with Heroku. But it was a really nice process for us to be able to use versus having to then read the file from, like you mentioned, curl it from somewhere else and then be able to parse it that way. Two other things that were top of mind for working on this task is one, item potency. You're going to rerun it, friends. At some point, your task is either going to bomb, and it's going to err. And then you're going to have to triage and run it again. Or whoever requested that you run this task and they said, “Oh, it's just temporary. We're just going to run the once,” that's not true. You're going to run it again. So keep in mind how to make that safe, that you can rerun it. And then that won't be its own scenario that then you have to triage and figure out. CHRIS: Item potency is one of those critical ideas, and I just wish the word were different. I feel ridiculous every time I say it. And I feel like I have to push my glasses up on my nose, and I'm like, well, have we considered item potency for this? But it's such a good idea. And it's the sort of thing that...you're totally right. Every time you're doing this sort of thing, it is something that you should consider. And we use GET requests, and they have rules about it. And it's such a good idea and such an important idea. And I just wish the word were different so that I felt more comfortable using it in polite conversation. STEPH: [laughs] I don't know why… and this may be sharing too much of myself. But the song Under Pressure by Queen and David Bowie the Under Pressure song has been in my head. But I've been replacing the under pressure part with item potent. So it's [singing] under pressure, and I've been [singing] item potent. [laughter] And that has just been my song for the week. CHRIS: You've normalized it enough for me now that I'll just hear you singing it every time, and I'll be like, this is a nonsense word. We're fine. We can just go – [laughs] STEPH: That's what I'm here for, to turn technical terms into nonsense. [laughs] CHRIS: It's really what this show is about at the end of the day. So you are our hero. STEPH: I just have to work on more lyrics for the song. I really just have that one line, that one hook. [laughs] CHRIS: Now I just want to scrap the rest of the episode and just come up with lyrics to item potent. [chuckles] But maybe we don't do that. STEPH: [laughs] CHRIS: Maybe that'll be after the credits B-roll, something like that. STEPH: The other way I do phrase that question is I'm like, what happens when it fails? And that always feels like a safe way. Because if I ask someone like, “Hey, is the item potent?” It feels more natural for people to be like, “Oh, it's fine. It doesn't need to be.” But if you say, “What happens when it fails?” It's harder for someone to say, “Oh, it's never going to fail. [laughs] There is nothing that could go wrong.” So it feels like a more intentional question in regards to how are we going to handle this when we need to rerun it? The other part that really came in handy was the fact that we spent more time on the reporting as well. So we really wanted to know what happened when we are processing all of these rows. So were there any invalid rows? And if we do encounter an invalid row, do we want to just stop processing and stop right there, or do we want to keep moving? Do we have any rows that didn't match, a row in our database, and how do we capture those? And because it's item potent, maybe we want to capture skipped rows so then that way when we rerun it, we can see okay, well, we skipped, you know, a thousand rows because we'd already run them before. And all of that reporting has been so handy because we're also using this to triage. Like, hey, we're sending a bunch of messages to this third-party system. We reach out to that third-party group, and we say, “Hey, we sent you all of this. This is how it went. Let us know how it went on your end.” And then, we can have a more collaborative discussion around what happened on their end versus what happened on our end, and then we can make tweaks to each system. So overall, it felt more of that run-of-the-mill task where you're going to write a Rake task, you're going to parse a CSV. But something about the reporting really resonated with me because in the past, when I've written Rake tasks, I've leaned more on the this is temporary, so it's okay if it's not great. But the reporting has been so crucial that from now on, I always want reporting from any Rake tasks that I run, and I want to know what happened. And then I also want to be able to rerun it. And I'm very wary of any time that someone says, “Oh, this is temporary,” because then I also think that leads to interesting discussions around testing. Because initially, when we started this, we were under some pressure. Hey, that goes back to my song. We were under some pressure for writing this particular task. And then the question came up: do we want to test it? And to be frank, testing a Rake task isn't great; it's not fun, which is one of the reasons we get out of a Rake task as quickly as possible and put it into a class. So that was also one of the drivers or one of the conversations that went against, like, oh, this is temporary. So it's okay if it's not the best code. It's okay if it's not tested. And then I was more of an advocate for, like, well, I don't feel good about this. And I'm rerunning the Rake task every time I want to confirm that the changes that I've made are correct. And so once I hit that manual labor point where I'm like, okay, I'm testing this. I just don't have automated tests for this, that then I actually started adding test coverage around it. CHRIS: I'm so excited that we have transcripts, particularly for that last minute that you were just talking about, because I feel like that was a mini master class in software development. And more generally, there's been almost like a poetic something to the two different topics that you've brought up today are the sort of mundane, very real things that actual software development is made almost entirely of. It's not often that we're just starting with a greenfield app and building a new thing. I happen to be doing that this week, but it's rare. It's going to be over very soon. And then I'm going to be in the world of oh; we have to backfill a bunch of data. How are we going to do that? Or we have this portion of the code that, frankly, we should have been testing more, but we didn't. How do we deal with that? And these murky, gray areas where there isn't a clear answer and you have to go with intuition, and you have to...a bunch of the things that you just listed as these good heuristics that you have around how you think about software. I'm just really excited for the transcript to that because that was awesome. STEPH: I'm so glad you enjoyed it because I think it's not until right now where I'm processing this and talking about it with you that it is...I was trying to think earlier, like, why is this so interesting? Why am I so excited to bring this here to this conversation? And I think it is for the reasons exactly that you said, that it does feel like one of these...this is a mundane task. We write a task; we process some things; we send some data. We do that all the time. But then it's all the other bits around it, and the other ways that we've been bitten, and how we avoid those scenarios, and then how we identify a risk like when someone says, “Oh, it's temporary. It's fine.” That part, I think, is always the very interesting aspect of writing software. CHRIS: Do you consider this sort of stuff the distraction from the work or actually the work? And in my experience, this makes up a lot of the work. And treating it like what you were saying about testing like, “Yeah, that thing where you're telling me that it's going to be temporary and we probably don't need to test it, I've been told that before,” and I just want to spot-check that real quick. Or what you said of the when I was manually testing, and I crossed a threshold where I'd done that enough, that now adding a test harness around that totally makes sense. It's worth the investment at that point. Those little heuristics that we build up over time are the things that are hard to get. And so, yeah, I love that conversation. STEPH: I really like how you also asked and then responded to that question around is this distraction, or is this the work? And I am wholeheartedly with you that this is the work. This is the part of the work that I do find interesting, and knowing when to make those trade-offs, and when you've hit a decision point, and which direction you're going to go, and being able to recognize something that otherwise could have been a fire. It could have been much worse in terms of if we'd built a task that wasn't robust. Because of course, then the second time that I ran it, you know, emphasis on the second time that I ran it because we needed to do it again to process more data. It erred halfway through, and I panicked in the moment. But then I was like, oh yeah, this is fine. We planned for this. This was in the game plan. So it goes back to that we want the calm execution. We want to plan so we are back in that calm state. We want calm software. And this feels very in line with how do we make this more calm? CHRIS: I love that theme that you're bringing up there, which I think is a theme that we've touched on a bunch of times. I think we actually have an episode called Seeking Calm. And I think that little title there, as much as I love the nonsense titles that we have for most of the episodes, that one I think really captures the theme that a lot of what we talk about is in orbit around yeah, we want it to be calm. We don't want things to be on fire every day. And what does it look like to build software with that in mind? STEPH: Yeah. I also love that theme. And I like that it's something that we have surfaced and then really stuck to because it resonates deeply with me. But that's pretty much all I have for my Rake task adventure. What else is new in your world? CHRIS: Well, I have one more hopefully quick thing. I'm going to try and boil this down to its essence, but I ran into, let's call it, a subtlety. It's not an issue. It wasn't a bug per se. But looping back to the previous episode that you and I recorded together, we talked a bunch about multi-step forms, which was a great conversation in and of itself. But I eventually completed the feature that I was working on, put it up for acceptance. And the product manager who was reviewing it highlighted a couple of different things. They recorded a video which, as an aside, I love that as a way to do acceptance and show what's going on and talk through it. There were a couple of smaller issues, which I was able to resolve very quickly, but there was one more interesting one that I've extracted this as future work because it was too complex to try and solve in the moment. But basically, what's happening is imagine that we have a two-step form. So there's the first page of the form. The first form that you see is for your name. So it's just an input that says, “Name,” and you fill in your name and then you hit continue. That posts to the server. We save off that data. And then, we redirect you to the next page on the form, which is, say, phone number. So two steps. We start with name; we go to phone number. What happens if you type in your name, you hit continue, everything processes correctly. You end up on the phone number page, but you hit back. What do you think happens? STEPH: I would expect to go back to the name field and probably expect my name to be populated but would also be fine if it's not. CHRIS: I like that you would be fine with the fact that it's not, if it's not, because it's not is the answer. And what's unfortunate is so if someone goes back, they will see the unpopulated form, so not filled out. But if they reload at that point, we will serialize down the value and pre-fill the input with their saved data. And so that inconsistency is not great. It's all the more unfortunate because as I tried to resolve it, I'm like, oh, okay, this feels like a solvable thing. I just need to tell Chrome, “Hey, if someone hits the back button, do a better thing than what you're doing.” I needed a way to instruct Chrome or whichever browser because this should be a standards-level thing. And there are things in the HTTP spec about this. So there's the Cache-Control Header is one of the headers that you can send down with a response. And there's a bunch of different values that can be in there, no-cache, no-store. There's also the…I want to say it's the max-age, or I think it's Expires. That's a different header. But you can set it to have an expiry that's just already expired. There's also a Pragma, which you can say no-cache. Some of these are standard. Some of these are not standard. Chrome ignores all of them. Chrome's just like, “Nevermind.” So the idea is that those headers are intended to inform intermediate proxies. Say you have a caching layer, so you're using Fastly or CloudFront or something like that. When that service fetches the page from your backend, from your actual, say, Rails app, then it will look at that header and say, “Should I hold onto this for a little while or not? Is it public, or is it private? What should I do as an intermediate caching proxy?” Ideally, Chrome would also look at those and say, like…there should be a version of me being able to tell Chrome, “Listen, if someone hits the back button, please go to the server and ask for it.” Like, I'll take the second of latency that that introduces in navigating back because I always want to show them the correct data. Unfortunately, I have not found a way to do that. There's a bunch of things on Stack Overflow and other places of JavaScript solutions where I can listen to the window.popstate event and then force location.reload. But that feels like a pile of hacks that I don't want to get into. It feels like it will be very inconsistent between browsers. So I am still searching for a solution. But I would like to figure something out here. As a more pointed version of this to try and explain an example where this could happen, imagine that you've got the header of your application, and in it, you have a sign-out button. And so that sign out is going to delete to the session's endpoint. So you're deleting your session. And after that, you get redirected to the login form. If you then hit back, you will be taken back to the browser's cached version of the previous logged-in state page that you were at. This is probably fine in a lot of cases. If you reload, you can't do any nefarious action at that point because you are logged out. But you are seeing potentially sensitive information. So imagine that you log in in a cafe, you go through Gmail, or whatever, or your bank, then you log out, you walk away. If you leave that page up and someone hits back, they can now see what was on the page. And part of that particular version, I read a bunch of backstory about that on the Inertia repo because someone posted this as an issue against Inertia as a framework. And the Inertia team...and I really love how they handle these sorts of things. So they were very kind, very welcoming to the issue but also said, “Actually, we're doing...like, this isn't us. But let's talk about it,” and gave a ton of detail and went through the HTTP spec. And it's a fantastic issue as a read. It's like a fun bedtime reading sort of thing to learn about how the internet works. But the Inertia crew really, really cares about being spec-compliant and doing the right thing. So, unfortunately, this is outside of their purview as well. But yeah, I don't have a solution, and it makes me sad. STEPH: I liked that second example that you provided because I feel like I see that one more commonly when I'm on an application, and I don't know why. But I hit back, and then it shows that I'm signed in, and I'm like, that's a lie, I'm not signed in. I also really appreciate how Inertia is responding so kindly and welcoming to folks and then providing such thoughtful responses. That sounds immensely helpful. I don't know, yeah, I am also interested in this. It's something that I haven't worked with in a while, so I don't have any grand ideas at the moment. So I'm also curious if other people have run into this and how they've approached it. CHRIS: Yeah. If we're being honest, partly I wanted to share this with you, but also I wanted to say this into a microphone, and then hopefully someone out there on the internet knows an answer. I've tried, I think, all of the normal things, all of the different variations of headers. I haven't actually poked at the JavaScript things yet, but that's probably the direction I'm going. But if anyone out there has an idea, I would absolutely love it. I think in my mind, the ideal version of this is if I'm making GET requests and I'm clicking around on a page, it's perfectly fine for Chrome to use its cache version of the previous page because, sure, that's fine. It may actually be stale just based on it's been a few seconds, and something's changed on the server, but I'm willing to accept that. But if I've posted, or patched, or deleted, or done any action that by definition should be changing data on the server, then I would love for a way to invalidate Chrome's back cache, so its version of the pages that it's restoring when I'm hitting back. I'd love that as the heuristic to get to. I don't know if I can get there. My sense says chrome's like, “No, I want to go fast. That's all I care about.” [chuckles] I'm like, all right. Well, I get that vibe but -- STEPH: Yeah, that's a nice, succinct way to say that if I've changed data, then I want to invalidate that browser cache, so then we don't show them a fresh page and we actually show them the name that they entered on the form. CHRIS: As we know, though, cache invalidation is one of the very easy things to do in software development. So I'm sure my naive, quick idea is very easy to implement and will have no edge cases of its own. STEPH: Well, this will be our parallel Pixar movie. We have one that we highlighted earlier, and this will be the other one, The Cache Buster. I'm not great with titles. [laughs] This will be our other Pixar movie. CHRIS: Buster the Lonely Cache. Yep. STEPH: All right. Well, in parallel, we'll work on Buster the Lonely Cache. Is that the name of this? CHRIS: Yep. STEPH: Cool. We'll work on that script. And in the meantime, I'll also think about it if I encounter this or come up with some ideas and share them with you. And then also if other people have any ideas, that'd be fantastic. CHRIS: That would be fantastic. STEPH: Yes. Please write in to help Buster with the lonely cache, which, wait; I don't get it. Why is it the lonely cache? CHRIS: Because the cache has been busted and evicted. So he's got no friends. There's nothing...There's no data left. I don't know. STEPH: [laughs] CHRIS: I came up with it real quick. I don't stand by it. It's not a great idea, but we'll workshop it. It'll be fine. STEPH: That's true. Yeah, we'll go through it. I'm asking too many questions for a very quick creative. We're in the creative space, not the critical space. But please write in to help Buster figure out [laughs] the lonely cache or how to bust the cache. Oh, goodness. I'm done with my jokes for today. I'll try to stop. CHRIS: I believe that's a perfect note. Shall we wrap up? STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. 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.

294: Perfect Duplication

Play Episode Listen Later May 25, 2021 45:31

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.

tv love friends google pr teaching mvp mess personally react flipping users api gmail dry marie kondo javascript rails googling go ahead elm scala circling mandy moore haskell duplication heroku lisp refactoring rest apis svelte chris yeah christ here ben orenstein chris you chris oh thoughtbot sandi metz sidekiq avdi grimm chris thanks pragmatic programmers katrina owen chris they chris fair chris toomey

272: Hacking the Gibson

Software Developer's Journey

Play Episode Listen Later Dec 15, 2020 33:27

In this week's episode, Chris undertakes long-running background jobs that are performing duplicate work and adding significant load on the database. Steph shares her initial take of the book "Soul of a New Machine", a non-fiction account that chronicles the development of a mini-computer in the 1980s. They also dive into the question "how can teams turn a slow, hard to maintain test suite from a liability into an asset?" and touch on how to identify highly-functioning teams. 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. HelloFresh (https://HelloFresh.com/bikeshed80) - Visit HelloFresh and use code bikeshed80 to get $80 off including free shipping. ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. Sidekiq (https://github.com/mperham/sidekiq) The Soul of a New Machine by Tracy Kidder (https://www.tracykidder.com/the-soul-of-a-new-machine.html) Bike Shed Episode 236 - Featuring "The Cuckoo's Egg" by Cliff Stoll (https://www.bikeshed.fm/236) Hackers (https://en.wikipedia.org/wiki/Hackers_(film)) WarGames (https://en.wikipedia.org/wiki/WarGames) Labyrinth (https://en.wikipedia.org/wiki/Labyrinth_(1986_film)) Therapeutic Refactoring by Katrina Owen (https://youtu.be/KA9i5IGS-oU) Goodhart's law (https://en.wikipedia.org/wiki/Goodhart%27s_law) Drive by Daniel Pink (https://www.danpink.com/drive./) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

soul drive testing hackers hacking labyrinth egg war games rails daniel pink goodhart new machine tracy kidder sidekiq katrina owen cliff stoll

Communication Debt with Andrea Goulet

Legacy Code Rocks

Play Episode Listen Later Oct 19, 2020 43:54

As menders working with legacy code, we are focused on identifying and reducing technical debt. But how much easier this task would be if the creator of the code or the previous maintainer left us some breadcrumbs to follow? A simple note on the rationale for a particular decision they have made or a warning about interconnected lines of code would take us a long way! Today we talk with Andrea Goulet, co-founder and Chief Strategy Officer of Corgibytes. Her empathy-driven approach to software development earned her recognition as one of the Top Ten Professionals in Software Under 35 by LinkedIn. She tells us about this lack of communication in software development, the phenomenon she calls the communication debt, and how its reduction can make the software more robust and its maintenance more efficient. When you finish listening to the episode, connect with Andrea via LinkedIn, contact her via Corgibytes' website, and check out her LinkedIn courses: Agile Software Development: Remote Teams and Creating an Agile Culture. Mentioned in this episode: Andrea on LinkedIn at https://www.linkedin.com/in/andreamgoulet/ Andrea on Twitter at https://twitter.com/andreagoulet Corgibytes website at https://corgibytes.com Andrea Goulet, Agile Software Development: Remote Teams at https://www.linkedin.com/learning/agile-software-development-remote-teams Andrea Goulet, Creating an Agile Culture at https://www.linkedin.com/learning/agile-software-development-creating-an-agile-culture Changelog podcast with Katrina Owen at https://changelog.com/podcast/108 Katrina Owen, Exorcism.io at https://exercism.io Indi Young, Practical Empathy at https://amzn.to/3jkDlLH* Legacy Code Rocks with Indi Young at https://www.legacycode.rocks/podcast-1/episode/270edc0e/practical-empathy-with-indi-young Ward Cunningham on technical debt at https://youtu.be/pqeJFYwnkjE Legacy Code Rocks with Arlo Belshee at https://www.legacycode.rocks/podcast-1/episode/c240c45d/naming-with-arlo-belshee Daniel Kahneman, Thinking Fast and Slow at https://amzn.to/3kceRW3* Legacy Code Rocks with Cyrille Martraire at https://www.legacycode.rocks/podcast-1/episode/2fd0fdeb/living-documentation-with-cyrille-martraire Cyrille Martraire, Living Documentation at https://amzn.to/3kd2J7e* * Heads up! If you purchase a book through the links above, we will get a small commission which helps us continue to bring quality content to our Legacy Code Rocks! community. You won’t pay a penny more, we receive a small kickback, and you’re supporting our friends who wrote them. Everybody wins!

debt exorcism chief strategy officer daniel kahneman thinking fast changelog andrea goulet indi young ward cunningham corgibytes agile culture katrina owen arlo belshee

#72 Katrina Owen, one little piece at a time

Play Episode Play 28 sec Highlight Listen Later Oct 21, 2019 46:21

Katrina first told us about her rocky start that had nothing to do with science or programming. She described the detours she took and how she finally woke up earning a living as a programmer some day. She explained how her first job in a fashion startup was a forming experience and how she picked her next job afterwards. We touched on her debut in public speaking and how it started an avalanche that led her -through hard work- to working for Github nowadays.Katrina is an ecosystem engineer at GitHub. She accidentally became a developer while pursuing a degree in molecular biology. When programming, her focus is on automation, workflow optimization, and refactoring. She works primarily in Go and Ruby, contributes to several open source projects, and is the creator of exercism.io, a platform for code practice and programming mentorship.Here are the links of the show:https://www.twitter.com/kytrinyxhttp://exercism.iohttps://exercism.io/bloghttps://events.codemotion.com/conferences/berlin/2019/Book: "99 Bottles of OOP", book that Katrina co-authored with Sandi Metz https://www.sandimetz.com/99bottlesBook: "Good Strategy / Bad Strategy: The difference and why it matters" by Richard Rumelt: https://amzn.to/2NoqY5oCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayPatreonFinally, if you want to help produce the podcast, support me on Patreon. Every cent you pledge will help pay the hosting bills!Thanks!Support the show (http://bit.ly/2yBfySB)

germany drop software gift piece mentoring developers github bottles timoth software engineering crafters oop yung kartz richard rumelt sandi metz katrina owen

Katrina Owen, ecosystem engineer at GitHub

Creating useful people

Play Episode Play 30 sec Highlight Listen Later Jun 8, 2019 41:51

Decision-making frameworks for a successful career and lifestyle.Katrina Owen is an ecosystem engineer at GitHub, the world’s leading software development platform. She accidently became a software developed whilst pursuing a degree in molecular biology! Katrina is also the creator of Exercism, a platform for code practice and programming mentorship that has helped over 200,000 people all over the world learn new programming languages. Katrina mainly works in programming languages Go and Ruby, and she’s a Ruby Hero, which is an award given out by Ruby to their top programmers. Katrina is committed to creating beautiful code and has co-written a book about this called 99 Bottles of OOP.In this episode we discuss Katrina’s life before and after the pivotal age of 25, her younger self’s approach to decision-making, how introverts become exhausted and putting lifestyle and routine at the centre of success. More from Katrina on her website.Support the show (https://www.amazon.co.uk/dp/0992691362)

decision engineers ecosystem github bottles oop exercism katrina owen ruby hero

RWPod Кафе 9: Katrina Owen

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Mar 11, 2019 27:48

Добрый день уважаемые слушатели. В гостях RWpod Cafe сегодня Katrina Owen: Текстовая версия Could you briefly introduce yourself? What will your talk be about, exactly? Why this topic? You are a co-author of “99 Bottles of OOP”. Are there any plans for a new book? Exercism had started in 2013. Nowadays, after 6 years, do you have any high-level conclusion about it? After all this year with Exercism what did you learn about managing open source project? From your perspective, which skills are most important for the software developer? When working alone and when working with a team? If you did something that turned out to be the most expensive technical lesson you have learned? Do you have any “must read” list of books for a software developer? Why Kytrinyx? What is the background of the nickname? You have a Bachelor Degree in Molecular Biology. Does this knowledge help in your software development? What do you like to do in your free time? Blog Github Twitter 99 Bottles of OOP Exercism RubyC 2019

bottles molecular biology oop bachelor degrees exercism katrina owen

102: Sticky in the Flow with Katrina Owen

Greater Than Code

Play Episode Listen Later Oct 24, 2018 55:31

Greater Than Code Episode Episode 008: 99 Bottles of OOP with Sandi Metz and Katrina Owen (https://www.greaterthancode.com/2016/11/21/008-sandi-metz-and-katrina-owen/) 01:29 – Katrina’s Superpower: Organizing and Systematizing 09:44 – Motivation by Success The 5 Second Rule | Mel Robbins (https://melrobbins.com/blog/5-second-rule-everyday-courage/) Procrastination | Mel Robbins (https://www.youtube.com/watch?v=SFOUrb-Jyq0) 18:04 – Trust and Code Review 27:04 – Systematizing and Refactoring 30:54 – Training for Circus and its Parallels with Software Development and Mentorship and Working with Others Sarah Mei: How We Make Software: A new theory of teams (https://vimeo.com/178469403) 43:12 – Deliberate Practice and the Appearance of Expertise Reflections: John: Short iterations and early feedback as a way of creating and maintaining motivation. Coraline: How to create a sense of psychological safety in code reviews, in particular. Sam: The five-second window in which you can change your behavior and increase motivation. Janelle: Feedback loops as spirals that are reinforcing towards the positive or negative. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Katrina Owen.

amazon trust training motivation llc mentorship slack circus appearance sticky parallels bottles software development deliberate practice oop systematizing sandi metz second rule mel robbins katrina owen devreps

169: Fear Driven Development

development code software hackers rebuilding programming open source ground up software engineering jerod changelog exercism katrina owen

Play Episode Listen Later Sep 7, 2018 38:44

Chris is joined by Kane Baccigalupi, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since. Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do that, testing vs test driven development, and approaches for refactoring large untested systems. 18F - A consulting team within the government helping to introduce modern software development practices. Kane's tweet about the enjoyment of the refactoring and design parts of the process. Sarah Mei on The Bike Shed Uniform Access Principle Observations on the testing culture of Test Driven Development - TDD article that introduces the phrase "calling the shot" for the practice of TDD. Convenience class methods on service objects Testing Pyramid - A way to think about the cost and value of the various types of tests. Therapeutic Refactoring by Katrina Owen Katrina Owen on The Bike Shed Strangler Pattern - A systematic approach to refactoring and decomposing large-scale The encasement strategy: on legacy systems and the importance of APIs Martin Fowler on the Strangler Pattern

fear san francisco development driven observations convenience apis uniform tdd california state test driven development martin fowler 18f katrina owen sarah mei

Episode 44: Learning Programming Languages and Strategies With Katrina Owen

Tech Done Right

Play Episode Listen Later Aug 22, 2018 42:47

Learning Programming Languages and Strategies With Katrina Owen Table XI is offering training for developers and product teams! For more info, email workshops@tablexi.com or go to http://www.tablexi.com/workshops Guest Katrina Owen (https://twitter.com/kytrinyx): Blog (http://www.kytrinyx.com/) | Katrina’s Talks (https://confreaks.tv/presenters/katrina-owen) Summary What's a good way to learn a new programming language that focuses on solving problems and not merely syntax? Katrina Owen is the creator of Exercism, a tool for getting beyond "hello world" in new programing languages. She is also the co-author of 99 Bottles of OOP, and the presenter of a number of outstanding technical talks. We start off by talking about Exercism, how it started, how it evolved and what it’s good at, and then we talk about how the process by which it evolved, and how Katrina learned to analyze the project more strategically, and how that strategic thinking has helped her in other parts of her life and career. Notes 02:14 - Exercism (https://exercism.io/) 03:37 - Solving Programming Language Learning 99 Bottles of OOP (https://www.sandimetz.com/99bottles/) Practical Object-Oriented Design: An Agile Primer Using Ruby (https://amzn.to/2nV55Mt) 06:15 - Redesigning Exercism: Conceptually and Logistically 17:41 - Exercism Language Communities Exercism Language List (https://exercism.io/#explore-languages) Elixir (https://elixir-lang.org) Delphi (https://www.embarcadero.com/products/delphi) CFML (https://helpx.adobe.com/coldfusion/get-started.html) Coq (https://coq.inria.fr) Ballerina (https://ballerina.io) Pharo (https://pharo.org) Haskell (https://www.haskell.org) 23:45 - Gaining Control of an Open Source Community/Project 27:37 - Strategy and Priority Good Strategy Bad Strategy: The Difference and Why It Matters (https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239) Mud Rooms, Red Letters, and Real Priorities (http://www.43folders.com/2009/04/28/priorities) Chad Fowler: Great Leaders Don’t Juggle Priorities (https://medium.com/@chadfowler/great-leaders-don-t-juggle-priorities-f83c74f37905) 32:54 - Strategy vs. Tactics Related Episodes Rubyists in Other Languages with James Edward Gray II and Steve Klabnik (http://www.techdoneright.io/43) Programming Languages and Communication With Kerri Miller (http://www.techdoneright.io/34) The Elm Programming Language with Corey Haines (http://www.techdoneright.io/17) Special Guest: Katrina Owen.

Rebuilding Exercism from the ground up

The Changelog

Play Episode Listen Later Aug 8, 2018 73:46 Transcription Available

Adam and Jerod invite back Katrina Owen after years away focusing on Exercism—a 100% free platform for code practice and mentorship with over 2500 exercises and 48 different language tracks. They talk to Katrina about how the platform has changed, the direction it’s taken, the backstory on the recently launched version 2, and how she plans to turn Exercism into a sustainable business. Also, what happens if that doesn’t work?!

Rebuilding Exercism from the ground up (The Changelog #309)

development code software hackers rebuilding programming open source ground up software engineering jerod changelog exercism katrina owen

Play Episode Listen Later Aug 8, 2018 73:46 Transcription Available

Better Public Speaking with Chad Fowler

The Better Show

Play Episode Listen Later Jun 25, 2018 85:13

We explore how to engage an audience with public speaking veteran Chad Fowler. We talk the art of storytelling, how to surprise an audience and the pros & cons of scripted versus free style public speaking. Show Notes 1:13— We introduce our special guest for this episode, Chad Fowler. 4:16— Chad describes how he first began becoming aware of the importance of public speaking from watching his grandfather, who was an electrifying Assembly of God preacher. 6:07— We discuss the training that preachers go through that helps them learn how to best deliver a public speech using techniques like physical movement and one's position on stage to enhance the message they intend to convey. 7:35— Chad recounts an experience where his history of writing and speaking about programming in Ruby caused others to consider him “the best Ruby programmer in the world” even though they had not seen at any of the code he'd personally written. 8:50— “If you speak around a topic, you tend to be perceived as one of the leaders in that topic.” — Chad Fowler 19:02— Chad compares the experience of creating a public speaking performance to creating an improvised jazz track and how you never really know how it went you can gauge audience reaction. 20:16— Chad shares a tip about how he prepares a speech. He creates a basic outline but gives himself the freedom to improvise during the talk itself. 27:51— March discusses the difference between being under-prepared and over-prepared for a speech and Chad agrees with a comparison to creating an improvised musical piece. 31:15— We explore the tactics that stand-up comics use to prepare their material for a performance and rigorously study their audience's reactions. We also mention a few of our favorite stand-up comics and explore the unique styles they have for their performances. 35:42— Chad discusses some advice he outlined in an essay he wrote titled “On Having Something to Say”. 39:20— On getting the nerve to speak on a topic: “If you don't think you have anything to say, then you can think about what you wish you had something to say about.” — Chad Fowler 47:48— Chad explains why he never rehearses his public speaking performances. 49:45— Ian shares a trick that Rosie O'Donnell used to elevate the energy of her audience prior to a show. 54:35— We discuss the power of silence as a tactic that speakers can use to captivate audiences. 58:20— Chad shares the names of a number of speakers that he admires for their great storytelling ability. 1:01:58— Ian shares a few of his tips about how to get more comfortable with the room prior to getting on stage for a speech and Darren shares a trick that politicians use to make an audience feel more empathetic to them. 1:05:59— Ian shares the differences between speaking to large audiences versus smaller audiences and March recounts his anxiety in presenting to Bill Gates on several occasions. 1:08:47— Ian asks Chad for his advice on how to get started with public speaking. 1:13:27— Ian decides to experiment by picking one of his passions and 1:14:13— March decides to dive deeper into the talks by Sandi Metz, Katrina Owen, and Dave Thomas to get better at storytelling. 1:14:45— Darren decides to practice employing the use of silence as a tool to better engage audiences during his presentations. 1:15:19— We talk a bit about Chad's earlier decision to step back from public speaking. Mentions Netflix comedy special: Gad Elmaleh Improv comic: Todd Barry Post: On having something to say by Chad Fowler Author & book: Michael Pollan Public speakers that Chad admires for their storytelling ability: Sandi Metz, Katrina Owen, Dave Thomas, Michael Lopp Post: How to get your conference talk accepted; inspired by Ben Orenstein Follow Us Instagram Facebook Twitter Subscribe iTunes RSS Weekly email newsletter Full Episode Transcript Better Show Blog Feedback Email: hi@bettershow.io Enjoy the show? Leave a review in iTunes! Tell two friends about the show!

god bill gates communicate public speaking assembly dave thomas sandi metz chad fowler katrina owen

Ep. 146 - Codeland - Mentorship, Technical Blogging, and Open Source Talks from Katrina Owen, Quincy Larson, and Nell Shamrell-Harrington (Katrina Owen, Quincy Larson, Nell Shamrell-Harrington)

CodeNewbie

Play Episode Listen Later Jul 31, 2017 50:42

In our final episode of our Codeland mini-series, Katrina Owen shares what it really takes to get that mentor you've always wanted, Quincy Larson gives us his best practices for writing technical blog posts people will actually read, and Nell Shamrell-Harrington explores what it really takes for an open source project to be successful and what you should know as a future contributor. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Sample Testing Guide How to read Medium articles people will actually read CodeNewbie YouTube channel Continuous Integration (CI) Open Source Governance Sample Code of Conduct Travis CI Sample Contribution Guide Be Lucky—it’s an easy skill to learn by Richard Wiseman Codeland, CodeNewbie's conference - April 21 and 22 in NYC Codeland Conf Codeland 2019

medium mentorship technical blogging open source mongodb heroku codenewbie quincy larson katrina owen nell shamrell harrington codeland

Rebroadcast - Sandi Metz and Katrina Owen Interview

bottles oop saron sandi metz katrina owen

Play Episode Listen Later Mar 9, 2017 66:02

In this rebroadcast, Nadia and Saron interview Sandi Metz and Katrina Owen on their book, 99 Bottles of OOP.

Exercism and 99 Bottles of OOP

Spotlight

Play Episode Listen Later Dec 9, 2016 26:09 Transcription Available

Welcome to the first Spotlight series recorded at OSCON London 2016. Jerod talked with Katrina Owen, an accomplished speaker, creator of the excellent coding practice and feedback site, Exercism.io, and the co-author of 99 Bottles of OOP. Have you ever heard the story of how Katrina went from anonymous developer to sharing a byline with Sandi Metz? She shared all the details during this face-to-face chat.

development conference code software hackers programming spotlight open source bottles software engineering jerod oop changelog exercism katrina owen

Exercism and 99 Bottles of OOP (Spotlight #2)

development conference code software hackers programming spotlight open source bottles software engineering jerod oop changelog exercism katrina owen

Play Episode Listen Later Dec 9, 2016 26:09 Transcription Available

Episode 008: 99 Bottles of OOP with Sandi Metz and Katrina Owen

Greater Than Code

Play Episode Listen Later Nov 21, 2016 62:06

00:16 – Welcome to “99 Bottles of Podcasts!” …we mean, “Greater Than Code!” 99 Bottles of OOP by Sandi Metz and Katrina Owen (https://www.greaterthancode.com/2016/11/21/008-sandi-metz-and-katrina-owen/) 01:31 – Collaboration on the Book Practical Object-Oriented Design in Ruby by Sandi Metz (https://www.poodr.com/https://www.poodr.com/) People who like me call me disciplined & meticulousPeople who don't call me anal & pedanticIt's the same thing. @kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 14:56 – Audience: Who is this book for? 99 Bottles of Beer Exercise (https://www.sandimetz.com/99bottles/sample#appendix-exercise) 21:06 – The DRY (Don’t Repeat Yourself) Principle (https://en.wikipedia.org/wiki/Don't_repeat_yourself); Duplication and Replication DRYing too hard: "people encapsulate the pieces that are identical, though they don't represent a complete idea." @kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 29:21 – Code Review and Naming Things 30:40 – “In what ways is it 99 Bottles a richer kata than fizz buzz (http://wiki.c2.com/?FizzBuzzTest)?” – Benjamin Fleischer (https://twitter.com/hazula) 32:53 – “The 99 Bottles book seems to document all the trade-offs we’ve been implicitly making. Could this possibly be a first step in automating those decisions? i.e.: Might we take those now-explicit rules and partially automate the process of programming?” – Craig Buchek (https://twitter.com/CraigBuchek) 34:47 – Llewellyn Falco: “Sparrow Decks” (http://llewellynfalco.blogspot.com/p/sparrow-decks.html) Kathy Sierra (https://en.wikipedia.org/wiki/Kathy_Sierra) Philip Kellman (https://en.wikipedia.org/wiki/Philip_Kellman) 39:57 – “what non-Ruby technologies are you interested in right now?” – Darin Wilson (https://twitter.com/darinwilson) The more people involved in a projectthe less important the code becomesand more important the interactions.@kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 “Code is easy; people are hard. If you want to get things done, you have to get good at people.” - @sandimetz— Greater Than Code (@greaterthancode) November 21, 2016 45:00 – Sandi’s Unique Approach to Teaching 47:53 – Speaking at Conferences Listening is not how people learn.We learn by doing.To help someone learn-by-doing, ask them questions.@sandimetz @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 Reflections: Coraline: Inspiration to return to work on her book about empathy. Also, exploring whether that visual interpretation of code is the shape of code in the abstract or the shape of the code that’s written on-screen. Sandi: Controversy around the notion that duplication is better than the wrong abstraction. Katrina: We are humans and we have ideas and sharing those ideas makes us visible to other humans. It is also incredibly important and impactful to speak. Jessica: Development of relationships and partnerships with someone who will push you. Sam: Helping people realize things on their own is greater than telling them the answer. Also, practicing better self-control in coding and mentoring. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guests: Katrina Owen and Sandi Metz.

amazon speaking podcasts code llc collaboration slack conferences bottles drying unique approach replication duplication oop code reviews 5etfw jessica kerr sandi metz kathy sierra katrina owen greater than code dry don devreps craig buchek

99 Practical Bottles of OOP

The Changelog

Play Episode Listen Later Oct 28, 2016 86:51 Transcription Available

Sandi Metz joined the show to talk about her beginnings on a mainframe, her 30+ years of programming experience, the ins and outs of OOP, her book Practical Object-Oriented Design in Ruby (aka POODR), as well as her latest book 99 Bottles of OOP which she co-authored with Katrina Owen. We also covered a few listener submitted questions at the end.

development code practical software hackers programming open source bottles software engineering oop changelog sandi metz katrina owen practical object oriented design poodr

99 Practical Bottles of OOP (The Changelog #225)

development software practices architecture programming open source devops docker kubernetes golang exercism katrina owen

Play Episode Listen Later Oct 28, 2016 86:51 Transcription Available

development code practical software hackers programming open source bottles software engineering oop changelog sandi metz katrina owen practical object oriented design poodr

Programming Practices, Exercism, Open Source

Go Time

Play Episode Listen Later Oct 6, 2016 76:15

Katrina Owen joined the show to explore ideas about open source, code review, learning to program, becoming a savvy programmer, mentoring, projects she’s working on, and also her very prominent and amazing code learning tool Exercism.

Programming Practices, Exercism, Open Source (Go Time #19)

development software practices architecture programming open source devops docker kubernetes go time golang exercism katrina owen

Play Episode Listen Later Oct 6, 2016 76:15 Transcription Available

Programming Practices, Exercism, Open Source

Go Time

Play Episode Listen Later Oct 6, 2016 76:15 Transcription Available

development software practices architecture programming open source devops docker kubernetes golang exercism katrina owen

Refactoring with Katrina Owen

MS Dev Show

Play Episode Listen Later Sep 16, 2016 61:19

We talk with Katrina Owen about refactoring. Is Coding Style still a thing? Open APIs or be doomed, says Visa, And I didn't want an iPhone 7, but I'll take a free one.

iphone windows visa azure refactoring katrina owen

99 Bottles - Ep 5 (1.2)

bottles saron sandi metz katrina owen

Play Episode Listen Later Aug 28, 2016 25:02

Nadia and Saron discuss section 1.2, Judging Code, in Sandi Metz and Katrina Owen's '99 Bottles'.

99 Bottles - Ep 4 (Sandi Metz & Katrina Owen)

bottles saron sandi metz katrina owen

Play Episode Listen Later Aug 22, 2016 65:44

Nadia and Saron chat with Sandi Metz and Katrina Owen about how they wrote the book, what it was like to work together, and how readers can get the most out of the book.

99 Bottles - Ep 2 (1.1.1 Incomprehensibly Concise)

bottles concise saron sandi metz katrina owen

Play Episode Listen Later Aug 7, 2016 31:15

Nadia and Saron discuss 1.1.1 Incomprehensibly Concise from Sandi Metz and Katrina Owen's newest book, '99 Bottles'.

Why Are Computers 3: Ways to Be Less Clever

Why Are Computers

Play Episode Listen Later Aug 5, 2016

Sandi Metz and Katrina Owen reflect upon the process of writing a book together, the secrets of building good software, and the logistics of the self-publishing business.

computers clever sandi metz katrina owen

99 Bottles - Ep 1 (Preface-1.1 intro)

bottles preface saron sandi metz katrina owen

Play Episode Listen Later Jul 31, 2016 24:18

In which Nadia and Saron start discussing Sandi Metz and Katrina Owen's '99 Bottles'. They start with the Preface and go up to the introduction to section 1.1., 'Simplifying Code'.

65: Free as in Puppy (Katrina Owen)

Play Episode Listen Later May 25, 2016 45:52

While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews. Katrina Owen Katrina's conference talks Make the change easy, then make the easy change Skunk Works by Nickolas Means Factory, Workshop, Stage by Sarah Mei The Product Design Sprint Exercism.io Exercism GitHub Organization

stage workshop factory puppies skunk works railsconf exercism katrina owen nickolas means sarah mei

260 RR Training with Reuven Lerner

learning interview katrina owen

Play Episode Listen Later May 18, 2016 52:58

Want to be a Ruby Rogue? Apply at https://rubyrogues.com/ruby-nuby 01:47 - Reuven Lerner Introduction Twitter GitHub Blog The Freelancers’ Show Podcast Practice Makes Python by Reuven Lerner Practice Makes Regexp by Reuven Lerner Daily Tech Video 03:49 - Training Pedagogy 07:54 - Approaching Teaching Mental Model 09:33 - Pairing People Up Metacognition 10:57 - Example: Reuven’s Training Sessions 19:59 - Moving Up The Ladder 24:06 - Company Goals 25:56 - Hostile Learners 28:00 - Breaking Into the Big Company Market LinkedIn Devchat.tv Interest Survey 35:03 - Offerings 37:53 - Cultural Differences Picks Society Of Mind By Marvin Minsky (Reuven) Peter Hessler's Books (Reuven) Regexp Crash Course (Reuven) rspec-given (Sam) Katrina Owen on Confreaks (Sam) github-shoutouts (Coraline) Ruby Together (Coraline) Ruby Rogues Episode #224: Ruby Together with André Arko (Chuck) Ruby Remote Conf (Chuck) FitBit One (Chuck)

training books mental blog freelancers github offerings pedagogy cultural differences mental models training sessions metacognition reuven arko devchat peter hessler breaking into reuven lerner katrina owen fitbit one ruby rogues episode ruby remote conf ruby together confreaks

The Travis Foundation. Interview with Laura Gaetano Links and things we talked about: Travis Foundation (http://foundation.travis-ci.org) Open Source Grants (http://foundation.travis-ci.org/grants/) The Foundation's support of Katrina Owen from exercism.io (http://foundation.travis-ci.org/2016/01/25/exercism/) Exercism.io (http://Exercism.io) Rails Girls summer of code (http://railsgirlssummerofcode.org/campaign/) Diversity Tickets (http://diversitytickets.org) Conference support Speakerinnen (http://speakerinnen.org) Prompt (http://mhprompt.org/)

interview foundation prompt rails girls exercism katrina owen travis foundation

54: Katrina Owen

Turing-Incomplete

Play Episode Listen Later Jul 3, 2015 49:54

We discuss learning, practice, exercism.io, and programming in Go with Katrina Owen. Katrina Owen Splice - Music Made Better | Splice exercism.io Teach Yourself Programming in Ten Years Making Badass Developers - Kathy Sierra (Serious Pony) keynote - YouTube Teach Yourself Programming in Ten Years CLANG by Subutai Corporation — Kickstarter

200 RR 200th Episode Free-For-All!

Ruby Rogues

Play Episode Listen Later Mar 25, 2015 82:29

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat

dogs performance unity blog code speed hiring circle expanding elements keynote hardware makers github dart nighttime panelists 200th unreal engine blender raspberry pi book reviews teaching kids red hat first principles dvorak arduino splice curious incident be my eyes saron mark haddon matt richardson other languages lego mindstorms codenewbie saron yitbarek sonic pi scott feinberg sandi metz julia grace exercism aaron patterson alex ada elizabeth moon ruby rogues mark bates go programming language game programming katrina owen sara chipps ergodox ruby rogues episode james edward gray ii shimon schocken noam nisan codenewbies keep ruby weird gamesalad

200 RR 200th Episode Free-For-All!

Devchat.tv Master Feed

Play Episode Listen Later Mar 25, 2015 82:29

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat

200 RR 200th Episode Free-For-All!

interview soundcloud stem women in tech women in stem software developers error messages katrina owen

Play Episode Listen Later Mar 25, 2015 82:29

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat

dogs performance unity blog code speed hiring circle expanding elements keynote hardware makers github dart nighttime panelists 200th unreal engine blender raspberry pi book reviews teaching kids red hat first principles dvorak arduino splice curious incident be my eyes saron mark haddon matt richardson other languages lego mindstorms codenewbie saron yitbarek sonic pi scott feinberg sandi metz julia grace exercism aaron patterson alex ada ruby rogues elizabeth moon mark bates go programming language game programming katrina owen sara chipps ergodox ruby rogues episode james edward gray ii shimon schocken noam nisan codenewbies keep ruby weird gamesalad

STEM XX 019: Understanding the error message with Katrina Owen

STEM XX

Play Episode Listen Later Mar 1, 2015

Download | SoundCloud | iTunes In this episode we are joined by Katrina Owen, a software developer. Links/Resources Keep in touch exercism.io kytrinyx.com Intro and outro music Step On (Jahzzar) / CC BY-SA 4.0

Ep. 10 - Nitpicks and Devils (Katrina Owen)

CodeNewbie

Play Episode Listen Later Nov 15, 2014 53:40

She calls them nitpicks, her term for the code reviews people get on exercism.io. It's a platform that developer Katrina Owen created to help people get mentorship and feedback on their code. It started as a project for her own students, but grew into something much more. Katrina talks to us about building her platform to help people become better programmers, how she went from being a secretary to studying biology to being a programmer, and how code newbies can make the most of exercism.io. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Head First Series Bike Shed Wordoid "Upside of Quitting" - Freakonomics Episode Sandi Metz Turing.io Javaranch Codeland Conf Codeland 2019

devils mongodb heroku nitpicks katrina owen

163 RR Education with Coraline Ada Ehmke and Katrina Owen

Ruby Rogues

Play Episode Listen Later Jul 2, 2014 76:21

Katrina Owen comes back on the show to talk education with Coraline Ada Ehmke and the rest of the Rogues.

education rogues katrina owen coraline ada ehmke

163 RR Education with Coraline Ada Ehmke and Katrina Owen

Devchat.tv Master Feed

Play Episode Listen Later Jul 2, 2014 76:21

Katrina Owen comes back on the show to talk education with Coraline Ada Ehmke and the rest of the Rogues.

education rogues katrina owen coraline ada ehmke

163 RR Education with Coraline Ada Ehmke and Katrina Owen

Play Episode Listen Later Jul 2, 2014 76:21

Katrina Owen comes back on the show to talk education with Coraline Ada Ehmke and the rest of the Rogues.

education rogues katrina owen coraline ada ehmke

Exercism.io and Crowd-Sourced Code Reviews (The Changelog #108)

practice development code software crowd hackers programming open source python javascript elixir software engineering haskell sourced jerod clojure changelog exercism katrina owen

Play Episode Listen Later Oct 16, 2013 56:09 Transcription Available

Adam and Jerod talk with Katrina Owen about Exercism.io - an open source platform for crowd-sourced code reviews on daily practice problems. Practice problems are available in Ruby, Elixir, JavaScript, Python, Haskell, and Clojure, and other languages are in the pipeline.

Exercism.io and Crowd-Sourced Code Reviews

The Changelog

Play Episode Listen Later Oct 16, 2013 56:09 Transcription Available

practice development code software crowd hackers programming open source python javascript elixir software engineering haskell sourced jerod clojure changelog exercism katrina owen

50: It's Monday today, let's change everything

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later May 26, 2013 43:26

In this week's episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jeff Casimir and Katrina Owen from Jumpstart Lab and gSchool to discuss performing, speaking, and imposter syndrome, preparing for your talk, and what makes a good talk and how to give one. The also discuss gSchool, the way the program works and they way it's guaranteed, teaching, admitting ignorance, how good practice should be harder than the real thing, and why Jeff didn't like studying Computer Science and why he didn't enjoy programming and how Rails reignited his passion for creating things, and much more. Peepcode gSchool Jumpstart Lab Code Academy galvanize Go Follow @thoughtbot, @r00k, @j3 and @kytrinyx on twitter.

computer science rails change everything code academy railsconf ben orenstein katrina owen jeff casimir

069 RR Therapeutic Refactoring with Katrina Owen

Devchat.tv Master Feed

Play Episode Listen Later Sep 5, 2012 69:37

The Rogues talk to Katrina Owen about therapeutic refactoring.

therapeutic rogues refactoring katrina owen

069 RR Therapeutic Refactoring with Katrina Owen

Ruby Rogues

Play Episode Listen Later Sep 5, 2012 69:37

The Rogues talk to Katrina Owen about therapeutic refactoring.

therapeutic rogues refactoring katrina owen

069 RR Therapeutic Refactoring with Katrina Owen