Podcasts about practical object oriented design

Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it. Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out: Adventure (try something new) Passion (topic) Profit (from recent learnings) Low-risk (applicable today) = APPL Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work. Elm (https://elm-lang.org/) Practical Object-Oriented Design in Ruby (https://www.poodr.com/) Design Patterns in Ruby (http://designpatternsinruby.com/) Quarter Life (https://www.penguinrandomhouse.com/books/579928/quarterlife-by-satya-doyle-byock/) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting. I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time. So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles] JOËL: That's really cool. How does the speed compare to other sports you've gone to see? STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest. JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something. STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games. As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again. And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff. JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play? STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up -- JOËL: Oh no. STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun. JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening. STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them. So, Joël, what's new in your world? JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice. STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up? JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works. A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database. STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails. Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup? JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models. The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database. STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work? JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database. Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one. STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later. JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself. STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it. JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice. So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them. STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed. JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool. So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence. STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people. JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going." STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements. JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile? STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be. And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it. It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too. But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me. JOËL: Yeah, it's sharing these new things we've learned along the way. STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned? JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming language. So I had mostly done procedural languages back in the day. And then I got into Ruby, did a lot of OO. And then I got into Elm, which is statically-typed, purely functional, all these things that are kind of opposite of Ruby in some ways. But I think it shares with Ruby that same focus on developer happiness and developer productivity. So, in some ways, I felt really at home. But I had to learn just a whole new way of programming. And, one, it's cool. I have a new tool in my belt. And I think it's been a couple of years just learning how to use this language and how to be effective with it. But then afterwards, I spent a couple of years just kind of synthesizing the lessons learned there and trying to see, are there broader principles at play here? Are there ideas here that I can bring back to my work in Ruby? And then maybe even are there some ideas here that intersect with some theories and things that I know from Ruby? So maybe some ways of structuring data or structuring code from functional programming where some best practices there kind of converge on similar ideas as maybe some object-oriented best practices, or maybe some ideas from test-driven development converge on similar ideas from functional programming. And I think that's where, all of a sudden, I was unlocking all these new insights that made me a better Ruby developer because I'd gone on an adventure and done something completely out of left field. STEPHANIE: Yeah, absolutely. Do you remember what was hard about that when you first embarked on learning Elm? JOËL: All the things you're used to doing, you just can't do. So you don't have looping constructs in Elm. The only thing you can do is recursion, which, you know, it's been a long time since CS classes. And you don't typically write recursion in Ruby. So I had to learn a whole new thing. And then it turns out that most people don't write recursion. There's all these other ways of doing things that you have to learn. You have to learn to do folds or to use maps and things like that. Yeah, you're just like, oh, how do I do X in Elm? And you have to figure it out. And then maybe sometimes it turns out you're asking the wrong question. So it's like, oh, how do I do the equivalent of a for loop with array indexes in Elm to, like, iterate through a data structure? And it's like, well, kind of here's technically the way you could do that, but you would never solve a problem in that way. You've got to learn a new way of thinking, a new way of approaching problems. And I think it was that underlying new paradigm that was really difficult to get. But once I did get it, now that I have two paradigms, I think it made me a much more solid developer. STEPHANIE: Right. That sounds very humbling, too, to kind of have to invert what you thought you knew and just be in that, you know, beginner's mindset, which we've talked about a little bit before. JOËL: I think in some ways now being on the other side of it, it's similar to the insights you get from speaking multiple human languages, so being bilingual or trilingual or something like that where instead of just having assumptions about, oh, this is just how language works, because that's how your personal language works, now that you have more than one example to draw on, you can be like, oh, well, here's how languages tend to do things differently. Here's how languages are similar. And I think it gives you a much better and richer feeling for how languages work and how communication works. And similar to having multiple paradigms in programming, I think this has given me a much richer foundation now for exploring and building programs. STEPHANIE: That's really cool. I guess that actually leads quite well into the next element, which is passion. Because once you've tried some new things, you get the information of do I like this thing, or do I not like this thing? And then from there, you know, you gravitate towards the things you are passionate about to get a deeper understanding. And it becomes less about like, oh, just testing out the waters and like, knowing, hey, like, I constantly find myself thinking about this, like, let me keep going. JOËL: Yeah. Or sometimes, it's deciding what do I want to learn next? And you just pick something that's interesting to you without necessarily being like, oh, strategically, I think this is another paradigm that's going to expand my mind. Or this is going to make me, you know, help me get that promotion next quarter, purely based off of interest. Like, this sounds fun. STEPHANIE: That's really interesting because I think I actually came to it from a different angle, where one thing that I think was very helpful in my learning that came just, like, completely internally, like, no one told me to do this was reading books about design patterns. And that was something that I did a couple of years into my career because I was quite puzzled, I suppose, by my day-to-day experience in terms of wanting to solve a problem or develop a feature but not having a very good framework for steps to go about it, or not feeling very confident that I had a good strategy for doing it. It was very, for me, it felt very just kind of, like, throwing pasta to the wall and seeing what would stick. And I was really interested in reducing that pain, basically. And so that led me to read books. And, again, that was not something, like, someone was like, hey, I really think that you could benefit from this. It was just like, well, I want to improve my own experience. And, you know, some of the ones that I remember reading (And this was based off of recommendations from others kind of when I floated the idea.) was, you know, Sandi Metz's Practical Object-Oriented Design in Ruby. Design Patterns in Ruby by Ross Olsen. Those were just, like, purely out of interest. Yeah, I guess I'm curious, for you, what fun and passion look like. JOËL: Yeah, I think one thing that's a really fun side effect of passion learning is that I find that I tend to learn a lot faster and go a lot deeper, or I get more for every individual hour I put into learning just because passion or interest is such a multiplier. Similar to you, I think I went through a time where I was just gobbling up everything I could see on design patterns, and code structure, things like that. Yeah, I've always been really excited about data modeling in general and how to structure programs to make them easy to change while also not putting a high maintenance burden on it, learning those trade-offs, learning those principles, learning a lot of those ideas. I think that desire came out of some pain I felt pretty early on in my programming career, where I was just writing purely self-taught at this point from a few tutorials online. Code beyond a few hundred lines would just kind of implode under the weight of its own complexity. And so, like, I know that professional programmers are writing massively larger programs that are totally fine. So what am I missing? And so I think that sort of spurred an interest. And I've kind of been chasing that ever since. Even though I'm at the point where that is no longer a problem in my daily life, it is still an interest that I keep. STEPHANIE: Yeah. If I were to pull out another interest of yours that I've noticed that kind of seems in the same realm of, you know, you can just chase this forever, is working incrementally, right? And just all the ways that you can incorporate that into your day-to-day. And I know that's something we've talked about a lot. But I think that's really cool because, yeah, it just comes from just a pure desire on your own front to, like, see how far you can take it. JOËL: I think you pulled out something interesting there. Because sometimes, you have an interest in a whole new topic, and sometimes the interest is more about taking something I already know and just seeing can I take it to an extreme? What happens when I really go to the boundaries of this idea? And maybe I don't need to go there ever for a client project. But let me put up a proof of concept somewhere and try it out just for the fun of it to see can I take this idea, then push it to an extreme and see does it break at an extreme? Does it behave weirdly? And that is just an enriching journey in and of itself. Have you ever done, like, a...maybe not a whole learning journey but, you know, taken a few hours, or maybe even, like, some time on one of our investment Fridays to just explore some random idea and try it out? And it's like, huh, that was cool; that was a journey. And then maybe you move on to something next week because it's not like a big planned thing. But you're taking a few hours to dig into something totally random. STEPHANIE: I actually think I'm less inclined to do that than maybe you or other folks are. I find the things I choose to spend my time on do have to feel more relevant to me in the moment or at least in my day-to-day work. And I think that actually is another excellent transition into the last couple of elements in the APPL framework that we've now coined. The next being profit or, I guess, the idea of being valuable to you in your job in that moment, I suppose. Or I guess not even in that moment, but kind of connecting what you're learning to something that would provide you value. So I know you were talking about learning Elm, and now you're able to see all of the value that it has provided, but maybe at the time, that was a little bit less of your focus. But for me, I find that, like, a driver for how I choose to spend my time. Often it's because, yeah, for the goal of reducing pain. Being consultants, we work on a lot of different projects, sometimes in different frameworks, or languages, or new technologies. Like, you've mentioned having to, just now, on your new client project learning how to interact with different databases, and it sounds like older software that you might not have encountered before. And I think that ends up falling higher on my priority list depending on the timing of what I'm currently working on is, oh, like, you know, TypeScript is something that has, like, kind of come and go as my projects have shifted. And so when it comes back to working on something using it, I'm like, oh, like, I really want to focus on this right now because it has very clear value to me in the next three to six months, or however long. But I have also noticed that once I'm off of that project, that priority definitely recedes. JOËL: Yeah, I think that plays into that final element as well of the APPL, the low risk things that are applicable today that have value right now. Those tend to be things like, oh, I see that I'm going to be scheduled on a client that needs this technology next month. Maybe I should learn that, or maybe I should refresh this idea or go a little bit deeper because this is something new that I'm going to need. So, at some point, I knew that there was a Python project coming down the line. I was like, okay, well, maybe I'm going to spend a couple of Fridays digging into some Django tutorials and compare and contrast with Rails. STEPHANIE: The low-risk element is interesting to me because I found it to be a challenging balance to figure out how much time to invest in becoming really comfortable in a new technology. I find myself sometimes learning just enough to get what I need to get done. And then other times really feeling like, wow, like, I wish I knew this better because that would make my life easier, or I would just feel a lot better about what I'm doing. And kind of struggling with when to spend that time, especially when there's, you know, other expectations of me in terms of my delivery. JOËL: Yeah, that almost sounds like a contrast between technologies that fall in that low-risk bucket, like, immediately useful, versus ones that fall in the passion bucket that you're interested in taking deeply and maybe even to an extreme. STEPHANIE: That's really interesting. What I like about this list of themes that we've pulled out is that, like, one thing can fall into a number of different categories. And so it's really quite flexible. It actually reminds me of a book that I just finished reading. The book is called Quarterlife. And the thing that stuck out to me the most is the author, who is a psychotherapist; she has basically come up with two types of people, or at least two things, that end up being really big drivers of, like, human motivation and behavior. And that's stability types and meaning types, and the goal is to have a little bit of both. So you may be more inclined towards stability and wanting to learn the things that you need to know for your job, to do well in your role, kind of like we were talking about to reduce that pain, to feel a little more in control, or have a little more autonomy over your day to day and how you work. And then there's the seeking meaning, and when we talked about adventure and passion, it kind of reminded me of that. Like, those are things that we do because we want to feel something or understand something or because it's fun. And ironically, this list of four things has two that kind of fall into each category. And ultimately, the author, she, you know, was very upfront about needing both in our lives. And I thought that was a really cool distinction. And it was helpful for me to understand, like, oh yeah, like, in the early years of my career, I did really focus on learning things that would be profitable, or valuable, or low risk because those were the things that I needed in my job, like, right now. And I am now feeling stable enough to explore the meaningful aspects and feel excited by trying out things that I think I just wasn't ready for back in the day. But it actually sounds like you may kind of have a different leaning than I do. JOËL: That is really interesting. I think what was really fascinating as you mentioned those two sort of types of people. And, in my mind, now I'm immediately seeing some kind of two-dimensional graph, and now we've got four quadrants. And so are we leaning towards stability versus...was it adventure was the other one? Or meaning. STEPHANIE: Meaning, yes. JOËL: So now you've got, like, your quadrant that is high stability, high meaning, low stability, high meaning, like, all those four quadrants. And maybe these four things happen to fall into that, or maybe there's some other slightly different set of qualities that you could build a quadrant for here. One that is interesting, and I don't know how closely it intersects with this idea of stability versus meaning, is how quickly the things you learn become useful. So that low risk, like that L from APPL, those are things that are immediately useful. So you put a little bit of work learning this, and you can immediately use it on the job. In fact, that's probably why you're learning it. Whereas me going off and learning Elm is not because we've got any clients in the pipeline using Elm. It's purely for interest. Is it going to pay off? I think most learning pays off long-term, especially if it helps you build a richer understanding of the different ways software works or helps you have new mental models, new tools for doing things. And so I think, you know, 5, 6, 7 years later, learning Elm has been one of the highest payoff things that I've done to kind of take my coding career to the next level. That being said, I would not have seen that at the time. So the payoff is much more long-term. How do you kind of navigate when you're trying to learn something, whether you want something with a short-term payoff or a longer-term payoff? STEPHANIE: Yeah, that's so interesting. I wonder if there was maybe someone who could have helped you identify the ways that Elm could have possibly paid off. And I know, you know, you're looking back on it in retrospect, and it's easy to see, especially after many years and a lot of deep thinking about it. But kind of referring back to this idea of seeking meaning and that just being important to feeling happy at your job, like, maybe it was just valuable because you needed to scratch that itch and to experience something that would be interesting or stimulating in that way to prevent burning out or something like that. JOËL: Oh, I like that. So the idea that you're learning a thing, not specifically because you're expecting some payoff in the long term but because of the joy of learning, is reward in and of itself, and how that actually keeps you fresh in the moment to keep going on a career that might, you know, last 5, 10, 20, 30 years, and how that keeps you refreshed rather than like, oh, but, like, I'm going to see a payoff in five years where now, all of a sudden, I'm faced with a problem. And I can be like, ah, yes, of course, monads are what we need here. And that's a nice side effect, but maybe not the main thing you look for when you're going for something in that passion bucket. STEPHANIE: Yeah, absolutely. To go back to your question a little bit, I had mentioned that I was wondering if there was someone who could help point out ways that your interests might be useful. And I think that would be a strategy that I would try if I find myself in that conundrum, I suppose, of, like, being like, hey, like, this is really interesting to me. I'm not able to see any super immediate benefits, but maybe I can go find an expert in this who can share with me, like, from their experience, what diving deep into that topic helped them. And if that's something that I need to then kind of justify to a manager or just kind of explain, like, hey, this is why I'm spending my time doing this is because of this insight that I got from someone else. That would be, I think, a really great strategy if you find yourself needing to kind of explain your reasoning. But yeah, I also think it's, like, incredibly important to just have passion and joy in your work. And that should be a priority, right? Even if it's not immediately clear, the tangible or valuable to the company benefits in the current moment. JOËL: And I think what I'm hearing is that maybe it's a bit of a false premise to say there are some things that you follow for passion that only pay off in the long term. Because if you are in it for passion, then you're getting an immediate payoff regardless. You may also get an additional payoff in the long term. But you're absolutely getting some kind of payoff immediately as well. STEPHANIE: Yeah, I think that's true for adventure because knowing what you don't like is also really valuable information. So, if you try something and it ends up not panning out for you, you know, I think some people might feel a little bit disappointed or discouraged. They think, oh, like, they kind of wasted time. But I don't know; I think that's all part of the discovery process. And that brings you closer and closer to, yeah, knowing what you want out of your learning and your career. JOËL: So I'm really curious now. This whole, you know, APPL framework came out of a very random conversation. Is this something that maybe you're going to take into your own sort of goal-setting moving forward? Maybe try to identify, like, okay, what is something adventurous that I want to do, something I want to do for passion, something that I think for profit, and then something low risk? And then maybe have that inform where you put some energy in the next quarter, the next year, whatever timeline you're planning for. STEPHANIE: Yeah, I thought about this a little bit before we started recording. But one very loose goal of mine...and this actually, I think, came up a little more tangibly after coming back from RubyKaigi and being so inspired by all of the cool open-source tooling and hearing how meaningful it was for people to be working on something that they knew would have an impact on a lot of people in their development experience. Having an impact is something that I feel very passionate about and very interested in. And the adventure part for me might be, like, dabbling a little bit into open-source tooling and seeing if there might be a project that I would be interested or comfortable in dipping my feet into. What about you? Do you have anything in the near or long-term future that might fall into one of these buckets? JOËL: So I do have a list of things. I don't know that I will pursue all of them or maybe any of them. But here's my kind of rough APPL here. So something adventurous, something new would be digging into the language Rust. Again, the idea is to try a completely new paradigm, something low-level, something typed, something that deals with a lot of memory, something that does well with concurrency and parallelism. These are all things that I've not explored quite as much. So this would be covering new ground. Something that is a passion, something that's interesting to me, would be formal methods, so I'm thinking maybe a language like TLA+ or Alloy. Data modeling, in general, is something that really excites me. These techniques that I think build on some of the ideas that I have from types but that go, like, to an extreme and also in a slightly different direction are really intriguing to me. So, if there's something that maybe I'm staying up in the evenings to do, I think that might be the most intriguing thing for me right now. Something that might be more profitable, I think, would be digging into the world of data science, particularly looking at Notebooks as a technology. Right now, when I need to crunch data, I'm mostly just doing spreadsheets. But I think there are some really cool things that we could do with Notebooks that come up in client work. I manage to do them when you're with a random command-line script or sometimes with Excel. But I think having that tool would probably be something that allows me to do that job better. And then, finally, something low-risk that I know we could use on a client project would be digging in more into TypeScript. I know just enough to be dangerous, but we do TypeScript all the time. And so, mastering TypeScript would definitely be something that would pay off on a client project. STEPHANIE: I love that list. Thank you for sharing. JOËL: Also, I just want to note that there are only four things here. It doesn't fully spell APPL because there's no E at the end. And so when I see the acronym now, I think it looks like a stock ticker. STEPHANIE: It really does. But I think it's pretty trendy to have an acronym that's basically a word or a noun but then missing a vowel so... JOËL: Oh, absolutely. Time to register that applframework.com domain. STEPHANIE: Yeah, I agree. I also love what you said. You called it a rough APPL. And that was very [laughs] evocative for me as well. And just thinking about an apple that someone has, like, bitten into a little bit [laughs] and has some rough edges. But yeah, I hope that people, you know, maybe find some insight into the kinds of learnings and goals that they are interested in or are thinking about. And using these themes to communicate it to other people, I think, is really important, or even to yourself. Maybe yourself first and then to others because that's how your co-workers can know how to support you. JOËL: That's really interesting that you are thinking of it in terms of a tool for communication to others. I think when I first encountered this idea, it was more as a tool of self-discovery, trying to better understand why I was interested in different things and maybe better understanding how I want to divide up the energy that I have or the time that I have into different topics. But I can definitely see how that would be useful for communicating with team members as well. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice. Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Julia Evan's Wizard Zines (https://wizardzines.com/) Why's Poignant Guide To Ruby (http://poignant.guide/) Learn You A Haskell For Great Good (http://www.learnyouahaskell.com/) Mazes for Programmers (http://mazesforprogrammers.com/) thoughtbot dotfiles (https://github.com/thoughtbot/dotfiles) rcm (https://github.com/thoughtbot/rcm) Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So I got a very exciting package in the mail the other day that I wanted to share with you. So I think I've mentioned her on the pod before, but I got a package of software development-related zines by Julia Evans, and I'm going to share a few of the titles that I got. So I picked up, "Oh shit, git!" [laughs] Can I swear on this podcast? I don't know. I guess we're going to find out. Or maybe we can just make the executive decision that it's fine. [laughs] I also got "Hell Yes! CSS!", "The Pocket Guide to Debugging," which I think I mentioned previously. I had seen the PDF version before, but now I have this cute, little, I don't know, six-inch book that I can carry around for all of my debugging needs. Who knows? Maybe I'll be out in the world and just need to pull it out [laughs] and debug something while I'm on the train; who's to say? And then I also picked up "HTTP: Learn Your Browser's Language!" So I'm really excited to have these little illustrated digest-sized resources. I think they'll look really cute on my shelf next to my more intense hardcore technical books like "Design Patterns" and "Practical Object-Oriented Design in Ruby" or whatever. I'm really excited about the more creative endeavors people have done with creating educational resources about software development. In fact, I think last time when we talked about creativity and creative expression, we totally missed the world of side projects. And I've really just enjoyed when people illustrate things and make stuff a lot more accessible to a wider audience than a traditional textbook or more text-based heavy resources. JOËL: I love when people go for a bit more of the playful or quirky when dealing with technical topics. And this is a great example. I love Julia Evans' work. But I'm also reminded of things like "Why's (poignant) Guide to Ruby," "Learn You a Haskell for Great Good!" or even...I forget the title of it. But there's a book by...I think it's Jamis Buck on mazes. And it's told in this sort of quirky style in a narrative. But it's all about maze-solving algorithms but told through the eyes of characters who are wandering through a maze, and it's just delightful. STEPHANIE: Aww, that's so cute. I love that. I also just had the thought that these things would make great gifts for a fledgling developer or a developer in your life who, if you don't want to get them something super specialized or technical or whatever. There are so many, like you said, quirky and fun things out there that I'm sure they'll appreciate. So, Joël, what's new in your world? JOËL: I play D&D regularly with some colleagues at thoughtbot. And recently, I got to thinking about the mechanics of rolling dice. Specifically, what dice can be rolled together? Like, can I roll multiple dice at the same time? And which one do you have to wait for the outcome of a previous roll before it makes sense to roll it? That was really interesting to me because I think that connects to a lot of other things that we do in software, where sometimes some things are independent. You can do them at the same time. And then, other times, you have to wait for the outcome of the first thing before you can even start doing the second thing. So I think, in many ways, it's a great metaphor for the difference between parallel versus series operations. STEPHANIE: I think it's very funny that you found a way to connect D&D to software development. I'm just imagining you rolling your die and then while you're doing that, having some revelation like the math lady meme or whatever, just thinking about, whoa, if this outcome happens, then [laughs] what happens? I have not joined in on our company's D&D campaign, but I do like that y'all post little updates about the story in a public space for the whole company to check out. So sometimes I've been searching for some message in our company's knowledge base, and I have stumbled upon a post about the campaign so far and what happened in last night's session, you know, how all the adventurers fought the big bird, [laughs] and it is very delightful to me. JOËL: It's a really fun way, I think to be creative. I think I enjoy the role-playing side of it a little bit more than just the mechanics of rolling dice, even though the thing I was excited to share today is rolling dice is fun. It is kind of like doing improv, where you're trying to figure out what would your character do and how do they respond to what other people say? It's fun, but it's hard. STEPHANIE: One burning question I have is, does anyone do voices for their characters? JOËL: Absolutely. Aji Slater, who was on a previous episode of this podcast, is part of this campaign, and their character has some really fun voices. STEPHANIE: That's awesome. I'm really interested in joining as a guest or something. But yeah, the improv aspect of it kind of freaks me out. I bet it's a really welcoming group. And if other people are getting into it, then I can get into it too. JOËL: Yeah, this group is very, very low-key. Most people playing, I think, are fairly new to the game. So it's very friendly, very kind of tolerant of, oh, you didn't know this rule existed, that's totally fine. We'll make it work, things like that. STEPHANIE: Nice. So another recent development in my world is that I started a new client project, actually the same client that you've been working on for many months, Joël. JOËL: Yes, the same client but different teams within the client. So we don't get to necessarily interact with each other day to day. But it is interesting that now we get to share knowledge about how this application works with each other. STEPHANIE: Yeah, yeah. And I don't think we've gotten a chance to work together even in the same world like this before. So that's kind of exciting. JOËL: How has the onboarding been for you? STEPHANIE: So, one onboarding development that was surprisingly easy and felt good was setting up a new laptop. So the client company shipped a laptop to me to use for all of their work. And I had to set up just the laptop from scratch, so I could develop on it. And I was able to do that pretty painlessly with the help of the dotfiles that I had previously put together and all of the configurations that I had exported and uploaded to like a cloud drive. And so I was able to have that up and running within a day with all of my favorite keyboard shortcuts, applications, all my little preferences, and that felt really good. So I'm going to pat myself on the back [laughs] for past Stephanie's efforts in making current Stephanie's life easier. JOËL: I'm curious, do you use thoughtbot's dotfiles as the base for your development environment, or do you use something custom? STEPHANIE: I have my own personal dotfiles that I have in a GitHub repo. But I think I did, at one point, go through thoughtbot's dotfiles for inspiration. I found that it has just a lot of extra stuff that I don't really need, but I do like that it's out there. So if any folks want a place to start with having a laptop setup configuration, you should definitely check that out. And we can link that in the show notes. JOËL: I really like the tool rcm, which is also by thoughtbot that allows you to have a modular system of dotfiles that you can pull from a few different sources and combine together. STEPHANIE: Oh, that's neat. I hadn't known about that one. That's cool. JOËL: It's a suite of command-line tools that allows you to pull probably from a git repo. And it might be several, and then trying to pull them all to the right place on your machine to be executable. So, in my case, I have the thoughtbot dotfiles and then also some personal ones. And it just kind of merges them together based on some rules and creates all the dotfiles in my home directory for that. STEPHANIE: Nice. I think the one thing that I do need to keep up on is pushing updates to the dotfiles when I make changes locally because I did have to pull in a few things that I had adjusted or made tweaks to that didn't make it to the source that I was pulling from on this new machine. This is actually my fifth MacBook that I own [laughs] just from remnants of jobs and clients' past. And one day...I keep telling myself that I'll have to return one of the older ones that I'm not using anymore, but as of now, I am an owner of five computers. [laughs] JOËL: Just start mining Bitcoin on the idle ones. STEPHANIE: Oh. [laughs] That's genius. I guess that's definitely a better use than them just sitting in my drawers. JOËL: I guess you're paying for power, and that's kind of the whole point, so... STEPHANIE: That's fair. JOËL: What are some things that you like to do when you onboard onto a new project? STEPHANIE: So, aside from my laptop adventures, when I joined this new project, I had a few things in mind that I wanted to achieve during this onboarding process. One of the things I think I want to get better at is understanding the business when I'm onboarding onto a new client. I think this is an area that previously I hadn't really focused on, but I'm now understanding is actually really important to being set up for success on a team. And so, as consultants, we're dropped into a client project oftentimes when things are already moving. And they kind of clearly have some things that they were hoping we could help with. But I am hoping to also use this time to just take a bit of a step back and ask questions about, like, what is the product? And what are its core features? And who are its users? And also, what's the direction of the business? Can I get some more context on how things are right now? We're so frequently brought in and being like, okay, like, you're going to work on this project but without the context of is the business scaling right now, or what are its struggles? We aren't quite able to make as informed decisions as we could if we had been at the company for longer and had just seen things change and had more of a feel of why we're doing what we're doing. JOËL: I love that you're asking all those questions upfront. I feel like coming in onto a new project, and that can be as a consultant, or it could be just starting a new job, is the perfect time to just be asking all of those questions. And people, I think, appreciate when we ask those questions. Sometimes I think as consultants; we can sometimes be afraid that, oh, if we're asking these sorts of basic questions, people might think less of us. But I think the opposite happens where because we're asking those foundational questions about the business model, about the future of the product, about how the technical architecture works, people really appreciate that we're asking those foundational questions where other people might not. So it actually helps build credibility rather than hurting credibility. STEPHANIE: Yeah, and I think they are really important in making the right technical decision, too, because it can help inform where you spend your time refactoring or evaluating whether this shortcut is worth it to meet this deadline or if it's not because of the bigger picture and where things are headed. If anything, I've learned that being a developer really isn't just about being in the code but having as much information as possible so that there is less ambiguity and you have more clarity to make the right choices when you do have to write the code. Another key aspect that I have become a lot more observational about, I think, is understanding the team that I'm joining, especially what their process is, how they communicate. One thing that's kind of funny about seeing a lot of different companies and how they work as consultants is they might claim to use agile, but in reality, it is a little bit different than that. And you can have that perspective as an outsider. Things like pointing an estimation is kind of all over the place in the industry. So I really like to make sure I fully understand how the team does that and what points means to them. I think another thing that I want to do during my onboarding time this week and as I'm getting to know developers on the client side is learning about the pain points that they're feeling. And, yeah, just getting more of a feel about what's top of mind for them and where is a good space to invest my time and my energy. Lastly, some more basic stuff is communication. Another thing about being a contractor that's challenging is that we don't normally get the full onboarding experience that full-time hires do. And so we may or may not have an onboarding mentor or a buddy and finding out, okay, who is the right person that I should be asking questions to? Or where's the right space for that? When you join new teams, are there any other things that you like to take into consideration? JOËL: I like that you talked about understanding the team's process. One thing that I often like to do pretty early on is make some kind of small code change but then have it go through the full process of coding on my machine to deploy it in production. And so just find some small change in the code that needs to be done, and maybe it's an easy bug fix or something. But just so I can walk through all the steps and find out what the team's process is. What are some sort of weird things that this team does that other people might not that I need to know about? Where does review happen? Is there a staging environment, unexpected ways which my change might get rejected? Things like that. So walking through the entire, I guess you could say software development lifecycle, kind of speedrunning is, I think, a really valuable exercise to do really early on a new project. STEPHANIE: Yeah, that's a great point. Like I mentioned, I think that looks so different for every team. And I'm now learning about new tools and SaaS products that I have never seen before. And even though I have an understanding of the software development lifecycle in general, just learning those quirks is very valuable so that you can be a contributor as soon as possible. JOËL: I like to contribute on day one, if possible, so kind of in order of...I don't want to say order of priority. But the order of things that I often do on a new project is one, clone the repo, try to run the setup script, or manually step through instructions in the README. Depending on the repo, that might be 10 minutes. That might be all of my first day. Number two, try to run the test suite. STEPHANIE: Yes. JOËL: Number three is figure out what went wrong for me in step one or two, make a fix for it, commit it, and open up a PR for it, and that's my contribution. If I can do those three things on day one, I feel like that is a solid first day. STEPHANIE: That's great. I love that. What can you do to help improve this process and make it just a little bit better for someone else? I think another good first-day task might be automating a part of that process that is currently manual and kind of annoying. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: So once you've cloned the repo and you're poking around the codebase, what are some things that you notice when you're looking at the code? JOËL: Ooh, that's always fun. In a Rails application, there are a few files I almost always open first in a new project just to get a feel for it. Number one is the routes file. What does that look like? Is it huge? Is it small? Are there a lot of non-standard routes in there, not just standard RESTful resources? That's going to tell me a lot about how things are structured. I can probably even get a sense of what controllers are large, what controllers have 20 non-RESTful actions in them just by looking at the routing file. The other place I like to look at is the user model. Generally, that just collects so many methods. And so I can also often get a feel about the app just by looking at that. And then from there, it's pulling on connections and trying to say, okay, well, what seems to be the core model of this app that everything coalesces around? And maybe for an e-commerce app, it's some kind of product, or maybe for an insurance product, it might be some kind of policy object. And so you find that, and then you find all of the core business logic around there. And that can often give you a really good picture of what the app is like. STEPHANIE: Yeah, a few other things I would add to that list of things to check out is the Gemfile. I like to look at that to see what gems are familiar to me. Do they have authentication, common authentication gems that I've used before? Or is there a lot of stuff that's new to me? And it also kind of tells you, are they more likely to reach for a library or try to build something themselves? I liked that you mentioned that you try to run the test suite early on. I think test coverage is a good place to investigate as well if they have any metrics, you know, that also tells you that it is or isn't something they value. And then seeing like, okay, what parts are well-tested and what parts are a little less tested? I'm really glad that you pointed out how much information you can glean about controllers because then, once you're poking around in there, that can tell you a lot about where are the scary parts of the app? I've found that to be really interesting. You know, sometimes you can just open up a file and be like, whoa, [laughs] and have kind of a gut reaction. Other times, you might pick it up from other developers, and you might start hearing about areas of the app that they are a little nervous to touch. JOËL: I definitely connect with that. I feel like many products have a particular file that is kind of scary and that people don't want to touch. And sometimes, people will tell you upfront, sometimes, you just discover it yourself. And I've been on projects where it's like, oh no, we have a ticket that's come up. It's fairly straightforward, except we know whoever picks it up is going to have to touch the scary file, and I'm not it. STEPHANIE: Yeah, absolutely. JOËL: I'm curious if you run any kind of automated tooling to try to understand a little bit more about the code. So I'm thinking things like maybe Flog or Flay or some of those tools to get a feel for maybe what are the hotspots in the application, anything like that that you like to look for? STEPHANIE: That's a great point. I think the only times I have invested energy into doing that has been more when I'm doing a code audit for a client, which, in some cases, is a separate service that clients can pay consultants for. But I can see the value of doing it when you're joining a team for the first time. JOËL: In a sense, I almost feel like we do a kind of abbreviated code audit for ourselves as part of onboarding. STEPHANIE: That's fair. I wonder if you can use those tools and scope it in a way to the particular team or areas in the codebase that you know that you'll be working on. JOËL: You mentioned the Gemfile earlier. And one thing that maybe seems super obvious is checking version numbers for things like Rails and Ruby because that will significantly impact how development is going to work. Is this a Rails 3 app, or is this a Rails 7 application? STEPHANIE: Yeah, yeah, that's a great point. I am glad you mentioned that because I think that's probably the very first thing [laughs] that I would do just to set my expectations around what I'm working with. JOËL: I feel like it's one of those things that's often just told to you when somebody helps you onboard. It's like, "Okay, you can clone the repo. It's over here. By the way, this is a Rails 3 app. We're kind of behind the times. Here are some weird things we've had to do to keep it alive. We have this other team. They're in this back room over there, slowly working on a Rails 4 upgrade. It's been in progress for four months, but we think we're pretty close. Can't wait for Rails 4." STEPHANIE: Oh God. [laughs] I think the alternative is a developer being like, "Oh yeah, we just upgraded to Rails 7," and they're all really excited and feeling really good about it, [laughs] as they should be, because I think that Rails upgrades are an important thing to stay on top of. And it is really great when you are working on a project that gets to be up to date there. JOËL: Yeah, Rails upgrades are interesting because I feel like when you're proactive about them, they're not that bad, especially more modern versions. I think Rails has gotten a lot better about making those upgrades smoother today than they were ten years ago. But when you're not up to date about them, when you've just kind of procrastinated on doing the updates, every month or year that you wait to do the update makes it so much harder to do that update when the time comes. Because now more gems have fallen out of date, more things have now been abandoned that you just can't use. A lot of community knowledge is just not around as much anymore. Because Rails 3...I forget when Rails 4 came out, probably about ten years ago. So people who remember how things were done idiomatically ten years ago, some of that knowledge has kind of passed on. It's not as prevalent as knowledge around Rails 6 or Rails 7 is. STEPHANIE: 100%. I think I heard someone at thoughtbot identify themselves as a post-Rails 5 generation developer. And I loved that because it really tells you a lot about just their experience. And it's kind of fun. I can imagine some kind of BuzzFeed quiz or something that's like, what Rails generation are you? But yeah, I've certainly seen pro-con lists about joining different projects, and a con might be the app is still on Rails 3. And then, if the app is on a very new version of Rails, that's usually in the pro column because folks are excited about getting to have all that good, new stuff. What do you look out for in terms of design patterns in a codebase? Is that something that kind of sets off your radar at all? JOËL: One thing that will definitely make me raise an eyebrow is heavy use of metaprogramming. I've been bitten by that a lot on projects. Some things are way too clever by half. So a lot of metaprogramming typically means it's going to be difficult to read and follow the flow of logic in the code. And also, there might be some unexpected bugs. Or I found once a memory leak that happened because of some weird metaprogramming. So that definitely makes me a little bit skeptical of part of the code. STEPHANIE: Yeah, that's fair. And it also just makes it hard to understand the domain when you have no idea where things go. And you have to just find out later when you are debugging and are in the middle of desperately trying to figure out how this app works. So I can see how that is a little suspicious. I think one thing that I am reevaluating for myself when I notice design patterns is trying to figure out, do I want to perpetuate them? Do I want to follow them? And in the past, I have been more likely to just follow an existing pattern in the codebase. But one thing that I'm hoping to do moving forward is to simply ask, how do decisions get made around patterns? Who gets to introduce them? Are they documented? What does that process look like? Do you have a conversation with the team about it? Just so that I have more tools in my toolbox, I think if I ever do find something that I feel really strongly about, that should be different than what I'm seeing in the codebase. So kind of expanding my skill set there. JOËL: I think that's a fantastic question to ask, and I've done this on previous projects. And sometimes, the answers are just absolutely illuminating. So you see a weird pattern, and you ask, like, "Oh, where does that come from? Why do we do that?" And some will say," Oh yeah, that was Bob back in, you know, 2017. He read an article and was really a fan of this thing, and he put it everywhere. Nobody else really understood the pattern, but we haven't really been able to change it. And he's no longer with the company, and now we just kind of...it's there." Or sometimes it's like, "Oh, great question because you see, we have this subtle business problem. And we've got to reconcile these two pieces of technology with also this expectation that our customers have. And so we came across this pattern, and we decided to use it." And it's these things where just looking at the code with no context, you're like, that's weird. Why would you want to do that? And then, when you understand the underlying problem, it makes so much sense. It's like, okay, I don't love this pattern, but it's the correct solution here, and I fully support having that here. It's a tricky problem at the intersection of technological problems and business problems, and this was the best way we could solve it. I'm not always super happy, but it is the right choice. STEPHANIE: Yeah, I've heard someone describe that as code archaeology in a way that all codebases have a story to tell about how they got to the current state that they're in. And I have certainly struggled with this but trying to approach joining a new team and working on a new codebase, especially if it's legacy code, from a place of curiosity rather than being combative about it. And just going through the git commits or just simply asking members of the team, like, "Hey, what's going on here?" and getting to hear some of those fun stories. JOËL: Yeah, most code exists for a reason. It's not just people writing things just because, particularly code that, you walk in as an outsider and think, oh, that's bad code or looks weird. It's usually for a reason. People aren't just purposefully writing this to trigger you two years down the road. It's also important...as a new person onboarding onto a project, people care about your perspective. As an outsider, oftentimes, it's really rich to bring in an outside perspective. But it's also not a great look to come in and just immediately be like, "Oh, we need to tear this thing down," or "This is so bad." It's important to build trust with the team. And as with so many things in life, seek to understand before running your mouth. STEPHANIE: Wow, how insightful, Joël. [laughs] Speaking of building trust, can we talk a little bit about different strategies we have for doing that? JOËL: Yeah. As a new person on the team, you really want to build a strong connection with the client and to build that trust because then you can be more effective in doing your job. You can bring more value to the client. What are some ways that you like to get that moving in a positive direction early on a new project? STEPHANIE: I think setting up channels of communication is really important, so, ideally, having a one-on-one with a manager or a team lead because that is a great place to make sure that the work you're doing is aligned with what they think you should be doing. So figuring out what their expectations are, like, what do you expect me to get done in my first week? And then what do you want me to be doing by the first month? That is important because we might think about all the things we would love to improve about this codebase or like influence on the team. But if that is not lined up with their views of what success looks like, then we're not quite delivering on the value that we [laughs] had hoped that we would. Another thing that I'm starting to notice a lot more, and we talked a little bit about this previously when we talked about the value of sustainability in web development, but learning what the team's values are and also what the organization's values are because that will really inform the behavior of folks on the team and the decisions that they make. So some values that come to mind are transparency, or collaboration, or growth, or speed. Like, if you find out those underlying foundational pillars, that can really help you orient yourself in your work and being like, okay, I know that this organization really focuses on these kinds of things, so I would like to try to make decisions that uphold or are in line with the things that are important to them. JOËL: I want to really second your comment about good communication. That is one of the most powerful things you can do to build credibility to build trust with another human being, and that can happen in a lot of ways. Like you're saying, some of it is setting up actual communication channels with a manager. Some of that can be the things we mentioned earlier, like asking questions about the architecture, trying to learn all about the product and the business. That can also be being active in that particular team's Slack channel. Sometimes new people come on to a team, and they're a little bit more timid, and they're just kind of not present. And so kind of coming in and...like, you don't want to take over the channel but being active in the channel, asking your questions in that channel, even just talking about your onboarding experience being like, "Hey, I'm running through...I got stuck on this thing. Here's the thing I did to get unstuck." People love seeing that. And it helps them to feel like you're actively participating from day one. STEPHANIE: Yes, that is a great transition to what I wanted to make sure to say at the end of this is that your onboarding experience matters. I know that when you're joining a new team, you might feel a lot of pressure to start contributing and make sure that you are providing value. But your onboarding experience should be inclusive, and you should advocate for your needs. Like, if you don't have access to credentials or there are just various blockers to your onboarding, that's a big deal, and it should not be a gatekeep-y process. Everyone wants you to be able to do your job, and so if you're running into those issues, it's definitely important to raise those concerns for yourself and also for anyone else who comes along the way. Also, everything is new, and will probably feel uncomfortable. If you're anything like me, I feel a lot of pressure to prove myself when I join a new team and start contributing left and right. But it's just important to remember that when all this stuff is new, feeling uncertain or feeling confused and just being in that beginner's mindset again can be uncomfortable, but that is totally normal. JOËL: I feel like something I sometimes do that ties all of these ideas together is when I'm encountering some new code or a new problem, to help myself understand it, I will diagram it. But oftentimes, it can be nice to share that diagram in the team's Slack channel and to say, "Hey, I'm new to the project, and I was exploring this area, and I kind of diagrammed it." Just talk a little bit about the thing that you're doing and maybe what you learned about it. People love that. Visuals are a really powerful tool. And you might be surprised that there might be some team members that have been on the project for a while who never really understood that part of the code. And so they will latch on to what you've shared and be like, "Oh, thank you, because now I finally have a feel for that part." Or maybe you didn't get it quite right, and somebody will follow up and say, "Hey, I love your diagram, but you have a misconception here. There's actually a different piece that connects here." And then you can have a conversation, and you just revealed a blind spot. And so I've found that that can be a really positive way to get started. STEPHANIE: Yeah, absolutely. Joël Quenneville, professional diagrammer. But even if you don't draw a diagram, putting your assumptions out into the world and how you understand things I think is really valuable because, yeah, it's like you are showing your learning path and also being open to receiving feedback if it's not quite right and, hopefully, spreading knowledge all around. So I love that. JOËL: This reminds me a little bit of the episode we had with Steve Polito about learning in public. And he was focused more on learning about Rails, and open source, and things like that. But there's a sense in which you can sort of learn the product or learn the codebase. And public means your team channel. So you can say, "Hey, I'm digging into this model, and here's how I understand the way things work. It's a bulleted list of three things." You might get some good comments on that. You might get other people who appreciate it. So kind of learning the internals of a product within the public confines of a team, I think, is a really good framework as well. STEPHANIE: Absolutely. JOËL: On that note, Shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Você já deve ter ouvido falar em monolitos, mas você sabe o que fazer com eles? No episódio de hoje do Hipsters Ponto Tech vamos conversar sobre monolitos, descobrir se são bons, se dá pra começar com isso, se dá pra manter e até onde se mantém. Participantes: Paulo Silveira, o host que ficou animado com o temaDayanne Cunha, Solutions Developer na bxblueFabricio Buzeto, CTO na bxblueMauricio Linhares, Tech Lead na DigitalOceanRoberta Arcoverde, Tech Lead na StackOverflow Links: Livro "Patterns of Enterprise Application Architecture" de Martin FowlerLivro "Enterprise Integration Patterns" de Gregor Hohpe e Bobby WoolfLivro "Practical Object-Oriented Design" de Sandi MetzBlog Shopify Conheça o Alura CasesInscreva-se no YouTube da AluraInscreva-se na newsletter Imersão, Aprendizagem e Tecnologia Produção e conteúdo: Alura Cursos de Tecnologia - https://www.alura.com.br === Caelum Escola de Tecnologia - https://www.caelum.com.br/ Edição e sonorização: Radiofobia Podcast e Multimídia

Você já deve ter ouvido falar em monolitos, mas você sabe o que fazer com eles? No episódio de hoje do Hipsters Ponto Tech vamos conversar sobre monolitos, descobrir se são bons, se dá pra começar com isso, se dá pra manter e até onde se mantém. Participantes: Paulo Silveira, o host que ficou animado com o temaDayanne Cunha, Solutions Developer na bxblueFabricio Buzeto, CTO na bxblueMauricio Linhares, Tech Lead na DigitalOceanRoberta Arcoverde, Tech Lead na StackOverflow Links: Livro "Patterns of Enterprise Application Architecture" de Martin FowlerLivro "Enterprise Integration Patterns" de Gregor Hohpe e Bobby WoolfLivro "Practical Object-Oriented Design" de Sandi MetzBlog Shopify Conheça o Alura CasesInscreva-se no YouTube da AluraInscreva-se na newsletter Imersão, Aprendizagem e Tecnologia Produção e conteúdo: Alura Cursos de Tecnologia - https://www.alura.com.br === Caelum Escola de Tecnologia - https://www.caelum.com.br/ Edição e sonorização: Radiofobia Podcast e Multimídia

Welcome back to the Klaviyo Data Science podcast! This episode, we dive into… Required reading for data science A question we frequently get asked is: what books should I read to be a better data scientist/machine learning engineer? This may not surprise you, but there isn't just one answer — depending on the skills you have, your knowledge base, the point of your career that you're in, and many other factors, there are many books you could read that will help you learn more. This month, we cover several ways to improve the skills you need to contribute to a data science team. You'll hear about all that and more, including: Object-oriented programming, how to think about it practically, and how it can help anyone on a data science team The ethics of machine learning and AI, and why understanding AI ethics is one of your most powerful tools How Pac-Man delivers some of the most powerful data science insights of our time Mentioned this episode Some more reading or viewing that we mention in this episode: Practical Object-Oriented Design in Ruby by Sandi Metz: https://www.poodr.com/ Sandi Metz's keynote: https://www.youtube.com/watch?v=8bZh5LMaSmE Weapons of Math Destruction by Cathy O'Neil: https://weaponsofmathdestructionbook.com/ Northeastern CS 4100: https://www.ccs.neu.edu/home/jwvdm/teaching/cs4100/fall2019/ UC Berkeley CS 188: https://inst.eecs.berkeley.edu/~cs188/pacman/home.html Contact us The best place to reach the podcast is by messaging me on Twitter: https://twitter.com/lawson_m_t.

In this episode I talk with Tyler Williams, Software Engineer at Home Game Poker, about the contents of a blog post he recently wrote entitled Heuristics for Object-Oriented Design in Ruby. Tyler and I discuss some of the ideas in his blog post, most of which came from Sandi Metz's book Practical Object-Oriented Design in Ruby (POODR).

According to an ancient myth, the world rests on the back of a turtle. And what does that turtle stand on? Another turtle. It turns out that it’s turtles all the way down. Miki Rezentes, today’s guest, believes that all software rests on the back of APIs. Similar to the myth, it’s APIs all the way down. We open our conversation by discussing how homeschooling her children did more to prepare Miki for a software career than anything else she’s encountered. Miki shares highlights from her talk, ‘APIs All the Way Down’. This set up this episode’s key theme, that the tech industry is too concerned with how its software interacts to focus on how the people in its organizations communicate — their ‘human APIs.’ Following this, we ask Miki how she learns people’s APIs and we talk about the benefits of observation and mirroring. Tracking her career, we touch on how Miki transitioned from a homemaker to a developer before diving into her recent work at the data science platform Mode. She provides unique insights into how she views architecture and design and why the concept of domain-driven design doesn’t go far enough. We chat about how you can see your team as customers to promote domain-driven design and then drill into what she does to create a ‘shared pool of knowledge’ with her team. As Miki explains, ‘people problems’ are more difficult than technical ones and developers often make mistakes by not first developing common understanding. Especially when this relates to expectations within a company. Near the end of the episode, we explore what leaders can do to maintain productivity when growing their teams. Tune in to hear what you can do to deepen your team’s pool of understanding and improve the quality of your communication. Note: this episode was recorded in late July when Miki was working at Mode; she is now a Senior Software Engineer at Frame.io (https://frame.io). Key Points From This Episode: Why homeschooling her kids better prepared Miki for software development than anything else. How people within an organization express themselves through individual APIs. Understanding that people come from different backgrounds which influence their API. The ‘shared pool of knowledge’ and figuring out how to communicate with people. Miki’s journey from homemaker to becoming a software engineer. How nobody really knows what they’re doing. Security as a trade-off, privacy, and the power of two-factor authentication. Hear about Miki’s work at the data science platform Mode. What Miki enjoys most about working in Elixir and what she uses it for. How Miki sees architecture and the differences between architecture and design. Domain-driven design and the differences between data models and software. Treating your team ‘Agilely’ and seeing them as your customers. Miki’s process of developing a shared pool of understanding before hammering out the end-to-end components. Why ‘people problems’ are much more difficult than development problems. How tech companies misdiagnose ‘people problems’ as bad design. Conway’s Law and how code production reflects an organization’s structure. The importance of setting expectations to maintain productivity as a team grows in size. The danger of the Peter principle; when people are promoted to their level of incompetency. Links Mentioned in Today’s Episode: Miki Rezentes LinkedIn —https://www.linkedin.com/in/miki-rezentes-823ba02a/ Miki Rezentes GitHub — https://github.com/mrezentes Miki Rezentes Twitter — https://twitter.com/mikirez Mode — https://mode.com/ SmartLogic — https://smartlogic.io/ Elixir Wizards Survey — smr.tl/podcastsurvey Manning Publications — https://www.manning.com/ ‘APIs All the Way Down’ — https://www.youtube.com/watch?v=hBpbEsAG4es Turtles all the way down — https://en.wikipedia.org/wiki/Turtlesallthewaydown Crucial Conversations — https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/1469266822 Thomas Edison State University — https://www.tesu.edu/academics/online-degrees Xkcd — https://xkcd.com/ Toshiba Global Commerce Systems — https://commerce.toshiba.com/ Kroger — https://www.kroger.com/ CA Technologies — https://www.ca.com/ Jira — https://www.atlassian.com/software/jira ICFP 2020 — https://icfp20.sigplan.org/ James Edward Gray II — https://github.com/JEG2 Helix Data Engine - Mode — https://mode.com/helix/ Practical Object-Oriented Design in Ruby — https://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330 Tanium — https://www.tanium.com/ Poodr — https://www.poodr.com/ Gödel, Escher, Bach — https://en.wikipedia.org/wiki/G%C3%B6del,Escher,Bach D'Aulaires' Book of Greek Myths — https://www.amazon.com/DAulaires-Greek-Myths-Ingri-dAulaire/dp/0440406943 The Mythical Man-Month — https://en.wikipedia.org/wiki/TheMythicalMan-Month Applying Conway's Law to improve your software development — https://www.thoughtworks.com/insights/blog/applying-conways-law-improve-your-software-development Peter Principle — https://en.wikipedia.org/wiki/Peter_principle Special Guest: Miki Rezentes.

— Актуален ли все еще Ruby, и нужно ли переходить на другой язык (04:25) — О текущем состоянии Ruby on Rails (09:00) — Тенденция “оттока” разработчиков из Ruby: миф или реальность (14:53) — На сколько хорош Elixir (20:00) — Об ООП в Elixir и о том на сколько ООП в Elixir настоящее (26:05) — Работа в Toptal: структурная организация команд и используемый стек технологий (30:07) — О жизни и работе в Воронеже (40:43) — IT-сообщества и мероприятия Воронежа (44:23) Доп. cсылки: Доклад Станислава об Elixir - https://www.youtube.com/watch?v=_dFFUO_Du0Y Sandi Metz, “Practical Object-Oriented Design” - https://www.poodr.com/ Hacktoberfest Party в Воронеже - https://hacktoberfest-voronezh.github.io/party-2019/ Канал митапа “Deep Refactoring” - https://www.youtube.com/channel/UCkmu866apk8FbOMuEIQvH0g Блог Станислава - http://cspub.net/ Telegram—канал CSSSR: t.me/csssr Twitter CSSSR: twitter.com/csssr_dev Telegram ведущего: t.me/sgolovin Twitter ведущего: twitter.com/_sgolovin Telegram редакции: t.me/Vindizh Twitter редакции: twitter.com/Vindizh

Teaching and Learning with Sandi Metz Guest Sandi Metz: (https://twitter.com/sandimetz): Author of Practical Object-Oriented Development in Ruby (http://www.informit.com/store/practical-object-oriented-design-an-agile-primer-using-9780134456478?ranMID=24808) and 99 Bottles of OOP (https://www.sandimetz.com/99bottles). sandimetz.com (https://www.sandimetz.com/) Summary Today on the show we have Sandi Metz, author of Practical Object Oriented Design in Ruby and co-author of 99 bottles of OOP. I’ve literally been trying to get Sandi as a guest since we started recording the show and I’m thrilled that we’ve finally been able to connect. We talk about OOP and TDD, maybe going down a test-driven rabbit hole for a while, and also talk about what it’s like to teach and coach about OOP and TDD. I enjoyed this talk very much and I think you will, too. Notes 02:46 - Keeping Up With Tech 04:58 - Object-Oriented Design 09:53 - Why do we write tests? 17:53 - Teaching Yourself TDD 22:11 - Procedures and Patterns 34:07 - CI Jim Weirich (https://weirichinstitute.com/about) 39:23 - Approaching TDD 44:49 - What should we be doing as a community to share knowledge? The Magic Tricks of Testing (http://confreaks.tv/videos/railsconf2013-the-magic-tricks-of-testing) Special Guest: Sandi Metz.

Sponsors Sentry– use the code “devchat” for two months free on Sentry small plan Paymo | Opt for monthly & get 30% discount on paid plans for 6 months Try GanttPRO FREE for 14 days | Software Development project template Use coupon code “devchat” to get $50 for using GanttPRO CacheFly Panel Jeremy Green Erik Dietrich Summary The panel goes into detail on the most common reasons to give a discount, sharing experiences and whether or not it's a good idea to give these types of discounts. They generally agree that a "friends and family discount" is never a good idea and discuss the long term problems it can cause both in relationships and your business. The panel discusses offering a discount to get your foot in the door and to better your portfolio. Supporting non-profits and making sure you receive the proper credit for your work is discussed. Offering discounts as part of your business model is considered, discounts such as paying upfront or high volume discounts, are weighed. Jeremy Green shares an experience and warning against helping a business just because you like what they are doing. The panel gives advice on how to say no to someone asking for a discount.  They finish the episode with more advice on why to give a discount and explain some of the negative effects giving out too many discounts or giving discounts for the wrong reason can have on your business. Links https://www.squarespace.com https://www.shopify.com Picks Jeremy Green: Practical Object-Oriented Design, An Agile Primer Using Ruby Erik Dietrich: Ready Player One Hit to subscribe

Sponsors Sentry– use the code “devchat” for two months free on Sentry small plan Paymo | Opt for monthly & get 30% discount on paid plans for 6 months Try GanttPRO FREE for 14 days | Software Development project template Use coupon code “devchat” to get $50 for using GanttPRO CacheFly Panel Jeremy Green Erik Dietrich Summary The panel goes into detail on the most common reasons to give a discount, sharing experiences and whether or not it's a good idea to give these types of discounts. They generally agree that a "friends and family discount" is never a good idea and discuss the long term problems it can cause both in relationships and your business. The panel discusses offering a discount to get your foot in the door and to better your portfolio. Supporting non-profits and making sure you receive the proper credit for your work is discussed. Offering discounts as part of your business model is considered, discounts such as paying upfront or high volume discounts, are weighed. Jeremy Green shares an experience and warning against helping a business just because you like what they are doing. The panel gives advice on how to say no to someone asking for a discount.  They finish the episode with more advice on why to give a discount and explain some of the negative effects giving out too many discounts or giving discounts for the wrong reason can have on your business. Links https://www.squarespace.com https://www.shopify.com Picks Jeremy Green: Practical Object-Oriented Design, An Agile Primer Using Ruby Erik Dietrich: Ready Player One Hit to subscribe

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Iteration S05E09 Testing… Testing… 123 Publishing February 18th - Hope everyone had a good Valentine's Day weekend! A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. Introduction Writing changeable code is an art on which practice relies on three different skills. First, you must understand object-oriented design. Poorly designed code is naturally difficult to change. First, you must understand object-oriented design. A poorly designed code is naturally difficult to change. Second, you must be skilled at refactoring code. Finally, the art of writing a changeable code requires the ability to write high-value tests. Tests give you the confidence to refactor constantly. Reasons to test: Finding Bugs Supplying Documentation Deferring Design Decisions Supporting Abstractions Exposing Design Flaws Knowing What to test: “Most developers write too many tests” - OR NONE! hahaha Tests should concentrate on the incoming or outgoing messages that cross an object's boundaries. Back to the Kitchen Metaphor - Test that ordering a hamburger, returns a hamburger as expected, not that the kitchen staff turns on the grill or slices tomatoes. Incoming messages should be tested for the state they return. Outgoing command messages should be tested to ensure they get sent. Outgoing query messages should not be tested. Knowing When to Test Write tests first, whenever it makes sense to do so Knowing How to test: Testing Styles: Test Driven Development (TDD) and Behavior Driven Development (BDD). Proving the Public Interface Injecting Dependencies as Roles Testing Inheritance - Test your base class - then include the module to test each of the responses that are in the base class. Creating Test Doubles - DiameterDouble - A test double is a stylized instance of a role player that is used exclusively for testing - tend to override the base class in my test helper - I've run into silent errors this way. Testing Private Methods - interface. These private messages are like proverbial trees falling in empty forests; they do not exist, in a perfect world they do not need to be tested - testing them is a code smell. Testing Ducks - create a preferred test interface - mechanic and a guide can both prepare - you can establish a single interface and simply pass the different objects into it. Testing Inherited Code Testing Models + Objects Vs interface - where's the balance? Tests are indispensable. Well-designed applications are highly abstract and under constant pressure to evolve; without tests these applications can neither be understood nor safely changed. The best tests are loosely coupled to the underlying code and test everything once and in the proper place. They add value without increasing costs. Next Episode - Recap of Practical Object-Oriented Design and New book announcement! Picks: NOUN PROJECT - https://thenounproject.com/ **Super Smash Bros Ultimate ** Neil Davis - @Nei1dor Aaron Kelton

Combining Objects with Composition Metz, Sandi. Practical Object-Oriented Design in Ruby A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. “Combining the qualities of two existing subclasses, something that inheritance cannot readily accommodate.” We talked about inheritance, then modules, now this builds on top of the idea of modules and pushes it further. Composing a bicycle of parts... Bicycle > has A parts Parts has subclasses of - RoadBikeParts and MountainBikeParts Making the Parts Object More Like an Array - This part was freaky Parts Factory Different Configs within the parts factory > an array of all the keys and attributes - road_config - mountain_config Using all this to make a recumbent bike: Once this is all set up you have this incredibly powerful interface of a bicycle composed of parts: Bicycle.new( size: 'L', parts: PartsFactory.build(recumbent_config)) Composition VS Aggregation A Meal is composed of an appetizer - An appetizer does not survive outside of the meal. When the meal is gone by definition the appetizer is gone. A meal is composed of an appetizer. A band is an aggregate of musicians - when the band breaks up the musicians don't die. “Composition” encompasses both aggregation and composition - “This distinction between composition and aggregation may have a little practical effect on your code.” Deciding Between Inheritance and Composition “Think of it this way: For the cost of arranging objects in a hierarchy, you get message delegation for free.” When in doubt use Composition over inheritance “The general rule is that faced with a problem that composition can solve, you should be biased towards doing so. If you cannot explicitly defend inheritance as a better solution, use composition.” John's Pick: Book: "It Doesn't Have To Be Crazy At Work" -> David Heinemeier Hansen and Jason Fried JP: Kahn Academy - digging into math again Next Week: Final Chapter - Designing Cost-Effective Tests

Metz, Sandi. Practical Object-Oriented Design in Ruby Chapter 7. Sharing Role Behavior with Modules Welcome to iteration A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. Modules! Modules! Modules! Last episode we talked about inheritance which was kind of an extension of duck typing… but sometimes we need to combine the qualities of two existing subclasses, something that inheritance cannot readily accommodate. Many object-oriented languages provide a way to define a named group of methods that are independent of class and can be mixed in to any object. In Ruby, these mix-ins are called modules. Discovering the Schedulable Duck Type The Schedule expects its target to behave like something that understands lead_days, that is, like something that is “schedulable.” You have discovered a duck type. This specific example illustrates the general idea that objects should manage themselves; they should contain their own behavior. Mountain Bike? Mechanic? Now, in the code above, the dependency on Schedule has been removed from Bicycle and moved into the Schedulable module, isolating it even further. Like Using Inheritance COMES BACK TO AUTOMATIC MESSAGE DELEGATION Loggable Example When Bicycle includes Schedulable, all of the methods defined in the module become part of Bicycle's response set. When a single class includes several different modules, the modules are placed in the method lookup path in reverse order of module inclusion. Thus, the methods of the last included module are encountered first in the lookup path. When a single class includes several different modules, the modules are placed in the method lookup path in reverse order of module inclusion. Thus, the methods of the last included module are encountered first in the lookup path. Picks: John: Type to Siri - Accessibility > Siri > Type to Siri JP: Scrimba - https://scrimba.com/playlist/pKwrCg

Practical Object-Oriented Design in Ruby A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. Duck types are public interfaces that are not tied to any specific class. Objects that are defined by their behavior than by their class name. if an object quacks like a duck and walks like a duck, then its class is immaterial, it's a duck. In a way, the “+” operator is a “duck type” - because it responds differently to a different type of objects. Preparer TripCoordinator, Mechanic, Driver can all be a preparer - they all respond to the prepare method in their own ways. At a higher level, what are these all doing? They are preparing something - we can trust within this shared interface. Within mechanic - we only call prepare_trip vs gas_up or full_water_tank- Instead of switching on type You Talk through this Object: Notification Object? https://github.com/withbetterco/wellstart/blob/master/app/models/notification.rb#L156 It has this insane method checking to see if the user's notification settings match the notification that's trying to send We are wanting to extend the notification object, for another type - Push Notifications Object (message, comment, like) User NotificationSettings Notifier Notification Policy “The ability to tolerate ambiguity about the class of an object is the hallmark of a confident designer.” Recognizing a duck: “You can replace the following with ducks: • Case statements that switch on class • kind_of? and is_a? • responds_to?” Polymorphic Objects Went from a ParticipantNote, and ProgramNote, and ApplicantNote, to one single Note object through a Notable Module. They all have “ has _many: notes, as:: notable” instead of each having “program_notes”, applicant_notes, etc. “you are missing an object, one whose public interface you have not yet discovered.” Dot files - .zshrc - Custom prompt - with my git status - Slippers from JP - Quadie

A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. Pivot a bit: Less agnostic, more useful to just lean into the technologies we use every day for a while. We'll do our best to keep the information generally useful to all software developers. Moving forward this is a Web Development Podcast covering Ruby on Rails, Javascript and React. New book: Practical Object-Oriented Design in Ruby by Sandi Metz Also known as POODR About the Author: Sandi Metz: She is one of the foremost thought leaders in clean code. If you want some amazing programming talks just look up Sandi Metz on YouTube. About the book: “The Complete Guide to Writing Maintainable, Manageable, Pleasing, and Powerful Object-Oriented Applications” About Object-Oriented Design: Object-oriented applications are made up of objects and the messages that pass between them. Messages will turn out to be the more important of the two, but in this brief introduction (and in the first few chapters of the book) the concepts will get equal weight. “In a world of objects, new arrangements of behavior emerge naturally. You don't have to explicitly write code for the spouse_steps_on_cat procedure, all you need is a spouse object that takes steps and a cat object that does not like being stepped on. Put these two objects into a room together and unanticipated combinations of behavior will appear.” “Unfortunately, something will change. It always does. The customers didn't know what they wanted, they didn't say what they meant…. Even applications that are perfect in every way… change is ubiquitous and omnipresent” WHY IS CHANGE SO HARD!? Dependencies stand in the way of change Object Oriented Design is about Managing Dependencies “In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another.” “Part of the difficulty of design is that every problem has two components. You must not only write code for the feature you plan to deliver today, you must also create code that is amenable to being changed later.” Design Principles SOLID - design: Single Responsibility - Do one thing well. Open-Closed - You should be able to extend without modifying. Consistent interface. Liskov Substitution (Swap out code underneath methods) - squares and rectangles Interface Segregation - specific interfaces Dependency Inversion - High-level modules should not depend upon low-level modules. Both should depend upon abstractions. DRY - Don't Repeat Yourself LoD - Law of Demeter - Talk only to closely related objects- the principle of least knowledge Design Patterns Service Objects, Factory, Adapter, Decorator - This book doesn't cover these. Big Up Front Design Pitfalls Design takes time Next Chapter - we really get our hands dirty Sandi Metz Links: https://www.youtube.com/watch?v=npOGOmkxuio&t=1841s https://www.youtube.com/watch?v=29MAL8pJImQ https://www.youtube.com/watch?v=8bZh5LMaSmE&t=1s Pick: JP: https://testingjavascript.com/  John: SOLID Design Patterns in Javascript https://www.youtube.com/watch?v=GtZtQ2VFweA&feature=share - - - - - New Book: Practical Object-Oriented Design

Does the term “design” make sense in the context of code? I discuss Sandi Metz’s definition from her book Practical Object Oriented Design in Ruby.

Soroush Khanlou joins for a rapid fire style interview. He talks about the iOS dev community, app architecture, best books to read as a dev to level up, and more! Find Soroush at: https://fatalerror.fm/ and http://khanlou.com/ Wanna chat with other smart iOS developers? Sign up for our free forum: https://forum.insideiosdev.com Studying for an iOS Interview? https://iosinterviewguide.com/?promo=inside-ios-dev-ref Book recommendations: Domain Driven Design, Practical Object-Oriented Design in Ruby, Patterns of Enterprise Application Architecture.

In this episode of the Rabbit Hole podcast, we talk about software development books and literature. We talk about tow of our favorites in some detail, but also discuss the concepts of software development books more broadly (in the sense of what they can offer and why people might choose to read them). In general, these books (such as Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz) offer insight that encourages you to rethink your overall approach, technique, and mindset. Learning transferrable concepts, skills, and ideas is a strong motivator behind reading programming books, since there are other resources for simple references. One example of a book that offers this is The Phoenix Project, a novel that one of the panelists compares to being like Ayn Rand's works in terms of being allegorical and a teaching tool.   In the episode, we also talk about hard skills versus soft skills. “Soft” doesn't mean “weak” in this context,and soft skills have great value. This is summed up in a Portuguese expression, “água mole em pedra dura tanto bate até que fura.” We finish things up with a teach-and-learn moment about RSpec Bisect, and a toast to failure involving vcr. Tune in to learn more and to hear our thoughts on a couple of great books!

Alex and Andrew introduce the book Practical Object-Oriented Design in Ruby and discuss the chapter on testing. They explain how the principles in the book can be applied to any object-oriented application regardless of programming language. Finally, they discuss the main takeaways from the book and about testing an OO application.Wanna chat with other smart iOS developers? Sign up for our free forum: https://forum.insideiosdev.com

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.

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.

Rails Remote Conf   02:07 - Testing 07:28 - Adding Tests Later; When is the test useful? TDD (Test-driven Development) 14:35 - Testing the Happy Path 16:48 - Writing Tests First 18:53 - Sharing Code Larry Wall: Three Virtues 27:34 - Testing Error Messages 29:04 - External vs Mocking/Stubbing 34:11 - Exploratory Tests and Characterization Tests Sunk Cost Fallacy Katrina Owen: Therapeutic Refactoring 39:07 - Refactoring 47:22 - Mocking and Stubbing (Cont’d) Justin Searls: To Mock or Not to Mock @ SCNA 2012 Dependency Injection Practical Object-Oriented Design in Ruby by Sandi Metz Spies   Picks How American Politics Went Insane (Jessica) Alex Kitchens’ Minecraft Tweet (Sam) The "Is It a DSL or an API?" Ten Question Checklist (Sam) Transmit (Chuck) Zoom (Chuck) Rails Remote Conf (Chuck)

Rails Remote Conf   02:07 - Testing 07:28 - Adding Tests Later; When is the test useful? TDD (Test-driven Development) 14:35 - Testing the Happy Path 16:48 - Writing Tests First 18:53 - Sharing Code Larry Wall: Three Virtues 27:34 - Testing Error Messages 29:04 - External vs Mocking/Stubbing 34:11 - Exploratory Tests and Characterization Tests Sunk Cost Fallacy Katrina Owen: Therapeutic Refactoring 39:07 - Refactoring 47:22 - Mocking and Stubbing (Cont’d) Justin Searls: To Mock or Not to Mock @ SCNA 2012 Dependency Injection Practical Object-Oriented Design in Ruby by Sandi Metz Spies   Picks How American Politics Went Insane (Jessica) Alex Kitchens’ Minecraft Tweet (Sam) The "Is It a DSL or an API?" Ten Question Checklist (Sam) Transmit (Chuck) Zoom (Chuck) Rails Remote Conf (Chuck)

Rails Remote Conf   02:07 - Testing 07:28 - Adding Tests Later; When is the test useful? TDD (Test-driven Development) 14:35 - Testing the Happy Path 16:48 - Writing Tests First 18:53 - Sharing Code Larry Wall: Three Virtues 27:34 - Testing Error Messages 29:04 - External vs Mocking/Stubbing 34:11 - Exploratory Tests and Characterization Tests Sunk Cost Fallacy Katrina Owen: Therapeutic Refactoring 39:07 - Refactoring 47:22 - Mocking and Stubbing (Cont’d) Justin Searls: To Mock or Not to Mock @ SCNA 2012 Dependency Injection Practical Object-Oriented Design in Ruby by Sandi Metz Spies   Picks How American Politics Went Insane (Jessica) Alex Kitchens’ Minecraft Tweet (Sam) The "Is It a DSL or an API?" Ten Question Checklist (Sam) Transmit (Chuck) Zoom (Chuck) Rails Remote Conf (Chuck)

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

Sandi Metz describes herself as an "accidental author." Accident or not, her book Practical Object-Oriented Design in Ruby (POODR) is beloved in the ruby community, and she's used her ability to break down complex coding topics to build the second phase of her programming career, one focused on teaching and speaking. In part II of this two-part interview, she talks to us about speaking, how she prepares for her talks and her plans for her upcoming book. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Confessions of a Public Speaker Bailey White NPR This American Life Moth Radio Hour Bath Ruby CoffeeScript Codeland Conf Codeland 2019

Sandi Metz describes herself as an "accidental author." Accident or not, her book Practical Object-Oriented Design in Ruby (POODR) is beloved in the ruby community, and she's used her ability to break down complex coding topics to build the second phase of her programming career, one focused on teaching and speaking. In part I of this two-part interview, she talks to us about life pre- and post-POODR, what makes her a great teacher, and why she it took her four years to write POODR. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) RailsConf GoRuCo Exercism 99 Bottles of OOP Myers-Briggs Personality Test Theory of Mind POODR OO (Object Oriented) Programming Codeland Conf Codeland 2019

2:55 - Introducing Joseph Mastey and Jill Lynch Enova 3:20 - The origins of Enova’s apprenticeship program 6:20 - Creating and teaching the curriculum Rails Guide to Active Support Code School 11:05 - Realities of implementing an apprenticeship program 15:30 - Jill’s experience 21:10 - Feedback processes 22:50 - Advice for setting up an apprenticeship program 24:20 - Ideal candidates and mentors Women Who Code Code2040 Girl Develop It 28:05 - Apprenticeship and new hire diversity 28:45 - Experimenting with bias, communication, and engagement 33:20 - Do trainees take too much time away from regular employees? 37:05 - Teaching the codebase 39:50 - Firing apprentices 42:05 - Advantages of working at a lucrative company 45:45 - Learning outside the program Edx Coursera 47:40 - Breaking into the industry Email panel@rubyrouges.com with your experiences 58:10 - Who decides the circle? Picks: Ruby Tapas (Avdi) Nozbe (Avdi) Postach.io (Avdi) Neo4j (Caroline) Thinking in Systems by Donella H. Meadows (Caroline) DeskTime (Charles) “Codes of Conduct 101 + FAQ” post by Ashe Dryden (Joe) The Book With No Pictures by B.J. Novak (Joe) Practical Object-Oriented Design by Sandi Metz (Jill) Edx CS50 Class (Jill)

2:55 - Introducing Joseph Mastey and Jill Lynch Enova 3:20 - The origins of Enova’s apprenticeship program 6:20 - Creating and teaching the curriculum Rails Guide to Active Support Code School 11:05 - Realities of implementing an apprenticeship program 15:30 - Jill’s experience 21:10 - Feedback processes 22:50 - Advice for setting up an apprenticeship program 24:20 - Ideal candidates and mentors Women Who Code Code2040 Girl Develop It 28:05 - Apprenticeship and new hire diversity 28:45 - Experimenting with bias, communication, and engagement 33:20 - Do trainees take too much time away from regular employees? 37:05 - Teaching the codebase 39:50 - Firing apprentices 42:05 - Advantages of working at a lucrative company 45:45 - Learning outside the program Edx Coursera 47:40 - Breaking into the industry Email panel@rubyrouges.com with your experiences 58:10 - Who decides the circle? Picks: Ruby Tapas (Avdi) Nozbe (Avdi) Postach.io (Avdi) Neo4j (Caroline) Thinking in Systems by Donella H. Meadows (Caroline) DeskTime (Charles) “Codes of Conduct 101 + FAQ” post by Ashe Dryden (Joe) The Book With No Pictures by B.J. Novak (Joe) Practical Object-Oriented Design by Sandi Metz (Jill) Edx CS50 Class (Jill)

2:55 - Introducing Joseph Mastey and Jill Lynch Enova 3:20 - The origins of Enova’s apprenticeship program 6:20 - Creating and teaching the curriculum Rails Guide to Active Support Code School 11:05 - Realities of implementing an apprenticeship program 15:30 - Jill’s experience 21:10 - Feedback processes 22:50 - Advice for setting up an apprenticeship program 24:20 - Ideal candidates and mentors Women Who Code Code2040 Girl Develop It 28:05 - Apprenticeship and new hire diversity 28:45 - Experimenting with bias, communication, and engagement 33:20 - Do trainees take too much time away from regular employees? 37:05 - Teaching the codebase 39:50 - Firing apprentices 42:05 - Advantages of working at a lucrative company 45:45 - Learning outside the program Edx Coursera 47:40 - Breaking into the industry Email panel@rubyrouges.com with your experiences 58:10 - Who decides the circle? Picks: Ruby Tapas (Avdi) Nozbe (Avdi) Postach.io (Avdi) Neo4j (Caroline) Thinking in Systems by Donella H. Meadows (Caroline) DeskTime (Charles) “Codes of Conduct 101 + FAQ” post by Ashe Dryden (Joe) The Book With No Pictures by B.J. Novak (Joe) Practical Object-Oriented Design by Sandi Metz (Jill) Edx CS50 Class (Jill)

Sean and Derek discuss lessons learned from following Sandi Metz' rules on a project and the overall impact of rules on code. Sandi Metz' Rules Ruby Rogues, episode #87, where Sandi tells us the rules at 1 hour, 18 minutes, 27 seconds in. Practical Object Oriented Design in Ruby, or POODR, is an excellent book you should all check out. God classes thoughtbot's Ruby style guidelines wherein we disavow ternary operators and conditional modifiers. The facade pattern Guard clause Ruby's method_added method.

On this week's show, recorded at RailsConf 2013, Ben Orenstein is joined by Sandi Metz, developer, author, podcaster, and recent Ruby Hero award winner. Ben and Sandi discuss winning awards, writing, whether notoriety changes who you are, what Sandi is proud of, the bad code she's writing and why, what she's doing now, getting real feedback on your work, that it's OK not to know everything, and much, much more. Practical Object-Oriented Design in Ruby Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz Lanyrd Follow @thoughtbot, @r00k, and @sandimetz on twitter.

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

1:35 - Introducing Sandi Metz Practical Object-Oriented Design in Ruby by Sandi Metz Website Twitter 6:15 - The book writing process and the speech writing process 17:30 - Flow of POODR 21:35 - Why design is for everyone 24:20 - The fear of writing a book: Am I really an expert? 27:00 - Breaking the rules 34:00 - Cheat sheets, screencasts, and diagrams for POODR 42:00 - Topics beyond POODR 45:20 - Why Sandi loves Rails 51:05 - How long will Rails last? 55:30 - When should you begin introducing design? 1:01:00 - Working with an Inheritance interface 1:06:30 - Rules for testing 1:14:45 - Well-tested objects without well-tested interactions 1:18:45 - Sandi’s rules for coding and breaking them 1:26:15 - Having too many small objects versus having too big objects Picks: “The Deep Synergy Between Testability and Good Design” Speech by Michael Feathers (James) Endless Space game on Steam (James) Board games: Lords of Waterdeep, Love Letter, Eminent Domain (James) George Takai’s episode on the Penn’s Sunday School podcast (Avdi) Hardcore History podcast by Dan Carlin  (Avdi) Infinite Monkey Cage podcast by BBC Radio 4 (Avdi) Marked App (Josh) Herman Miller Aeron chair (Charles) Bubble Timer (Sandi) Gutter Cleaning Robot (Sandi)

1:35 - Introducing Sandi Metz Practical Object-Oriented Design in Ruby by Sandi Metz Website Twitter 6:15 - The book writing process and the speech writing process 17:30 - Flow of POODR 21:35 - Why design is for everyone 24:20 - The fear of writing a book: Am I really an expert? 27:00 - Breaking the rules 34:00 - Cheat sheets, screencasts, and diagrams for POODR 42:00 - Topics beyond POODR 45:20 - Why Sandi loves Rails 51:05 - How long will Rails last? 55:30 - When should you begin introducing design? 1:01:00 - Working with an Inheritance interface 1:06:30 - Rules for testing 1:14:45 - Well-tested objects without well-tested interactions 1:18:45 - Sandi’s rules for coding and breaking them 1:26:15 - Having too many small objects versus having too big objects Picks: “The Deep Synergy Between Testability and Good Design” Speech by Michael Feathers (James) Endless Space game on Steam (James) Board games: Lords of Waterdeep, Love Letter, Eminent Domain (James) George Takai’s episode on the Penn’s Sunday School podcast (Avdi) Hardcore History podcast by Dan Carlin  (Avdi) Infinite Monkey Cage podcast by BBC Radio 4 (Avdi) Marked App (Josh) Herman Miller Aeron chair (Charles) Bubble Timer (Sandi) Gutter Cleaning Robot (Sandi)

1:35 - Introducing Sandi Metz Practical Object-Oriented Design in Ruby by Sandi Metz Website Twitter 6:15 - The book writing process and the speech writing process 17:30 - Flow of POODR 21:35 - Why design is for everyone 24:20 - The fear of writing a book: Am I really an expert? 27:00 - Breaking the rules 34:00 - Cheat sheets, screencasts, and diagrams for POODR 42:00 - Topics beyond POODR 45:20 - Why Sandi loves Rails 51:05 - How long will Rails last? 55:30 - When should you begin introducing design? 1:01:00 - Working with an Inheritance interface 1:06:30 - Rules for testing 1:14:45 - Well-tested objects without well-tested interactions 1:18:45 - Sandi’s rules for coding and breaking them 1:26:15 - Having too many small objects versus having too big objects Picks: “The Deep Synergy Between Testability and Good Design” Speech by Michael Feathers (James) Endless Space game on Steam (James) Board games: Lords of Waterdeep, Love Letter, Eminent Domain (James) George Takai’s episode on the Penn’s Sunday School podcast (Avdi) Hardcore History podcast by Dan Carlin  (Avdi) Infinite Monkey Cage podcast by BBC Radio 4 (Avdi) Marked App (Josh) Herman Miller Aeron chair (Charles) Bubble Timer (Sandi) Gutter Cleaning Robot (Sandi)