Podcast appearances and mentions of gary bernhardt

covid-19 friends google apple stripe pausing changelog gary bernhardt

Play Episode Listen Later Jun 25, 2024 40:57

Stephanie and Joël discuss the recent announcement of the call for proposals for RubyConf in November. Joël is working on his proposals and encouraging his colleagues at thoughtbot to participate, while Stephanie is excited about the conference being held in her hometown of Chicago! The conversation shifts to Stephanie's recent work, including completing a significant client project and her upcoming two-week refactoring assignment. She shares her enthusiasm for refactoring code to improve its structure and stability, even when it's not her own. Joël and Stephanie also discuss the everyday challenges of maintaining a test suite, such as slowness, flakiness, and excessive database requests. They discuss strategies to balance the test pyramid and adequately test critical paths. Finally, Joël emphasizes the importance of separating side effects from business logic to enhance testability and reduce complexity, and Stephanie highlights the need to address testing pain points and ensure tests add real value to the codebase. RubyConf CFP (https://sessionize.com/rubyconf-2024/) RubyConf CFP coaching (https://docs.google.com/forms/d/e/1FAIpQLScZxDFaHZg8ncQaOiq5tjX0IXvYmQrTfjzpKaM_Bnj5HHaNdw/viewform?pli=1) Testing pyramid (https://thoughtbot.com/blog/rails-test-types-and-the-testing-pyramid) Outside-in testing (https://thoughtbot.com/blog/testing-from-the-outsidein) Writing fewer system specs with request specs (https://thoughtbot.com/blog/faster-tests-with-capybara-and-request-specs) Unnecessary factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) Your Test Suite is Making Too Many Database Calls (https://www.youtube.com/watch?v=LOlG4kqfwcg) Your flaky tests might be time dependent (https://thoughtbot.com/blog/your-flaky-tests-might-be-time-dependent) The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test (https://www.youtube.com/watch?v=De3-v54jrQo) Separating side effects to improve tests (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) Functional core, imperative shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Thoughtbot testing articles (https://thoughtbot.com/blog/tags/testing) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: Something that's new in my world is that RubyConf just announced their call for proposals for RubyConf in November. They're open for...we're currently recording in June, and it's open through early July, and they're asking people everywhere to submit talk ideas. I have a few of my own that I'm working with. And then, I'm also trying to mobilize a lot of other colleagues at thoughtbot to get excited to submit. STEPHANIE: Yes, I am personally very excited about this year's RubyConf in November because it's in Chicago, where I live, so I have very little of an excuse not to go [laughs]. I feel like so much of my conference experience is traveling to just kind of, like, other cities in the U.S. that I want to spend some time in and, you know, seeing all of my friends from...my long-distance friends. And it definitely does feel like just a bit of an immersive week, right? And so, I wonder how weird it will feel to be going to this conference and then going home at the end of the night. Yeah, that's just something that I'm a bit curious about. So, yeah, I mean, I am very excited. I hope everyone comes to Chicago. It's a great city. JOËL: I think the pitch that I'm hearing is submit a proposal to the RubyConf CFP to get a chance to get a free ticket to go to RubyConf, where you get to meet Bike Shed co-host Stephanie Minn. STEPHANIE: Yes. Ruby Central should hire me to market this conference [laughter] and that being the main value add of going [laughs], obviously. Jokes aside, I'm excited for you to be doing this initiative again because it was so successful for RailsConf kind of internally at thoughtbot. I think a lot of people submitted proposals for the first time with some of the programming you put on. Are you thinking about doing things any differently from last time, or any new thoughts about this conference cycle? JOËL: I think I'm iterating on what we did last time but trying to keep more or less the same formula. Among other things, people don't always have ideas immediately of what they want to speak about. And so, I have a brainstorming session where we're just going to get together and brainstorm a bunch of topics that are free for anyone to take. And then, either someone can grab one of those topics and pitch a talk on it, or it can be, like, inspiration where they see that it jogs their mind, and they have an idea that then they go off and write a proposal. And so, that allows, I think, a lot of colleagues as well, who are maybe not interested in speaking but might have a lot of great ideas, to participate and sort of really get a lot of that energy going. And then, from there, people who are excited to speak about something can go on to maybe draft a proposal. And then, I've got a couple of other events where we support people in drafting a proposal and reviewing and submitting, things like that. STEPHANIE: Yes, I really love how you're just involving people with, you know, just different skills and interests to be able to support each other, even if, you know, there's someone on our team who's, like, not interested in speaking at all, but they're, like, an ideas person, right? And they would love to see their idea come to life in a talk from someone else. Like, I think that's really cool, and I certainly appreciate it as a not ideas person [laughs]. JOËL: Also, I want to shout out that Ruby Central is doing CFP coaching sessions on June 24th, June 25th, and June 26th, and those are open to anyone. You can sign up. We'll put a link to the signup form in the show notes. If you've never submitted something before and you'd like some tips on what makes for a good CFP, how can you up your chances of getting accepted, or maybe you've submitted before, you just want to get better at it; I recommend joining one of those slots. So, Stephanie, what's new in your world? STEPHANIE: So, I just successfully delivered a big project on my client work last week. So, I'm kind of riding that wave and getting into the next bit of work that I have been assigned for this team, and I'm really excited to do this. But I also, I don't know, I've been just, like, thinking about it quite a bit. Basically, I'm getting to spend two dedicated weeks to just refactoring [laughs] some really, I guess, complicated code that has led to some bugs recently and just needing some love, especially because there's some whiffs of potentially, like, really investing in this area of the product, and people wanting to make sure that the foundation does feel very stable to build on top of for extending and changing that code. And I think I, like, surprised myself by how excited I was to do this because it's not even code I wrote. You know, sometimes when you are the one who wrote code, you're like, oh, like, I would love time to just go back and clean up all these things that I kind of missed the first time around or just couldn't attend to for whatever reason. But yeah, I think I was just a little bit in the peripheries of that code, and I was like, oh, like, just seeing some weird stuff. And now to kind of have the time to be like, oh, this is all I'm going to be doing for two weeks, to, like, really dive into it and get my hands dirty [laughs], I'm very excited. JOËL: I think that refactoring is a thing that can be really fun. And also, when you have a larger chunk of time, like two days, it's easy to sort of get lost in sort of grand visions or projects. How do you kind of balance the, I want to do a lot of refactoring; I want to take on some bigger things while maybe trying to keep some focus or have some prioritization? STEPHANIE: Yeah, that's a great question. I was actually the one who said, like, "I want two weeks on this." And it also helped that, like, there was already some thoughts about, like, where they wanted to go with this area of the codebase and maybe what future features they were thinking about. And there are also a few bugs that I am fixing kind of related to this domain. So, I think that is actually what I started with. And that was really helpful in just kind of orienting myself in, like, the higher impact areas and the places that the pain is felt and exploring there first to, like, get a sense of what is going on here. Because I think that information gathering is really important to be able to kind of start changing the code towards what it wants to be and what other devs want it to be. I actually also started a thread in Slack for my team. I was, like, asking for input on what's the most confusing or, like, hard to reason about files or areas in this particular domain or feature set and got a lot of really good engagement. I was pleasantly surprised [laughs], you know, because sometimes you, like, ask for feedback and just crickets. But I think, for me, it was very affirming that I was, like, exploring something that a lot of people are like, oh, we would love for someone to, you know, have just time to get into this. And they all were really excited for me, too. So, that was pretty cool. JOËL: Interesting. So, it sounds like you sort of budgeted some refactoring time and then, from there, broke it down into a series of a couple of debugging projects and then a couple of, like, more bounded refactoring projects, where, like, specifically, I want to restructure the way this object works or something like that. STEPHANIE: Yeah. I think there was that feeling of wanting to clean up this area of the codebase, but you kind of caught on to that bit of, you know, it can go so many different ways. And, like, how do you balance your grand visions [laughs] of things with, I guess, a little bit of pragmatism? So, it was very much like, here's all these bugs that are causing our customers problems that are kind of, like, hard for the devs to troubleshoot. You know, that kind of prompts the question, like, why? And so, if there can be, you know, the fixing of the bugs, and then the learning of, like, how that part of the system works, and then, hopefully, some improvements along the way, yeah, that just felt like a dream [laughs] for me. And two weeks felt about the right amount of time. I don't know if anyone kind of hears that and feels like it's too long or too little. I would be really curious. But I feel like it is complex enough that, like, context switching would, I think, make this work harder, and you kind of do have to just sit with it for a little bit to get your bearings. JOËL: A scenario that we encounter on a pretty regular basis is a customer coming to us and telling us that they're feeling a lot of test pain and asking what are the ways that we can help them to make things better and that test pain can come under a lot of forms. It might be a test suite that's really slow and that's hurting the team in terms of their velocity. It might be a test suite that is really flaky. It might be one that is really difficult to add to, or maybe one that has very low coverage, or one that is just really brittle. Anytime you try to make a change to it, a bunch of things break, and it takes forever to ship anything. So, there's a lot of different aspects of challenging test suites that clients come to us with. I'm curious, Stephanie, what are some of the ones that you've encountered most frequently? STEPHANIE: I definitely think that a slow test suite and a flaky test suite end up going hand in hand a lot, or just a brittle one, right? That is slowing down development and, like you said, causing a lot of pain. I think even if that's not something that a client is coming to us directly about, it maybe gets, like, surfaced a little bit, you know, sometime into the engagement as something that I like to keep an eye on as a consultant. And I actually think, yeah, that's one of kind of the coolest things, I think, about our consulting work is just getting to see so many different test suites [laughs]. I don't know. I'm a testing nerd, so I love that kind of stuff. And then, I think you were also kind of touching on this idea of, like, maintaining a test suite and, yeah, making testing just a better experience. I have a theory [laughs], and I'd be curious to get your thoughts on it. But one thing that I really struggle with in the industry is when people talk about writing tests as if it's, like, the morally superior thing to do. And I struggle with this because I don't think that it is a very good strategy for helping people feel better or more confident and, like, upskill at writing tests. I think it kind of shames people a little bit who maybe either just haven't gotten that experience or, you know, just like, yeah, like, for whatever reason, are still learning how to do this thing. And then, I think that mindset leads to bad tests [laughs] or tests that aren't really serving the purpose that you hope they would because people are doing it more out of obligation rather than because they truly, like, feel like it adds something to their work. Okay, I kind of just dropped that on you [laughs]. Do you have any reactions? JOËL: Yeah, I guess the idea that you're just checking a box with your test rather than writing code that adds value to the codebase. They're two very different perspectives that, in the end, will generate more lines of code if you're just doing a checkbox but may or may not add a whole lot of value. So, maybe before even looking at actual, like, test practices, it's worth stepping back and asking more of a mindset question: Why does your team test? What is the value that your team feels they get out of testing? STEPHANIE: Yeah. Yeah. I like that because I was about to say they go hand in hand. But I do think that maybe there is some, you know, question asking [laughs] to be done because I do think people like to kind of talk about the testing practices before they've really considered that. And I am, like, pretty certain from just kind of, at least what I've seen, and what I've heard, and what I've experienced on embedding into client teams, that if your team can't answer that question of, like, "What value does testing bring?" then they probably aren't following good testing practices [laughs]. Because I do think you kind of need to approach it from a perspective of like, okay, like, I want to do this because it helps me, and it helps my team, rather than, like you said, getting the check mark. JOËL: So, once we've sort of established maybe a bit of a mindset or we've had a conversation with the team around what value they think they're getting out of tests, or maybe even you might need to sell the team a little bit on like, "Hey, here's, like, all these different ways that testing can bring value into your life, make your life as developers easier," but once you've done that sort of pre-work and you can start looking at what's actually the problem with a test suite, a common complaint from developers is that the test suite is too slow. How do you like to approach a slow test suite? STEPHANIE: That's a good question. I actually...I think there's a lot of ways to answer that. But to kind of stay on the theme of stepping back a little bit, I wonder if assessing how well your test suite aligns with the testing pyramid would be a good place to start; at least, that could be where I start if I'm coming into a client team for the first time, right, and being asked to start assessing or just poking around. Because I think the slowness a lot of the time comes from a lot of quote, unquote, "integration tests" or, like, unit tests masquerading as integration tests, where you end up having, like, a lot of duplication of things that are being tested in ways that are integrating with some slow parts of the system like the database. And yeah, I think even before getting into some of the more discreet reasons why you might be writing slow tests, just looking at the structure of your test suite and what kinds of things you're testing, and, again, even going back to your team and asking, like, "What kinds of things do you test?" Or like, "Do you try to test or wish to be testing more of, less of?" Like looking at the structure, I have found to be a good place to start. JOËL: And for those who are not familiar, you used the term testing pyramid. This is a concept which says that you probably want to have a lot of small, fast unit tests, a medium amount of integration tests that test a few different components together, and then a few end-to-end tests. Because as you go up that pyramid, tests become more expensive. They take a lot longer to run, whereas the little unit tests are super cheap. You can create thousands of them, and they will barely impact your run time. Adding a dozen end-to-end tests is going to be noticeable. So, you want to balance sort of the coverage that you get from end to end with the sort of cheapness and ubiquity of the little unit tests, and then split the difference for tests that are in between. STEPHANIE: And I think that is challenging, even, you know, you're talking about how you want the peak of your pyramid to be end-to-end tests. So, you don't want a lot of them, but you do want some of them to really ensure that things are totally plumbed and working correctly. But that does require, I think, really looking at your application and kind of identifying what features are the most critical to it. And I think that doesn't get paid enough attention, at least from a lot of my client experiences. Like, sometimes teams just end up with a lot of feature bloat and can't say like, you know, they say, "Everything's important [chuckles]," but everything can't be equally important, you know? JOËL: Right. I often like to develop using a sort of outside-in approach, where you start by writing an end-to-end test that describes the behavior that your new feature ticket is asking for and use that to drive the work that I'm doing. And that might lead to some lower-level unit tests as I'm building out different components, but the sort of high-level behavior that we're adding is driven by adding an end-to-end spec. Do you feel that having one new end-to-end spec for every new feature ticket that you work on is a reasonable thing to do, or do you kind of pick and choose? Do you write some, but maybe start, like, coalescing or culling them, or something like that? How do you manage that idea that maybe you would or would not want one end-to-end spec for each feature ticket? STEPHANIE: Yeah, it's a good question. Actually, as you were saying that, I was about to ask you, do you delete some afterwards [laughs]? Because I think that might be what I do sometimes, especially if I'm testing, you know, edge cases or writing, like, the end-to-end test for error states. Sometimes, not all of them make it into my, like, final, you know, commit. But they, you know, had their value, right? And at least it prompted me to make sure I thought about them and make sure that they were good error states, right? Like things that had visible UI to the user about what was going on in case of an error. So, I would say I will go back and kind of coalesce some of them, but they at least give me a place to start. Does that match your experience? JOËL: Yeah, I tend to mostly write end-to-end tests for happy paths and then write kind of mid-level things to cover some of my edge cases, maybe a couple of end-to-end tests for particularly critical paths. But, at some point, there's just too many paths through the app that you can't have end-to-end coverage for every single branch on every single path that can happen. STEPHANIE: Yeah, I like that because if you find yourself having a lot of different conditions that you need to test in an end-to-end situation, maybe there's room for that to, like, be better encapsulated in that, like, more, like, middle layer or, I don't know, even starting to ask questions about, like, does this make sense with the product? Like, having all of these different things going on, does that line up with kind of the vision of what this feature is trying to be or should be? Because I do think the complexity can start at that high of a level. JOËL: How do you feel about the idea that adding more end-to-end tests, at some point, has diminishing returns? STEPHANIE: I'm not quite sure I'm following [laughs]. JOËL: So, let's say you have an end-to-end test for the happy path for every core feature of the app. And you decide, you know what, I want to add maybe some, like, side features in, or maybe I want to have more error states. And you start, like, filling in more end-to-end tests for those. Is it fair to say that adding some of those is a bit of a diminishing return? Like, you're not getting as much value as you would from the original specs. And maybe as you keep finding more and more rare edge cases, you get less and less value for your test. STEPHANIE: Oh, yeah, I see. And there's more of a cost, too, right? The cost of the time to run, maintain, whatever. JOËL: Right. Let's say they're roughly all equally expensive in terms of cost to run. But as you stray further and further off of that happy path, you're getting less and less value from that integration test or that end-to-end test. STEPHANIE: I'm actually a little conflicted about this because that sounds right in theory, but then in practice, I feel like I've seen error states not get enough love [laughs] that it's...I don't even want to say, like, you make any kind of claim [laughs] about it. But, you know, if you're going to start somewhere, if you have, like, a limited amount of time and you're like, okay, I'm only going to write a handful of end-to-end tests, yeah, like, write tests for your happy paths [laughs]. JOËL: I guess it's probably fair to say that error states just don't get as much love as they should throughout the entire testing stack: at the unit level, at the integration level, all the way up to end to end. STEPHANIE: I'm curious if you were trying to get at some kind of conclusion, though, with the idea of diminishing returns. JOËL: I guess I'm wondering if, from there, we can talk about maybe a breakdown of a particular testing pyramid for a particular test suite is being top heavy, and whether there's value in maybe pushing some of these tests, some of these edge cases, some of these maybe less important features down from that, like, top end-to-end layer into maybe more of an integration layer. So, in a Rails context, that might be moving system specs down to something like a request spec. STEPHANIE: Yeah, I think that is what I tend to do. I'm trying to think of how I get there, and I'm not quite sure that I can explain it quite yet. Yeah, I don't know. Do you think you can help me out here? Like, how do you know it's time to start writing more tests for your unhappy paths lower on the pyramid? JOËL: Ideally, I think a lot of your code should be unit-tested. And when you are unit testing it, those pieces all need coverage of the happy and unhappy paths. I think the way it may often happen naturally is if you're pushing logic out of your controllers because it's a little bit challenging sometimes to test Rails controllers. And so, if you're moving things into domain objects, even service objects, depending on how you implement them, just doing that and then making sure you unit test them can give you a lot more coverage of all the different edge cases that can happen. Where things sometimes fall apart is getting out of that business layer into the web layer and saying, "Hey, if something raises an error or if the save fails or something like that, does the user get a good experience, or do we just crash and give them a 500 page?" STEPHANIE: Yeah, that matches with a lot of what I've seen, where if you then spend too much time in that business layer and only handling errors there, you don't really think too much about how it bubbles up. And, you know, then you are digging through, like, your error monitoring [laughs] service, trying to find out what happened so that you can tell, you know, your customer support team [laughs] to help them resolve, like, a bug report they got. But I actually think...and you were talking about outside in, but, in some ways, in my experience, I also get feedback from the bottom up sometimes that then ends up helping me adjust some of those integration or end-to-end tests about kind of what errors are possible, like, down in the depths of the code [laughs], and then finding ways to, you know, abstract that or, like, kind of be like, "Oh, like, here are all these possible, like, exceptions that might be raised." Like, what HTTP status code do I want to be returned to capture all of these things? And what do I want to say to the user? So, yeah, I'm [laughs] kind of a little lost myself, but this idea that going both, you know, outside in and then maybe even going back up a little bit has served me well before. JOËL: I think there can be a lot of value in sort of dropping down a level in the pyramid, and maybe instead of doing sort of end-to-end tests where you, like, trigger a scenario where something fails, you can just write a request back against the controller and say, "Hey, if I go to this controller and something raises an error, expect that you get redirected to this other location." And that's really cheap to run compared to an end-to-end test. And so, I think that, for me, is often the right compromise is handling error states at sort of the next lowest level and also in slightly more atomic pieces. So, more like, if you hit this endpoint and things go wrong, here's how things happen. And I use endpoint not so much in an API sense, although it could be, but just your, you know, maybe you've got a flow that's multiple steps where, you know, you can do a bunch of things. But I might have a test just for one controller action to say, "Hey, if things go wrong, it redirects you here, or it shows you this error page." Whereas the end-to-end test might say, "Oh, you're going to go through the entire flow that hits multiple different controllers, and the happy path is this nice chain." But each of the exit points off at where things fail would be covered by a more scoped request spec on that controller. STEPHANIE: Yeah. Yeah. That makes sense. I like that. JOËL: So, that's kind of how I've attempted to balance my pyramid in a way that balances complexity and time with coverage. You mentioned that another area that test suites get slow is making too many requests to the database. There's a lot of ways that that happens. Oftentimes, I think a classic is using a factory where you really don't need to, persisting data to the database when all you needed was some object in memory. So, there are different strategies for avoiding that. It's also easy to be creating too much data. So, maybe you do need to persist some things in the database, but you're persisting a hundred objects into memory or into the database when you really meant to persist two, so that's an easy accident. A couple of years ago, I gave a talk at RailsConf titled "Your Test Suite is Making Too Many Database Requests" that went over a bunch of different ways that you can be doing a lot of expensive database requests you didn't plan on making and how that slows down your test suite. So, that is also another hot spot that I like to look at when dealing with a slow test suite. STEPHANIE: Yeah, I mentioned earlier the idea of unit tests really masquerading as integration tests [laughs]. And I think that happens especially if you're starting with a class that may already be a little bit too big than it should be or have more responsibilities than it should be. And then, you are, like, either just, like, starting with using the create build, like, strategy with factories, or you find yourself, like, not being able to fully run the code path you're trying to test without having stuff persisted. Those are all, I think, like, test smells that, you know, are signaling a little bit of a testing anti-pattern that, yeah, like, is there a way to write, like, true unit tests for this stuff where you are only using objects in memory? And does that require breaking out some responsibilities? That is a lot of what I am kind of going through right now, actually, with my little refractoring project [laughs] is backfilling some tests, finding that I have to create a lot of records. And you know what? Like, the first step will probably be to write those tests and commit them, and just have them live there for a little while while I figure out, you know, the right places to start breaking things up, and that's okay. But yeah, I did want to, like, just mention that if you are having to create a lot of records and then also noticing, like, your test is running kind of slow [laughs], that could be a good indicator to just give a good, hard look at what kind of style of test you think you're writing [laughs]. JOËL: Yeah, your tests speak to you, and when you're feeling pain, oftentimes, it can be a sign that you should consider refactoring your implementation. And I think that's doubly true if you're writing tests after the fact rather than test driving. Because sometimes you sort of...you came up with an implementation that you thought would be good, and then you're writing tests for it, and it's really painful. And that might be telling you something about the underlying implementation that you have that maybe it's...you thought it's well scoped, but maybe it actually has more responsibilities than you initially realized, or maybe it's just really tightly coupled in a way that you didn't realize. And so, learning to listen to your tests and not just sort of accepting the world for being the way it is, but being like, "No, I can make it better." STEPHANIE: Yeah, I've been really curious why people have a hard time, like, recognizing that pain sometimes, or maybe believing that this is the way it is and that there's not a whole lot that you can do about it. But it's not true, like, testing really does not have to be painful. And I feel like, again, this is one of those things that's like, it's hard to believe until you really experience it, at least, that was the case for me. But if you're having a hard time with tests, it's not because you're not smart enough. Like, that, I think, is a thing that I really want to debunk right now [laughs] for anyone who has ever had that thought cross their mind. Yeah, things are just complicated and complex somehow, or software entropy happens. That's, like, not how it should be, and we don't have to accept that [laughs]. So, I really like what you said about, oh, you can change it. And, you know, that is a bit of a callback to the whole mindset of testing that we mentioned earlier at the beginning. JOËL: Speaking of test suites, we have not covered yet is paralyzing it. That could probably be its own Bike Shed episode on its own entirely on paralyzing a test suite. We've done entire engagements where our job was to come in and help paralyze a test suite, make it faster. And there's a lot of, like, pros and cons. So, I think maybe we can save that for a different episode. And, instead, I'd like to quickly jump in a little bit to some other common pain points of test suites, and I would say probably top of that list is test flakiness. How do you tend to approach flakiness in a client project? STEPHANIE: I am, like, laughing to myself a little bit because I know that I was dealing with test flakiness on my last client engagement, and that was, like, such a huge part of my day-to-day is, like, hitting that retry button. And now that I am on a project with, like, relatively low flakiness, I just haven't thought about it at all [laughs], which is such a privilege, I think [laughs]. But one of the first things to do is just start, like, capturing metrics around it. If you, you know, are hearing about flakiness or seeing that, like, start to plague your test suite or just, you know, cropping up in different ways, I have found it really useful to start, like, I don't know, just, like, maybe putting some of that information in a dashboard and seeing how, just to, like, even make sure that you are making improvements, that things are changing, and seeing if there's any, like, patterns around what's causing the flakiness because there are so many different causes of it. And I think it is pretty important to figure out, like, what kind of code you're writing or just trying to wrangle. That's, you know, maybe more likely to crop up as flakiness for your particular domain or application. Yeah, I'm going to stop there and see, like, because I know you have a lot of thoughts about flakiness [laughs]. JOËL: I mean, you mentioned that there's a lot of different causes for flakiness. And I think, in my experience, they often sort of group into, let's say, like, three different buckets. Anytime you're testing code that's doing things that are non-deterministic, that's easy for tests to be flaky. And so, you might think, oh, well, you know, you have something that makes a call to random, and then you're going to assert on a particular outcome of that. Well, clearly, that's going to not be the same every time, and that might be flaky. But there are, like, more subtle versions of that, so maybe you're relying on the system clock in some way. And, you know, depending on the time you run that test, it might give you a different value than you expect, and that might cause it to fail. And it doesn't have to be you're asserting on, like, oh, specifically a given millisecond. You might be doing math around, like, number of days, and when you get near to, let's say, the daylight savings boundary, all of a sudden, no, you're off by an hour, and your number of days...calculation breaks because relying on the clock is something that is inherently non-deterministic. Non-determinism is a bucket. Leaky tests is another bucket of failures that I see, things where one test might impact another that gets run after the fact, oftentimes by mutating some sort of global state. So, maybe you're both relying on some sort of, like, external file that you're both writing to or maybe a cache that one is writing to that the other one is reading from, something like that. It could even just be writing records into the database in a way that's not wrapped in a transaction, such that there's more data in the database when the next test runs than it expects. And then, finally, if you are doing any form of parallelization, that can improve your test suite speed, but it also potentially leads to race conditions, where if your resources aren't entirely isolated between parallel test runners, maybe you're sharing a database, maybe you're sharing Redis instance or whatever, then you can run into situations where you're both kind of fighting over the same resources or overriding each other's data, or things like that, in a way that can cause tests to fail intermittently. And I think having a framework like that of categorization can then help you think about potential solutions because debugging approaches and then solutions tend to be a little bit different for each of these buckets. STEPHANIE: Yeah, the buckets of different causes of flaky tests you were talking about, I think, also reminded me that, you know, some flakiness is caused by, like, your testing environment and your infrastructure. And other kinds of flakiness are maybe caused more from just the way that you've decided how your code should work, especially that, like, non-deterministic bucket. So, yeah, I don't know, that was just, like, something that I noticed as you were going through the different categories. And yeah, like, certainly, the solutions for approaching each kind are very different. JOËL: I would like to pitch a talk from RubyConf last year called "The Secret Ingredient: How To Resolve And Understand Just About Any Flaky Test" by Alan Ridlehoover. Just really excellent walkthrough of these different buckets and common debugging and solving approaches to each of them. And I think having that framework in mind is just a great way to approach different types of flaky tests. STEPHANIE: Yes, I'll plus one that talk, lots of great pictures of delicious croissants as well. JOËL: Very flaky pastry. STEPHANIE: [laughs] Joël, do you have any last testing anti-pattern guidances for our audience who might be feeling some test pain out there? JOËL: A quick list, I'm going to say tight coupling that has then led to having a lot of stubbing in your tests often leads to tests that are very brittle, so tests that maybe don't fail when they should when you've actually broken things, or maybe, alternatively, tests that are constantly failing for the wrong reasons. And so, that is a thing that you can fix by making your code less coupled. Tests that also require stubbing a lot of things because you do a lot of side effects. If you are making a lot of HTTP calls or things like that, that can both make a test more complex because it has to be aware of that. But also, it can make it more non-deterministic, more flaky, and it can just make it harder to change. And so, I have found that separating side effects from sort of business logic is often a great way to make your test suite much easier to work with. I have a blog post on that that I'll link in the show notes. And I think this maybe also approaches the idea of a functional core and an imperative shell, which I believe was an idea pitched by Gary Bernhardt, like, over ten years ago. There's a famous video on that that we'll also link in the show notes. But that architecture for building an app can lead to a much nicer test to write. I guess the general idea being that testing code that does side effects is complicated and painful. Testing code that is more functional tends to be much more pleasant. And so, by not intermingling the two, you tend to get nicer tests that are easier to maintain. STEPHANIE: That's really interesting. I've not heard that guidance before, but now I am intrigued. That reminded me of another thing that I had a conversation with someone about. Because after the RailsConf talk I gave, which was about testing pain, there was some stubbing involved in the examples that I was showing because I just see a lot of that stuff. And, you know, this audience member kind of had that question of, like, "How do you know that things are working correctly if you have to stub all this stuff out?" And, you know, sometimes you just have to for the time being [chuckles]. And I wanted to just kind of call back to that idea of having those end-to-end tests testing your critical paths to at least make sure that those things work together in the happy way. Because I have seen, especially with apps that have a lot of service objects, for some reason, those being kind of the highest-level test sometimes. But oftentimes, they end up not being composed well, being quite coupled with other service objects. So, you end up with a lot of stubbing of those in your test for them. And I think that's kind of where you can see things start to break down. JOËL: Yep. And when the RailsConf videos come out, I recommend seeing Stephanie's talk, some great gems in there for building a more maintainable test suite. Stephanie and I and, you know, most of us here at thoughtbot, we're testing nerds. We think about this a lot. We've also written a lot about this. There are a lot of resources in the show notes for this episode. Check them out. Also, just generally, check out the testing tag on the thoughtbot blog. There is a ton of content there that is worth looking into if you want to dig further into this topic. STEPHANIE: Yeah, and if you are wanting some, like, dedicated, customized testing training, thoughtbot offers an RSpec workshop that's tailored to your team. And if you kind of are interested in the things we're sharing, we can definitely bring that to your company as well. 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: Byeeeeeeeee!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

chicago pain writing testing tests patterns jokes slack suite functional oftentimes api cfp ui community engagement unnecessary rails leaky software development mandy moore redis quenneville unit tests railsconf error handling thoughtbot rubyconf rspec gary bernhardt integration tests ruby central stephanie yeah stephanie oh

v6 - Pausing doesn't pause

Breaking Change

Play Episode Listen Later Feb 25, 2024 117:25

The audio is better this week! I'm learning. Also, I finally had something to talk about that has nothing to do with Apple! The target of the ion cannon that is my mouth this time? drumroll… it's Stripe! Sorry, Stripe. If you like rants about software quality and the systemic reasons everything is terrible, hoo boy! This one brings the heat.

#84 Die Evolution von JavaScript: Vom Ducktyping zum Monopol im Browser mit Peter Kröner

Engineering Kiosk

Play Episode Listen Later Aug 15, 2023 86:59

JavaScript: Eine multiparadigmatische Skriptsprache mit einem schwachen dynamischen Ducktyping-System.Um die Sprache JavaScript kommt man im Web nicht mehr vorbei. Die meisten kennen sie durch Frameworks wie React, Angular, Vue.js, Next und Co. Doch wie viel weißt du über die Hintergründe und die Weiterentwicklung dieser Sprache?In dieser Episode geht es nicht um das nächste hippe JavaScript-Framework, sondern wir sprechen mit Peter Kröner darüber, wie JavaScript erfunden wurde, was ECMAScript ist, wie TypeScript in den Mix spielt, warum die Sprache so beliebt ist, wie neue Features den Weg in die Sprache finden, was das TC39 ist, über das Monopol im Browser, verschiedene JavaScript-Engines und viel mehr.Bonus: Wenn Hamburg im Süden liegt.**** Diese Episode wird gesponsert vom Open-Source Förderprogramm Media Tech Lab: Bewirb dich jetzt und erhalte bis zu 50.000€ Fördersumme für dein Open-Source Projekt https://www.media-lab.de/de/media-tech-labDas schnelle Feedback zur Episode:

Ruby Language Server with Vinicius Stock

Remote Ruby

Play Episode Listen Later Mar 10, 2023 51:29

On this episode of Remote Ruby, Chris came down with what he thinks was food poisoning this week, Jason brings up Ghost Kitchens which seem to be a thing these days, and Chris applied to be a Guide at RailsConf 2023. Also, Jason and Chris are excited to have a guest joining them because they've always talked about how they wished for better tooling for day-to-day Ruby development, so they brought on Vini Stock, who's a Senior Developer at Shopify. Shopify has created the Ruby Language Server (LSP) to make it easier to implement features such as code definition and auto formatting for Ruby across different editors. We're so lucky to have Vini with us to discuss the Ruby LSP and some other really cool things happening in the Ruby tooling space. We hope you enjoy this episode! Hit the download button now.[00:06:19] Vini shares his journey of programming and working with the Ruby on Rails Infrastructure team.[00:08:27] Now that Vini is on the Ruby Infrastructure team, we find out what kind of projects he was first working on. [00:12:04] How long has the Ruby Experience team and the LSP project been a thing?[00:12:44] Vini explains why the Ruby LSP was created. [00:15:25] Let's find out some goals they want to achieve with the LSP right now.[00:17:37] We hear some of the differences between the work Vini's doing on Ruby LSP and something like Solargraph.[00:19:01] Listen here as Vini details how Go To Definition works, which is a more complex feature than others.[00:24:34] Jason asks Vini what language do you write a language server in? [00:27:26] Chris wonders what challenges Vini runs into and what's the next step of the problem of building the language server. Where does he go from there? [00:31:38] Vini shares his aha moment when he built a feature and used it, and he was thinking, “Build with joy!” [00:32:46] We hear if Vini's using RuboCop or Syntax tree for formatting, which leads him into telling us about future plans of adding a plugin system to be able to format with standard and with Ruby format. [00:35:56] Vini shares other ideas he has for the future of the Ruby LSP.[00:37:11] Outside of the LSP, we hear about some other projects Shopify is working on with contributing to the new Ruby debugger, Chris expresses his appreciation for all the new tooling the team at Shopify is working on, and Jason expresses his love for the Rust tooling.[00:42:18] Have you seen Gary Bernhardt's talk on building an editor? [00:46:27] If you want to try Ruby LSP, Vini tells us where to go to set up VS Code.[00:50:29] There's a great blog post Vini wrote, a video with his talk from RailsConf 2022, and find out where you can follow him online.Panelists:Jason CharnesChris OliverGuest:Vinicius (Vini) StockSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterVinicius Stock TwitterVinicius Stock GitHubVinicius Stock WebsiteRuby LSP (VS Code extension)Ruby LSP-ShopifyImproving the Developer Experience with the Ruby LSP by Vinicius StockRubyConf 2022- Improving the development experience with language servers by Vinicius Stock (YouTube)RailConf 2023A Whole New World-A talk by Gary Bernhardt from Strange Loop 2012Ruby Radar TwitterRuby for All Podcast

Operational simplicity is a gift to you (Ship It! #62)

Changelog Master Feed

Play Episode Listen Later Jul 20, 2022 57:30 Transcription Available

Gerhard's transition to a senior engineer started 10 years ago, when he embraced the vim mindset, functional core & imperative shell, and was inspired to seek simplicity in his code & infrastructure. Most of it can be traced back to one person: Gary Bernhardt, the creator of Execute Program, Destroy all Software and the now famous Wat idea. Few stick around long enough to understand the long-term impact of their decisions on production systems. Even fewer are able to talk about them as well as Gary does.

software operations cloud ship destroy infrastructure simplicity devops operational kubernetes gerhard sre devsecops cloud native cncf changelog gary bernhardt

Operational simplicity is a gift to you

Ship It! DevOps, Infra, Cloud Native

Play Episode Listen Later Jul 20, 2022 57:30 Transcription Available

software operations cloud destroy infrastructure simplicity devops operational kubernetes gerhard sre devsecops cloud native cncf changelog gary bernhardt

333: Tapas

Play Episode Listen Later Apr 12, 2022 41:53

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

ceo google pr spoilers zoom beyonce west coast east coast oracle cto similar slack magicians references api mid chrome ui github dry jk qa javascript rails sql git tapas prs mandy moore gitlab mongodb gerrit crs typescript vs code giant robots prettier yaml bitbucket sybase mapreduce chris yeah chris you chris no chris well sandi metz rspec shawn wang sam zimmerman avdi grimm i18n chris thank gary bernhardt repeat yourself chris thanks chris okay chris let kevin newton chris toomey giant robots podcast

Load Testing Rails Applications & Rails Conferences

Remote Ruby

Play Episode Listen Later Mar 25, 2022 43:56

[00:02:15] Jason shares some interesting news that happened at Podia that involves Harry Connick Jr. and load testing. [00:05:54] Chris tells us a story about his first Rails job which was building a website for Justin Timberlake's 901Tequila.[00:07:08] Jason tells us about a tool they used called k6. [00:18:11] Chris and Jason chat about query times with Heroku Postgres and Heroku Dashboard.[00:20:13] There's a great talk by Gary Bernhardt about Text Editor that Chris explains.[00:24:18] We find out about Jason's Sin City Ruby talk which was supposed to be on Simplicity but it now on SQL and Active Record. He also tells us about the talk Colleen Schnettler is doing on arel.[00:26:32] Jason had to do some SQL at Podia and talks about how there was no good way to make it anything but SQL.[00:30:56] The guys chat about submitting talks for RailsConf 2022.[00:34:32] Jason shares a funny story about the last time he did a talk at RubyConf 2017 and what happened when the fire alarm went off. [00:37:20] Find out what the guys are doing when they're in Vegas.[00:38:34] Earlier the guys were talking about missing indexes or things that could be indexed and Andrew tells us about a gem called lol_dba and Derailed Benchmarks.[00:41:48] The guys share much needed thank-you's to some important people for their contributions, inspiration, and all the work they've done for Rails.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:Hook RelayLinks:Ruby Radar NewsletterRuby Radar Twitterk6Text Editor From ScratchColleen Schnettler TwitterHammerstonearelRailsConf 2022lol_dba-GitHubDerailed BenchmarksSaving Ruby from the Apocalypse with Jason Charnes (RubyConf 2017)

306: If You Want To Go Far, Go Together

Play Episode Listen Later Aug 31, 2021 45:14

In this episode, Steph and Chris talk about things they've changed their minds about over the course of their careers as software developers. Steph talks about as it turns out, arm chair rests are good, feature flags and comments are also good, she's changed her mind about how teams structure the work that each person is doing at once, and believes strongly in representation in the field. Chris is not a fan up upgrading his operating system and when he first started out, he gravitated towards learning dynamic languages, and since then, much prefers functional languages, static typing or more broadly, static analysis. He also no longer believes in the 10x engineer, and also very much believes that URLs matter on the internet. So basically, don't call them single-page applications; call them client-side applications instead! Arq (https://www.arqbackup.com/) Karabiner-Elements (https://karabiner-elements.pqrs.org/) Kent C. Dodd's Epic React Course (https://epicreact.dev/) The Art of Code Comments by Sarah Drasner (https://www.youtube.com/watch?v=yhF7OmuIILc) Gary Bernhardt: Functional Core, Imperative Shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Transcript: CHRIS: I still have dreams that I missed an entire semester of math class, and now it's time for the final. I don't know that I'm ever going to grow out of that. STEPH: That's wild. CHRIS: You don't experience that? It's a mixture of I'm in elementary school, but it's a college final. Like, the physical school that I'm in is my elementary school, but it's a calculus college course that I missed. And now it's time for the final, and I won't graduate college as a result. But it's also high school at the same time. Just every part of education sort of melded together into this nightmare scenario. Do you not experience that? I thought this was normal. STEPH: [chuckles] Not in a very long time, not since I was in college. But I'm imagining this very cute, young Chris showing up with a backpack to the calculus final like, "Oh no." [laughs] CHRIS: Yeah, pretty much, yeah. I really thought I would grow out of it at some point. But it shows...I think it manifests when I have anxiety about something else in the world, and then I have a math terror dream. STEPH: That's your stress sign. That's your terror dream. CHRIS: Apparently. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week going? CHRIS: Oh, it's going fine. Yeah, I'll go with fine. I had to upgrade my operating system. Enough things had stopped working or seemed to be pestering me about it regularly, which normally I'm going to ignore that for as long as I can. That's sort of where I'm at in the world these days. Like, I don't want to upgrade because I don't know what's going to break and whatnot, but then things had broken already. Text messages were no longer showing up on my computer. And it turns out that the primary way that I interact with text messages is by replying to them through my computer. I don't want to type on my phone, that's not a thing. I'm already grumpy enough about text messages, to begin with, that I will regularly respond switching to email, and then I'll go off from there. But yeah, they stopped working, it stopped connecting. And then I got this really weird message from Apple when I tried to sign in. And I was like, I feel like I should at least try to upgrade to the new operating system, which I think has been out for a long time, and I've just been ignoring it. But then I had the added problem of I didn't have enough space on my computer to install it, which I tried once before. So I downloaded the installer, but the installer downloader doesn't check whether or not you have enough space to do the install. So it's just like, hey, so you know how you didn't have enough space? Well, we took up the remainder of it, and now you can't do anything about it. And the installer is hidden somewhere in the computer. So at one point, it just went away, and then suddenly had a lot of space on my computer. But finally, I decided to bite the bullet. I found a bunch of caches on my computer. So there was a cache for my backup utility, which is called Arq, A-R-Q, which was a lot of space. It was like 20 gigs or something like that. So it was like, sorry, you have no more cache. I'm pretty sure my computer's going to light on fire the next time it tries to do a backup because it has no cache to rely on, and it's got to try a lot harder, pull a lot more data down. I don't know what it does, but whatever. It's going to do that. And then, I found the more general application caches on the computer. Spotify had like six gigs of cache. Well, what are you doing? Aren't you streaming from the internet? Stop it. That's not okay. That is not acceptable. Yarn had three gigs. I was like, what is everybody doing? And I busted all of these. I threw away everything, and my computer seems to be doing fine after the fact. So, were the caches even doing anything? I ask. Anyway, so I upgraded, and then some stuff didn't work. And so then I had to find the versions to make stuff work. The particular one that stood out was Karabiner-Elements, which I used to make my mechanical keyboard do the right things for the function keys. That stopped working. And I tried to upgrade it to the newer version because I figured okay; they probably hopefully released a new version, but it failed in the upgrade process. And it turns out the secret was I had to upgrade to an intermediate version. I was on 12.3, and I needed to go to 13.4. But in between, I had to go to 12.10. And if I went to 12.10, then the upgrade to 13...everything about it was everything that I hate about upgrading software. It's like, I just know it's working right now, and I feel like if I even just look at it wrong, this whole tower of software is going to fall over. The worst thing, the thing that I have not been able to fix, is now I use iTerm as my terminal, my terminal emulator as it were. And I typically run with transparency mode on which some people look at and say, "Wow, that's a choice." And I say, "I kind of like it. I don't know; it makes me feel like a hacker or something." I don't know, whatever. [chuckles] Let me live my life. But for some reason, switching to Big Sur, the version of OS X that I'm on now, iTerm doesn't have transparency anymore. And I just haven't been bothered to fix it yet. But, man, I got rambly. I clearly have some feelings about upgrading software. STEPH: You have so many feelings. The fact that you kept going...People can't see me, but I'm just dying because of that whole story. [laughs] CHRIS: I kind of felt like I had to get through it. I had to exorcise the demons, tell my tale, and then be done with it, which I think I'm at now. STEPH: When I start laughing that hard, [laughs] I try to hide from the camera view because I want you to keep going for people to listen. CHRIS: But what's fun is you bob and weave. You'll hide for a minute, and then you'll come back and be like, okay, I'm composed, never mind. And then you'll just fade off to the side again. So yeah, but I powered through. [laughs] STEPH: Oh, all right, there is so much there. [laughs] Upgrading is the worst. I agree with that. That was actually something I ran into earlier this week. Well, it was a mix of where upgrading presented a problem and then upgrading something else resolved that problem. And so that was an adventure where I shared a tweet. I can link to it in the show notes as well. But Ruby was just taking up 100%, a full core, just all the time, and I couldn't figure out why. I wasn't doing anything with Ruby. We weren't talking at the moment, but it was just turning up one of those 100% CPU or higher. And so then I did some searching. And I did find the resolution, which was to upgrade the Listen gem because there was something in the Listen gem that didn't fully support Big Sur. Is that the name of the thing that I am on? CHRIS: That's the new one, yeah. I know because I've just upgraded to it. I have thoughts on the matter. [chuckles] STEPH: Cool. [chuckles] Yeah, when I upgraded to Big Sur. But then someone had kindly marched in to fix it, then upgrading resolved that problem. And Ruby is back to a peaceful level as to the amount of process, the amount of CPU that it should be taking up. Transparency mode, I'm thumbs up on it. I like how you called that out, how that's a choice. And I'm with you on that choice, although I didn't realize that's broken. I guess I just hadn't...I guess I don't care deeply enough that I've tried to restore my transparency, but you're telling me to hold on. CHRIS: We're going to get realer now in this moment. So I have a very old version of iTerm because it has a different way of going fullscreen than the default operating system level fullscreen. I really hate that it animates to fullscreen, and it doesn't quite fill the full screen. Like, it still had a border around it or something. So I have a very old version of iTerm that I've been running with forever, and I refuse to upgrade in any way as a result of I want to cling to this old version of things working. But as a result, I think I finally hit the end of the road on that. This is like years running now too. I remember I kept it in a Dropbox folder so that each time I upgrade or get a new computer, I'm like, okay, good. I still have my old special version [chuckles] of iTerm. But I think that time is over and I got to find...I feel like there are new terminal emulators out there. It's like Alacritty and other stuff that people talk about. So maybe it's time for me to try and find something new as long as I can get that transparency because I want to feel like an uber lead hacksaw. STEPH: You have such a brand of new-new that I'm now discovering that you are also a software hoarder, so you have both in your personality. [chuckles] CHRIS: There was a period early on in my software career that was like, oh, I got to find all this stuff. I got to figure things out and configure it. And then I was like, wow, that's taking up a lot of my time, I should stop it. And I think since then, I haven't upgraded anything. If you go look at my .files, I don't know the last time I pushed to them, but it's been a while. I'm still doing things, of course, but not as much. I know the cost of it, and I know the cost of maintenance. And really, this is an allegory for software overall. This isn't just about our local development environments, but entropy exists in software. Software does not exist at rest, and it will decay over time. And so the idea of we've worked with so many clients where they're like, yeah, we're on Ruby 1.8, and it's Rails 0.9. So okay, all right, well, we're going to have to deal with that, it turns out. We can't just keep ignoring that. So really, it's the same story played out but in my local hoarder cavern. STEPH: There was a part of the saga, the story that you shared with the installer and that you don't have enough space, and it took up the rest of the space, and you can't do anything. I'm very nervous; what happened to your stuff, your space? How did that resolve? [chuckles] CHRIS: I finally bit the bullet. And so I have a bunch of...I've tried a bunch of the different pieces of software that will visually analyze your disk space. So they crawl the whole directory starting from the very root of your computer, and it will be like, all right, applications has this much, and the library directory in your home directory has this much. Here are all of the different places that stuff might be hiding on your computer. And then you can visualize and be like, okay, that's where the most of it is. Node modules, as an aside, we did not choose an efficient way to approach how to put code on my computer because Node modules take up a lot of space on my computer, but they're so spread out. Multiple times I've seen people share a version of rm -rf, and then it's some subshell that does find every Node modules directory underneath a code folder. So you can find every single Node module and just blow them away. That will regain you some space. But that was not the solution this time. I've tried lots of piecemeal solutions over time. But eventually, the thing that got me there was just busting all of those caches. So I cleared the backup utility, Arq's cache. I cleared a bunch of them, Spotify Yarn, et cetera. And that cleared enough space for the installer to actually run. And then, once that was done, the installer program itself was no longer around, so I reclaimed that space. But it was this weird chicken and egg thing where I had to have enough space to complete the installation such that the installer could go away. And now...actually, let me see what my hard drive looks like now. So somehow, according to the Macintosh hard drive info, I have 50 gigabytes of available space, which is really frustrating because there were a number of weeks where we went into a Bike Shed recording, and I was like, I have one gigabyte. I'm not safe right now because this audio is going to be more than that. And so I don't know how now I'm sitting at 50. I guess all those caches that I cleared and the installer being gone probably puts me in a good spot. But anyway, I'm living in an upgraded, wonderful world. As an aside, Big Sur is ridiculously rounded and colorful and almost cartoonish. They're really leaning into the iOS vibes. And I'm not sure it's my personal aesthetic, but that's fine. I spend most of my time in the terminal anyway. But I think that's enough of me ranting about upgrading my operating system, which apparently I had a lot to say about. But what else is up in your world, Steph? STEPH: I do appreciate the ranting, though. You're not often grumpy, and when you are, it's quite humorous. [laughs] I really enjoy the grumpiness. And it's often a painful process. So I appreciate all of that story. Something that I really need to share with you and get off my chest is a couple; I don't know, x number of episodes back, you and I were talking about computer chairs. And I bragged about the fact that I have a computer chair that has no armrest, and I love it. I love my chairs like this, and it's wonderful. And I just think it's the best way to live. And it turns out that that's bad because I happened to go see a massage therapist who's also very well-skilled in physical therapy and other areas. And they were talking to me about my desk setup. And I mentioned the fact that I get these typical headaches, and I have my chair, but there's no armrest. And they're like, "Oh, that would do it." I was like, "Why? I like my setup. What's wrong with it?" And they're like, "Well, if you don't have armrests, then your back is having to compensate and to hold up your arms and your shoulders all day. So while you're typing, you're using more muscles to then hold that. And then they eventually tighten and contract, and then that can cause headaches." So in case, I have led anyone astray into having no armrest, they are apparently very important to not having headaches or having your back overworked to the point that you have headaches, which I'm a bit sad about. But on that front, I have ordered a new chair, and we'll see how it goes. I will have to assimilate into the world of chairs with armrests. CHRIS: We welcome you with open armrests. [laughs] Sorry, I saw it, and then I went with it. Anyway, I'm realizing now I actually don't use the armrests on my chair per se. I actually end up putting my arms on the desk, which is probably not ideal either. I have a little wrist pad so that my wrists are brought up and so that I don't have the upward breaking of the wrist thing going on. I think that matters a lot. And then my arms are supported by the desk, but it is just right on the desk, and I wonder if that's worse. But I've never...I don't know, getting the armrests just right and then also having the wrist pad. But I can't adjust my desk is probably the main problem. If I could bring my desk down a little bit, and if it were a thinner top, then I'd have more flexibility. The chair that I have is wonderful and has flexibility. The arms can go up and forward into the side and lumbar and this and that. And so I'm able to make the chair work to the desk. But I do wish I had more of an adjustable...ideally, like a stand-sit desk. But I haven't made that jump just yet. STEPH: When you're ready to make that jump, I'm going to share with you where I bought my desk because I'm really happy with it. And it's also not nearly as expensive as most of the other desks that will go up and down. CHRIS: Presumably, we can include it in the show notes as well so that we share it with everyone. STEPH: Definitely, yeah. CHRIS: Otherwise, that's just kind of mean. [laughs] You and I have a weird back channel that we talk about on the show, but they're not actually put in the show notes. STEPH: We're not mean. We wouldn't do that. I love my desk. And it was from someone else. They're the ones that shared it with me, so I'm happy to pass it along because it has served me well. And yeah, I'm also not sure about how this is going to work with the chair and the armrest because I'm just worried they're going to be too wide, and they're not going to actually offer support. I have doubts. I have lots of doubts, but I'm willing to investigate. And we'll see how this goes because I would like for the headaches to stop. CHRIS: Good luck on that front. That definitely seems like an indication of worth putting in some effort there. STEPH: Agreed. I also have some other exciting news. Stephen Hanson at thoughtbot has organized a number of other thoughtboters to get together who are interested in really diving into leveling up, learning React, and specifically focusing on purchasing the Kent C. Dodd's Epic React course. And it's for anyone that is comfortable writing code, whether you know React really well or if you're new to it. Everyone's welcome to join. So we just kicked that off today where we're going to go through the course together and then meet every Friday. I think the cadence is probably three hours, three and a half hours every Friday, that then we're going to commit to working through the course together. And I have to admit, I always nerd out a bit over how does someone build a course? Like, I'm really excited about the content as well, but I just want to know how did someone go about producing this content and then sharing it with everyone? And then what's their outline? How do they help people that are getting stuck because they can't be there in the same room? How do they record their videos? So I'm really excited to see all the ways that Kent has crafted this workshop. And so far, there's so much content, but I'll have more to report as we really start to dive in. But I'm excited to revisit React because I haven't been in React land for at least a year and a half; it's been a while. And so it's one of those areas that I know some bits, but a lot has also changed. And I would like to just revisit that world. So I'm really excited to dive into the course. And so far, I really like the structure that Kent has taken with the curriculum where we're focusing first on what exactly is happening and all the effort that goes into if you wanted to actually write HTML and then layer on JavaScript on top of that. But then here's how React makes that easier for you. Here is how JSX makes it even easier on top of the React API. I really liked that. Here's some pain; feel a little bit of pain, let's get a little bit better. And then let's get even better on top of that. And that has been a really nice reminder and progression into the course. CHRIS: I'm definitely a fan of the way you're describing it like, feel some pain, and then let's get better. But then, like, what's the hook? With any educational content, this is the sort of structure where there can be full education. But this is the thing that I feel very deeply about conference talks is my goal isn't to teach you everything if I'm giving a conference talk; it is just to get your attention just to say, "Here's the thing, here's why you might care." And starting from the problem, starting from the pain is always such a good way to do that. Because you know how this stuff is hard? What if I had an option that was easier? And then building from that totally makes sense. I want to say that course, Kent's course was built in conjunction with the egghead team, egghead.io. And it's a distinctly branded course. But it was built on top of the framework in the platform that's there and all of that, and then some of the editing support. I don't know this for certain, but I think there was some teamwork there. And I love just pushing forward the envelope of how we do educational content in the world of development because it is such an interesting world that has, frankly, such a need for ongoing development. The world is changing out from underneath us every two days. And therefore, having great educational content is so important. So yeah, definitely interested to hear how your experience goes both with the course and then also diving deeper into React. Well, switching gears just a little bit, I had a topic that I wanted to dig into with you today. And so to give some context, the topic, the thing that we're going to be talking about today is what have we changed our mind about? So you and I have both done a little bit of thinking and tried to come up with some answers to this. The background, this was actually inspired by a tweet that I saw between Shawn Wang, aka "Swyx" on the internet, and Charity Majors, a recent guest here on this podcast. And Charity is someone who is known for having strong opinions. But Shawn asked the question of what are some opinions that you've changed your mind about? And Charity actually had a wonderful list, which we'll link to her tweet thread where she shared some of her both technical and then also more personal ones, but really talking about the sort of evolution of thinking and the way someone's thoughts can change over time. And I thought it was just such an interesting thing because, for most points in time, we experience someone's sort of snapshot of where are you at now? What do you believe to be true? But I think there's such an interesting story and sort of the arc there of what did you believe to be true that you don't anymore? What have you softened your beliefs on? What have you strengthened your beliefs on? So yeah, with that as the context, what have you changed your mind about, Steph? STEPH: Yeah, this one really got me thinking, and I feel a little stumped on it. I have a few that I'm excited to share. But I'm very excited to hear your list to see if that also helps me reflect more on some of the things that I have changed my mind about. And I have found that there's only a couple maybe that I feel like I've really solidly changed my mind about. The others, I've either dialed up the strictness, or I've dialed it down. So the ones where I've really changed my mind about are feature flags and comments. Those are two of them. Well, there's a third one, but I'll get to that in a moment. So starting with the first one, feature flags I was more in the camp where I very much appreciate feature flags, but I use them sparingly because then there is a tedious nature of introducing them and then having to clean them up, and then having to maintain two states of code. But now I've really seen the value of feature flags and how we can make sure that we have calm releases and ensuring that main is always in a deployable state. So feature flags is one for me. I'm very invested in having more of a robust feature flag system because I see the benefit to that. The other one was comments. I used to be very rigid about comments are bad. We should never have comments in our code. They are just waiting to go out of date, and they're not going to be helpful. But I have since dialed down that strictness where I have certainly seen moments where comments do feel very helpful, and I can see how people use them. I still want to avoid them for the most part, but I am less strict now in regards to people who really find value in comments. I'm more open to that discussion. I want to understand what it is they find helpful about that comment, and if it is something that we can't capture with code or a test, where does that live? CHRIS: Those are both interesting. Feature flags, for me, I think I actually was more strongly opposed in the beginning. Earlier on in my career, I saw them as added complexity, as noise. I often would encounter them left behind in a codebase. And so, I had this negative association with them. And I didn't see the value; I hadn't yet felt that pain. And over time, I've definitely shifted to where you're at where I'm like, I love feature flags. This is a critical tool in our toolset of how we actually…like you said, calm deploys, being able to always deploy main, making sure that we don't have long-running feature branches. There are so many benefits that come out of it that I'm now very strongly in favor of them. But it's interesting; I think I would say that I started in a more strongly opposed place. So that wasn't on my list, but it's an interesting one that you've brought up and probably one that I've moved more on. Code comments, I think, actually started in my career being like, obviously, you comment your code. It's the thing that I read about and stuff. And slowly, over time, I think I've just dialed in on I don't think we should be doing that. There are, of course, going to be exceptions. And actually, one of the things that I discovered about myself as I was trying to go through this exercise is there are very few things that I believe are black and white. If anything, that maybe is one of the things that I've leaned into over time. It's like, nothing is binary. Nothing is black and white. Everything is on a continuum or shades of gray. There are things that I believe a little more seriously. But there's almost nothing that I can be like, nope, absolutely I will not equivocate on this beyond how we interact with other humans and being reasonable, kind people. And in terms of software practices, not really. Comments, though, are one that I still am pretty strongly not going to lean into. So it's interesting that you're like, eh, I've kind of opened up to that one. STEPH: There's a particular talk, The Art of Code Comments by Sarah Drasner, and that's the one that really shifted some of my opinions around comments, and then how we talk about them, and what benefits they can play. But I will admit, if I see a PR that has code comments, I still immediately have a negative reaction to that. And I want to have a conversation around why that comment was added and if we can remove it, and how we can remove it. But even with that negative perspective, I still find that I'm more open to that discussion versus before, where I would have been like, no, that's just unequivocally bad. CHRIS: I do like that you always bring up that talk whenever we talk about comments. This is a great talk. And in the background, I just looked up Sarah's Twitter profile because every time you bring it up, then I mention that she has a still from the movie Labyrinth in her Twitter background, but she actually changed it. And so now that's not true anymore. It's now something from The Force Awakens. Well, it's actually a joke, but I'm still going to suggest that you watch the movie Labyrinth at some point. That's the thing that I feel actually kind of weird about. It's a weird movie. STEPH: I'm going to take your suggestion, but not watch it. But thank you. [laughs] To share my truth today. CHRIS: That's fair, that's fair. STEPH: What are some of the things on your list? CHRIS: Okay, I have a couple, some more on the technical. Let's lean into one of the technical ones. Early on, I started with dynamic languages. I think I started with Python primarily and a little bit of JavaScript. I eventually found my way to Ruby and felt very at home there. And then, I started to explore functional languages. And I started to lean into them really hard and felt that immutability and functional programming and true pure functional programming was the thing. It was the answer, and I just needed to figure out how to do it. And so I would say that is the belief that I have since changed my mind on and decided, you know what? Actually, it feels like a bit of a force fit. I have tried. And maybe for others, it is actually a really fantastic way to build software. But having worked with a number of other people in more functional contexts, I find that it is a bit of a force fit. It's a bit rough. And in particular, of late, I've been working with Svelte as opposed to React, and React does sort of lean into the functional paradigm, especially with Hooks and all those sorts of things. And it's a little bit rough because it turns out UIs are these deeply mutable things. We're changing values or typing things in. There are actions that are changing the state over time, and having a system that just more directly models that feels very natural. I still love functional programming for the more core of an application. So again, I reference this talk often, but Gary Bernhardt's Functional Core, Imperative Shell. Gary has really formed some of my thinkings on this. And now I've started to find the examples in the work that I'm doing of like, oh, okay, I see that pattern actually applied here. But much as I would love to use them, the functional languages I find just aren't quite landing for me. And additionally, the mutability, particularly in the front end right at the edge of the UI, is not quite as good of a fit. STEPH: So I think that resonates with me although I do still get very excited about following more patterns that represent more immutable state just because I felt so much pain and found bugs from the fact that we have mutated state in surprising ways. I'm honestly not quite sure how I feel about it. I'm going to have to think on that one. That's a very interesting one that you've changed your mind on. CHRIS: Yeah, similarly, my feelings are lukewarm, whereas before, they were stronger. I was like, oh, okay, I think I found something here. And then, in attempting to use it across a wide variety of applications, it just didn't quite feel right. I felt like I was swimming upstream sort of thing. Actually, there is an interesting counterpoint. One thing that I have leaned into and definitely changed my mind on and embraced is static typing or, broadly, static analysis. But I think static typing being the most pointed version of that. Early on, like I said, I got my start in very dynamic languages in Ruby, and Python, and JavaScript. And so that dynamic duck typing runtime can be anything. We just make our systems respond to the messages, and all of that sounded great. But it turns out I really love having a compiler that can tell me some truths about my program before it ever reaches runtime. And the idea that a typo can make it to production feels absurd at this point. And actually, as I'm working in Ruby, I'm like, man, I really got to go look at that whole Ruby typing thing we got going on. I don't know what the state of it is. I've looked at it in the past, and I need to revisit it soon. But like TypeScript, I've definitely embraced that very strongly. And I would not work without TypeScript in a JavaScript project at this point. I've loved the work that I've done in Elm, although that also sort of blends into the functional stuff where it's like, it was a little bit noisy, though, I'll say that. But the type system and the fact that the compiler can give you so much rich information about your program, I would not trade that at this point. And I don't see myself going back on that front, which is an interesting place for me to be on of actually, I'm not that into the functional programming as the core way that I build my applications. But I do like static typing. And I feel like functional programming and static typing actually go together incredibly well. And functional programming and, more imperative, whatever it is that I'm doing with my day-to-day life these days is a more interesting fit. But it is interesting to me to observe that sort of combination of opinions where I really like static typing, and having a compiler, and something that can tell me about my program before I get to runtime. But also saying that I don't quite want the functional programming thing, or at least not as the entire way that I modeled my application because I found it a bit difficult to work with. Because I think static typing or compilers and functional programming go really well together. But I think generally, what I'm finding is a more middle ground dynamic optimization of a bunch of different things. And the answer is like, well, it depends which I guess if you've listened to the show before, you'll have heard those words said, so I guess it makes sense. STEPH: Yeah. All of that makes sense to me. And I can see why you might have a favor for types or why that feels more valuable initially because that is giving us so much feedback right off the bat versus following a more functional paradigm is something that could feel like more of a force fit and doesn't provide that same immediate feedback. But it has a longer-term or a longer cycle of that reward system. So I can see why you might favor one over the other or why I myself would favor one over the other. CHRIS: How do you feel about types? STEPH: I'm a big fan, although I say that, but I work in Ruby. [laughs] I don't have them. But when I have worked with types, I very much enjoyed it because it makes me think more about the design of my code in a way that I don't as much with Ruby. And working with types has heavy influence than when I am working in Ruby and thinking about the design of my code. So I think working with types is a wonderful thing that, frankly, all of us should do as developers at some point because it is so influential. So I'm for types, but I'm not using types in my day-to-day. Another thing that I have changed my mind about is how we structure the work that each person is doing. So I used to be more in the camp of everybody can work on their own very complicated piece of codebase, their own complicated feature. We can have a bunch of complicated things in the sprint, and everything will just be great; it'll be fine. And we'll get a bunch of work done, and we'll ship it. And then we're an even more productive team. And I very much disagree with that now where I have found where everybody is working in their own silo on a complicated feature has slowed down the progress of then being able to ship that feature. Because we often want to collaborate with someone, we need to collaborate with someone. Then the PR review process is tough if I really have no idea what you're working on, and I don't have a context that then when I look at your code, not only am I evaluating at the code level, but then I'm also trying to understand the feature and gain all of that context. And that's a heavy cost for me to have to pay to then pick all of that up and then for you to have to reintroduce me to what's happening. Or I might make the bigger mistake, and I may look at your code and just evaluate it from the code perspective but not really understand the feature, the value that's being delivered. And that doesn't feel useful. And I have a recent example where that happened where someone was working on a very complicated feature that I didn't have any insight into. So then, when I was looking at the PR, it was easier for me to just look at the code and get feedback on that. But then it was probably a day or two later. It wasn't until then that I finally started asking, what are we building? Like, what purpose is this serving? And that opened up a much larger discussion where we realized what was being built didn't actually really deliver what we needed to deliver. So I no longer agree with the idea that everybody should be working on their own complicated features independently, and there should be some collaboration. And, you know, it's the buddy system; we all need a buddy. CHRIS: Well, I like that one. I feel like I've shared similar ideas where it made sense. It was just the efficient thing to do, to split the work up and have everybody very independent. I also feel like earlier on in my career; I was more scared of Git conflicts and things like that or people interacting with the same parts of the code. And so in my mind, it made sense to really strongly separate like, oh, you shouldn't even be touching the controller for this. I'll handle the views, and you handle the controller; it'll be separate. And I care less about that now. And I think what you're saying of like, it's actually better if we have some shared context, and we understand what we're working on, and it's more of a collaborative process. Yeah, I like that one. I think I followed a similar arc, and I'm at a similar place now as well. Interestingly, to go into another one of mine that I think you'll probably be most surprised by on my list is I think I used to believe in 10x engineers. I used to believe in the idea of that one developer just off in the corner fueled entirely by Mountain Dew that would just produce the perfect code. They would just solve it. Over the weekend, they would write the entire billing system, and it would be great. And I think it was predicated on the idea that the coding is the hard part, which I no longer believe. I think coding at its core is communication. It's taking this thing that we want to be true in the world and then communicating it to a computer but also ideally communicating it to our teammates, and to future versions of ourselves, such that we can revisit that code, we can maintain it over time, other people can add to or augment it. And so the idea of this loner that can just do incredible volumes of work and have that be a good outcome that just doesn't make sense to me anymore. I've worked with incredibly talented developers, to be clear, folks that I was sort of in awe of. I've worked with people who have, I think, just truly photographic memories. They seem to remember every single bug that they've ever had and exactly where they can look it up. Or from the top of their head, they can just intuitively know, oh, this bug means this. Go look at this line of code. I'm like, how did you do that? How did you do that magic trick? And they're incredibly capable developers. But at the end of the day, the folks that I see being most impactful on a team are the folks that are able to communicate and collaborate most effectively and make the whole team more effective. STEPH: Maybe it's the Mountain Dew; maybe that's actually the secret sauce here. That's what I'm missing from my life to take me into that status. CHRIS: I'm now imagining Mountain Dew but in a more viscous form, like a barbecue sauce, but it's Mountain Dew flavored. That's the secret sauce because it's a very…anyway, moving on. [laughs] STEPH: It's a terrible product. We should make it and sell it. [laughter] CHRIS: Career pivot, we now sell Mountain Dew sauce. STEPH: [laughs] CHRIS: But yeah, I do not believe in 10x engineers anymore. If anything, I believe that that is a huge warning sign if you have anyone that's behaving in something close to that space. STEPH: Yeah, I'm super interested in that you've shared because I don't think...We've talked about 10xers, but we haven't talked about the fact that you used to think that they were more of a thing and that they existed. And now it's all I'm sorry, but it's all crap. [chuckles] That's super interesting to me. Do you remember what changed your mind? Do you remember that pivotal moment of where you were like, oh, maybe this is all bullshit? CHRIS: I think it was just an amalgamation of experience over time. I've encountered people who fit the archetype. But if anything, I would say they're deeply problematic in teams. They're that individual who refuses to collaborate, who just goes off and heads down, writes a bunch of code, but then it doesn't integrate with the other pieces, or no one else knows how to use it, or they won't let anyone contribute to it. And yeah, I've seen that just be very, very problematic. So the folks that most fit, I think the imagined version of this, actually end up, in my experience, leading things astray. And the folks that are actually most productive and really cause teams to improve in a drastic way behave very differently. They're much more collaborative; they're much more engaged with the team. It's less about their individual contributions and it's more about building a system together, collaborating, communicating, engaging external stakeholders, et cetera, et cetera. It's all that stuff that matters. And so, it's very much in contrast to what the 10x engineer ethos is about. But there's no one day where suddenly this idea that I had in my head crumbled when I saw that behind the pile of Mountain Dew cans, there was nothing there. [laughs] STEPH: It's all a mirage. [laughs] I do like what you just said around that there are very impressive people out there. And those impressive people often focus less on their individual contributions and more at a higher level around communication. And then they are the powerhouses that then is helping facilitate everybody else be their best and have high levels of individual contribution. Those are the ones that...I'm still not going to endorse a 10xer, but they are the ones who, to me, embody the idea of someone that is incredibly efficient and really good at their job. CHRIS: There's an adage that comes to mind here that "If you want to go fast, go alone. If you want to go far, go together." And that does ring true to me. I think an individual can have their individual productivity be higher if they're working entirely on their own, if they understand every line of code because they wrote every single line of code if they know where every feature of the platform is integrated because they wrote the whole thing. But they're going to be fundamentally limited. And in order to do bigger, more complex things, fundamentally, we have to work as a team. And then the way you have to interact just fundamentally changes. So I think it started from that, like, one person on their own I think can be individually more effective. But the minute you start to have a team, that one person acting on their own is actually dragging the team down because other people can't then work in that space, and that's a problem. STEPH: I really like that adage that you just shared where, "If you want to go fast, go alone. If you want to go far, go together." And that touches on something else that I have really changed my mind about, and that's representation. And this is more specific to me. So when I joined engineering and became a web developer, and I joined a team, and I was the only female engineer on that team, my initial feelings were I am the only female engineer, and that is fine. We're all just a group of engineers. We're here to solve problems together. It really doesn't matter if there's anyone here on this team that's like me. It's fine if there's no one that I can see myself in that's in leadership because we're all just people, is what I was coming down to. And I've completely changed my mind and realized that that's not true. And I've experienced this where I've worked on other engineering teams with female engineers, and it's fucking awesome, and it does make a difference. And then when I can see someone that I can see myself in, in a leadership position, that is also inspiring. So that is something that I went in where I think it was more of I was trying to shield myself from the idea that I am different from everybody else in this room, and that could be a problem. And instead, I just tried to neutralize it by saying it's not. But I think representation is incredibly important. People are not just people. We all have very important social and racial, and cultural identities. And it's very important that we get to feel that we can express all of those identities and see people that represent those identities in spaces where we would like to go. That's a big one that I've changed my mind on. CHRIS: Yeah, I certainly agree that representation certainly matters, and being able to bring your full authentic self to work and seeing others around you that reflect that. And frankly, having teams that are made up of people that represent the users of the software that we're building feels so critically important. And it's very interesting to hear about the arc that you've had on that where initially, you tried to downplay it, but then you found a little more truth in it. And so yeah, thank you for sharing. STEPH: You're welcome. It feels good to say that, too, because that's something that I've admitted and realized on my own, that that is something that has changed and shifted. But it's nice to be able to share that here with you as we're going through the things that we've changed our mind about. What else is on your list? CHRIS: Well, to round us off with one more very technical version because, of course, that's where I'm going to take us after a much deeper and more nuanced topic that you led us on, single-page applications. Broadly, I'm opposed to the name; that's a side conversation. But, man, URLs matter on the internet. So don't call them single-page applications, but client-side applications or whatever. Broadly, the idea of a bundle of JavaScript, and so you send down an empty HTML document, and then you reference a bundle of JavaScript, which that thing boots up and it then makes a bunch of API requests to the backend, and then it starts to fill in the page. I was convinced for a while that this is a reasonable and perhaps even necessary way to build software. We need APIs for our mobile apps anyway. So if we're doing that, then let's have that be the consistent way that we are accessing information. This is going to be fine; it's not a problem. And then eventually, we found some problems. So then we got GraphQL, and we tried to solve it that way. But overall…and I have spent a lot of time trying to make this thing work, trying to find a version of this that I'm happy with that I find the end outcome of the software to be as pleasant to work with from an end-user perspective as a server-driven application, and I can't find it. And so, to be clear, I'm still doing client-rendered applications these days. But Inertia.js is the framework that I've leaned into that helps me bridge that gap. And the idea that the server owns routing, that the server owns statefulness, things like that, not having to think about client-side routing, not having to think about client-side state management, being able to use traditional auth mechanisms built into cookies, all of these familiar things that we've had. Leveraging the fact that the server is the more privileged in terms of the information it has access to, the more secure, the more powerful environment, all of these things feel right to me. And the nature of the application that I can build just feels more robust, more consistent, easier to evolve. There were a lot of promises that I heard when we started building applications in these ways. And I just haven't seen an example or have not worked on an example, at least of an application that is built as a client-side bundle that boots up and does some stuff and had a good experience with that. So Inertia, as an aside, is my answer to this. And I continue to be extremely happy with that as a solution, as really a middle-ground solution. Because going all the way back to true HTML server-side rendering is limiting in other ways that I didn't like. But I find that Inertia really strikes an ideal balance in the middle there. STEPH: I feel like I completely agree with everything you're saying. But I also feel like I have a developer secret to share where I really haven't worked on single-page applications, and I am okay with that. [laughs] CHRIS: It's fine, skip it. Just go straight to Inertia. It's better. STEPH: Cool, cool, cool. I am working on leveling up React, and then the plan is to go to Svelte and Inertia. So I'll just completely...I'll skip that. I'll skip that part of my career. CHRIS: I actually want to back up just a little bit as I'm saying this because I really try to avoid being in a more negative space. And I think this space, this architecture for building applications, is complex, and there are things that will warrant it. So things like Google Maps, it makes sense to have a lot of Dynamic JavaScript and to be doing complex things on the client-side. Trello is another example of an application that that as a server-rendered thing, doesn't really make sense. And frankly, using a tool like Inertia wouldn't quite work there. That said, that is, in my mind, truly a single page within the broader application. So the Trello board page is a very, very complex stateful application, and I think modeling it as such makes sense. Google Maps, similar. But there's still the profile page, and the login page, and all of these other things. I think routing is probably where it breaks down for me. I think client-side routing is the thing that I feel the most pain on. Because at the end of the day, the server still needs to know the answer. And if we do client-side routing, we end up with this duplication of logic across the client and the server-side. We end up with disagreements from time to time. We end up with the weird flashes of half-rendered layout, and then we go to the login page because we get an API response that is different. And so, I think that is probably the kernel of the thing that I struggle with. And, of course, it is possible to build great things using any of these technologies. But I think my summary is I've really tried on that front, and I've just not been able to make the fidelity of application that I want using…primarily; I'd say it's client-side routing is the thing that I struggle with the most. STEPH: Yeah, it sounds like you're saying there are very valid use cases for using a single-page app or following that structure. But we haven't really gotten there in terms of our web development expertise, where we've made that easier to maintain and easier to implement. And there's still enough pain points around it that even though it seems like a very valid idea and approach, it still feels painful enough that you actively avoid it until it feels like something that you have to then invest in at that point to then really deliver the user experience that you want to provide. CHRIS: Yeah, I think that's an accurate summary. And I think adding on to that, I'm noticing it becoming more and more of the standard approach; this is the way we build applications, and I don't agree with that. That is probably the thing that is the kernel of what I don't believe in. I think actually server rendering is a great way to start, and then you can slowly augment or move more things into complex client-side behavior. But starting with this as the mode that we're building our applications just feels like a less stable foundation than I would want. So it's perhaps an architecture that you want to evolve to at some point as the complexity necessitates it, but I definitely wouldn't be starting there. Similar to service-oriented architecture, not going to start there. Client-side routing, I'm not going to start there. STEPH: Ooph. I feel like I've been holding my breath this episode. I feel like this was a very interesting topic that has been challenging to reflect on what we believe and what we've changed our mind about. CHRIS: I think it's perhaps more nuanced than a lot of our episodes where often we're saying this is what we did, and this is how we felt in the moment. And that can be very experiential and true. But this, yeah, we had to draw the line in the sand and say what do we believe? I similarly definitely feel more tension in this episode than other ones. But hopefully, it was useful. Hopefully, folks found some value in the things, and hearing our story, also, the idea that we have singular formed opinions. Hopefully, this episode has broken that idea in anyone's head. And we're all on a journey. STEPH: I really like how this has prompted me to reflect on the things that I used to hold dear and really cherish or follow strictly to then reflect on what are things that I used to believe versus what I believe now? Because that transition often happens so seamlessly for me that I don't really stop to think about it to be like, oh, something just happened that is really changing how I approach things, how I build, how I work with teams. And I really like this reflection point to be like, oh, what did I used to believe, and what's different today? I'd like to keep this practice going and just try to track the things...I'll have to make a list of all the things I believe. That seems like an easy list. [laughs] CHRIS: Just the easiest list to write. STEPH: The easiest list to write. And then I'll just check in with it every so often, scratch stuff out, or update it with the things that have changed my mind about. This is the good idea, terrible idea where you go, "Stephanie, that's a terrible idea." [laughs] CHRIS: I don't know, write it down on a list, and then look at it in six months and see if it sounds like a good idea, and then we'll be able to close the loop on the whole thing. But with that, should we wrap up? STEPH: Let's wrap up. I've got a list to write. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshedor reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

spotify art apple pr clients code software ios leveraging kent transparency similar feature react api labyrinth google maps python ui dropbox force awakens apis javascript html rails upgrading trello mountain dew cpu hooks dodd node git elm yarn macintosh urls big sur inertia mandy moore go together os x typescript graphql go far arq uis svelte charity majors jsx chris yeah christ here chris you chris how chris oh chris well sarah drasner shawn wang gary bernhardt chris thanks iterm chris okay chris good stephen hanson chris toomey kent c dodd

305: Burnout & Bugs

development code software hackers programming open source software engineering vim changelog julia evans gary bernhardt jerod santo suz hinton

Play Episode Listen Later Aug 17, 2021 50:02

This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX. Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it? Svelte Is Beloved! - Stack Overflow Survey (https://twitter.com/sveltesociety/status/1422372693827985409?s=21) Bifunctors (https://stackoverflow.com/questions/41073862/what-are-bifunctors/41075765#41075765) CleanShot X (https://cleanshot.com/) Next.js Image (https://nextjs.org/docs/api-reference/next/image) Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. And we're off the rails already, everybody. It's going to be a good one. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? STEPH: Hey, Chris, it's going really well. We talked recently that I have a new laptop. So I have been migrating the things that I'm accustomed to over to my new laptop, but I also love that clean, fresh start. So as part of that fresh start, I was like, what if I use Safari? What if I just switch? I'm a Chrome user, for the record. I'm pretty sure you know that, but just to share that. I was like, well, what if I just switched and I try out Safari for a while? So that was the thing. CHRIS: So I heard the words try and the phrase that was the thing, but I'm going to probe a little deeper. How'd that go? Was it good, great, not so great? STEPH: Honestly, it was fine. I did enjoy being in a new environment to see how Safari handles bookmarks and then also the inspector. So it was novel to be in a different browser where I really don't spend much time in a different browser other than when I need to test this specific UI bug or things like that. But the reason that I ended up migrating back to Chrome was frankly for Chrome profiles because I really like that I can have this clear separation now between my work life and my personal life, and then it also keeps me signed in. So my personal email versus my thoughtbot one versus before the Chrome profiles, which I'm not sure how recent of an addition that is where Chrome introduced that feature. But before, I just always had to be signed into both, and it was just all together in one spot. But now I really like that I can separate. And it's more intentional where I'm like, oh, I'm going into work mode, so I just want that profile versus I do need to hop over to my personal side for a while. So that was the thing that brought me back. CHRIS: Interesting. I don't take advantage of that at all. I know of the feature, but it's never really called to me. And if anything, I do the opposite. So specifically, this doesn't work in the browser, but on my phone, I use the iOS Gmail client, and I use the unified inbox. So I just have everything come together. And I subscribe to the idea of, I don't know, it's all work and stuff. And hopefully, people aren't sending me a lot on the weekends, and I will defer and snooze and all of that. But that holistic view pulls me in. And so it's interesting that you're just on the other side of that. It totally makes sense. I actually think I'm wrong here. I think I'm doing the wrong, bad thing. But it's interesting just the way we're on the two sides of that. STEPH: I can see the merits for your approach where it all goes to one place. So you have one place to go and triage, and I think that makes total sense. I haven't triaged my personal life well enough that I want it to come into my work life. And that's the one that needs the more immediate response typically. So I want to prioritize all of my work emails and focus on that and then have my personal ones more like, okay, I've got some time, and I want to check on this. But I don't want to blend those together. Because frankly, I need to do some more triage on the personal side if I'm just going to bring it all into one space. CHRIS: Interesting. Yeah, I would almost view it from the other point of view of I want to protect my personal space, and this is obviously not what I do based on what I just said but protect my personal time so that when it's evenings or weekends or whatever, that I'm not seeing work emails in there. I do my best to snooze them and get them out of the way. But if they are coming in, maybe there's something I need to respond to or, I don't know, maybe it's FOMO in a certain way, FOMO but professional FOMO. I don't really know. It's interesting that that's the feature that brought you back. But overall, how was your experience using Safari? I have heard loosely that now most of the browsers are evergreen; even Edge has really caught up and is now implementing features in a similar way. And so Chrome, Firefox, and Edge are very similar. And my understanding is Safari is the one that actually lags behind or even holds back web standards and implementations and things like that. So, did you find any rough edges of that sort, or was it otherwise just fine, and it was mostly the profile stuff that made you switch? STEPH: It was honestly just fine. I also may have not used it long enough to run into any of those rough edges. But overall, it was just fine. It worked. I just got to that point where I've run into this situation before where I'm signed into my personal email, and then I'm signed into my work email. And then I'm going to Google Hangouts, and Google Hangouts gets confused, and it's like, which person are you? And then I have that moment of where I have to sign out of one, or sometimes it just gets complicated. And what I found with profiles is that that's just never an issue. I don't have to worry about it anymore. So yeah, overall, Safari was fine. I wouldn't mind going back to using it. I just really like the profile feature. This was one of those moments where it helped me notice how much I really liked that feature because I had just opted into it a while back. But this was that moment where I was like, oh yeah, I really miss that. So I'm going to go back to it. CHRIS: The thing you said a minute ago about which person am I? [chuckles] There's a deep philosophical underpinning there, but I've definitely struggled with that and trying to trick the browser into it. So Trello is the one that I'm struggling with that right now. I am one human in the world, I assure you. But GitHub gets this; GitHub plays the game correctly where I'm one human, but I have multiple internet identities. I am the work person. I am the open-source person. And I'm able to route notifications and things to the different inboxes based on the organization that they're part of, et cetera. And I really liked that, that GitHub seems to understand that I am a human that is multifaceted, whereas Trello does not. And so I use Trello in a professional context a lot, but it's my personal...like, I would have to create a distinct account on Trello. And I'm like, Trello, that's not true; I'm still one person. Just understand this Trello organization is a separate facet of my existence. Got on my soapbox on that part. The other thing I want to say is I do feel bad about the fact that I'm just on Chrome. Because increasingly, Chrome has got so much of the market share, and it's becoming the new deeply dominant thing. And so I want to be the agent of change or like, no, we should use different browsers, and we should support them and make sure that we're testing against them and all of that. And then I'm just on Chrome all the time, and I feel bad about it. But it's one of those like; I have so much muscle memory and built-up knowledge around how to use Chrome. And I've just used it for so long now that the switching cost would be pretty high, I assume. I actually haven't even really tried, but I feel bad about it. I'm now saying two things which are I feel bad about it, and I've never even really tried. So I don't feel great in this moment, but these are my truths. STEPH: [laughs] Well, I can plus-one your truths. Those resonate with me. Well, there's always stuff that I am trying that's new all the time. So I feel like I need some constant in my life until I'm ready for other things to be the constant in my life. And then I can muck around with which browser I'm using and change other things. And you have to be in that moment. You have to be ready for it. So going back to a thing that you said a minute ago about separating your work life and your personal life, I very much like that framing, and that's a nice segue, frankly. And it's something that I've been thinking about where you and I often start with technical topics. But I have a very people-centric topic that I'd love to chat with you about today, and it is emphasis on burnout. And who's feeling it? How do we identify it? What do we do about it? And that's been very much on my mind because I have noticed a lot of people around me, including myself; I just feel like we are more inclined to experience burnout right now or are going through it actively. And it feels even more important to have those conversations with each other and with ourselves to talk about what does it look like when we're burned out? How do we recognize when we're there? Because often, when we are burned out, it's not something that happens gradually, or at least it's not something that we notice happening gradually. It's like, okay, I'm fine. And then suddenly, okay, I'm burned out. And I'm at a place where then I can't really focus. I feel overwhelmed. I'm drained. For anyone that is less familiar with burnout, one, hooray, and then two, burnout is a state of emotional, physical, and mental exhaustion that can be caused by excessive and prolonged stress. So then that's what leads to us feeling very overwhelmed, emotionally drained, unable to meet constant demands, or those are the things that are causing our burnout. So I have been doing what I typically do when I'm thinking about a particular topic, and then I'm looking to gather knowledge and information is I try to go pretty wide where I start looking for podcasts, books, just people that are having similar conversations and trying to synthesize a lot of the information that they're sharing. And I have found some really good stuff. The question is now, what does one do once one has that content, and then how do you bring it back and help apply that content to yourself and then people that are around you? So I have some thoughts there, but before I go further, I'm curious, what's your experience with burnout? CHRIS: I think for me, I've been somewhat lucky in that I don't think I've ever really got into an acute period of burnout, but I've definitely had periods where I just felt weighed down. And there are ebbs and flows of life, and of work, all of those things. There is something that I've been thinking about recently, which is the inherent nature of the work that we do where consistently we're working on something where we don't quite know how to do it, and we're struggling, and we're struggling. And finally, we figure out how to do the thing, how to trick the computer into doing what we want. And then the minute we do that, in trying to encode, ideally, we're automating that away. And we take that solved problem, and we just ship it off. And then, we pick up the next unsolved problem from the list. This isn't entirely true, but it feels like sometimes unspecificity in sort of I'm just working on things that are underdefined, underspecified, and I'm trying to solve little puzzles constantly. And, I don't know, I was feeling that recently of the nature of the work was burning me out. And I think earlier on in my career; I definitely experienced this in a certain way. And then, in the middle of my career, there was this perfect inflection point of my skills and the level of tasks that I was going for. But then, the further I got into my career, the more I tend to take the weird underspecified stuff and anything that's relatively clear I'm giving to other folks on the team. I'm like, "Oh, here's this well-defined piece of work here. Can you go implement this admin page?" Whereas I am doing the investigate integrating with third-party platform XYZ that uses a SOAP API that isn't documented. I'm like, okay, cool. Let me roll up my sleeves and figure out what that means. And I noticed in my work that that was starting to weigh on me, and I was able to shake that off and shift around some of the tasks that I was doing. But that was a particular form where the work itself was weighing on me. And I took a step back, and I was like, why do we do the things that we do as developers? Because there's something just fundamental like, you have to enjoy that nature of challenge and constantly escalating challenge to a certain degree, I think, to really like this work, but it can be a lot sometimes. So I feel like maybe that's a slight digression from the topic, but it was a thing that I was feeling in this space. And that's a little bit of my story. STEPH: Well, the beautiful thing about that is it highlights everybody experiences burnout differently. So that could really be how someone is experiencing burnout where they're taking on all these very complicated, different tasks, and they're feeling just worn down by that and that they're not able to meet demand. And they get to that point where maybe they lose their interest in tech and coding because they have pressed too hard in one direction. And so then they need to take a step back. As for me, I've been thinking back over the last couple of months because there was once or twice where you and I had, I think a conversation here on The Bike Shed where I shared that things were okay, but I didn't feel like my normal self. I was losing some of my interest and energy for technology and coding. And I'm very fortunate; I love what I do. So the fact that I wasn't feeling that interest was a really big sign to me that something's different; something feels off. And it does vary depending on the client that I'm working with. And I think feeling that burnout then was a mix of some of those client pressures that I was feeling and that I was working perhaps too many hours as I was very interested in that client's success. And then the other stuff was more personal because we only have, to borrow from the spoon theory, we only have so many spoons to give. And so if you have a lot going on in your personal life as well, that's going to detract from the energy that you also have to give to work. Are you familiar with the spoon theory? CHRIS: I am not. STEPH: I recently heard about it, and I can't stop using it now because I really like it. But it essentially...and there's a really great article that we can link to so others can read about it because I'm not going to remember exactly who came up with this theory. But the idea is that each spoon represents a unit of energy. And let's say if you start each day with only ten units of energy and you use spoons to represent that, as someone needs energy from you, maybe it's work, maybe it's a personal commitment, maybe you're dealing with a chronic illness, then you are giving a spoon away to each of those. So at some point, you're going to run out of spoons. And you want to also be mindful of who you're giving these spoons to because you are giving that energy away. CHRIS: I definitely liked the idea of we start each day with a certain amount of energy, and different things can pull from that pool and whatnot. I'm intrigued by spoons as the unit. It just feels like a weird...I got this little bag of spoons that I walk around with, [chuckles], and I give them out throughout the day. I guess it could be anything in there, you know, objects. But, I don't know, spoons are interesting to me. STEPH: I think it's because this person who came up with the idea was literally having a conversation with their friend in a cafe. And so that was just something that was in front of them. And they're like, oh, I can use spoons to represent. Well, we'll have to double-check the article to make sure, but I think that's why spoons became the representation. So circling back to once you're in burnout, what do you do with it? And that is one of my questions right now. And that's what I'm trying to synthesize a lot of information around. Because once you're in that state, I don't know of a lot of great ways to help other than take time off because, at that point, you're in a crisis state. And you need to step away, and you need to find out how you can recover from having entered this state of crisis. So that feels really important to identify ways that once someone is in that state, that then we can help them. And that feels good. We can advise someone to take PTO. I still don't feel great about it in terms that then, as a manager myself, I don't really know of other helpful ways to then help someone through that period. So then I really started thinking about the fact that once someone is in that burnout stage, frankly, it's too late. We have let someone get to that point that now they are in that crisis instead of addressing it early on. So that is the other thing that's on my mind is one, how do we help people that are already in that crisis state? But then two, how do we start identifying that someone is starting to go in that direction? And then how do we help them tell us? How do we then triage those situations? How do we prevent them from getting to that burnout state? And that's where I've also found some really good content. And specifically, there is a podcast that I've started listening to called The Burnout Show. They essentially share their experience with burnout, and what they did about it, how they recovered from it, and then how they continue to fight it because a lot of people then still go back to the workforce. So then, once you do find a way to recover, then how do you go back to work? And there have been some really great episodes. And I'll be sure to include a link for it in the show notes. There's one particular episode with Grant Gurewitz, who is a guest on the show. And he speaks specifically to the strategy of Three Good Pockets. And this speaks to the idea that there are many things that we can't control in our day. It could be work, family, other commitments, but we can strive for Three Good Pockets of time where we focus on something that's just for us. This is time that's reserved for you and any activity that you find restorative or joyful. And each pocket can vary in size. So perhaps that first pocket is spent just reading a few pages from a book that you're enjoying, and then the next pocket of time is spent outside or calling a friend. And Grant also has a great suggestion around if you're worried that you'll get sidetracked and not actually step away, which I felt called out for that one because that one's definitely me. I will have good intentions, but then I won't actually take the break that I set for myself. So Grant recommends creating a list of restorative activities so that way when it is time for that break when your calendar is reminding you, then you have a list of these activities to choose from. So it makes it easier to say, okay, then I can do this for a couple of minutes, and I can truly step away from work and step away from my screen. But especially now, when so many of us when we're sharing our workspace with our restorative space, for everybody who is still working from home or working remotely, then creating those daily breaks are incredibly important to our wellbeing. And so, it has me thinking about what restorative activities can I add to my day? How can I encourage other people to add more restorative activities to their day? So I really appreciated that advice. And I have noticed that the idea of burnout, but not so much burnout specifically, I've been thinking of it as recovery and balance is a theme for me. And it is something that I am purposely choosing as a theme right now where I want to research and understand more of how we handle these situations and continue to make progress not just for myself but also for my team. CHRIS: I think finding that right cadence and structure and way to reinvest in yourself and ideally gain more spoons if that is at all possible or at least defend the spoons that you have, those all feel very meaningful. I do have a question. I'm interested in your thoughts on this. I feel like we hear about burnout a lot in our industry. I get the sense maybe that it is a more common thing. Like, I hear so many developers talking about how their dream is just to give up tech and go get a cabin and just farm in the woods or something like that. And I wonder, is it a more pervasive thing in our industry? So that's one question. Another is just an observation that we actually do work in a wonderfully...it's an amazing industry where being a developer, there are so many jobs out there. And I don't want to discredit anyone's efforts if they're earlier on and struggling with that. But broadly speaking, it is a developer's market trying to go out there and get jobs and extremely well-compensated, as a general rule. But does that come with this inherent burnout? And if so, which I'm not sure is true, I wonder if maybe we're just more vocal and maybe we actually share more in public. We have more blogs and podcasts and things like that. And that's just a common thing for developers, and so we hear the stories more often, whereas maybe in other industries, it is actually very common, but people are suffering in silence. But also I do wonder, our industry is still so young. The work that we're doing is changing constantly, and that churn and that working in the unknown maybe there is an inherent nature. So that's a bunch of pontifications off the top of my head. And I have no idea what the answer to any of them is. But I am intrigued because it does feel like the shape of burnout as a concept in the developer world is perhaps a little overrepresented, or maybe it shows up more than I would expect. And, I don't know, is the work that hard? I don't know. But then I hear these stories constantly, and I definitely have felt it myself, so maybe. STEPH: Yeah, maybe. Yes, I do think the work is that hard for the record. It's challenging work. I enjoy it, but it is challenging work between figuring out the tech but then also everything else that comes with that. I don't have anything to back this up, but I suspect that a lot of other industries are also experiencing burnout. And I just happen to be more aware of it right now because I'm hearing it more from my friends and the people that I work with. And I suspect that's more directly related to we all just went through 2020, and probably a number of us were trying to forge ahead and get through that time. And so there may be a lot of us that are just now dealing with those consequences of where we just pushed ourselves through a very hard time. And now a lot of that is manifesting and surfacing around really identifying the damage that we may have done to ourselves by just prioritizing work and trying to put our head down and get the work done even though there was so much happening around us. And I suspect that may be a contributing factor is that now people are really starting to recognize, like, oh, I feel this way. And maybe there's time for me to address it. Or frankly, it may not even be that there's time, but your body is just like, okay, I'm done. I made it through the past year or however many months, and I'm going to start shutting down on you. I've given you all the warning signs, but now we're here. We're at a breaking point. So I don't know about the other industries, but I do know the reason that it's more on my mind is because I'm just hearing it more from people, and they're just expressing it. And so, it has become more of a focal point for me, and I've experienced it myself more recently. I'm sure I experienced this back early on in my career, but I took a strategy of well, I'm just a junior, and I just have to get through this. And I have to build experience. For the record, that is not a healthy mentality. I'm just being honest about where I was in my life. And so, I didn't really stop to think about it, but perhaps it is becoming more normalized where people are having more open, honest discussions about where they're at. And if other industries aren't talking about this, I would love for them to. So to round that out a bit, this is something that is just very interesting to me. It's very top of mind. So I suspect I will be sharing a lot more content in future episodes that are just around this. How do we recover? And then how do we balance? How do we work hard without burning out? CHRIS: Work hard, play hard; those are the two placards that you have. Well, I look forward to continued conversations on all of those topics because they are sort of that's the story that underpins all of the work that we do. So I'm very interested to chat more about that. STEPH: Thanks. So what's going on in your world? How's your week been? CHRIS: Oh, my week has been fine. My topics are going to be way more mundane and tech-focused. But let's see, a couple of things, so one is that Stack Overflow has their I think it's Annual Developer Survey. And this year, the results came out, and there was an interesting standout, which was that Svelte was the most beloved framework, which was very exciting to see. Granted, you always have to take these sorts of stats with a grain of salt. But Svelte was 71% loved and 23% dreaded, which they give it as a ratio of how many people really love this thing versus how many people really hate this thing. And so Svelte, 23% of people who have used it are like, I hate that, but 71% loved, so that's a 48% net approval rating. Versus React which was 69% loved, 31% hated or dreaded as the word would be, so that's a 38% net approval. And then Vue, interestingly, was 64% loved, 36% dreaded for a 28% net approval rating. So, yeah, Svelte was decidedly winning in that. But again, the big grain of salt there is looking at the usage stats. React has 40% usage. So of all the respondents, 40% of the people responding to the survey were like, yeah, I've done React professionally, which is a wildly high number for a JavaScript framework. Vue was at 19%, so roughly half of React's usage, which I'm actually impressed that Vue is that high. And Svelte came in at 3%, so it's definitely still in the early adopter strong fan phase. So it makes sense that they would have this outsized high rating. I'm actually surprised that Vue wasn't higher than React, given that. Because I feel like more people are cajoled into React versus Vue can be more of a choice. And I would have expected this to shape out a little bit differently, but yeah, that's the story. STEPH: That's really cool. I liked how you described that as in the very early adopters' strong fan base stage. CHRIS: But nonetheless, the people that are using Svelte do seem to really like it; that's coming through in these numbers. And that definitely is my experience. I love Svelte and would love to continue using it for as long as possible. But really, I want a lot of other people to start using it. I want to really grow the usage base so that there are more libraries, and frameworks, and blog posts, and just mindshare in that space because I really do believe there are some wonderful ideas in Svelte. And it's just so straightforward to implement things that I just want more people hanging out. So that's one quick thing. Another quick thing is, I've been using a utility lately or a program called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX, and it is just fantastic. So I can capture a screenshot. I can capture a window. You can capture a GIF or a video. And then you can do little trims and annotations. And then it has this really nice feature where after you take a screenshot, it just hovers in the bottom corner of your screen and is easily accessible. So if you take a video, and then you want to upload it to a Trello card, it's just floating there waiting for you. You can actually dismiss it and push it down, but it's still peeking up from the bottom of your screen, and you can pull it back up, and you can have a couple of them. But it just really makes the whole workflow of grabbing screenshots or videos so easy. And I cared deeply about that because now that I have this tool, I'm all the more inclined to grab a screenshot or a video with just about every piece of work that I do. So it's going into pull requests; it's going into Trello cards. And it's so nice to have a utility that just really makes that as easy as possible. STEPH: I really liked how you mentioned that you can annotate because I often...I'm laughing as I'm thinking about this. When I am taking a video of something that I'm going to share with someone, I will use my mouse to indicate, oh, this is important. And so I circle around it and do silly things with my mouse to try to indicate but being able to annotate would be so much nicer. I know there is another tool that you're really excited about that I can't remember off the top of my head right now. Do you know the name of the tool I'm thinking of? CHRIS: Was it Loom? STEPH: Yes, Loom, because I also used that for a little while, and I've really enjoyed it. So I'm curious, how does Loom and CleanShot X stack up? Is one replacing the other, or are they complementary tools? CHRIS: Mostly complimentary. Loom is great because it hosts the videos, and you can also do audio capture, although I wonder if CleanShot has that as well. CleanShot also, I think, has a hosting thing. So I think there's a strong overlap in their functionality, but right now, I'm using both. And definitely for screenshots and things, CleanShot owns that end of it. And I think it's more likely that I could have CleanShot as the entire tool that I'm using. But I'm still using Loom for this is a walkthrough where I'm going to talk to you about a thing. I want to make it available at a URL that everyone can see rather than actually getting a GIF or MOV artifact file on my computer. So ever so slightly different, but I think of them, CleanShot X is probably the ideal one. But yeah, I'm still reaching for both. So the one other thing I did want to talk about is I have been expanding our use of the dry-monads within the project that I'm working on. And I've done some things. I did some stuff, Steph, and I think it's good. STEPH: Shtuff with Shteph. [chuckles] CHRIS: Shtuff with Shteph, yeah. I'm definitely pushing the envelope of how much we're leaning on these concepts within the app, and I continue to question it. I'm really intrigued to see what happens when other folks come into the project, and they're like, "Why can't I just get the value? It should be a string. Why isn't it a string? Why is it a string that I have to do a ceremony and a dance to get at?" And I'm like, "Well, because everything can fail, you know, like life." But what I have done here so dry-monads is the project that we're using, particularly their result type. So the result represents something that can either succeed or fail. And so we either have a success, which is this wrapper around the value that's successfully executed. So say we make an API call, we get back a response. If we get a 200 or maybe even a 300, then we get the data, and that's a success, or we get a failure and the error message. But fundamentally, we're modeling that in our system in a way that downstream from that, we have to basically determine if it was success or failure. So we're really encoding into the system; listen, pretty much everything can fail, so let's be careful with that. Let's be intentional and purposeful with it. But there is an interesting thing where these objects have fmap as a method on them. So fmap is a way to transform that wrapped value, but fmap works specifically on the success case. So if you make an API request, you get back the data. Everything's great. You can call fmap, and it will yield into a block that data. You can transform that data in some way, and then it will rewrap it up as a success object. So you can operate on this thing as if it has been successful. But in the case that it's a failure, it will just ignore that transformation because you don't want to transform the failure. It's going to be a totally different shape of data. So you want to separate those. We're getting into functors and monads here. So I'm going to handwave a bunch. But fundamentally, that's the thing that we're going for here. But we found ourselves really wanting to work with both sides. So we make this API request, and in the case that it succeeds, we actually want to transform and actually slice out a piece of data from the nested object that we get back. So that's one transformation that we want to apply on the success portion of the aisle. But then, we also want to transform the failure message. It turns out this backend is giving us very unfriendly error messages. So we want to take those and transform them into friendlier user-facing error messages. So it turns out we want to map both sides. And so I went to dry-monads, and I was like, what do you got? I want to know about this in the world. And it turns out they did not have anything. So I started looking into it, and it turns out this is a concept in the world of functors, specifically. Or, more specifically, I reached out to a former colleague, Sid Raval, a former thoughtboter as well. And he likes the functional programming stuff, so I knew he was the right person to ask about this. And he pointed me at bifunctors. So I found myself in a new space and category theory which I never thought I would explore a category theory in this way, but here we were. So a bifunctor basically is exactly what I was talking about where there are these two branches. In our case, it's either success or failure, but it allows you to operate on both sides, both branches. So the method or the function that gets applied there is bimap. So it's fmap which I don't know why it's f why that's typically what it's called. Success map would be a really great word in this context in my mind. So success map only deals with the success side, but bimap takes two different transformations, one for the successful outcome and one for the failure outcome. And it allows you to very directly talk about what you want to do with that. To be clear, dry-monads has a function called Either or Either, depending on how you want to pronounce it. And that takes two Lambda proc-type things because it's Ruby, and functions are kind of weird in Ruby. But it yields you either the successful value or the failure value, but then it doesn't rewrap them. So it's meant to be the terminal. You use that in a controller when you're either redirect or render or whatever it is you want to do. What I wanted was something for mapping, so staying in the success object or the failure object but yeah, bimaps. So I introduced my own extra wrapping layer. This is where things go off the rails, I think. We now have our own internal result objects. I thought about monkey patching for a while. I convinced myself monkey patching was a bad idea. Now that I've implemented as an extra layer of wrapping and I got the wrapping wrong like four times, or I kept recursively wrapping and re-wrapping, and there's a reason people aren't supposed to write these things themselves. But I think monkey patching may have been a better idea here, or maybe I should have never done any of this. We ended up with a stable working implementation and a nice test suite that covers it. But I introduced bimap and failmap as two different methods on our success object. And I did it by doubly wrapping the result objects. So we have our internal result, which wraps the dry-monad result. And I'm worried about that future situation where a junior developer comes on the team and is like, "I don't know what any of this is." STEPH: I love the weekly progression of I've done some things, and let's talk about it. And then seeing this glimpse into your argument with yourself as to yes, but we need it, and we want it, and it's not something that's defined. So let's go ahead and implement it. You ended on a high there where you talked about the fact that it is nice to work with. It does the thing that you'd like it to do, and it's well tested; I love that part. I'm deciding which thread to go with because there were a lot of interesting bits in everything that you shared. And I'm intrigued about the monkey patching as to why you think that could have been a better approach. Could you talk more about that one? CHRIS: Sure. So I ended up having to introduce the secondary object that then wraps the result. And so if you poke at that even a tiny bit, you start to see this like Russian doll nesting of it's our result wrapping a result, wrapping a value. And it's a burrito with three different tortillas wrapped around it. And if you want to add guacamole, you got to unwrap all three burritos. I'm sorry, this is a terrible monad joke here. [laughs] STEPH: For the record, if Taco Bell is not offering that, they should now, now that you've created that. [laughter] CHRIS: There is one, but there's usually cheese in between the layers. They're not just extra layers of tortillas, so that's what I've got here. It's way too much tortilla, and that's sad. You don't want that. And it's confusing. You're like, wait, does this one have two or three layers of tortilla? So when I was working on it and when I was implementing our additional wrapping layer, I tricked myself multiple times. And my test suite was telling me that things were working, but I was testing incorrectly. And I was like, oh man; this is very subtle. And even though I'm deeply immersed in the context here, I'm still struggling with this. So the question is, did I successfully encapsulate all of this? And now anyone downstream just gets to use it,, and everything will be fine. Am I the heroic programmer that made the perfect abstraction that no one's ever going to struggle against, or was that pain that I was feeling representative of the complexity of what I'm trying to do here, and maybe I got it wrong? And so then the monkey patching side is we've got this one layer of wrapping. What if we just monkey patch the result such that it's got these new methods? I'm not adding an additional layer. I don't need to deal with double mapping through multiple layers, and I just get to deal with the context that I have. So I did an initial spike of an implementation that way, but I talked myself out of it because #monkeypatchingisbad, but I don't know. I don't know where I'm ending here. I am happy with where we're at, but I am aware that I may be sad down the road. STEPH: I'm just dying over here [laughs] from everything you're saying. I have this image of you staring out the window thinking, am I the hero, or am I the villain? And figuring out who you are in this scenario with this abstraction that you've created. CHRIS: To be clear, it's raining, and I have a nice rocks glass of scotch in my hand. And I'm just wistfully looking out the window trying to determine what's true. That's pretty accurate, actually. That's pretty much what's going on here. STEPH: I think we're just going to need updates as it progresses along. CHRIS: I will say overall this paradigm...so failures can happen at all levels. These command objects, which are the core of where this is coming in in the application, really represent the workflows of the app in a wonderful, testable, straightforward way. So I love that part. And if I have that, it implies that I have to have this other stuff. I don't think I can get away from that. The other thing is I've always loved Gary Bernhardt's Functional Core, Imperative Shell, which is a conference talk that he gave a while back. I talked to Gary about it actually when he was on the show, and we can link to both that and the conference talk because they are fantastic. And I just love the way he thinks about software. But that was always a little bit abstract for me. Like, what does that actually look like, though, in say, a Rails architecture? And I didn't have a great answer. And now this thing that I'm doing is the closest I think to that where the innards of the system are almost functional even though it's Ruby. We're leaning into that. And so we have these command objects that take in some data, and then they operate on it, and they yield out these results. Did it go well, or did it not? We've got the railway-oriented stuff, which again I'll link to. I link to now every third episode, apparently, but here we are. And that just models the reality of these programs in a really great way. And then we've been trying to introduce some, not rules per se, but guidelines as to how we interact with these things. So inside of the core of the application, we're trying to be as functional as possible. We do transformations on these result objects, but that's it. And then it's only really in the controllers or the mailers that we are doing unwrap or deal with the actual nested value, but everything else is working on conceptual values or whatever it is…these result objects. And that's actually been really nice, and it's allowed us to have really nice error handling within the app. The logging is very straightforward. A lot of apps that I've worked on in the past, I've just silently thrown away many error cases or edge cases. And this is a really great way to sequence the work that needs to be done but never throw away data that you would want. And so far, I'm finding it to be really great. And I'm seeing very obvious ways to hook into it like, oh, this is where we need to find the user-facing error message versus this is where we figure out what we want to log. And so, in some ways, it's great, but I am still open to the idea that this was a terrible idea. I always remain open to that idea to be clear. [chuckles] STEPH: I love how that's the feedback that you're always open to it. You're always trying something new, and then you're constantly going back to revisit; was this a good idea or a bad idea? To go back just a little bit, I do absolutely love the priority and focus that you're giving to the failure state because I feel like that is an area that we, as developers we're very skittish of that failure state. And I realize I'm projecting here. So if you're listening, feel free to take that however you like; maybe it doesn't apply to you, maybe it does. But the failure state is like you said, it's life, it's important, and it's something that is going to happen. And it is something that we should make accommodations for. And I find that we're often very hand-wavy with a failure state. So I love, love how much you always prioritize the failure state and make that something that people can work with and understand. Versus then when something goes wrong, then that's when we have to start to understand the failure state. I recognize there's a balance there because you're not going to know the failure state until you encounter it, but there are ways that we can still optimize to have observability into that failure state for when we do encounter that failure. CHRIS: I've definitely seen that as an evolution in my own thinking, how much am I focused on how easily can I do the core thing, the happy path versus how robustly can I do all of the variations of what this app needs to do? What if the network's down? What do we do there? I do occasionally worry that I've overcorrected on that. And it's like, you know what? This thing that I'm worried about that I'm protecting against in the application is a 0.01% edge case. It's going to affect almost no users, and we're both putting time into trying to avoid it. But also, there's code complexity that comes from trying to handle all the different variants. And so there's definitely an optimization, and I feel like, at different points in my life, I've been undercorrected or overcorrected on that. But I think if I were to describe the arc of my career, it is desperately searching for that optimal path and trying to find exactly the right amount of error handling to apply, and then yeah, then I'll be happy, then it'll be great. But it is like when I look at DHH's classic 15-minute I'm making a blog, look how much I'm not doing, I'm like, sure, sure, sure. Show me that in three years, though. What does the blog look like? How easily can I add a new feature? What happens when there's a bug in production, and a user reports it? Can I chase it down? Can I figure it? Can I fix it? These are the questions that I care about now, almost to the exclusion of what's the first run experience like? I almost don't care about that at this point. Because I spend my time…six months and on that's where the hard work is. And so the first couple of months where you're figuring things out, that's not the hard work of this thing. And so, I'm very strongly focused on those later periods of time. But again, I'm open to the idea that maybe I am overcorrected there. STEPH: I think it does highlight more of a shift in our career. We're still building, but we have experienced the maintenance side as well, and we felt that pain. And so that has led to perhaps overcorrecting, or maybe it's the correct amount of correction. But I do like how you highlighted there is always a cost to each side and those are usually the questions that I'm asking myself when I'm thinking about the failure mode and how much I want to optimize for the failure mode is how much does it cost when this fails? Who's it going to impact? And how much does it cost for me to make this more observable or to address this failure state? And then I try to find the balance between those two. Because you're right, it's not free to address that failure state. And so I may not want to fully optimize to handle that if it's going to be a very small percentage of users that actually are impacted by this failure state, or it seems very rare this is going to happen. But then still finding ways to know that if it does fail, then I can say, "Okay, I'll come back, and now it's worth the investment to improve this." CHRIS: When you said earlier that this is really hard work that we do, I don't know that I believed you. What you just described sounds super easy. You just handle all the stuff, and you dynamically optimize for the needs at the point in time. And that seems easy. [laughs] STEPH: Super easy, yeah. [laughs] Way to bring it back. Well, speaking about observability and failure states, that does lead nicely into a bug that I was working on this past week where there was a particular page that was loading very slowly. And it was something that we'd heard from users that then they let us know that this page was either taking a very long time to load or, frankly, it was just crashing. And then they were never getting to that page. So I happened to be the one that then picked up that ticket. And I went to reproduce the issue, and sure enough, when I clicked on this particular link and then started counting, it took about 14 seconds for that page to load, which is a very long time. And then also sometimes it was just crashing. So the first place that I went was to our error tracking. So I went to New Relic to then look to see okay; maybe there's a slow query. There's something here that's creating this performance issue, but I couldn't find anything. And New Relic does a great job of breaking down all the different response times so I can see how long Postgres is taking, Redis, and Ruby. All of those looked very normal. I couldn't find anything that seemed alarming that was indicating that the page was struggling to load even though I could reproduce the problem. Because I was clicking on it several times thinking, okay, well, if I just do this a couple of times, New Relic's going to notice, and then I'll get to see something, a little breadcrumb that's going to lead me in the right direction. And while I was waiting for New Relic to surface something helpful to me, I mentioned to another developer the issue that I was triaging. And they said, "Yeah, that page has been getting progressively slower, and we don't know why." And I thought, ooh, okay, I'm intrigued even more now as this is something that has been escalating over time, and now we've hit this threshold that we're working on it. And I discovered that in New Relic, I can look specifically at Postgres, Redis, Ruby, all those different response times. But there's a browser monitoring tool that I had not used before. And it showed a lot of helpful information around first paint, First Contentful Paint, window load, all of those areas. So I started diving in and found session tracing, and it was there that then I saw New Relic was telling me, "Hey, you have a page that's taking about 14 to 15 seconds to load." And I thought, okay, I feel validated now that at least New Relic is recognizing this issue. I have seen this issue, but I still didn't know why it's occurring. So the next tool that I used that I don't know if I've used before or it's just been a very long time; it felt fresh in the moment, but it's the Chrome DevTools, the performance tool. And so you can open that up in your inspector, and then you can go to the page that you want to track the performance. And then you can essentially say, "Hey, go ahead and start profiling and reload this page." And it has so many stats when it finally does load. It has CPU flames charts, which essentially it visualizes a collection of all the stack traces. It has a film strip, so you can actually see the rendering progress of your website along different time points. So if you wanted to go back to a specific time, you can see what did the webpage look like at this point? And then if you go a little further, okay, how much was loaded at this point? So there's a lot of interesting and a little overwhelming information that's there. But the thing that did catch my attention is there's a chart. I don't actually know what this chart is called. It's not a pie chart because there's no center to it. So it looks like a donut chart, and it's broken down. And it shows you the loading times, scripting, rendering, painting, all of those different values. And the rendering time was taking 35 seconds. And I was like, ooh, okay, that is meaningful right there. So then further investigation, now that I knew what I was looking for, I wasn't looking for something more on the back end. I was looking for something more on the front end. And I didn't think it was necessarily JavaScript because we also have JavaScript on this page. So at least this was helping me get a little bit closer before then I went into the codebase to start seeing what's happening. So once I knew it was a rendering issue, I went to look specifically at that view, and we have a form on that page that was generating an empty HTML select option for every record that's in the system. So let's say that you're ordering from a restaurant. On this page, there was a form where it had a list of all the restaurants, and, in our particular case, we had about 17,000 restaurants. So there were 17,000 empty HTML selection options, which could have some significant impact on the DOM and page load time. And that was the piece that was really leading to the performance, is the fact that we were rendering that empty select option. So from there, it was then just triaging okay; we don't really need to render all of these restaurants. There are ways we can scope this down. And that way, we're only showing a little bit at a time versus creating all of these empty options. I should clarify they're empty because part of this form is you select from the first dropdown, and then it populates the other one, and it gives you more information. But the way that this form was implemented, it was actually trying to show all of them at once. But it didn't actually have the data yet, but it was doing like a restaurant.all type of count. And so then that's how we were getting that many empty options. So it was a very interesting journey. It was very helpful to learn that New Relic has this browser monitoring tool. And I really appreciated their performance tool. And circling back to Chrome, Safari may have something similar. But I found Chrome's performance tool very helpful because then it helped me realize that it was the rendering. And so then I could really focus on the markup and the view versus knowing it wasn't more in the database layer. CHRIS: I really love the description, almost like a mystery novel of these bugs when we encounter them. Because if you just get to the end and you're like, oh, I was rendering a select, and it had all of this, that loses so much of this story because again, the coding is not the hard part of the work that we do; it's the figuring out what needs to be done. And in this case, that journey that you went on to find the bug. I really like the point where you said, "And someone mentioned this page has just been getting progressively slower over time." I was like, ooh, that's interesting. Now we got a clue. Now we've got a lead, and we'll chase it down, and then finding the browser tools and all of that. And also, as an aside, browsers are just such an immensely impressive piece of technology, everything that they do. And then you add the DevTools on top of them and magical stuff going on there. But yeah, also probably don't render 17,000 empty selects. [laughs] That seems like it will get you in trouble pretty quickly. But also very easy to get to and especially if there is this incremental, slow creep over time where it's like, oh, that page seems like it's a little slower. It's a little slower still, and it just keeps creeping up over time. But yes, I appreciate you taking us on that journey with you. STEPH: Yeah, it was a fun discovery. And it made me realize that while we have alerting set up for some of our other queries, we don't have anything set up for the browser time. So that would be a good optimization on our side is to start alerting us before a page gets to the point that it's taking that long to load to notify us sooner. So we don't have to wait for a user to reach out to us, but we can triage sooner. CHRIS: I also do love the idea of extending the metrics that we hold ourselves accountable to all the way through to the user, and so the First Contentful Paint and all of that. The one that I really love recently that has captured an idea that I struggled to put words to is the Cumulative Layout Shift. Are you familiar with this piece? STEPH: Uh-uh. CHRIS: So there's like, how quickly does the page render? That's the thing that we want to know. But a lot of applications these days, particularly single-page apps, render pretty quickly, but they render what ends up being a skeleton or a shell of the page. And then behind the scenes, there are like ten different AJAX requests happening. And as the data comes in, suddenly, a part of the screen will render. And they'll render a list of items that they just got back from the back end, but they're still waiting for the information to populate the header. And so if you look at that page, it's constantly shifting as it's loading and just feels, I don't know, flimsy in my mind. But I didn't have a good word, or I didn't have a metric or a number to attach to that. And then I learned about Cumulative Layout Shift, and I was like, oh, that's the one. Now you've mapped the thing that I was feeling. And I like when that happens. STEPH: Is that the difference between the first paint and First Contentful paint? Is that similar? CHRIS: I think it's more than that because there are not just two discrete events in this. It can be multiple. And so it's like, how many different times did the thing that's rendered on the screen move around? And so if images are loading, but you didn't have a proper image height and width set, that's another way that this can happen. Then initially, the browser is not going to reserve any space for that because it's like, I don't know how big this is. And then, when the image shows up, it now knows the intrinsic height and width of the image. So suddenly, your page is going to jump from that. You can get ahead of that by putting the height and width on your image, and that's great to do. And frameworks like Next.js have done some really amazing work of making that a build time step as opposed to something you have to do manually. But then also, more generally, how do we handle this? React is doing some interesting work with Suspense, where you can aggregate together multiple different loading states into one collective thing. It's almost like promise.all, but for your page. I haven't followed that too closely, but I know that that's framework-level work that's happening over there. GraphQL does a really great job of allowing you to group queries together. So there's a solution on that side. But broadly, if you just render some HTML on the server and you send it to the front end, then you don't have this problem because you just have one ball of HTML. The browser is pretty good at rendering that in one pass versus if you have single-page applications that are making a handful of AJAX requests that will resolve in their own timelines and eventually paint to the screen. You get this different shape. And then the worst case of it in my mind is you render half the page. And then suddenly, one of the requests realizes the JWT has expired, and suddenly, you get thrashed over to the login page. Please don't give me that experience, developers, please. Please do something else that isn't that. That makes me sad in my heart. STEPH: Prioritize the failure state. That's what I'm hearing. CHRIS: Callbacks. STEPH: Well, on that wonderful circular reference, shall we wrap up? CHRIS: Wait, I thought circular references were bad...Never mind. Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed, or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Why we

The Changelog

Play Episode Listen Later Jul 21, 2021 44:56 Transcription Available

On this special edition of The Changelog, we tell Vim's story from the mouths of its users. Julia Evans, Drew Neil, Suz Hinton, and Gary Bernhardt join Jerod Santo for a deep and wide-ranging discussion about “the best text editor that anyone ever wrote.”

Why we

Changelog Master Feed

Play Episode Listen Later Jul 21, 2021 44:56 Transcription Available

development code software hackers programming open source software engineering vim changelog julia evans gary bernhardt jerod santo suz hinton

300: Mozzarella Sticks & Knowledge Silos

coding dogma tdd stocker clean code test driven development tdd gary bernhardt

Play Episode Listen Later Jul 13, 2021 45:08

The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio... They then, together, answer a listener question re: knowledge silos: Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed. inertia-rails thread safety (https://github.com/inertiajs/inertia-rails/pull/70) Rails Cache-Control no-store fix (https://github.com/rails/rails/pull/40324) Transcript: STEPH: I have no shame. CHRIS: That's important in this industry. STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we learned along the way. Hey, Chris. So today's an exciting day. It's a rather momentous day, at least in my world, because today is our 300th episode. CHRIS: 300? That is incredible. STEPH: That's an incredible amount of episodes. And it made me pause and reflect on how many episodes I have been a part of. And I've realized it's over 100. I think it's around 104 or something like that, and I can't believe it. Time flies when you're behind the mic. CHRIS: Time does fly, yeah. So yeah, fully a third of these you've been involved in. I don't know what the number is. And I'm just so grateful to Derek Prior and Sage Griffin, who started this whole process. And then to Thom Obarski, who was the producer for so long, and Mandy Moore, who recently joined us and has been doing a wonderful job of carrying that forward and to you, Steph, because this has just been such a joy to work on. Yeah, it's just a joy to be on the show and to get to chat with you each week and share some things. And frankly, learn from folks writing in questions and sharing pointers with us, and it really is such a delight. And yeah, 300 is pretty momentous. STEPH: The listener questions and feedback have undoubtedly been a highlight for me. That is one of the areas that I love the most. I love the questions. I also love when people provide helpful answers to us, and then they help us out in return and also, all the incredible guests that we've had on the show. It has been phenomenal. I'm also very thankful to have been part of this journey and appreciate everyone that has got us here today. I wonder what the fourth iteration of The Bike Shed looks like. I consider this the third iteration because the first iteration was Sage Griffin and Derek Prior. The second iteration was where you took over The Bike Shed, and then you were hosting a number of incredible guests on the show. And then the third iteration is the iteration that we're living, so I wonder what the fourth will look like. CHRIS: Oh, that is an interesting question. Hopefully, you and I get to hang out for a good bit longer. But at some point, much like the Green Lantern, this will get passed on, and someone else will take up the mantle and tell some stories. But, yeah, hopefully, that's not too soon because I certainly enjoy hanging out with you. STEPH: Oh, I agree. I certainly enjoy this, and I'm in no rush to leave The Bike Shed. But I think it's just fun thinking about the next people that will carry this journey forward. CHRIS: And determine the color of The Shed. STEPH: And determine. I mean, that is their right. As host and co-host, they get to determine the color of The Shed. CHRIS: 300 episodes in, and we still haven't figured it out. So I guess we got to keep trying. STEPH: Oh, I have. I already know what color it is. CHRIS: Is it yellow? STEPH: It's yellow. CHRIS: Yeah. Okay. [laughs] STEPH: I like how we said yellow at the same time, you know. [laughs] CHRIS: I do, although I feel like it's wrong to have a color in mind, or at least I want to dig in and talk about it for a while just to be in keeping with the show, but... STEPH: One must first argue before deciding and then argue again. But to not continue bikeshedding on The Bike Shed, what's new in your world? CHRIS: My week has been good. Actually, I have two quick updates on various Inertia things that I've shared in previous weeks. So we can include a show notes link for the two different episodes where I talked about these respective things. But there was one weird issue that I ran into with Inertia where it could start clicking a button that would delete, was behaving weirdly and occasionally, intermittently; some of the responses would end up as a full HTML page response as opposed to the expected Inertia response. And there's a bunch of subtlety around this. I actually reported it as an issue to the Inertia team. And they very kindly pointed me to the HTTP semantics at place. So it's the difference between a 302 redirect and a 303 redirect. And so, in their code, they were correctly doing a 303. They were standards-compliant; everything was great. But for some reason, it was still misbehaving sort of randomly, and I could never pin it down. I ended up working around it and opting out of Inertia behavior for those endpoints. But my assumption was that something in my Rails Middleware Stack was behaving weirdly and occasionally overriding Inertia Rails' setting of the status. So Inertia Rails was saying, "303," which is a special version of redirect, and something else in the Rails Middleware Stack, was saying, "302, it will be fine." Turns out, in retrospect, the Inertia Rails team has discovered that this was, in fact, a threading bug on their side. So it's not Inertia's fault. Inertia as a core concept and as a protocol was definitely doing the right thing. And the Inertia-Rails Middleware was attempting to do the right thing. But threads and concurrency got in the way, which I'll be honest, I don't deeply understand those concepts. So I was just like, oh okay, that sounds like a thing that could go wrong occasionally, which is exactly how I experienced it. But now they've made an update to the project, so that should be resolved in a deep way. But goes to show you threading and concurrency are really tricky to chase down. STEPH: I appreciate that you're coming back to give us the conclusion to that issue because I remember talking about it, and you were still going off on a journey and finding out what's wrong, so that's super interesting. And yeah, threads and concurrency those are super easy, like cache invalidation and naming, that's right up there. CHRIS: It's actually kind of funny. One of the issue threads where I wrote about it, someone followed up and asked if I'd come to any solution. And I said, "Oh, I've gone kind of this weird way, and I'm doing these things." But I shared a code sample, and I said, "Just to be clear, this is 100% about something Rails is doing and not Inertia, which remains a stellar project." And then, very shortly after that, someone from the Inertia-Rails team was like, "Ah, actually, I think it was us. Sorry about that, but we fixed it now." And I was like, "I still love you guys. This is great. You're doing a great job. [chuckles] You continue to push the envelope in a wonderful way." But it was a funny interaction where I was like, never shall I let the name be dragged through the mud. Whoops. Okay. Never mind. STEPH: You're an excellent hype man for Inertia. CHRIS: I try, I really try. I believe in it to my core. And actually, there's another one that this one's not really related to Inertia at all, although I've seen it discussed within the context of Inertia. And again, I think the Inertia team has done a really great job of responding and pointing to here are the HTTP semantics, and adhering to the standards, and the way that things should work. But this one has to do with the back button. When you're doing sequential forms or really any sort of form type thing, the browser will just pull from its back/forward cache, which is a local cache of the HTML of the page as it just had it. And I had come to the understanding that this was not something that I could workaround. This was not something that I could control. I had tried every combination of headers, at least I thought I had, in Rails to try and control this from the server-side because ideally, the server is the one who knows about when data is changing and things of that nature. The server should be able to inform the browser, "Hey, don't cache or store this page in any way, always revalidate it." It turns out there was a bug in Rails that was improperly normalizing the Cache-Control header and always removing the no-store Cache-Control value. So there are like five different or a handful of possible values that can be set for that header for the Cache-Control header. And Rails has a bunch of internal logic that says, "Okay, if you've set this, then I'll put these two, but not that one." And they're just trying to manage it and do nice things on our behalf. But unfortunately, they were being a little overzealous in that normalization effort. And so they were dropping an important value, which is no-store. So now there's a PR opened in Rails, or I think it's actually been merged in at this point that will fix that and allow you to set that particular header value, which then should get the behavior of "Hey, browser, if I hit the back button, please go ask the server. Don't trust your local cache, “which is exactly what I want. STEPH: Interesting. Wow. So that's two very helpful resolutions to some of those strange issues you were running into before. CHRIS: Yeah, definitely. And actually, for that issue, in particular, it was a very kind Bike Shed listener; Alexei Vasiliev wrote in and shared some initial thoughts, pointed me in the direction of some things. In that case, I actually was like, "I don't think that's the case. I tried it." And he was like, "No, no, no, pretty sure." And he was definitely correct in this case and was very kind and gave me an example of code reproduction and all of those nice things. So I was able to chase this down and then eventually find the issue in Rails, which had been opened like eight days before. So I think for me, I just happened to run into a weird period of time where Rails was subtly broken around this behavior. And therefore, I determined that the world was broken when, in fact, it was just a tiny slice of Rails' history. But yes, thank you so much, Alexei, for writing in and pointing me in the right direction on that. STEPH: The dream came true. We talk about some of our troubles and our strifes, and people respond and help us out. CHRIS: That is the dream. But yeah, so those are some quick updates, not really about me, although tangentially, I got to go along for these rides, and it was fun. But what else is up in your world? STEPH: Let's see. Well, I also have a small update that I can share. It's circling back to the conversation that we had talking about extracting an untrustworthy service to a new location. And at that time, I don't remember exactly the process I laid out. But at that time, it's the idea that it is a bit untrustworthy, but we have some security in how this process works, and it is ideal that we move it to this other location. So let's just go ahead and move it wholesale, bugs and all to the new location. And then there, we will start to refine, and we'll start to improve the service. Well, the update is that we have realized that the untrustworthy service is untrustworthy enough that I'm actually working on improving it in its current place just to a certain extent that then it feels like we can move it to another location. There have been enough issues with it that it has taken my focus to continue patching those bugs and making sure everything is working appropriately. But now I'm in the space of where I'm like, goodness, I thought I knew this thing and now I'm realizing I don't. And so, I'm looking for ways to inform myself and the team when something isn't working when we think it is. So to provide a bit of context, this service is sending a bunch of messages to other systems, and most of the time, that is working, but there are times that it's not. And when it's not working, it's silent about the fact that those messages aren't being sent, and it's very important that we send those messages. So what's been on my mind is looking for a way to then elevate myself and the team to say, "Hey, these are the number of messages that are being sent on average." And then suddenly, let's say it dropped by 50%, or maybe we typically send 98% successful messages, and we have a 2% failure rate, but suddenly we have a 50% failure rate, but looking for those metrics that I can capture and then alert the team if something is going wrong. And one of the suggestions that was bubbled up by Chad Pytel, who's a developer, he's also founder and COO of thoughtbot, and we're working on the same project together. And he had highlighted that a previous project that he worked on used AWS specifically to leverage the idea of tracking how many successful messages are being sent, or perhaps in their particular project, it was focused on how many orders were being processed. That was important to know. And in our case, we could do a similar metric where we look to see are we still sending messages? Has the number dropped significantly lately so then we can be notified, and then we can escalate that to PagerDuty? So then we notify the team that something's going on. I don't know the specific mechanics of how I'm going to implement that yet. So I will report back, but I'm excited to have something that's going to alert me for when things aren't working the way I expect versus waiting for then someone that's a customer to notice it and then get back to us. It's very in line with a number of the topics that you've brought to the show recently, talking about how we can measure more of the user's experience and be notified sooner versus waiting for a user to bump into an error and then they reach out and notify us. CHRIS: I'm super interested to hear where you get with that because that's definitely an area that I've poked at but not dug into particularly deeply. I know there are a number of projects like StatsD is one of them. I think there are others in that space, but that's where you're sending metrics just out to some service, and then you can aggregate and graph. I've also done similar things with Papertrail; I want to say, where you can do a very specific search in the logs, and then within that, you can aggregate and graph and show things over time. So you can do a very simplified version of what you're describing to sort of visualize a rate of something over time. And then I think they might have some thresholding alerts. But also, that's one of those super hard things to do because it turns out like Monday morning, a lot of emails get sent and then Friday afternoon, fewer, and then on the weekend, none. And so, there's going to be an inherent sort of fluctuation to the data. And so then what is normal? What does the baseline look like? And then how do you do anomalies around that? Because inherently, there's going to be noise in the data. And so is it a 10% band around the normal? And I'm just saying a lot of words now that I barely know the meaning of. But it's one of those things where it's like, oh yeah, just let me know if it's behaving abnormally. There's so much in that one little sentence. And it's one of the like; I love the fractal complexity of this space where every part of that sentence that I just said is like, oh, that's way more complicated than it sounds when you just say that word. So very interested to hear where you get with this. And this is also something that I'll probably be pushing on in my work in the near term. So maybe we can even compare notes, but as of now, I just have, I think, buzzword-level knowledge of it. STEPH: Well, I love that phrasing fractal complexity because yes, that was also where my brain got hung up in starting to think about this process and like, well, what's normal? I don't actually know what normal looks like because I haven't been tracking this until now. So do I go back a week and say, "Okay, let's compare our average sent rate to in the past week and try to define normal in that timeframe?" And I think the answer, for now, is to do the smallest thing but also has the biggest impact, and that's to notify the team if messages just stop. That feels like the first, small step to take, and then we can fine-tune. Do we want to know if suddenly successful messages are being marked as a failure? We have an increase in failed messages versus successful messages. But I think the first iteration is just to know or to confirm that we are sending messages and send us an alert if suddenly we're not sending messages for...ooh, I just realized there's a complexity in that statement too. It's like, how long are we not sending messages for? Is it for an hour? Is it for a day? CHRIS: I was going to ask. [laughter] STEPH: I just caught myself there. Yeah. I don't have an answer to that right now. I have to think about it, but there's an answer there. I will have to choose an answer. CHRIS: You sure will. And then you'll probably have to tweak it over time. It's also one of those topics where false negatives and false positives are really easy to fall into where the system's alerting too often. And so people then start to ignore the alerts versus it's too cautious before it will send out an alert and, therefore, you're missing things and so finding that optimum level. It also might be different days of the week. Aah. [chuckles] STEPH: Yeah, I think that's very true. It will be different for different days of the week. So I have a lot more to think about in regards to how we're going to report on this. But that still feels very much like something I want in the world because right now, it's a lot of spelunking and production consoles to find out what's going on with the data and making sure that it's going through. And that feels like the least favorable option as to the world that I want to live in. Oh, on a completely unrelated topic, I saw an article that I'm very excited to read. And it's not related to technology at all, but it looks like a very delightful article that someone wrote and titled My 14-Hour Search for the End of TGI Friday's Endless Appetizers. And I haven't read it in-depth yet, but I just read the first bit, and it seems like it's going to be delightful. But I thought of you because we've had previous outtakes around mozzarella sticks. And you were very excited when you thought thoughtbot had mozzarella sticks, the actual fried kind versus just the healthier cheese stick kind. So this seems like a thing that you'd enjoy. CHRIS: I feel like it may have even ended up in an episode, and we talked about mozzarella wedges and the ratio of surface area to volume. STEPH: Yes. CHRIS: I don't know if that made it into an episode or not, but we have definitely you and I discussed mozzarella sticks before. And I'm definitely intrigued by this article. I will add it to Instapaper immediately and then probably never read it again because Instapaper is where I put things to forget them. But maybe someday I'll sit down with a coffee and read things. STEPH: I've heard you mention Instapaper before, and I've looked into it. And I don't know why, but it just hasn't stuck for me. So I always throw anything that I want to explore or something that is also critical for me to do. I use Todoist. I don't know if you're familiar with that app, but that's my go-to. CHRIS: Well, I'm familiar with Todoist. I take a slight line between my to-do list, which I want to be as, I don't know, clean and tidy and only the things that I have to do versus for me, Instapaper is a list of when I get around to it when I've got those ten free minutes, which apparently don't exist in the world. But when I have them, this is the list of things that I can read. But I think I've heard this from a number of people of having a more integrated system that all the stuff's in the same place. I keep my to-dos in Trello, also as an aside, and I'm not super happy with that. How do you like Todoist? Is it bringing you joy? STEPH: I really like Todoist. I find it is simple enough an interface that I'm not spending a lot of time customizing it or messing around with it. I can just go there and log the things that I want. I can create individual projects and spaces as well. So if I want to separate my personal to-do list from my work to-do list or if I have a project, that's a really nice feature as well. I think my only small complaint is if I'm writing a date or if I'm writing tomorrow, Todoist will try to do the smart thing and say, "Oh, I'm going to add a due date for you since you mentioned a date." And I'm like, no, no, no, I don't want a due date. I just want to mention the specific date because somehow it's relevant. And undoing that is sometimes a little tricky. But otherwise, I have found Todoist very helpful. I'm a big fan. Also, you and I are slightly different creatures in terms of how neat and tidy we keep our spaces. I think how we both manage our email inbox is a really good indicator of this where you are more organized than I am when it comes to emails. And so, our to-do list might be similar. I'd be interested to see if Todoist fits your needs or if it doesn't offer enough structure. CHRIS: I almost certainly could make it work. And it's one of those things where I've actually settled on Trello, which is a very loose tool. And so I've been able to shape it sort of to what I want, but it doesn't really have that many true productivity-type features. It's just a loose board where I can drag around cards and move them through. And that's worked fine, or I've been able to talk myself into not trying to be as neat and tidy and intentional with my to-do list, which I think has been good overall. I've looked at Todoist in the past. And the thing that gives me pause sort of related to what you were talking about with the date things, but I get the idea, or I get the sense that Todoist really, from a fundamental philosophical approach, really wants things to have dates and to have priorities, and my thinking is not quite that. Like, there is a priority, but it's relative. So it's the order of things in a list, but it's not this is a one, and this is a two, and that's another two. I find that logic of like there are different tiers of importance doesn't really map to my world, nor do dates. Almost everything I do has no date, has no context. It's just like when I'm at the computer because that's the only place I ever am. So it's when I'm at the computer, it's all kind of important-ish. Nothing really has a date, but it should probably be done pretty soon. That sort of stuff doesn't quite map to what I see in Todoist. So I've always found a little bit of a mismatch between what I think I want and what Todoist, as far as I understand, provides. I know they added Kanban-type boards recently. So I think that might help with just visualizing workflow and being a little closer to Trello, which I'm familiar with. But I'm sort of on the search right now for another to-do list. I like what you said about being able to separate the work and personal because that's definitely a thing that I would want, although there's always the added complexity of whatever tracking tool that we're using as a team at work and which things go into my list versus that list. And do I try and synchronize them in any way? And then I do what I do, which is I start to imagine this ridiculously complex, fully integrated, bi-directional sinking nonsense system where like, never mind. Stop it. Pen and paper, Trello. I don't know; you've lost your privileges, though. This is me talking to myself. I lose my privileges much like I'm not allowed to ever try Emacs. I have had a multi-year moratorium on exploring new productivity tools, but I think maybe, just maybe, now is the time to revisit that. STEPH: If you ever disappear for a week or two, I'll know that you tried Emacs or something like that happened CHRIS: [chuckles] My beard is three times longer when I come back, and I'm like, "All right. I figured some stuff out, though." STEPH: I'm with you in regards to trying to bucket all of your to-do items as if it's a priority one, two, three. I am not good at that, and I'm always wrong. So I've also given up on that system. I would describe myself as a minimalist user. I'm using all the basic functionality. I'm not leveraging what a lot of stuff that Todoist probably can do for me. And so I have a very just flat list of things that I'd like to do. I do have a couple of projects because I do try to have that personal versus work, and maybe I have some other project that's on there as well. And then, in my mind, I try to avoid due dates unless it's really important. Although I say that if it's really important, it's going on my calendar too because I'm going to budget time for it or make sure that I don't forget it. But then each day then I go through that full list, and then I pick the things that need to be done that day or it's reasonable to get done that day, and then I kick everything to the next day. So that way, I'm always reevaluating a fresh list of what do I need to tackle? What's reasonable for today, and what can I punt on? And Josh Clayton said this to me before, and I really liked it in terms of punting on work because typically, when you're really busy, something's always going to drop. You're always going to push something to the next day. So then it's just figuring out what's going to bounce and what's going to break? So I'm always looking for what's going to break? And let's prioritize that for today to make sure it gets done. If it will bounce, then I'm going to kick it to the next day, and I can't see it until I'm going back through that full list again. CHRIS: I really like that framing around you're going to have to drop things. That's just the nature of life. There's always more to do than there is time. So will it bounce, or will it break in that? And that framing around how to decide which things get moved out. Interestingly, I just looked up because I wanted to know does Todoist support snoozing things? Which is something that I use constantly in Trello and Gmail and basically everywhere else. I'm just like, nope, future me problem, future me problem, and I just keep pushing things into the future. But critically, I want them to be hidden until that time. And it sounds like Todoist; you can set a future due date, and then it'll show up in today. But again, that's sort of conflating how I think about productivity and whatnot. Also, I found…this is a Reddit post that I'm looking at where I'm determining this. And there is the question, and then there's someone answered, but the answer is deleted. And then there's someone replying to that saying, "Wow, what a thoughtful response. Have you written this up anywhere else, like a blog post? You sound like an absolute pro." But the parent comment, which apparently was beautiful, and articulate, and well-written, has been deleted. And this is the sadness of the internet. So a really beautiful xkcd about the saddest thing you can see is you search for a question, and you find Stack Overflow from 10 years ago one person asking the question and no answers. And you've got one other person out there in the world who cares the same way you do, but you have no answers, and it's sad. But I'm just sad about the loss of information. STEPH: That's so tragic, or that's a really pro troll move. And you leave a comment, and then below, you're like, “Wow, that was amazing. That was beautiful.” And then you delete your own previous comment. So then you're just tricking people into thinking there was an answer. CHRIS: It does sound almost performative, especially the last line, "You sound like an absolute pro." So I could see that being the case. And you know what? I'm going to choose to believe that that's what it is because then I can sleep better at night. So thank you, Steph. STEPH: Happy to help. CHRIS: But I think we should probably move on to perhaps a listener question or something. But before we do that, I do want to ask if anyone out there has a to-do list that they're using and they love; I would love to hear about it. I think I'm familiar with most of them, but votes of confidence from the listeners of this show will certainly go a long way with me. Because I think you folks are all very smart people. I mean, you're listening here, so, obviously. STEPH: Yes, obviously. This very deeply intellectual show about mozzarella sticks and the ratio of cheese to fried and what's the best. CHRIS: It's an important question. STEPH: It is an important question. I have strong feelings about it. That's why we've talked about it. [chuckles] CHRIS: On this very serious show that we host. STEPH: [chuckles] Yes, we have an awesome listener question that I'm really excited to dive into. But before we do, I have a quick git thing that I'd love to share. It's a tip that Dimitry, another thoughtboter, shared with me today that I think is just really nice and something that I have not used before. And it's specific to a workflow where if you need to grab a file from another branch or from another commit, and then if you want to bring it into your current branch. And there are a couple of ways to go about it. One of them is you can do git checkout main and then pass the file presuming the file that you want is in main and then you want to bring it to your current branch. And that will copy over the file to that exact location. But if you wanted to grab a file that's on the main branch but then you want to port that file to a new location, then you can use git-show and do git show branch. So let's say you're bringing a file from main over to your current branch, so it would be git show main: and then pass to the file that you wish to copy, and then the greater than sign and the path to where you want that file to live. So you can grab that file and then stash it in a new location, and you can also do it for commits too. So if someone has pushed up a commit and you want to copy a particular file, say if you need to bring in some of their work into your branch, then you could also do git show commit, and then that colon, and then the path to the file. And then, if you wanted to move it to a new location, you can use that greater than sign and then the path to where you would like that file to live. So it's a nice combination of the git command of git show and then also shell redirection. So then, you can pipe that content from the file that you wish to copy over to the new location that you would like. And it's not something that I've reached for very often, but I find lately I've been in a mode where I'm trying harder and harder to stay within my terminal and not have to jump over to GitHub or to external UIs if I can. And so this just feels like a nice additional tool where then I can use this one more thing where I don't have to either...I guess it's small. I could check out main locally. But even with this way, I don't have to switch branches, grab something, and bring it over, or I don't have to go to GitHub and then look for something. It feels like a nice way that then I could grab that file locally and bring it over to my branch. CHRIS: That's a nice combination of tips there. Like you said, a bunch of different pieces at play, but that is definitely a super useful thing. It's one of those that I've not gotten that into muscle memory yet or even close to muscle memory. Git is complicated in terms of the interface that it provides, at least at the command line. I've been trying to make sense of it all and then trying to find what are the useful workflows that I want to build? Because you can do anything, and you can do most things in five different ways. And so finding that set that you do want to know deeply but then also getting that committed into your hands, not even into your head, is the thing that I strive for. But that particular one is one that I struggle with every single time. So especially, I think you broke that down really nicely, so it makes sense. There's a corollary in Fugitive for any Vim users out there. There's a Gread command, so it's capital G-re-a-d. And then after that, it takes some identifier, and I've never gotten the identifier right. But as you just described it, it's the same as the git show sequence. So it's a commit or a branch name, colon, and then the file path that you want. And then, in Vim, you can use % to reference the current file. So I've tried really hard to teach my brain Gread main :%, and somehow, my brain doesn't want to remember that ridiculous sequence of characters. So, only in this moment am I like, oh, it all kind of fits together. STEPH: Oh, that's nice. I am a Vim Fugitive user, but I didn't know that one. And I'm with you; I rarely remember all these off the top of my head unless I've done them like a hundred times, and it finally starts to sink in. So I always have a cheat sheet, or since we were talking about tooling earlier, I use Notion to capture tidbits for myself. So this is a place where I would probably stash in a web development folder that I have. And it's just a tip to my future self as to like, hey, remember when you were trying to do that thing, and then you had to look it up and figure it out? Well, here's how you did it, so then I can revisit it in the future. CHRIS: I thought a number of times about introducing a flashcard system to revisit these sorts of things. Gary Bernhardt, who I had on a while back now, is building a platform that does this essentially for TypeScript and regular expressions in JavaScript arrays and a bunch of different topics. But it's got built into it the idea of spaced repetition, so you review a thing and then three days later, you review it again and then seven days later, and then ten. And there's a particular sequence to it, but it helps you to really internalize that knowledge. I've never gotten to the level of going to that, but I like that idea of being purposeful and trying to commit some things to memory because having them at your hands and being able to stay, like you said, in the terminal and closer to the work and not having to break out of the context, I do find a lot of value in that. But it does take some effort to build that up. So I've never quite gotten to that flashcard system myself. STEPH: Yeah, that's interesting. I think I have mixed feelings about it because, on one hand, it is nice to commit some things to memory. And on the other hand, I'm totally cool with having a way to organize stuff so I can easily search it and find it later and not use up memory space for something that I don't use that often that then I just can't commit it. So I could definitely see it being useful. But I'm also okay with just having a nice way to search for it. But pivoting a bit and circling back to the listener question that you alluded to earlier, we have a listener question from Jen and Jen wrote in about knowledge silos across different projects. Specifically, Jen wrote in "Hello, Steph and Chris, first of all, I want to say that I love to listen to your podcast for multiple years now." That's awesome. Thank you, Jen. "I like how you both share things along your week and fill the discussion with so many useful things and findings. Our team, which consists of three pairs, is currently working on two different projects. And due to that fact, we are creating information silos. Now we are looking into ways into how we can minimize those information silos. And do you have any ideas for how we can achieve this? Some additional context, switching pairs we're unsure about as this will be difficult for the new person to get up to speed. And currently, we are thinking about having a mob review session. But of course, with those, you only get a limited overview." All right. Well, thank you, Jen, for the question. I'm excited for knowledge silos because, I'll be honest, I am guilty of this one right now. I am a bit of a knowledge silo on my current project if we're telling our truths here on the show today. CHRIS: Steph, I thought I knew you. STEPH: You know, I'm full of surprises. CHRIS: Aren't we all at various times? This really does feel like one of those core things that I associate with you, though. So it is interesting. But it's so easy to fall into this space. I think without purposeful, intentional effort, this is the natural way things will trend. It's so much easier for the person who understands a portion of a system or an entire system to take on the next piece of work for that system. And I think we can probably offer some specific advice. But to talk about it more generally, Jen, I think you've found yourself in the pretty common position of there isn't a great answer here. There's going to have to be an investment of some amount of effort; some potentially decreased productivity for a period of time in order to get out of the situation that you're in. But that's just the name of the game. So if we name it as that, and we say that, then the question becomes how much effort do we need to put towards that, and what are the different ways that we can do it? So to go through the two that you listed, mob review sessions, I think can be a great way to give an introduction to a project, but I think they'll very quickly taper off in my experience. So I think it's a great way, especially if you're going to do any more formal things after that; a mob review or even a mob overview of the system is a great way to introduce new folks into it. But then from there, I personally would think that if you are feeling pain around the knowledge silos or even if you're not, because frankly, knowledge silos can very quickly become a major problem, say if someone needs to...if someone happens to leave the company or if someone needs to take some time off, anything of that nature, this is one of those things that can be fine until it's not, and then it's not in a very serious way, and that's the wrong time to try and resolve it. So I would very much be in favor of more purposeful things. As you described, switching pairs is an interesting one. I think that's a cost you're probably going to have to pay. I am interested; the way you're talking about it, it sounds like your teams are paired up consistently, so you're working exclusively in those pairs, which frankly is a really interesting thing. I think it was the previous episode where Steph and I talked about agile and particularly 100% pairing, and that's a pretty intense idea. It also does potentially lean towards this. Now, each of those groups of people, each of those pairs is collectively aware of the same subset of the application. But now, if you were to split that up and you have six individuals that pair in varying sets across the different projects, you have this sort of Venn diagram tapestry of knowledge of the different systems and the subsets and the features. And for that reason, I actually would probably question, at least if I'm correctly interpreting it, that you have three consistent pairs; maybe you shuffle that up. Maybe that's a practice that should be unwound. And now the pair should rotate on a daily basis or something to that effect. But overall, I think this is a cost you're going to have to pay but will pay off longer term. And it's definitely worth doing in my mind. But yeah, that's some high-level thoughts. What do you think, Steph? STEPH: I agree with all of those sentiments very much. And as you're talking about the cost and investing in the team, I think that's very true and something that needs to be done. The fact that they're working in pairs is already reducing knowledge silos because you at least have another person. Because I have been part of teams where there's one person that is that knowledge silo. So at least here, we already have two people that are aware of how code works and then why code was implemented in a certain way. So then, to categorize how painful that knowledge silo is or how risky that knowledge silo is, I think there are really two ends of the spectrum. And on one side, there's that example that you alluded to a little bit ago about isolating one developer on a project for six months, and they have minimal code reviews. And then suddenly that person leaves, and that's the hardest silo to then rectify. And it will probably be a lesson that stings enough that hopefully it won't be repeated where someone gets that isolated and then others have to figure out what was going on while that person was working on something independently. And then on the other side of that spectrum is you need to take some time to explore and understand a portion of the application that you haven't worked on before, or perhaps it's you need to understand how to work with an internal API. And stuff on that side of the spectrum feels more addressable with documentation and also mob reviews. And maybe there are also demos as well because a lot of the knowledge that goes into building a product may not be specific to the code, but it's more why was this done, and why was it built, and why did we go this way? And that feels more addressable with documentation, with commit messages, with those mob review sessions, and also with demos where then you can show the high-level functionality of a feature that's being implemented. So then, even if everyone else on the team doesn't have the technical knowledge as to how it was built, they'll have more of the user context, and the product context as this is a feature that we built, and this is why it's useful to the world. I find a lot of that knowledge is what's harder to capture because then you'll find a feature and wonder who uses this and how is it in use? And that stuff is harder to backtrack. Circling back to something that Jen caught out in their question, highlighting that it takes time for someone to get up to speed. That's a really interesting one for me because it goes back to the idea of wanting to know well; what's difficult? Not specifically what is difficult, but let's define difficult and what's a reasonable level of difficultness because onboarding to any applications or onto a new section of code is always going to take some time to process and understand. But what's an acceptable timeline in which someone can onboard and be productive? There's something that I've heard from someone at thoughtbot. I don't have the exact context to quote them directly. If I find it, then I'll be sure to add it to the show notes. And they shared that another company is measuring this difficulty of onboarding by they take the person's first starting date, and then they track to see when that person has merged in 10 PRs because they are looking to see how long it took for that person to get up and running to then feel comfortable, to then make some contributions. Often, your first couple of PRs might be something that's less challenging. It might be something that's updating the README because you are going through that onboarding process. And that's a great time to then reevaluate how clear the instructions are. But by the time you get to the 10th PR, you've probably addressed something that's a bit meatier and impactful to the product. And then they use that as a metric to then calculate okay; how well are we doing? Is it a month? Is it six months until someone gets there? How complicated is the application is another way that you could look at that metric to say, "Well, if it takes people a very long time to get there, maybe it's because of the codebase versus processes." And I really like that thinking of we have knowledge silos; let's think about where it's actually hurting us. And then, if we think it's specific to the onboarding process where that part is painful, then let's break down how we can measure how difficult it is, and then look for ways to improve it but then also track that improvement. CHRIS: Well, I like that idea of trying to quantify and measure onboarding. I've heard a lot of organizations having like, "We want you to ship a PR on your first day," that's a meaningful thing. But obviously, that first one will probably be pretty small, and it's sort of getting that first one out of the way, if anything. But it's not truly representative of someone being able to comfortably work within the repo, but ten, that starts to feel like a real number. And I do like quantifying it. More generally, I'm intrigued. Metrics around developer productivity is such a difficult thing to pin down. And it can, I think, become really complicated, especially if you're looking at individuals and trying to say, "Well, you had four PRs, but you had two PRs," and comparing individuals. But I do really like the idea of more aggregate stats of on average; right now last month, we were doing 1.2 PRs per week per developer, and now we're down 2.7 PRs per week per developer, something like that, and seeing that looks like something that we might want to address. Are there fundamental things that are happening that are causing development to slow down? Are we doing bigger PRs, et cetera? And starting to look at that, but try and have a metric to keep an eye on that. So I'm super intrigued by that and then again, more specifically to the onboarding one that you were talking about there. Actually, popping up a slightly higher level, though, I think both you and I sort of jumped into this conversation as, like, yes, knowledge silos got to fix those, that's a problem. And I do feel that way. This is a topic that I feel pretty strongly about and pretty clearly about that knowledge silos are the natural state that things fall to, and it's not a good thing, and we want to avoid it. But it is important to ask the question of who is deeming this to be a problem and for what reasons? And we had a good conversation two episodes back in response to a different listener question about consulting versus building product. And I feel like, with this, we can almost go up to the consulting level of this can be a problem, but it also maybe isn't. Or, who believes it's a problem? Is it management thinking, "Oh no, when that person went on vacation, suddenly everything ground to a halt? This is a problem, and we need to resolve that." Or is it the development team themselves saying, "Hey, we feel like we're a bit siloed here, and that's a problem we're recognizing," but they don't have buy-in from management. Or worst case management saying, "This is a problem, but you get no time to resolve it." As long as everyone's in agreement of the potential benefits and aligned to this is a thing that we would want to improve, and then also aligned to there will be a cost to resolving it, that it's not free to try and unwind this siloing of knowledge, then I think everything can be great. But any mismatch at sort of any level of that either on the cost or the benefit side can be problematic. And so getting to the point where you've had a clear conversation that defines this and gets everyone to come to an idea of yes, we think it's a problem, and yes, we want to put in the effort to resolve it, then I think you can move forward and tackle any number of different approaches. But I think you have to start from that conversation. STEPH: I love asking that question of how has this manifested into a problem or a concern? Because you just highlighted a really great example where if it's only a concern because someone was on vacation and the team couldn't respond to a customer request or couldn't respond to an outage, then there are different ways to address that. So documentation may not be the best way to help out with that. That's probably a pairing session. So then someone can respond quickly to an outage versus you don't want to say, "Okay, here's a couple of pages of documentation," and then have that developer go on vacation again, and then there's an outage, and you're trying to read through those pages to figure out what's wrong. So figuring out the right approach based on the pain that's being felt feels like a really great way to go about this. Because frankly, breaking down a knowledge silo is always going to have a cost. So you want to make sure that you're being as cost-efficient as possible with your approach and then addressing the root concerns and making everybody's lives better. Because I do think there's some knowledge silo that's appropriate. And I think silo may be the wrong word, but someone who is more skilled or an expert in the area or has more context for a particular area of the application. Because applications can get so large that not everyone's going to know everything and context switching between all of those can be really challenging. So I think it's very natural that you're going to have different people that you go to around a certain feature. If there is some lofty feature around search and you know a particular person that has worked on it for a while, then you go to them, and that feels like an appropriate level of knowledge that someone has obtained. And I wouldn't classify that as a silo at that point. But then if you do get to the point where that person went on vacation and then search broke, then you can start to revisit okay, maybe this person does have too much context, and then we can offload some of that context to someone else. CHRIS: There was a phrase I used earlier of like a patchwork quilt, but I think that's not quite the right image. There's an image in my mind of little islands of color that are fully separated; that's bad. And then there's a version of more like a Venn diagram overlap where each of the colors sort of bleeds into the other ones, and I think that's good. But then the perfect overlap where it's just one big blob of brown because all the colors are the same, that's bad. And I think that's what you're highlighting is like, you don't want to go to that. You don't need the perfect overlap of everyone having a complete shared knowledge set. I'm trying to make word pictures over internet radio. So it's probably not going great, but it's something to that. Like, there is an optimization here, and I think the way to find that is by starting from what are the pain points? What are we feeling that is less than optimal? And then coming up with solutions that directly address those pain points, not generically try and target like knowledge silos bad. And retros are a perfect way to do that. So if you listen to our previous episode where we talk about the virtues of retros and other agile philosophies...This is great. I feel really good about being able to reference previous episodes. I think we've talked about good stuff in the previous episodes. STEPH: You've been on fire with this episode. I think you've referenced at least two, three episodes at this point. [chuckles] CHRIS: Yeah. Wow. Well, I mean, we're at 300 now, so we've got plenty to go back to. [laughter] STEPH: We've got plenty of content to reference. I think you and I do have an advantage here based on our experience where we have had to join a number of projects. And then we know our time with that project is very determined, and we want to make sure that we don't take any knowledge with us. So something that you and I have acquired as a skill is seeking knowledge when we first join a project and asking a lot of questions around how the application works and then understanding more about the intent of different features, and then knowing where to dive into a codebase to then make fruitful contributions. And I think there's a similar approach that can be taken when trying to break down a knowledge silo is a person who is that silo may be in a spot where they're having trouble communicating all that information and then dispersing it to others. So then us, as their teammates, can go to them and try to ask those types of questions to then help ourselves level up and then recognize areas that don't feel documented. And maybe it's adding documentation, maybe it's adding tests, or maybe it's doing a demo, maybe it's recording something about the feature and then sharing that with the team. But then you can be an advocate for that person who is in a silo position to then help them share that knowledge because they may be too far down that path where they don't recognize what they know, and other people don't. I don't know if that's directly related to being a knowledge silo but just an additional way to approach helping breaking down when you recognize that a silo does exist and looking for ways to then help that person communicate and distribute their knowledge. CHRIS: Yeah, I think you're describing a distinction between a push versus a pull. It could be incumbent upon the person who has the knowledge to try and push it out to the team. But often, they're going to be perhaps a more senior person. They've got code review to do. They've got other meetings, and planning, and things, and they just may not have the time. But is there a way that other team members can proactively pull that information from them and help them find the moments that will clarify that? So, yeah, broadly, as a team, let's rally around the desilofication of the whole adventure. STEPH: That's exactly what I was going for is that push versus pull mentality and how we can break down the silo from both sides. So thank you, Jen, for that wonderful question. I hope we gave you some helpful ideas and suggestions around addressing a silo and then also identifying the pains that you're feeling so that way you can find the most cost-effective approach. But on that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: The show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

time pr reddit coo api metrics sticks shed gmail aws github notion apis green lantern fugitive javascript html rails trello venn silos git prs circling inertia kanban mandy moore stack overflow mozzarella alexei typescript tgi fridays vim todoist readme uis paper trails pagerduty aah dimitry instapaper emacs chris yeah christ here chris you chris oh chris well chris is gary bernhardt chad pytel chris let chris on chris toomey derek prior chris time

George Stocker — A Dogma-Free Approach to TDD

Tiny DevOps

Play Episode Listen Later Jun 8, 2021 29:31

Guest Goerge Stocker cuts through the often polarizing debate about Test-Driven Development (TDD) and offers his view on when the practice does and DOES NOT make sense, based on technology as well as human factors which are often overlooked. We discuss the concept that TDD is one of a vast array of techniques to choose from, and some of what goes into selecting the right tool for the job.ResourcesBoundaries talk by Gary Bernhardt of Destroy All SoftwareIs TDD Right for Your Team? by George StockerToday's GuestGeorge Stockerhttps://georgestocker.comTwitter: @gortokWatch this episode on YouTube.

269: Things are Knowable (Gary Bernhardt)

boundaries api backend frontend typescript anki knowable gary bernhardt

Play Episode Listen Later Nov 17, 2020 46:04

Steph's taking a quick break this week, but while she's away, Chris is joined by special guest Gary Bernhardt. Gary is the creator of Destroy All Software screencasts as well as his more recent venture, Execute Program. Between Execute Program, his screencasts, conference talks, and more Gary has consistently provided some of the highest quality and most impactful educational content around building great software and has been a huge inspiration to the hosts of this show. In the episode, Chris and Gary discuss Gary's recent work with TypeScript and how it compares with Gary's focus on testing, they revisit some of Gary's ideas around software architecture and how they map to his current work, Gary's thoughts around the value of knowing our tools deeply, and the trade-offs between careful upfront design and shipping early and often. This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post Gary Bernhardt on Twitter (https://twitter.com/garybernhardt) Destroy All Software Screencasts (https://www.destroyallsoftware.com/) Execute Program (https://www.executeprogram.com/) Deconstruct Conf (https://www.deconstructconf.com/) Gary's Conference Talks (https://www.destroyallsoftware.com/talks) Gary's new video - End-to-End TypeScript: Database, Backend, API, and Frontend (https://www.youtube.com/watch?v=GrnBXhsr0ng) TypeScript Eslint (https://github.com/typescript-eslint/typescript-eslint) tsuquyomi Vim TypeScript integration (https://github.com/Quramy/tsuquyomi) Functional Core, Imperative Shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Boundaries (https://www.destroyallsoftware.com/talks/boundaries) A Compiler From Scratch (https://www.destroyallsoftware.com/screencasts/catalog/a-compiler-from-scratch) The Unix Chainsaw (https://www.youtube.com/watch?v=sCZJblyT_XM) A Whole New World (https://www.destroyallsoftware.com/talks/a-whole-new-world) Hammock Driven Development (https://www.youtube.com/watch?v=f84n5oFoZBc) WaniKani kanji learning app (https://www.wanikani.com/) Anki - spaced repetition flashcard system (https://apps.ankiweb.net/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

257: How Late On a Friday Can You Deploy?

technology development startups testing web product software typescript gary bernhardt

Play Episode Listen Later Aug 18, 2020 50:27

On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out! This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy FusionAuth (http://fusionauth.io/podcast) - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code BIKESHED Rack::Timeout Sigterm (https://github.com/sharpstone/rack-timeout/pull/157) The Art of Code Comments - Sarah Drasner | JSConf Hawaii 2020 (https://www.youtube.com/watch?v=yhF7OmuIILc) Technical Debt Panel from thoughtbot (https://thoughtbot.wistia.com/medias/msdwdg790m) Gary Bernhardt on Full Stack Radio (https://www.fullstackradio.com/episodes/144) Sandy Metz - The Halflife of Code (https://sandimetz.com/blog/2017/6/1/the-half-life-of-code) Code Climate Churn vs Complexity Graph (https://docs.codeclimate.com/docs/churn) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

art code deploy gary bernhardt full stack radio

144: Gary Bernhardt - TypeScript and Testing

Full Stack Radio

Play Episode Listen Later Aug 5, 2020 84:58

In this episode, Adam talks to Gary Bernhardt about building Execute Program, why he chose to build it as a full-stack TypeScript application, and the implications using TypeScript has on what you need to test.

252: I'm a Designer Now

The Build Better Software Podcast

Play Episode Listen Later Jul 14, 2020 54:50

On this week's episode, Steph and Chris discuss leveraging the Unix utility sed to search files and remove unnecessary test setup, using Vim's Arglist to create a to-do list for file edits, and budgeting time for fancy command-line scripts. They then take a deep dive into the world of utility-first CSS and TailwindCSS. This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to get get an extra three months FREE on a one-year package Register here to attend the free panel discussion "How to sell technical debt to the business" (https://tbot.io/tech-debt) sed (https://www.gnu.org/software/sed/manual/sed.html) The Unix Chainsaw by Gary Bernhardt (https://youtu.be/ZQnyApKysg4) awk (https://en.wikipedia.org/wiki/AWK) Vim's Arglist as a File-Centric Todo List (https://ctoomey.com/writing/using-vims-arglist-as-a-todo-list/) xkcd (https://xkcd.com/) React Podcast - 88: Adam Wathan on Making Your Own Money, Refactoring UI, and tailwindcss (https://reactpodcast.com/episodes/88) Tailwind CSS (https://tailwindcss.com/) Tailwind Cheat Sheet (https://nerdcave.com/tailwind-cheat-sheet) Redesigning the Tuple Client UI (https://tuple.app/blog/redesign) Bourbon (https://github.com/thoughtbot/bourbon) PurgeCSS (https://purgecss.com/) thoughtbot dotfiles (https://github.com/thoughtbot/dotfiles) PostCSS (https://postcss.org/)

designers react bourbon rails css redesigning sed unix vim tailwind css awk adam wathan postcss gary bernhardt react podcast refactoring ui

Wardley Mapping With Ben Mosior

Play Episode Listen Later Jun 8, 2020 51:47

Links: Simon Wardley's book on Wardley Mapping Simon Wardley - @swardley (Twitter) Learn Wardley Mapping - Ben Mosior's site on... Learning Wardley Mapping. Ben Mosior: @hiredthought (Twitter). Site: Hired Thought Tatianna Mac - @TatianaTMac (Twitter) Tatianna's work on helping white dudes learn about systemic racism, how to recognize it, and what to do about it: "White Guyde to the Galaxy". Tatianna Mac also wrote a white woman focused guide, called "Save the Tears: White Woman's Guide". Please support Black Lives Matter in any way that you can.Episode Transcript (Automated Transcript via @otter_ai)George Stocker 0:00 Welcome to the built better software podcast podcast for software leaders who want to enable their teams to build better software. I'm your host George Stocker. Today, I'm joined by guest, Ben Mosher to talk about wardley mapping, then Welcome to the show.Ben Mosior 0:16 Thanks for having me, George.George Stocker 0:18 For folks who are just meeting you for the first time, could you share a little bit about who you are and what you do?Ben Mosior 0:25 Well, my name is Ben Mosier. I do a little bit of this and that I kind of jokingly call myself a methodology whisperer, which roughly translates to God, I wish I had a job title because I don't know how to describe myself. But you know, roughly that means I take these methods that people are using for thinking that are relatively unknown, but quite innovative. And then I try to turn them into everyday tools. So for the mapping is one of those endeavors. There are others but yeah, that's that's what I do. I run workshops and things like that and Build resources for people to learn.George Stocker 1:02 Now for people who are new to wardley mapping, what is it?Ben Mosior 1:07 Yeah, wardley mapping is a strategic thinking tool. I like to think of it as like a knowledge creation tool that enables action. It was invented by this lovely old man who lives in a swamp by the name of Simon wardley. He lives in UK. And he created this method after quite an extensive bit of research into what I would basically point out as being kind of fundamental patterns of capitalism, or the mapping the practice is basically three things. It's first and foremost a visual communication method. It's about kind of creating an artifact that we can challenge and have a conversation around. That's visual. And the second thing is, it's a body of research around these patterns of supply and demand competition, you know, how does capitalism big work, how do things evolve. And then the final thing is a strategic thinking process that kind of ties both those things together in order to enable you to make new decisions based on seeing a kind of strategic landscape that most will not be able to see. So it's a knowledge creation tool in order to enable you to take action.George Stocker 2:24 Okay, and now with wardley mapping when when you start out with it, what are you mapping?Ben Mosior 2:31 Yeah, so when you make a wardley map, what you're focusing on are things like, you know, what is the system that you're a part of, and you can have to make some curatorial decisions about how how some curatorial decisions about what scope to pay attention to, but you could say map of business, or you can map a market. You could even map yourself as an individual But roughly what you're doing is focusing on what is the system? What is its parts? How do they relate together? And then you do two things. You think about how the system produces value for somebody, some user. And then you also think about how those parts are changing under the pressures of supply and demand competition, which is capitalism. So what is the system? How is it changing? How does it produce value for users? And is basically creates a way for you to interact meaningfully with the world by modeling it. We can get into more of what that actually looks like. But it's not as complicated or weird as it sounds. It's literally just what are the parts? You know, what do they like? And how should we treat those parts? How should we have intent with respect to each of those parts?George Stocker 3:51 Now, how do you spend your days with wardley mapping?Ben Mosior 3:55 So I spend time with teams doing strategic kind of training. assizes, where what we'll do is we'll kind of go through the basics of wardley mapping, we'll apply doctrinal principles about, you know, what you ought to do as individuals in the organization, how to think about, basically, what's it What's a universal principle that you can apply to the work that you're doing? That that value that you all kind of share. And then also thinking about what Simon calls climatic patterns, which is basically like, what what is relatively predictable about capitalism that if we only took the time to notice, we could actually use that to anticipate change that's occurring in the wider market. And then like finally just thinking about how to go about strategic thinking, I get more energized by the thought of getting into kind of like, what what is the you're doing George, like with this podcast and what, what are the big questions you're trying to answer? And then you and I riffing off of that, given the context of what I do, and Given the context of mapping and how I think about those things, I feel like a lot of energy coming out of that kind of conversation, and kind of nodding toward the mapping without having to like get big make it the focus so much, if that knows,George Stocker 5:14 no, I really like what you said. And that's, that's key is that, you? I, I believe that we, as software developers, and as an as a practice, software development itself is still in its infancy. You look at you look at construction, and they have building codes and building codes and building codes. They can tell you to a tee, how much a bridge will cost and how, what it can hold. You know, who's it for? What does it does, and with software development, we can barely tell you how long a little feature will take. And that's after 16 years of doing it. And then we'reBen Mosior 5:55 still having fights about about like whether or not estimates are a valid thing to do.George Stocker 6:00 Exactly what can you imagine? And you're to the point about building? Can you imagine if the building codes were like, yeah, you don't need blueprints. But we built software every day without blueprints without specifications. And we actively derived teams that do produce specifications that do produce tests in the form of test driven development. Now, what I focus on is I focus on I want every software team out there to know about test driven development. And I want to make it accessible for all software developers to a point that it becomes, I believe, it can become the standard way of developing software. Now I believe that we have we have taught it incorrectly. We have glossed over the hard parts. And we have, you know, over simplified it and not gone to, when you would use it, how you'd use it, why you'd use it, who it's for, and Who it's not for, and what the, you know, the two standard schools of TDD, get right and what they get wrong. And if you go inside out as an example, if you go in that inside out TDD, you're so focused on the feature that you forget the world around you. And when by the time it comes to getting to integrating with the world around you, you you're doing it haphazardly, or you're not able to do it at all. And then from the other side, if you go on the outside in and you take in the whole context of the world, you're operating around you, you're coupling yourself to that world through the use of mocks and stubs. And there are other ways and in fact, someone named Gary Bernhardt talks about a style called FOMO, which is a melding of the two worlds you inside of your domain inside of your business context. You keep yourself isolated from everybody, and then around that, that's the functional core of your SOP of your system. That's completely done through TDD, has no outside dependencies doesn't deal with anything, databases, API's or anything. But outside of that, that that impatience. If shell that part where you talk, the world has very few entry points into your into your domain into your application. And those you don't TDD, you may write end to end tests for those, but you've reduced because all of your system is inside of that domain is isolated from the world, you've reduced the surface area that your end end tests have to cover, you know, to to the end, down to a, relatively a handful. But we as a software development community, you know, have not embraced TDD because the way that we were taught it, we were we were taught these systems that that, you know, you got three rules, they just work and they don't just work. Your mocks and stubs don't make testing easier. They make testing harder, but we we've not given enough attention to the practice and really diving into the practice of sharing its value. How How can it help your beginning software develop And we have not gotten into how it can help teams and businesses. And I think that if we we hone in on the business aspect of the value it provides to businesses as far as fewer regression bugs, faster time to market, because you're not worried about making changes to the system. If we focus on things like that, and we focus and we give each person to your point about these people or these capabilities in these parts in the wardley map, you know, software developers worry about one thing, QA worries about another business, people worry about a third thing, they worry about the value they're going to get out of this feature. But if we focus on what can How can doing TDD, give you the value that you're looking for, no matter what your position in the company is. I think we might have a better time for it instead of focusing solely on developers which is what we've been doing for the past. 20 years with TDD and it hasn't worked. It's it's demonstrably failed. So we've got to change your tactics. And that's why I am here. That's why that's why I care. I believe that all software teams can produce value and produce more value for their customers faster. And I believe that software development itself must change. It must adapt to the world around it. And it must produce some sort of standard in order to be able to produce software reliably, which we still can't do. And I think that something like FOMO style of TDD will get us there. It will give us much closer it may not you know, it may not be the the end thing, but it is the next thing.And that's what I that's what I help teams do.Ben Mosior 10:46 Yeah. So it's like the Faux-O Manifesto, right? No, yeah.George Stocker 10:50 And it's not like it none of this is original to me. Like I learned about it. When I went to PyCon in 2012. Gary Bernhardt was on stage. And he's he's talking about it in the context of his own site, destroy all software, and in the context of it and its billing mechanism. And during this, I was watching it unfold. And I had been well versed in to that point both from the inside out perspective and the outside in. And I had, I had been dealing with all the problems that he talked about mocks and stubs and how brittle they were. Because once you start mocking something, you're now you're not coupled to it. If you're mocking a method, you were coupled to that method being called. And it bothered me because we would get failures in our test suites for no reason other than, hey, we took out this implementation detail, no longer calling this method inside of, you know, these three other methods. And that would break the test and it shouldn't break the tests. But in his talk, which is called boundaries, he goes through, you know, this is what functional core imperative shell Looks like this is how you can model your system. So that you you return primitives inside inside of that functional core. You don't mutate objects, you stay away from the Oh, which is I have one object I mutated state. Now you always return a new object with that new state, and you never mutate objects. Also, you deal with primitives, you don't deal with how external for instance, the Active Record pattern would return you an object, you don't deal with that you deal with your own method of object retrieval. Now it turns out the shell side of it when you do have to talk to the database, you're going to have to deal with that mapping. But inside of your domain, that mapping is entirely your domain objects, your primitives that don't have external dependencies, and you start there. That's how you decompose your system so heavy into it. Domain driven design flair. Understanding your bounded contexts of understanding your domain, and of speaking in the customers language. Now from all that you can, from all that you can make sure that the actual business work that your system does is testable and is fully tested through test driven development. And then your, your, your shell, you know, the delivery mechanism of your software is the thing that you need to write end to end tests for. But that's, you know, that's an API endpoint or two, that's not, you know, trying to have that API endpoint do all of the internals of your system as well.Ben Mosior 13:42 Yeah, what I'm what I'm so here's a, you know, here's an admission, right? So I'm a former systems administrator. And I have, I'll be honest, I couldn't tell you the difference between them. I couldn't tell you the difference between a stub and a mock I will set a mob and a stock and I'm notGeorge Stocker 13:58 sure They should have named him that.Ben Mosior 14:01 Yeah, honestly. No. But like what? What's interesting though is I heard you do something that I hear people do when they learn wardley mapping. I heard you disambiguate a term that is used almost ubiquitously. So test driven development, right? You You took that thing and you made it two things. And then you talk me through how each of those things is used in different contexts. And then you described that as a third thing. So test driven development is now three different things. It's inside out outside in. And then the third one, which I of course, have no idea what the name is called, but it sounds like fun to pronounce.George Stocker 14:42 Yeah, the Gary Bernhardt calls it Faux-O and it is, it's exactly a third way to do TDD. Yeah. From wardley mapping with with test driven development. Would there be a way to map out you know, a team adopting TDD Through wardley mapping?Ben Mosior 15:01 Yeah, it's really the question like, how would you ever be able to have the conversation? Like, what conditions would you have to create to have the conversation where you could contextualize each sub practice of TDD into a context that you in a way that you would enable you to know when to deploy? Which one? And so like, you shift the conversation from which one is right, always, to which one is right, in which case? And what conditions would you have to create in order to have that kind of conversation? And and frankly, the answer without something like wardley mapping is luck, to be honest, or really like incredible intuition, perhaps. And kind of like I know, we were talking before a little bit about like human shock absorbers, sometimes the embodied kind of cognition that people have, they have these like, tacit things that they just know without being able to explain and so sometimes they'll pick up on something like that and able to have the right conversation. But like, it looks an awful lot like luck to me. So I would rather have a predictable way to create conditions for conversations where we could disambiguate, like big, messy things like TDD into context specific deployment of specific methods. Now, I just used a bunch of $5 words. So I'm going to like, take a break, and pat myself on the back. Let's let's get really like concrete. This is this is what you did. You took TDD, you split it apart. And then you said, in one context, do this in another context, do that. That's what you what you did was you had a struggle of ontology. What is test driven development? And you You brought in a language of existing models, which is exactly what you can do when you're getting started. You're like, Well, okay, the thing that is test driven development actually turns out to be several different things. And so when should we use one over? The other is an interesting question. So just just pointing out that there are multiple things enables you to actually say, Hey, we should use one in one case in another in another case. So so what what happens next? Like what what are you thinking about?With respect to like?George Stocker 17:23 Yeah,Ben Mosior 17:24 actually, here's the question like, how would you create, like, currently create the possibility for that conversation? Like, how would you enable a team that you were managing to have that kind of conversation?George Stocker 17:39 Yeah, so for me, I'm always interested in the bottom line in what will this do for me or for the team for the business or for the customer? You know, we adopt TDD. What's Why? Like, why are we doing it? Are we doing it because we have Lots of regression. When we deliver code, are we doing it because we find it hard to change code? Are we doing it because we, you know, heard on a podcast, it was good idea. Why are we even doing this thing? And that's the first question that I want to answer. And I want to get that down on paper.Ben Mosior 18:17 Most of the time, the reasons people are adopting things is fashion and tribalism. Right? Yeah. It's what what's awesome is that's the phrase that I stole from Andrew clay Schafer, but basically, it's like, what's really cool that people are talking about that gets me excited, because, you know, what have you liked? hundreds of companies are doing this. So we should do it to or, you know, our group of people who believe this thing versus that group of people that believes in that thing. nobody's asking what test driven development actually makes possible for us. When we have it as a capability in the organization. What does it enable for us?George Stocker 18:53 Yeah, so for what I've seen is when you when you Do TDD and you use the right and and you went you, you hit on it earlier. And you really hit on the center of that is that not all forms of TDD are acceptable in all situations. But when you apply the right form of test driven development, to the right situation, to the right code base, you give yourself give the team confidence. So if your team is lacking confidence, or you have a lot of new developers on the team, you're giving them confidence that when they make changes, those changes won't break anything else, which, as a developer, new to a code base, that's the first thing I'm thinking of is I don't want to be embarrassed in front of my teammates, because I just made a change, and I broke production. I don't want that to happen. From a business's perspective, you're gaining the confidence that you can deploy at Friday at 5pm. You know, there's that mean, you don't deploy on Friday. And if you have a testable system and a system that is tested, you you gain that confidence of Hey, I really need this fix to go out right now. Can we do it and you as business you can. Now you To start to answer yes to that question, from a system perspective, from a maintainability perspective, you're now looking at, there's an I see it every time I'm, I'm with a new team, it's the desire to rewrite this desire to get rid of this thing and to replace it with this magical new thing. That is so much betterBen Mosior 20:21 problem of discipline to write, it's like, it's like this assumption that like, hey, if we just rewrite it again, it'll be fine. And so you start this, this whole new effort without having all of the understanding or the skills that would make writing good software possible, expecting to get a different result. And I do believe there's a word for that George,George Stocker 20:41 it's called insanity. And I've been guilty of it myself. And I've also been in situations where you know, the rewrite decision was made before I came in and I was asked to implement rewrite and say, Look, and I had to keep saying like this is not going to go the way you think it is. Because the rewrite you don't have the people who produce the original system. Usually, you don't have the original context. And you don't know all the cases where the system is in use, like you. There's a semantics, Twitter account that I love. But it's basically like the it tweets out, you know, things that are real in systems. For instance, the system does what it wants to do. It's not it has its own agenda. But you don't know those things when you rewrite. And you just think that the system is what you see in code, instead of the whole context.Ben Mosior 21:31 Not to mention that oftentimes the business doesn't even know what the software is supposed to be doing. The business probably couldn't tell you how the software actually fulfills user needs in a way that produces profit for the organization. Because like, this is this is like unintentional ality, which is a word I'm going to make up for whatever reason, like it's the absence of being intentional. Is it all the way down? It is it starts at the highest level of the C suite. It goes all the way down into our engineered engineering organizations, product organizations, operations organizations, it doesn't matter where you look, you're going to find this disconnect. And so the question becomes like you as a software developer or us a software leader, trying to make an informed decisions with respect to this entire system, unintentional ality, it becomes really, really hard. And so of course, it just, it starts to feel like a well, ah, it's a mess, and we didn't manage the legacy well, so I guess we should just rewrite it because that's at least going to be approved by the business as like a panacea, right, or a panacea that's gonna at least be approved by the business as a cure all for the problem, because, you know, they don't know any. They don't know any better either.George Stocker 22:48 Yeah, and sometimes it might be there are instances where a rewrite is the best thing for the team. But, you know, for for businesses that don't want a chance to rewrite information. teams that have the situational awareness to realize they don't know what they don't know about the system, introducing characterization tests to figure out what the system does. And then from that, you know, producing test driven development tests, you know, to port over new functionality to put it under test. And then gradually refactoring the system using those characterization tests, refactor parts of the system, into something that you is produced, or can be maintained through test driven development helps. But that goes to those three different types of test driven development. You know, if you're producing a new feature in isolation, and then you integrate it later, maybe inside out as your best way to go worry about your feature, worry about what it does, specify it through tests, implement those tests, or implement the test, implement the code for the test, and repeat that. You know, that's best when you have a feature in isolation and you're not as worried about trying to integrate it into a larger system. Whereas outside in or, you know, introducing mocks and stubs and mocking out things you don't own or stubbing the state of the system, or stepping parts of the system that you're using. That's good when you're trying to take something existing and put it under test. It's a good first step, the problem with mocks. And I said this earlier, the problem with mocks is that they tie you to an implementation. You know, I verified that this method was called Yeah, in refactoring might end up removing that method. And if we're not careful and don't realize that it's being called in this test somewhere by dependency, it's going to fail, our tests will fail, even though nothing changed behaviorally. And then that introduces that next third style of test driven development FFO, which allows you to then test the behavior of the system and not worry about the implementation. I'm testing the behavior of this billing reconciliation feature. I don't know care what methods actually get called? All I care about my input is, you know, this this bill, the state of the system is this bill is in a certain state and all I want to know is, you know, is it reconciled or not. And with that you can then change a lot of the implementation, and your test don't get affected by it.Ben Mosior 25:20 Yeah, one of the things that seems really critical in designing an organization, let alone designing software, which I mean, Conway's Law is a thing, but like, roughly speaking, where are the boundaries between the parts of the system, and very quickly in both an organization and in software, you start to realize that entangled pneus is one unnecessary evil, but also something that shouldn't be allowed to dominate as as an extreme or a default. Right. So like, what I mean by that is like tightly coupling things right where, like, you're being tied to implementations is probably not a great right thing to do, if there's a chance in the future that that thing has to change, right? So you have to pay attention to change. And if like, it's a 5% chance that that thing will have to change in 20 years, then maybe who cares, right? But like, if there's an 80% chance that in the next six months, there's going to be security vulnerability that requires you to actually adjust the implementation in a way that would have, you know, cascading effects and all the other parts of the software, then then, yeah, maybe I should be a little bit more concerned about being tied to an implementation in that case. So one of the things that I really like so wardley mapping really points at this idea of interfaces, and and cell based structures, both for organizations but also for, I think, in particular software. So So what is the interface? How do you create those clean lines, and unfortunately, there's like this whole body of skills that you have to build in order to do that. You have to be comfortable. Like taking a decent guess, under circumstances of ambiguity, where to draw lines, what to include inside the boundaries and what to push outside the boundaries. And if you're not careful, what you start to see is that in an organization, say between a development organization and an operations organization, you'll notice that there are things that get stuck between those two saw, like sets of things in the organization, that they're just, you know, crust that stuck somewhere, and nobody's responsible for it. And so it starts to decay and it starts to smell. Similarly, in software, if you don't have clean lines that, like, make responsibility for each part of the software clear, you really start to notice how like that is the zone of no maintenance, that those are the things that will not be touched. And that is equally applicable to organizational theory, from simpler like people's in teams.George Stocker 27:57 That's right, and you're going to get it Wrong. That's one reason if you use domain driven design, and you think about your bounded context, which is you know, inside of this context, a word means what it what it means. And outside the context, this word may mean something else. But in this context, the word has a specific meaning it's not going to change in this context. If you use things like your bounded context, and the domain, the language of the customer, the language of the problem you're trying to solve, you, you start to see where, where things are defined, and what they relate to. And you start to see those those boundaries crop up just from when words change, meaning. You know, change management means something completely different to a business person than it means to me.Ben Mosior 28:46 And it means something very different to a consultant as well.George Stocker 28:49 Yeah. And so, you know, when I know that word has changed, meaning I know I've crossed a boundary of some sort, and you're going to get it wrong. One of the tenets of TDD is that you don't start out with the right You don't start out with the right architecture, you're going to evolve to it. Because you're going to learn every time that you add a new test to test out a new feature, or you add a new feature, the system is going to change shape. And you'll figure out you know, what the system and you know what it should look like, through that evolution because you don't like you're never going to know less than you know about something at the beginning. So if I'm, I got a new system, I will never know less than I know about it right now. You know, every moment I will learn more and more and more. And you hope that when you learn more and more more systems easier, easy to change, it's not easy to change, like that's a that's a smell,Ben Mosior 29:43 that it's a huge smell. If for example, like you need to do a lot of exploring, right, actually, this is where the wardley mapping concept of evolution starts to become really helpful here. So like, we may or if you if you've looked at wardley mapping, you know, there's a This x axis kind of like idea of evolution, right? four stages from Genesis to custom built the product and commodity, you can also look at that through the lens of like practices. So like emerging, sorry, novel practice emerging that novel, practice emerging practice good and best. And so there's this progression from left to right. And like how evolve something is changes the way that you should treat it. So for example, things that are in like the first couple stages of evolution, so Genesis or custom build, those have to be easy to change, because they're so uncertain that you, you almost have to assume that like nine times out of 10, you're going to do the wrong thing the first time. And so that's where you start to see things like agile being really helpful, where you're basically trying to lower the cost of change of that thing, so that you can change as many times as necessary until you find the value, as in find the right form of the thing that produces value for the people that you're serving, by building the thing in the first place. Now that's completely different from say, like, if you're looking at something like a login function, right? Generally speaking, authen off z, like these are things that are broadly understood. And for you to reinvent that wheel, and to pretend like you need a low cost of change, and the need to rapidly change around logins, is kind of absurd. If you compare that to the way that the rest of the industry treats that kind of practice. And so there instead of reinventing the wheel and using an agile method, that you might actually want to just adopt something, either in terms of the design or in terms of an external solution, because it's so well understood. And of course, you're going to have trouble like adapting it to your local context to your software. But in truth, you don't want to be have to be the expert in that thing. And a high cost of change is okay, because the thing isn't going to change in 20 years very much. So it's like trying to understand how do you continue Realizing practice? How do you contextualize, like each of the different sub practices of TDD? What does each thing depend on? What does each thing? What depends on each thing? It's like you look up, look down. How does it How is it situated in this larger scope of things, such that you could make those nuanced decisions without just reverting basically to like, my way or the highway kind of approach?George Stocker 32:27 That's really interesting, because as you're describing it, I'm seeing, you know, both the forms of TDD. And when they would use animal types of systems and on what aspects of the systems like I'm seeing that overlay onto the workday map. So something that, you know, is going to change a lot. I mean, want to put a lot of effort into making sure that that part is designed through TDD, but something that interfaces with the login mechanism that's over on the commodity side of the working map. I may not I may only want to have an index Test around it and automated an automated UI test around it. I may not even want to deal with that from a, from a developer. I'm writing tests for this perspective, because it's, it's not in the novel. Or the emerging, it's, it's over there on the commodity side of things.Ben Mosior 33:24 Yeah, it's like, how certain is it? And do you really need to doubt that it's working? Now, it also depends on like, your organizational context, like if this thing doesn't work, what are the implications? Right? If this thing spits out garbage data, you know, what are the implications of that, like, Are people going to die? Or is it just that, you know, someone gets a 404 page when they weren't expecting to, right so, and that's where you start to notice that. Look, the whole system of software and the organization building, the software is A bunch of little negotiations between different parts of that system. And so that's when you start to find that things like SRP are really interesting. Because it explicitly calls out that negotiation as a function ofGeorge Stocker 34:15 site reliability engineering.Ben Mosior 34:16 Exactly. Yeah. And like, just, if you go read the free, like just the one chapter from Google on, sorry, about s ellos, and SL eyes, like just go look at that chapter and think about what it means to negotiate a boundary like that between operations and development, for example, you start to recognize that this this whole thing, all of this that we're doing, like we might think that software is like, understood or understandable. It is one giant human mess, and that's actually okay. But we should probably be careful about where things are more or less uncertain. And if we more explicitly have the kinds of caution conversations around negotiations between the boundaries of these components, we can actually start to be more intentional about how we're treating each thing. Like until we can build a software system that doesn't turn into a giant ball of yarn, in like a giant tangled knot. Eventually, if until software systems are not inevitably going to result in that kind of end up in that kind of state, I have a really hard time thinking of software development as something that's known.George Stocker 35:31 Yeah, that's you would you put it on the emerging end of the scale,Ben Mosior 35:37 possibly just to be a pain in the ass? But like, I think that it's an interesting question. And when you break down software development into its hundreds and hundreds of different sub practices, asking the question, what is software development becomes not super easy, and every single one of those sub practices is somewhere else. along that spectrum of evolution. And unless you're aware of that, I think you'll be reinventing the wheel for the foreseeable future.George Stocker 36:09 And now we're really getting into the value of wardley mapping. As a software leader, I can use it to contextualize my team, our practices, our relationship, business. And I can, you know, give myself a view of where are we at? What are we doing and how does it fitin this larger context,is a way to visualize you know, what is as opposed to what we want it to be.Ben Mosior 36:42 Yeah, it's really interesting because it enables Conversa- it like once you start sketching out artifacts like this. You can look internally and say, Okay, how should we be behaving like how should we treat this set of components, and then you can compare that to the way that the larger market treats that component. And you can say, Okay, well, how is everybody else doing? Especially in like public sector, like public sector can learn from private sector, for example, and go like, what are our counterparts in private sector doing? Like maybe they're not bound in certain ways that we're bound. But can we at least like learn from the way that they're doing, like authentication or something like that, right? You, there's a lot of learning that you can have just by looking outside of your organization and doing basic like open source intelligence gathering, like, read the press releases of other companies, when they talk about the thing that that is somewhat related to what you do. And you learn a lot about how different people view that same thing. But then you have to talk about time. Because if you notice a gap between what you're doing and what others are doing, and that gap isn't valuable, like it's not differentiating, it's just a waste of time. So for example, if your custom building a login function, I know I keep like hammering on that example, when you should probably just be adopting a library. It's gonna it's gonna take Little bit of work for you to get from point A to point B to actually resolve that bias. And so when time starts to be involved, you end up comparing like your your desired internal future state against where the rest of the market is going to be in, like, however long it's going to take for you to make that change. Because if you, if you set your ideal future state internally, to the current way that things are externally and the world keeps changing, then you might embark on a big heavy lift for nothing if the world changes significantly enough for your change to be out of date. I know this is like a really hard way to like, explain the phenomenon but it's like, that's what happens to most organizations when it comes to business strategy is even if it's just a gut feeling. By the time the organization actually implements the strategic initiative, so to speak, though So the world has moved on. And that may no longer be the right thing. So like this whole, like, unless you can have conversations about how to tackle that problem, like, I don't see a lot of hope for the for the quality of decisions being made, either in terms of the software that we're building or in terms of the strategy that we're implementing in our businesses.George Stocker 39:22 Now, for software leaders, I think those conversations less on the business side, or more on the, you know, what tech stack should we use? What database should we use, you know, what practices should we adopt among our team? building software? A thing that I see is that, you know, they try to answer those questions first, instead of answering those questions after they've done what you've suggested, which is figure out strategically as a business. Where do we want to be? Because once unlike, unlike other, unlike code, if you're using a data store, You're going to become coupled to that data store unless you're very, very careful. And I've not yet seen it seen a team that was careful enough not to become coupled to some aspect of their data store. And so, you know, if I'm sticking around and I choose Mongo, and I say, Well, you know, we're going to use Mongo. And then, you know, two years later, there's that nice article about how Mongo lose this data, like, Oh, we need to get off Mongo. Well, we're pretty coupled to it. That's not happening. But it sounds like with wardley mapping, you can we can, we can situate where we want to be strategically as a business, we can orient the software team towards that ideal future state. And then from there, you make decisionsbased off those factors.Ben Mosior 40:47 Yeah, I think for software leaders in particular, what something like wardley mapping enables you to do is to be intentional, you know, local way and I bet We just mean, when you look at all the parts of the system that you're responsible for, do you have an intention for each part. And that's, that's a serious obstacle for most. Because until they until they are able to actually grapple with all the parts of the system, they're not going to be able to make sense of it in a way that together, it is like a coherent strategy. And in particular, I think like software, leaders need to have that kind of intent. Because otherwise, they're going to become subject to what I would very lovingly call meddling from other parts of the organization, not because those other parts of the organization are bad or anything, but it's more like they just have priorities, and they have things that they think they want. And if you're about to make a new decision about either what data store to start with, or whether or not the news that mangos losing data, for example, is a significant enough. No impetus to actually change the data. Or if you if you aren't prepared with local intent for each part, then you're probably going to end up being swayed by the political winds. And you'll be making decisions based on other people's feelings. And I for one value feelings, but I don't think they are necessarily the primary way that you make decisions, especially decisions with impacts that lasted many, many, many years. So, when I think about this, I think it's strictly about being able to, to understand why you made the decisions that you made, especially when others around you aren't. When they aren't sure about those decisions that they they're making. This is a really like, messy thing, because you soon start to realize that like wardley mapping in particular looks like just a like, Oh, it's just another diagramming technique. And I know the DDD, people seem to like it as well as an approach and like, I'm encouraged by that. But like, what I think is like the, what I think is hidden underneath the surface of all that isit's all about conversations.And in particular, it's all about conversations about deep social problems inside the organization that are not going to be obvious that you can't exactly code your way out of. And when someone comes to you and says, I want to do this, and it's it's a bad idea, but you don't have a reason to say that it's a bad idea other than it just feels wrong, you're going to lose.George Stocker 43:40 But wardley mapping can help you show why it's a bad idea in context.Ben Mosior 43:46 It really like boring mapping is one tool and I in a huge set of tools that can help you be more intentional about the work that you're doing. I for sure, have experienced circumstances where by mapping out of space Honestly, one of the one of the typical experiences is you map out a space and you go, Oh, no, I made a decision A long time ago, that really is hurting me right now. And frankly, like the early, you rip that band aid off better. But once once you've reckoned with it, you start to recognize that you have an intent.And when you have an intent, you start to care about it.They make sense, I should do this this way. This is what I'm trying to do. And And ideally, you're having that conversation with other people around you in a way that brings them along and help them even challenge some of your ideas using some of the this kind of language like, well, what, okay, yeah, you want to choose Mongo, but Mongo entails all these dependencies, is that going to be right for us? And if you can't answer those questions, then you know, then that was an effective challenge and you've all learned something now because you'll go off and find out what you need to find out in order to answer that question. But otherwise, the other way that this works, sometimes it's just that people are will be making decisions based on their feelings. And they'll try to impose those decisions on your organization. And especially when you're in charge of an organization, that leg is full of other people. When their lives are disrupted because of someone else's feelings in the organization, you know, that's gonna really hurt morale, especially if it doesn't make logical sense to them. If you can't help communicate intent from other areas of the organization and make it make sense, then you're just going to produce an organization that is just doing what it's told, instead of thinking actively about how to make good decisions in terms of building software.Sorry, it's a bit of a rant but likeGeorge Stocker 45:50 no, that's that's great. And that's that gets to the value that you provide in teaching teams. wardley mapping is that you can help them ensure that their teams areProducing software intentionally by mapping out where they're at.Ben Mosior 46:03 Yeah. So here's what I'd say, if, if some of the things that I made that if some of the things that I just said, even if they don't make sense, if they're intriguing to you, then what I would highly recommend is go to learn more the mapping calm. And just click around a bit until you find some things that are interesting to you. And if you decide that it's interesting, go read the book, ask me questions, you can email me either through the website or by emailing Ben at hired thought, calm, reach out and tell me what's going on and I'll help you get started. Like I love helping people start to make sense of their worlds with this stuff because it betrays my optimism even. Even now, it betrays my optimism around how if people are just more intentional, I think they'll bring more good about about into the world.I want to help you get started. Socontact me say hello, ask questions. There's a lot of good resources just to start getting exposed to the method. And what I'll have to say, above all, do it like actually sit down with a piece of paper and follow the steps and try to do the process. And if you don't learn something, I will be surprised.George Stocker 47:24 I think I'm actually going to do that. I'm going to sit down and I hadn't done it yet. But you'd sent me some materials on wardley mapping. I'd like to sit down and put test driven development in that context and see what that looks like. But then this has been this has been an amazing time. You know, people can find you online at learning wardley mapping calm and they can email you then at higher thought.com. Are there any other ways that people can find you online?Ben Mosior 47:53 Yep, I'm on Twitter as well @hiredthought.I was going to say something self demeaning Because I hate that handle, but here we are. Branding is branding. Yep, I'm on Twitter @hiredthought. And I'm pretty accessible on there. What I'll say right now is like we're recording this on June 3. And you know, the United States is hurting. And I think a lot of people are hurting in general. And what I will say is like, right now, I'm not tweeting so much because of that context. I want to be respectful. But if there's one thing that you could do, even if you don't care at all about wardley mapping, if there's one thing that you could do that would help yourself and help those around you, it's learn a little bit more about race and the context of race and the way that it manifests in the United States. And what I'll say is that include this in the show notes as well. It's a URL to a list of books and other suggestions by Tatyana Mac. You can access that URL by going to https://lwm.events/race. So I opened up a page with some books that I highly recommend you engage with. And I'm currently reading The New Jim Crow. And frankly, I am learning about some things that I didn't know before for the first time and I'm kind of ashamed about that. So, use that shame for good. Don't let me be shame. shaming myself in vain. Go learn about race and learn why this country is experiencing the anger that it is.George Stocker 49:32 That's, that's critically important. Anybody who's watched my Twitter feed over the past few days is just just seeing retweeting and showing what's happening in these protests and how the protesters are being treated by people in power. And I second and I will put the show notes, Tatiana's work. I've read some of it. I'm buying the book. That she's linked to not on Amazon by buying the books that she's linked to. And I second it's, it's really important I struggled whether or not to bring up the we are indeed recording this on June 3, two days past the point where a sitting president ordered military or civilian cops to clear out the area right in front of the White House for photo opportunity. And just that, whether or not you agree with that actor, not just how historic and context changing that action is, you know, what it represents? Who would effects and more importantly, what it says about us as a culture as to what we allow and what we don't allow. And that's not even including all of the really important events that have happened, up until this point, that we as a culture have not yet learned from. We've not changed, we've not improved. And hopefully these protests mark a turning point where we as a culture, take a good hard look at ourselves at our at our past and say never again and actually live the values that we claim that we have. On that note, Ben, it's been it's been a pleasure talking to you. Thank you for taking the time out of your dayto talk with me, andall right. Alright folks. That's it for today. I'm George Stocker, and I hope you'll join me next time on the build better software podcast. Thanks

244: Existential JavaScript

performance draw window javascript existential rails sql glimmer octane pry gary bernhardt

Play Episode Listen Later May 19, 2020 40:54

On this week's episode, Steph troubleshoots a mysterious Ember test failure that can't find a visible element, and Chris recounts an exciting three-act adventure that spans N+1 queries, caching, and SQL window functions. Steph also touches on upgrading to Ember Octane and Glimmer components and Chris shares a new helpful tool for drawing architecture diagrams. Window.find() (https://developer.mozilla.org/en-US/docs/Web/API/Window/find/) Dash (https://kapeli.com/dash/) Wat - Lightning talk by Gary Bernhardt (https://www.destroyallsoftware.com/talks/wat/) Draw.io (https://app.diagrams.net/) batch-loader (https://github.com/exAspArk/batch-loader) SQL Window Function (https://thoughtbot.com/blog/postgres-window-functions) Advanced ActiveRecord Querying (https://thoughtbot.com/upcase/advanced-activerecord-querying) Scout (https://scoutapm.com/) ActiveSupport::Notifications (https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html) Ember Octane (https://emberjs.com/editions/octane/) Pry show-source (https://github.com/pry/pry#code-browsing)

98: Adam Covers for Derrick

The Art of Product

Play Episode Listen Later Aug 8, 2019 37:07

Derrick’s short notice about not co-hosting this episode because of being on a plane, and Ben not knowing or planning what to discuss, who and what’s left? Updates and reports on Tuple and Tailwind. Welcome back Adam Wathan! Today’s Topics Include: Today’s Trend: Advisor/investor/founder journals and reports of accomplishments Serves as a way to stay in touch, build relationships, ask questions, and get feedback Three Tuple Reports Later: Things are still going good Programming meets Business: Gary Bernhardt commits to being future podcast guest Successful Tuple Shipments: Significant use of Webcam feature Pricing Options: Ben expresses concern over free trials or pre-paid plans to capture credit cards and emails Invite-only vs. Public Launch: Continue as is, or open Tuple up to all Tuple Update: Revenue is growing quickly, receiving 70-100 support tickets weekly, and room to add customers Tailwind Update: Adam launched first set of videos for Tailwind CSS course Tailwind Subscription/Price Structure: Yet to be determined Adam’s Prediction: Education and documentation determine open source winner Links and resources: Adam Wathan on Twitter (https://twitter.com/adamwathan) Full Stack Radio (http://www.fullstackradio.com/) Tailwind CSS (https://tailwindcss.com/) Refactoring UI by Adam Wathan and Steve Schoger (https://refactoringui.com/) Steve Schoger (https://www.steveschoger.com/) Tyler Tringas on Twitter (https://twitter.com/tylertringas?lang=en) Brian Casel (https://briancasel.com/) Gary Bernhardt on Twitter (https://twitter.com/garybernhardt) ExecuteProgram.com (https://www.executeprogram.com/) David Heinemeier Hansson (DHH) on Twitter (https://twitter.com/dhh) Giant Robots Episode 26: Deep into the psyche of Gary Bernhardt (https://giantrobots.fm/episodes/26) Giant Robots Episode 27: Fabulous new mistakes with Joe Ferris (https://giantrobots.fm/episodes/27) Giant Robots Episode 28: Farther, further, faster with David Heinemeier Hansson (https://giantrobots.fm/episodes/28) Node.js (https://nodejs.org/) React (https://reactjs.org/) Ruby on Rails (https://rubyonrails.org/) Zoom (https://zoom.us/) Superhuman (https://superhuman.com/) Screenhero (https://screenhero.com/) Slack (https://slack.com/) GitHub (https://github.com/) Art of Product on Twitter (https://twitter.com/artofproductpod) Derrick Reimer (http://www.derrickreimer.com) Website Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein (http://www.benorenstein.com/) Website Ben Orenstein on Twitter (https://twitter.com/r00k?lang=en) Tuple (https://tuple.app/) Tuple’s Pair Programming Guide (https://tuple.app/pair-programming-guide) StaticKit (https://www.statickit.com/) Level (https://level.app/) Level Retrospective (https://www.derrickreimer.com/essays/2019/05/17/im-walking-away-from-the-product-i-spent-a-year-building.html) Level Manifesto (https://level.app/manifesto)

art deep zoom product react slack covers fabulous github rails superhuman node tailwinds farther ruby on rails david heinemeier hansson tailwind css tuple brian casel ben orenstein adam wathan derrick reimer tyler tringas gary bernhardt refactoring ui screenhero full stack radio steve schoger

190: Going Steady With a Platform

The Python Podcast.__init__

Play Episode Listen Later Mar 15, 2019 52:26

On this week's episode, Chris is joined by Alex Sullivan, mobile developer in our Boston office. Alex takes Chris on a tour of the mobile landscape comparing the core native platforms (Android and iOS), the languages, developer tooling and IDEs, and fundamental thinking. They also dip into a discussion around React Native highlighting some of its strengths, as well as areas where native still clearly wins. Finally they touch on Flutter, the newest entrant into the mobile space to round out the discussion. Runkeeper Android iOS ViewModel Room Java Kotlin Objective C Swift Scala JetBrains Type erasure Reified types Android Studio Xcode AppCode Gary Bernhardt React Native Xamarin Flutter Dart Alex's post comparing performance of native, Flutter, and React Native Thank you to CircleCI for sponsoring this episode.

android platform ios swift java dart ides scala flutter react native kotlin xcode jetbrains objective c xamarin circleci runkeeper android studio going steady gary bernhardt appcode alex sullivan

113: There and Back Again: A Quest For Simplicity with Philip Poots

The Frontside Podcast

Play Episode Listen Later Oct 25, 2018 45:06

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

new york art work russian record argentina quest llc netherlands cuba west coast east coast simplicity nest zen react excel nirvana buenos aires mls api ml github beam apis javascript rails basecamp cpu rack elixir elm coursera mandy moore haskell ruby on rails v1 matz jquery redis readme taras ecto motorcycle maintenance erlang christopher alexander be crazy poots pirsig syro frontside richard feldman rich hickey yehuda katz frontend masters gary bernhardt tom dale lodash richard gabriel charles lowell scott wlaschin david have taras mankovski dialyzer devreps

Interview: Adam Wathan, co-creator of Tailwind CSS and Laravel educator

The Laravel Podcast

Play Episode Listen Later Jun 7, 2018 70:37

An interview with Adam Wathan, co-creator of the Tailwind CSS library and author and video producer. Adamwathan.me Test-Driven Laravel Refactoring to Collections Advanced Vue Component Design Tailwind CSS Alberta Oil Sands Reaper Conestoga College Vehikl Desire2Learn Tighten Nitpick CI Adam Wathan's $100k product launch Full-Stack Radio Mark Rippetoe - Starting Strength 5/3/1 Video of Adam lifting tons of weight 5/3/1 calculator Matt's WeightXReps Training Journal Agile Principles, Patterns, and Practices in C# Adam on Twitter Refactoring UI Editing sponsored by Larajobs Transcription sponsored by Tighten Matt Stauffer: Welcome back to the Laravel podcast, season three. Today we're talking to Adam Wathan; author, video maker, teacher of the things, power lifter. Stay tuned. Matt Stauffer: All right, welcome back to the Laravel podcast, season three. This is the version of the Laravel podcast where we get to know less about tech and more about the people behind the tech, and today my guest is none other than Adam Wathan who has taught us all about testing, collections, view, components and many other things. One of things I love about Adam is that he's never satisfied with what's happening around him and he's always taking in stuff from other places, and we'll talk about this more probably later in the podcast, but when I describe Adam to other people, I say he's the guy who basically finds what's good everywhere else and brings it to us in the Laravel world. So if you haven't heard of Adam, my mind is blown. You should go consume everything he's ever made; it's all gold. I will say to some of y'all that his name is pronounced Wa-than, right? That's right? Adam Wathan: Yeah, you got it. Matt Stauffer: Wa-than. Not Way-thin, not Way-than. I'm trying to think about other things I've heard, but Adam Wathan. So Adam, say hi to the people, and the first question I always ask everybody is when you meet somebody in the grocery store how do you introduce yourself? How do you tell them what you do? Adam Wathan: Cool. Yeah, so thanks for having me on. I'm Adam. I usually explain ... It depends on what people ask, because some people ask like what do you do? I say I'm a software developer, although I don't actually get paid to write code, I get paid to teach people about code. So I either describe myself as a software developer who creates courses and e-books and training products for other software developers who are looking to kind of level up. So that's kind of the shortest version that I try and give to people that usually is enough that they kind of either are interested in it and ask me more questions or aren't interested and don't want to hear anymore. Matt Stauffer: Yeah, so I'm already going to cheat a little because I want to ask one little thing about your motivation that I've been curious about for a while and hopefully they'll still come out when we talk about your background but, you know, you're really smart guy, you learn a lot of stuff, but you're also a teacher and you also have like marketing kind of like sensibility, and you just gave an elevator pitch that would make someone who doesn't even understand programming want to go sign up for your product and I don't think that that's really common for a lot of us to know how to talk about it that well, so ... And if this is going to come out later that's cool, but do you have a sense for where your ability to kind of understand how to market something and how to ... And you talk a lot about how to do it in a non-skeezy way, but where did that come from? Is that something you had to work on, or do you feel like you've got some experience that's kind of taught you that? Adam Wathan: That's a good question and I don't think I have a great answer for it. I think I've always just really liked creating things that I was proud of and putting them out into the world with enthusiasm and I think that's been kind of like the simplest version of how I have always tried to share what I've been working on and then I think with the marketing stuff too, I guess I just care just as much about the quality of that as I do about everything I do. I just really like to make everything I do as good as I possibly can and that comes down to even things like, you know, landing pages and how things look on stuff like that. To me, the marketing is a product too and I want it to be good and I want to be proud of it, so it's just something that I just put a lot of effort into I guess the same way I would with something else. Matt Stauffer: Yeah, I mean, I tell this story to people all the time, but when you first joined Tighten, one of the things we were talking about was working on some open source projects together, and we immediately found a conflict in our ways of working where I was like, so what I do with this thing Symposium is I figure out a feature and I spit out the feature as fast as possible and then I move on to the next feature, and you're like what I do is I try to figure out exactly the best way to do this feature and I ponder on it and I make plans and I make diagrams and I get it exactly right so people will really get their needs met and then and only then do I actually build out a feature. Matt Stauffer: And we kind of had this like little head butt moment, and I think that I've kind of ... I would say I've shifted to your way of thinking, but I've been influenced by it a lot. Do you have a sense for where your kind of desire for excellence ... I think you were just talking about like where that comes from, is that just a personality trait? Is that something from your family, and what's that ... Where does that come from? Adam Wathan: I think it's just a personality trait. I've been like that with basically everything that I've ever been interested in my entire life. Like I would sit and play guitar and play the exact same seven notes for four hours straight until I played them perfectly, you know what I mean? So I think I just get a little bit obsessive over the sorts of things that I get interested in. Matt Stauffer: Yeah, I just want to get really good at it. All right, well, I'm sure we'll dip into the stuff a little bit more, but I do want to make sure that I actually have the space for your back story. So the second question I always ask everybody is, where was it that you ... Or what was the context in which you first had interactions with a computer? How old were you and kind of what was your interaction like at that point? Adam Wathan: Yeah, so I have sort of conflicting memories for a lot of some of the stuff. Not necessarily conflicting, but sometimes I have a hard time figuring out like what the timeline was, but some of my earliest memories of working with computers, probably the earliest one that I can think of. is when I was in grade ... It must have been probably grade two, maybe grade three, but I had this librarian at my school who worked with like some of the gifted kids to do little projects and stuff and me and him were working on the super old Mac that we had at the ... It was new at the time I'm sure, right, but like my memory of it's like the old school Mac where everything's black and white and stuff like that. Using hypercard to make this little project we went around and it was actually pretty cool. Adam Wathan: We got to like drive around the neighborhood and I got to like ask questions like different business owners about things and we put together this like little presentation in hypercard, and that's probably like my earliest memory of working with a computer and we got a computer in my family when I was pretty young too, probably grade four or grade five. It was just like kind of your standard ... It was like an Acer or Compaq PC or something with four megs of RAM and, you know, I can't even think, a 500 megabyte hard drive, and we got- Matt Stauffer: Yeah, a 486 or something like that. Adam Wathan: Like our internet a couple years later. Yeah, it was a 486 and I used to dick around on that, you know, looking up game tutorials for my Sega Genesis at GameFacts.com and stuff like that and- Matt Stauffer: What's the best game on the Genesis? What's your favorite, do you remember? Adam Wathan: Favorite Genesis game. I used to play the hockey games a lot. That was probably what I got- Matt Stauffer: You're so Canadian. Adam Wathan: The most fun out of. The funny thing is like I'm not super into hockey, but those were just the most fun like multiplayer games that you could play. That and like Mortal Combat and Street Fighter. Matt Stauffer: Yeah, of course. Adam Wathan: And all the classics. I didn't do much of the single player stuff, just mostly hanging out with friends and playing. Matt Stauffer: No Sonic and Knuckles and things like that? Adam Wathan: I did play Sonic, but I wouldn't say like I have, you know, nostalgic memories about how much I loved that game or whatever. It was a fun game but, yeah. Matt Stauffer: Yeah, I feel like not a lot of people have the same level of memories of Sonic as they did at Mario. I just never quite connected in the same way. Adam Wathan: No, Mario definitely has a more special place in people's hearts, I think. Matt Stauffer: Yeah, you actually got into this a little bit, but my next question is going to be kind of what was your first exposure to the internet? So was that primarily it at least at the start? Adam Wathan: I'm not sure if it would have been at school or at home, but yeah, it would have been most of the time that I spent on the internet would have been at my home desktop computer on our 14.4 connections we used to use. Matt Stauffer: Yeah. So when you were in middle school and high school, what do you think you wanted to do with your life? Did you know? Adam Wathan: I had some conflicting thoughts, so at one point when I was a kid I wanted to be a cartoonist, that was my dream actually. Matt Stauffer: I had no idea. Adam Wathan: I used to draw all the time and I used to like ... You know how you'd have like the book fairs at school, I don't know if you had those in the States. Matt Stauffer: Yeah yeah, Scholastic. We had them here. Adam Wathan: The Scholastic Book Fairs. Matt Stauffer: Yeah. Adam Wathan: I'd always be ordering like the how to draw this or the how to draw that books and I never got really good at it, but it was fun and then eventually I got into like playing guitar and stuff like that and I wanted to be like an audio engineer, but I also wanted to be a programmer and I really liked my programming classes in high school, so I ended up going to university for computer science, but I also considered going to college for music industry arts, which is a program that actually Steve Schoger, who some people might know actually did go to at the college that I used to go to. Matt Stauffer: Oh, he did? Adam Wathan: But I decided against it because it just didn't seem like a profitable career path, so I eventually chose computer science. Matt Stauffer: So you had programming classes in high school. Was this Java or C++ or what kind of stuff were you guys doing there? Adam Wathan: Let me think. So I think we ... I don't think we had computer programming classes 'till like grade 10 and we did a lot of like Pascal and we did C, and we did Java and then we have a web one which was later, which was kind of weird because the Java stuff was ... Even the Java stuff isn't ... When I think back to the fact that we did Java in high school, I don't remember doing any of the stuff that I know about Java now. Like I didn't know what object oriented programming was when I came out of high school, even though Java is an object oriented language. We just would write procedural code in like our main- Matt Stauffer: Good job, yeah. Adam Wathan: Java file or whatever, right? Matt Stauffer: Yeah. Adam Wathan: And stuff like that, but yeah. Matt Stauffer: What made you choose those classes? Adam Wathan: I think I just thought it was really fun to be able to make the computer do stuff. Matt Stauffer: Yeah. Adam Wathan: So I remember like one of my earliest memories of programming actually is when I was a kid I was like super obsessed with pro wrestling, that was like my thing. And I used to download all these like wrestling simulators so you could like ... It's so funny because they weren't ... they're not like games, right? They're like you create characters, you choose their move sets, you give them the statistics and stuff and then you like run simulations and it would spit out like texts, like this guy punched this guy, then this guy powerbombs this guy- Matt Stauffer: Right, and you're not actually controlling what they did, right? Adam Wathan: No, no, no. It's just a computer simulation based on random events- Matt Stauffer: That's fascinating. Adam Wathan: As well as like, you know, the statistics and attributes of the different wrestlers. There's a couple different programs that you could use to do that and I was always looking for different ones to test them out, and then one day I stumbled upon a tutorial online that was like make your own wrestling simulator in QBasic. Matt Stauffer: Oh, nice. QBasic, yes. Adam Wathan: And I was like, okay. And that was my first exposure to QBasic. I followed the tutorial and got everything set up and I didn't know how to like do random stuff or anything like that, so I never got very far with it. It was all just very like ... It was not like conditional logic or anything, you would just do this, this, this. Matt Stauffer: It just takes input- Adam Wathan: I couldn't figure out how to make it do exactly what the other things are doing, but I could make the computer do stuff, and that kind of got me interested in the whole QBasic programming stuff and then I just started looking into more like QBasic tutorials and finding out stuff that you could do, and I remember getting really into ... I don't think I'll ever remember the actual name of it. I found a site that I think might have been it, which is Pete's QBasic tutorials, which I don't know if that was the site for sure, but some of the content looked really familiar, but it had lots of tutorials on like making like tile scrolling RPG engines in QBasic and stuff and- Matt Stauffer: What? Adam Wathan: Where you could create like little sprite characters and you'd make these like 20 pixel by 20 pixel squares and lay them all out and make it scroll as you use the keyboard and stuff like that. So one summer I had this dream of making an RPG, which of course never even remotely happened, but I had a lot of fun just hacking around on the computer getting it to render this stuff and do stuff like that. So I think that's where I really got excited about programming because I don't know if I have a specific passion for programming more than anything else, but it was just like a really perfect kind of platform for just doing creative things, you know what I mean, and making stuff. It's the most like powerful tool for just like making interesting things that I know of so far, right? Matt Stauffer: Yeah. Adam Wathan: So I think that's what kind of got me into that. So I did a bunch of QBasic stuff messing around with that and eventually I started making my own little websites on Geocities an Angelfire and stuff like that and yeah, I've kind of been doing that ever since, so. Matt Stauffer: Yeah, I was thinking about how creation was definitely a trend for you. I mean between music creation, you know, as a guitarist and music production, you know, and the art and everything like this is it's wanting to make things happen and figure out what the tools are, so it's interesting hearing you say, you know, it's the most powerful tool that you can use for that. Adam Wathan: Yeah. Matt Stauffer: Do you ever draw still? Adam Wathan: No, not at all. Matt Stauffer: Do you have any of your old drawings anywhere? Adam Wathan: I might. My parents just sold their house and gave me a big box of like crap lying around that was mine. Matt Stauffer: You got to find something, man. Adam Wathan: I think there's a couple sketchbooks in there so I should maybe- Matt Stauffer: That would be amazing. Adam Wathan: Dig through those. Matt Stauffer: Please. Okay, so you went off to school for computer science and did you have a sense ... Did you have any shifts during school with what kind of aspect of CS that you were interested in or if ... And yes or no, what did you think you were going to do afterwards? Adam Wathan: Yeah, so I actually only went to the university for a single semester, so I did the first semester a bunch of the classes I did find fun like the ones that were direct programming, so we had like a C class where we'd basically get these weekly kind of projects that we have to work on where just have to go through a bunch of problems to get the computer to do that stuff, and that was the stuff that I was really interested in and really excited about, but then we also had classes that weren't as interesting, like digital fundamentals and stuff related to more like computer engineering sides of stuff which is interesting, but it didn't get me excited and want to work on it. Adam Wathan: That stuff was like a chore, and at the time I was also playing in a band and we ... That was all I wanted to do. Like we were playing shows and recording demos and stuff like that, so the computer stuff was not really a big focus for me at the time and I was commuting to school which was about a 45 minute drive away and living at home, so I didn't really get like embedded into the sort of university community that was there. Adam Wathan: So I didn't really like make any friends or meet anyone, I was only there for classes and that was it. So it was really hard for me to sort of, you know, become a university student. That was like this thing on the side I felt like for rest of my life, where my friends were and my hobbies were and stuff like that, so I only stuck with that for a single semester and then dropped out to just basically work full time while I reconsidered what I wanted to do, because it just ... I just wasn't enjoying university and I don't think it was the programming that I wasn't enjoying, it was just the educational side of it and having to get pulled away from the things that I was actually excited about to work on that. So I don't remember what the original question was, but that's kind of that story. Matt Stauffer: Well, no, and that's actually perfect and before I move on from that, I want to ask one question which is, was the distinction between doing versus learning abstract theory, was it about how concrete something was that was the difference between what you did and didn't like, or did I kind of miss that a little bit? Adam Wathan: No, I think that's true. I think the other thing is there's just a lot of classes that you have to take in university that aren't as ... they're not all really like cohesive, you know what I mean? I don't know what the system is like in the U.S., but in Canada we have university and college, which I think is kind of like college and community college in the U.S. Matt Stauffer: I think so, yeah. Adam Wathan: But the way that you pick your classes and stuff a lot of it is you have to go into the school and you have to go and sign up for different classes and you have different requirements, and you have to get credits and different things, but a lot of it is kind of up to you and they don't really put together like a cohesive curriculum. So I had to have X Math credits, X Elective credits, so I took like this history of music class, which is the only class I've ever failed in school in my entire life. Matt Stauffer: Oh, my God. Adam Wathan: And you would think that I ... Just because it's so damn boring, right? Matt Stauffer: Yeah. Adam Wathan: And I just like couldn't get into it at all. But everything was just kind of disconnected. There was like some math over here, some physics over here, and because at the early stages of things it's kind of like when you're in like first year of high school or something, they're just trying to teach you all these fundamental concepts- Matt Stauffer: Basics, yeah. Adam Wathan: Without kind of tying them back to the goal they you're trying to get into and I ended up going back to college years later which we can talk about maybe a little bit later, where the curriculum was much more cohesive and everything is sort of designed to teach you to be a programmer, and I really liked that experience. So yeah, I think it is just the fact that there was only one class that I actually liked, which was the programming class and everything else just felt like high school all over again, you know. Matt Stauffer: Yeah, yeah. No, I totally hear that. I mean there's a lot of conversations happening these days and I'll wait to go into them until we talk more about your later school experience, but around trade school versus university, versus whatever else and what are the pros and cons of each and I think a lot of it ... You know, one of the things I've come down to recently is that I've always been a pro university person with lots of caveats, and one of them is just like the school you're at really makes a big difference, and the classes you take and the professors you have. You know, there's a lot of factors that can give you a very, very, very, varied experience, even in the same type of program in the same type of school. So where did you go from there? You said you kind of were reconsidering your working full time, you were recording with your band and were you doing any touring at that point, too? Adam Wathan: No, we never got successful enough to do anything interesting like that. I was local shows and stuff, but yeah, so I was just working like crappy factory jobs basically. I'm trying to think what was the first job that I got after I left university. I have to try and reconstruct a time line, but the one I remember most specifically was working for a company where I was basically just in a factory building really high-end like antique looking stoves. Adam Wathan: So I did that for like a year while I still played in bands and did stuff like that and then eventually a friend of mine was working up in the Alberta oil sands like way up north and I would have all these construction projects to extract all the oil out of the sand and sell it of all over the world, and his dad actually ran the site up there so he had a lot of pull and one day he just called me and he was like, "Hey, do you want a job up here?" And I was like, "Sure." He's like, "Someone's going to call you tomorrow and offer you a job." And I didn't know- Matt Stauffer: That's awesome. Adam Wathan: What it's going to be. Like I had never seen the job description or anything, but this is just this guy's kind of style and so ... Yeah, I ended up working up there for two years doing like basically data entry stuff for the materials team, so I worked in an office in the frigid cold in Fort McMurray where it's like minus 50 degrees Celsius in the winters. Matt Stauffer: Holy crap! Adam Wathan: Our offices are these little portable trailers on the construction site and I was just there basically in Excel reconciling like purchase orders and invoices and making sure that, you know, we received the materials that we had paid for and that all this ... Just a bunch of really kind of monotonous data entry stuff, but for being like a 20 year old kid it paid really well and I did that for like two years until kind of that whole industry and economy started to suffer a little bit more because gas prices and oil prices dropped and they did a bunch of big layoffs which was ... So I got laid off, which was like a blessing in disguise really because I know a lot of people that basically just stayed up there forever because you can never get paid the same thing to come home. And I would work up there for 14 days straight, 10 hours a day and then they would fly you back to where you lived for seven days off. So I was constantly flying back and forth. which just made it really hard to have like a normal life, right? Matt Stauffer: Yeah. Adam Wathan: So yeah, I got laid off from that, came home, decided I would use that chance to try and get into like the recording stuff, because I was getting into recording a lot when I was up there and doing it when I was coming home just as kind of a hobby, but I thought why don't I try and like find some bands and record and like mix EPs for them and stuff. So I did that for like a year, which is a dumb industry to get into because bands don't have money, especially local bands, so you can't make a lot of money doing that, but what I found is while I was doing that I was using this tool called Reaper, which I still use out of my podcast and stuff like that, and I found that there was a bunch of features that I wished it had that it didn't have, and it was created by the guy who created Winamp originally, and it's like a very hacker friendly tool, so it lets you like extend it with Python or C++ or Lua now as well, so you can write all these sorts of like plugins and extensions for it and the API that they give you to do that stuff is like very powerful, you can access basically everything in the tool and write your own menu options and dialog boxes and all sorts of features and stuff. Adam Wathan: So I started getting into like hacking around with that doing really simple things and then one of the guys in the IRC chat for the software, kind of like this elite group of people who are like hacking on stuff there. I made this thing using Python and he was like, "You should port this to C++ so we can include it in this big extension that they maintain." and I was like, "I'd love to do that, I just don't have any idea how." and he's like "Well, okay, I'll help you." So for the next little while he would kind of like ... He kind of put together like a playground in this extension source code for me to like write my features in and help me figure out how to get XCode compiling it and all this different stuff, and that's when I kind of really like reignited my excitement and passion for programming because I was just having so much fun adding features to this tool and making it easier for me to do my work to the point where I was having way more fun adding features to the tool than I was actually using the tool to record bands. Adam Wathan: And I didn't even get back into web development or anything at that point. I hadn't made a website since like high school. So that's when I decided you know what, I think I'm going to go back to college and do this programming thing again, but I decided to do college and study university specifically because I knew like what I didn't like about university and I wanted to do something that was a lot more practical and focused on making you into a programmer than it was, you know, educating you about computer science. Matt Stauffer: So I had been meaning to ask and that's helpful. Are you familiar with the concept of a trade school? Adam Wathan: Yeah, like where you would go to learn to become like an electrician or something like that? Matt Stauffer: Yeah, that's not the same thing, right? You're more talking about it's a school, but it's more like single focus sort of like our community colleges, but I was wondering whether colleges like a little bit different than communities or if it's just- Adam Wathan: Yeah, I'm not sure. So the college I went to is Conestoga College. I'm going to pull up the website now, but basically here college programs are usually two-year programs and you get a diploma, and university are four years and you get a degree, that's kind of the fundamental difference. So I'm going to try and pull up like the actual program that I did here so I can kind of talk a little bit about the actual curriculum because I think it's kind of interesting. Matt Stauffer: While you do that, this is definitely similar to community college. It literally even in the Google preview says your community ... Ontario Community College and this is definitely not trade school, definitely community college, if that makes sense. Adam Wathan: Yeah, so I did the software engineering program there, and not the computer programmer course, which I got kind of turned on to that by asking around to friends who had gone to the school to kind of figure out like, you know, what are you supposed to do, but if you look at the actual program courses here we can maybe like link to this and then show it to people that are interested, but like in the first year we had classes like software engineering fundamentals, operating system fundamentals, C, C++ programming, computer security, object oriented programming, some of this has changed, but then year two we did like web design and development, relational databases, Windows and mobile programming, microprocessors and embedded systems, software quality, so like in school we learned about automated testing, which is pretty cool. Matt Stauffer: Nice. Adam Wathan: You never learn that in university. Advanced computer security, mobile application and development. Yeah, so it was just like all programming. Every class was programming, but it was just focused around some different kind of element of it using different technologies and stuff like that. So the nice thing about that is that college is really close to my house and unlike university where the schedule it's like really weird, sometimes I'd go to a three-hour lecture and then have seven hours off then have to go back in the night for a one-hour class. Like this is structured so much similar to high school, you know what I mean? Adam Wathan: Like you'd get there in the morning, you'd leave in the afternoon, so you're there for a long period of time, you get to like meet people, you get put on projects with people, and I really got into what I was doing there in terms of like I made a lot of friends, you know, that kind of became like my focus which was I think what made me not stick it out in university. It was just like such a side project, whereas I was able to really sort of like embed myself into what we're doing in this program, so- Matt Stauffer: That's really interesting. Adam Wathan: Yeah, that went really for me. So I did that for two years. It's a three-year program, but the way they do it is kind of weird. They have like three years with co-op, I don't know if people use that term in the U.S. It's kind of an internship- Matt Stauffer: I don't think so. Adam Wathan: Like paid internship. Matt Stauffer: Oh, yeah. Adam Wathan: So if they do like two years of schooling and then for 18 months you go out into the workforce. There was like four work terms across those 18 months I think, something like that. And some people do them all the same company, some people do four different ones, some people split up however, but you get paid to do that, which is pretty cool like 18 bucks an hour or more depending on who the employer is, and then once you're done that kind of co-op internship stuff, you go back and do your third year of schooling and then you get your diploma and then you're done. Matt Stauffer: Oh, cool. Adam Wathan: So I just did the first two years, and then I did my co-op at Vehikl who were called Chrome Media at the time, and I think I was like the only person to apply for that job because everyone else was trying to get a job at Desire2Learn which is a company that makes like education student management software, and it's all C# and Windows stuff and that's what they teach us in school so that's what everyone was excited about and they were kind of like the cool, hip company in the area, but I was like the only kid in my class that used a Mac, so doing the Windows stuff was painful for me. I had to like boot up a VM and do stuff like that, so even with all our projects I would do in school I was always trying to find technologies that I could work with easier on my Mac. Adam Wathan: Because we had a lot of like web based projects, even though we didn't have a lot of web specific courses, but in the later years we'd have like a project that was a two-month project and you could choose the technology, which is cool, so some people did C#, some people did, whatever. I chose PHP because that was the only programming language I knew of that you could do dynamic stuff on the server. Like at the time I didn't know that oh, you can use Ruby to do that or Java or any of these other languages, I just knew from like trying to create PHP scripts I could accept form submissions when I was 16 years old that like PHP was the language that you do ... I used to do stuff on the server, so I started looking into, you know, tools for PHP that could compare with like ASP or C#. Matt Stauffer: Like MVC. Yeah. Adam Wathan: That like framework and I found my code igniter and stuff like that and so we started messing around with those sorts of things, and I was lucky enough to find a handful of people that wanted to work on those technologies with me instead of doing the C# stuff and they were all pretty bright people, so we did a bunch of projects using that stuff and then when it came time to look for co-op opportunities I applied to Desire To Learn and they never got back to me, which is great because if they had and I had gotten a job there I'd probably still be a C# developer now. Adam Wathan: Instead I saw this tiny, little company that was only three people at the time that was doing like Magento sites and some custom app development in PHP, and I was like you know what, I'll apply for that and I ended up being like the only person in my class who applied there and that ended up being like the best way it could have ever possibly worked out because I met some really cool, talented people there that really helped me get my career to where it is now and encouraged me to speak at user groups and get involved in open source and stuff like that. Matt Stauffer: That's awesome. Adam Wathan: So after I went and worked there I did my whole kind of internship co-op stuff there and I just never went back to school because I had a mortgage and stuff like that. I was like 26 at the time or 25, 26, and I couldn't really afford to like not get paid for another year or going back to school and the whole point of going to school was to be able to get a job. and now I had a job and even if I wanted to leave there, well, I had a job doing programming for a living on my resume now so it didn't really matter, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So I got what I needed out of it and then kind of got into the workforce doing PHP stuff and actually like even when I started there, that's when I really got seriously into Laravel stuff. We actually started using Laravel 4 on a client project before it was officially released when it was still like in a beta, which is cool, so I was getting paid to write Laravel code on my very first programming job. Matt Stauffer: Which is amazing. Adam Wathan: Pretty neat. Matt Stauffer: That's very cool. And who are the three? It was Chris and Grant and who was the third person, do you remember? Adam Wathan: Chris, Grant and Caryn, who is like a ... She's a product designer. Matt Stauffer: Product designer, yeah. Adam Wathan: A UX person there. Matt Stauffer: I didn't know she was employee number one. Adam Wathan: I don't think she was employee number one. They kind of went through a couple different iterations of the company doing different stuff- Matt Stauffer: Got it. Okay. Adam Wathan: Over time, but when I got there it was the three of them and they kind of had their thing figured out. Matt Stauffer: Very cool. All right, so the story from there you did at Vehikl ... So when did you start speaking? Was it the Laracon EU testing talk? Was that your first kind of big conference, or what was your speaking journey like? Adam Wathan: So the first talk that I ever gave was like an intro to Laravel talk at a Meetup that we created so that I could give that talk basically like the vehicle we created like the Kitchener-Waterloo Laravel Meetup which only survived like a few Meetups because we also had this like Guelph PHP user group which half the time we were doing Kitchener anyways and that eventually just became like oh, we'll just do everything there because we'd meet up once a month there. But yeah, so I gave a talk at that user group to about like 30 people or something, which was my first time doing any speaking like that, and I may have done another talk after that to like a local Meetup, but yeah, the first conference talk I think was the community day at Laracon EU 2015 or maybe '14, yeah, and I did the talk- Matt Stauffer: I remember it, but I don't remember the year so, yeah. Adam Wathan: Yeah, I can't remember what the talk was called, TDD the good parts, I think, and then after that I think I gave a talk at True North PHP in Toronto at Chris Hartjes and Peter Meth's conference and from there I just kind of got into it more and more. Once you kind of have one conference under your belt, it's a lot easier to get into the other ones, especially if you make the effort to get them filmed and post them online and be able to use that stuff to help show people hey, I can actually do this and it'll be fun. I'm a grown up I can do a good job. Matt Stauffer: Cool. So at some point you were using Laravel, and you became more aware of some of the world's around there. You were looking into things in Rails, you were talking about Ruby some. What was that journey like from Laravel being the thing that you were spending all your time in, to kind of expanding your exposure to the rest of the web world, I guess. Adam Wathan: I can't say ... I can't think of a specific ... I can't remember exactly how I heard about some of these other things, because like I said, I only remember being in college and being like well, PHP is what I use on a server. I didn't even know Rails existed. Like in some ways, in a lot of ways I wish I had known, because I probably would have never become a Laravel programmer. Not because I don't have ... I have anything against Laravel, but throughout the years it's become pretty clear that philosophically I'm much more aligned with the way people think in kind of the Ruby world, right? Adam Wathan: So I was already kind of like deep into Laravel stuff and feeling like pretty fast and productive with it and I'm sure all I was doing was poking around the internet looking for tutorials, reading things about how to do this and that and somewhere in there someone said similar to how this works in Rails blah, blah, you know what I mean? Like eventually you just kind of like start hearing about these things. Matt Stauffer: Yeah, yeah, yeah. Start hearing it, yeah. Adam Wathan: And the Laravel community was a lot less mature than it is now at that point, so a lot of the really good content that was out there was focused on Rails. Like Rails had a big head start on a lot of what we're doing in the Laravel world. Rails came out in like 2004 I think originally. And there's blog posts written in like 2008, 2009 that are still really useful blog posts for people writing Laravel stuff now, so it was actually really interesting for me to discover that kind of whole world because at the time this was like 2013, 2014 when I was learning Laravel originally. Maybe ... Yeah, probably 2013, there was like eight years worth of high quality Rails content out there. So if I could just figure out- Matt Stauffer: Yeah, sitting out there already. Adam Wathan: How to translate the syntax from Ruby to PHP, you know, there was all this content out there that could make me a better Laravel developer, basically. So I got really, really deep into all that stuff and that's when I discovered companies like Thoughtbot that had done tons of blogging and written books and put together video tutorials or Gary Bernhardt's Destroy All Software, which is all Rails stuff. There was just so much good stuff out there and that's where I basically focused all my learning at that point was taking everything that people had already ... Like I make this joke a lot of the time that any time like someone runs into a problem with Laravel, like a design decision where you're like okay, well, what's the best way to do this in Laravel, take the current year subtract four years, include that in your search query and look for how to do that in Rails and there will be like 100 quality blog posts out there. Adam Wathan: So yeah, I got really into just kind of researching what people were doing in these other ecosystems and finding out what made sense to try to port back and apply to what we were doing in PHP stuff and yeah, that's kind of been like my shtick, I guess. I'm always looking outside my existing community to see if ... I think of myself as like Christopher Columbus like going across the sea to the foreign lands and bringing back treasures for people. Matt Stauffer: Nice. Yeah, so let's see. So you worked at Vehikl for a while and do you know how big Vehikl was when you left? Adam Wathan: So it was still actually just the four of us- Matt Stauffer: Oh, yeah? Okay. Adam Wathan: When I left, which was kind of like my motivation for leaving. I still was really enjoying the work that I was doing there, but I had this like nagging feeling that I was missing out on the ability to grow faster by not being part of a bigger team where there was more ... Not more experienced developers like developers with more experience, but just more developers- Matt Stauffer: More people, yeah, yeah. Adam Wathan: That were experienced- Matt Stauffer: With different experiences, yeah. Adam Wathan: To learn from, right? Matt Stauffer: Yeah. Adam Wathan: And that was kind of stressing me out at the time, so I ended up leaving to go work for a company that did Rails consulting, but when I got there I got dumped onto a project doing C# and Angular, so I only stayed there for like three months because I want to blow my brains out ,and I soon ... Like within the first week of working I was like I can't believe I left my other job, this sucks so bad. And then after being there for a couple months Tighten, this company out of Chicago that does some Laravel stuff, I don't know, people might have heard of them, posted a job posting on the old Laravel job site and I applied for that and ended up going to work there for a while. Matt Stauffer: It's so weird because I've been trying to figure out how to ask you questions about that time, and it's really tough. I don't know how, but maybe I'll just try and throw a broad one at you and see if that goes somewhere. What was the area you grew in the most while you're working at Tighten? I think that may be a question to start with. Adam Wathan: That's a hard one. I can't think exactly what ... I think the biggest changes for me are the things that I had to figure out the most was like the remote working thing. That was like a new thing for me and figuring out how to ask for help with things and get stuff done and get help from people in a way where like I'm just so used to ... I was just so used to working in an office where if you're frustrated with a problem, like the people sitting around you can tell, you know what I mean? Matt Stauffer: Yeah, yeah, yeah. Adam Wathan: And that's not as easy in a remote company, so you have to figure out ways to manage that sort of thing, especially when people are not always like available at the same time because everyone's kind of working ... Like even though you have kind of standard-ish hours, there's still a lot of a synchronicity to it, right? Matt Stauffer: Yeah, yeah. Adam Wathan: Everyone has different calendars with different things going on, which is very different than being in an office. Yeah, people have stuff scheduled and calls and stuff, but you can like see when someone is available. So figuring that out was probably ... That was probably the biggest change and area for me to kind of figure out how to work that way, and yeah, it was good though. I think the remote working set up is the way to do it, as long as you can make sure people are able to communicate when they need to communicate and feel ... You have to be more deliberate about asking for help, which can be hard, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: If you can just be frustrated and people can tell and people offer to help, that's one thing, but sometimes it's like you feel like you have to ask for help every 15 minutes with something, especially when you're starting, right? Matt Stauffer: Yeah. Adam Wathan: And that could be like ... It's like a degree of shame or something like associated with that. That's hard to get over. Matt Stauffer: We've been working ... That's probably been the biggest barrier with bringing on juniors is that the combination of junior, plus remote, it's really an extra level of shame. Adam Wathan: Plus new job, right? Matt Stauffer: Yeah. Adam Wathan: Which is hard for even for like an experienced person, yeah. Matt Stauffer: New job, remote, new tech, I don't know what I'm doing, everybody else here has got it and I'm asking for questions every 15 minutes, I feel like I'm bothering people. Adam Wathan: Yeah. Matt Stauffer: That's definitely tough. Adam Wathan: Yeah. Matt Stauffer: So this is the last question I'll ask about your time at Tighten, but one of the things that was really impactful from our perspective was that you had a lot of thoughts about how a company should be run and a lot of them came from watching Base Camp and and Thoughtbot, and thinking about concepts that you've talked about in the podcasts and some of the times I've talked with you about on podcasts of things like no estimates and stuff like that, where there's a certain way of thinking, and I think that Dan and I say often that your time at Tighten was really impactful in terms of just kind of like sharing those things with us, but it wasn't always just as easy as Adam comes in and teaches something. Matt Stauffer: Often it happened in the context of, you know, there was a ... Not necessarily there was a conflict, but there was sort of like well, why is it not happening this way and we'd be like, "Oh well, I don't know. We'll figure that out." So I was wondering during your time at Tighten, do you feel like you learned anything about what you wanted to kind of do when you grew up kind of vibe in terms of teaching, or were there things that you learned about how you think software should be written or something that happened in the context of those learning moments and those conflicts and everything that we had during those times? Adam Wathan: Yeah, I'm try to think if there's anything specific I can take away as like a learning ... Matt Stauffer: And if not, no worries, I'll just edit out the question. Adam Wathan: Yeah, I think like ... I mean, what I like working on the most at Tighten was being able to create projects for companies, build stuff for other people. I think if anything, what I maybe took away is that ... What's the best way to say this? I like having control I guess of like my own destiny in that sense because working with companies to build new projects for them there's like this of course this whole layer of stuff that comes with that that isn't there when you're just building something for yourself of course, right? Matt Stauffer: Yeah. Adam Wathan: And it can be a real challenge sometimes to get people on board with building something in a way that is in their best interests, even though they might not understand why or agree why, and that's just like a whole thing that you have to figure out how to navigate that can just get in the way of what you want to do which is just like creating the best thing for solving a problem for them, right? Matt Stauffer: Yeah. Adam Wathan: So I think being able to get into what I'm doing now where I get to like create training stuff and stuff like that has been a nice change in that sense, because it lets me focus on just doing ... Creating the thing that I want to create. But yeah, like you said, like I think a lot of the reason that I cared so much at Tighten and everywhere I worked about how to try and run these projects successfully is for that same reason because I just want to make the great project, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: And I think everyone is on the same page there, right? Like you want to figure out a way to navigate the other stuff and minimize it so that you can just focus on doing the work, but because I just care so much about doing the work and that's what I want to do, that it kind of pulls me down this path of figuring out like okay, what is stopping us from being able to just do the work and what ideas are out there in the world that people have that can help us focus on- Matt Stauffer: Help us, yeah. Adam Wathan: Just doing the work for people. So I don't know if that really answers your question in terms of I guess like a specific kind of learnings or take aways, but in terms of, you know, that sort of project management side of things, I think that's sort of like where my motivations at least come from to care about that stuff. Matt Stauffer: Well, it's funny because you say everyone feels that way and of course everyone, you know, hopefully wants to really do a good job for the client, but it also reflects a little bit back on what we were talking about earlier about you love doing things to the best they can possibly be done and it's not just your things, you know, it's also other people's things. Like every project you have a hand in, you want it to be the best possible thing, and if there's stuff getting in the way of that, well, then that's stuff that you need to kind of shave off so that it can just be the optimal it will be. So I totally hear that and that makes a lot of sense. Thanks for answering that kind of convoluted question. Matt Stauffer: So the transition from there was it was during your time there that you wrote your book and you released it and you were able to transition it to be doing your own educational stuff full time. So in terms of that switch, when and what was the process like for you to start thinking you know what, working at somebody else's consultancy may just not end up being the thing for me and I want to try info products or I want to try my own products or something like that? Like what was that journey like for you? Adam Wathan: Yeah, so I think for me what really happened there as I put together this book and released it, I didn't really have crazy expectations for it or anything like that. Again, it was just one of those things where I've always just really liked making polished things that are finished that you can look at and be like this is done and this is tidy and this feels nice. And I used to do that with even like trying to contribute tutorials to Game Facts and stuff back in the day. I never got anything on there, but I would just like agonize over like making some sweet like ASCII art title at the top of these like stupid plain text files- Matt Stauffer: That's perfect. Adam Wathan: And I just wanted it to feel like a polished thing, right? So that was kind of like one of my biggest motivations for making the book was first of all, I've always been interested in like creating something and selling it and seeing like what it's like to make your own money on the internet sort of thing, but I also just like ... It's hard to think back to it now because I have a few products now, but back then I kind of felt like I just had never got to finish anything, if that makes sense? Matt Stauffer: Yeah, definitely. Adam Wathan: And this is a common thing that I think like agencies deal with a lot in general, right? As you get to work with a client, you do a lot of really great work for them, but you're not necessarily like always around 'till the end of the project because maybe eventually they hire their own team which is one of their goals from the beginning, right? They're trying to get like a head start on something so that once they have a little bit of traction they can build their own team around it, because of course that's more economical way to handle that. Adam Wathan: Or the other end of the spectrum is you start working on a project for someone and it turns out that they just aren't able to hold up their end of the bargain really and the project is just not going to work out and you do work for them for six weeks and then they realize like you know what, I'm not ever going to be able to make an app company properly, so you kind of just say okay, thanks for your work, you did a great job, but like that's the end of the project. Like I've worked on so many projects that never even went to production, you know? Matt Stauffer: Yeah. Adam Wathan: Or got any users or anything like that and that's kind of like a ... At the time that was kind of "I just want to finish something. I just want to have something that's done." I did that with my Nitpick too, that little SaaS something- Matt Stauffer: Yeah, I remember. Adam Wathan: That I built, and the whole goal there was just the same thing, like I want to build an app 'till it's done and then put it out on the internet, and that was just like a cool feeling. So I did the same thing with the book and then the book ended up being, you know, pretty successful, and before I worked on that book, I had the idea all along that what I really wanted to do was some sort of testing thing, like some TDD book or course or something, but it was just like ... Sounded like so daunting, it just sounded like a big project. Adam Wathan: So I stumbled on this idea to the collections thing, and that seemed so much more manageable, so once I had finished that and, you know, it was pretty successful, I thought you know what, if I want to do this like testing product, this is the best possible chance that I'm going to have to be able to spend the time on that because the book did well enough that like I can take six months off and focus on this thing. So I thought you know what, I'm not going to get a chance like this again. If I don't do it now then this money is just going to go into an RSP or something and it's just going to ... Yeah, of course that's good, I should have money saved away for a time. Matt Stauffer: Right, right. Adam Wathan: I'm not going to ... Like it's not going to change my life in any way, I'm just going to keep doing the exact same thing that I'm doing. The book's going to be out there, but I'm not like seizing the moment to use it as an opportunity to try something. So I thought you know what, this is like the only chance that I'm going to get to probably do this, so why don't I try it out. So that's when I decided to move on to try and to just do something for myself and see how it panned out and I did the testing course, which was way bigger than I even was worried about it being originally. Adam Wathan: So it's a good thing that I didn't try and put it together when I was still working, but that did really well too, and that's been able to let me focus on continuing to do more stuff like that. I'm always able to stay just like a little bit enough ahead of where I need to be that I have some time to figure out what the next thing is going to be, you know, and I'm just kind of like building the bridge as I try and cross the river. Matt Stauffer: Yeah, that's awesome. I remember one of the things that you said when you let us know that you were going to be going off to do the thing full time and you said, "You know, I don't know how this is going to work out, but I know that if it totally flops in six months I can apply to one of a myriad programming jobs, but if I don't try this, there's no guarantee I'll ever have this chance ever again where there's the traction for my book and I have enough money to kind of try this thing and so I got at least try it." And that really stuck with me, just the idea that like ... And I mean I've had that happen where I've had an influx of cash and it just kind of goes and spreads out across retirement savings and health expenses and whatever else, and your life is exactly the same even though you put all that work into it, and so that idea of those are those moments and it's scary, but like what's the worst thing that's going to happen? I'll use up all the money and then apply for jobs on the other end. Matt Stauffer: You know I'm a little less stable because I'll have to be applying for a job versus having once settled, but there's no guarantee that your job's not going to shut down the next day, you know, and so like the idea that oh well, everything's perfect now, I'll be put ... No, no. You know, I really love that kind of thinking and obviously at least so far it's working out really well for you, so I'm hoping that's an inspiration for other people to kind of consider taking some of those leaps. Matt Stauffer: I would love to ask you a million questions about how you think about product and stuff like that, but we're longer than usual, and thankfully other people have asked you that on their podcasts, so I'm going to try and link some of your stuff with Justin Jackson and some other people, also Full Stack Radio, even though it's you interviewing other people, you do learn a lot about the interviewer by the questions they ask. So all this super interesting stuff that we don't have time for, I hope that we'll be able to ... People will be able to kind of suss that information out anywhere else. Matt Stauffer: But I think one of the things we have not talked about, so every time I'm going to be interviewing somebody in the Laravel podcasts I go into Tighten Slack and I say I'm about to interview this person and I'm actually opening my Slack right now to make sure that new questions ... Yep, a couple of new questions came in, and I say, "Are there any particular questions that y'all want to ask them?" And so I ask that question in Tighten Slack, which is kind of funny because you are still in some of our Slacks and you used to work there, but there's still some questions. Matt Stauffer: So the first question came up for you is, "Do you even lift, bro? Which first of all is fantastic, but second of all in our Slack that actually triggers a gif of you doing a lift, so it's perfect. So we haven't gotten to talk about that at all. Adam Wathan: Yeah. Matt Stauffer: Where did that fit into your whole world? Can you tell everybody a little bit about kind of that part of your life? Adam Wathan: Yeah, so when I was working up in Fort McMurray in Alberta, I've always been kind of like an overweight kid. Matt Stauffer: Same. Adam Wathan: And like most people, like you just want to look better, right? Matt Stauffer: Yeah. Adam Wathan: So when I was working up there, you're just like so bored and you're not using your willpower for basically anything else that it was like an opportunity to finally try and do that seriously, right? It's actually funny because if you follow along with like the bootstrap podcast like Ian and Andre, Andre is kind of doing the same sort of thing. Like he decided to basically take off some time during the year from any really like mentally sort of straining work. Like I think he's just mostly focused on doing some consulting stuff and I'm not even sure if he's working the same amount of hours and stuff that he was doing normally, but he decided like, you know, I want to take this opportunity with this kind of reserve of mental energy that I have and focus on something like really life changing thing, which for him was like getting in shape, right? Matt Stauffer: Yeah. Adam Wathan: And it's funny because I never really thought about it that way, but when I heard him phrase it that way it's like you know what, that's exactly like why I was able to do it originally, because I just didn't have anything else pulling at my brain. So when you're going to make dinner or even going out for dinner with your friends it's easy to order the vegetables instead of the fries because like I just haven't used any of that brainpower, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So when I was working out there, I just ... It was easier for me to start eating a lot better and get into like home workouts and stuff like that and that led me down this whole path of eventually discovering like strength training. Pro tip; if you're a programmer who wants to like start exercising, the terms that you should be Googling are strength training. That is the term that's going to find you ... At least I think is going to find you the stuff that's going to resonate most with how your brain works in terms of things being really measurable and being able to like science the shit out of everything with lots of percentages and math. Adam Wathan: But eventually I kind of stumbled onto this like form of exercise where you're just focusing on like lots of really high bang for your buck compound exercises like multi joint movements like squats and deadlifts and bench press and overhead press and chin ups and barbell rows and stuff like that, and once I finally found the good stuff online which was like Mark Rippetoe's content and stuff like that, you learn like what you should be doing is progressively trying to increase the weight that you're lifting. Like a lot of people just go to the gym and they just like pick whatever they think is going to be like a good weight to lift that day and just do it or whatever, but they're not actually tracking their progress, so they don't really make progress, but if you can develop a plan where you know like okay, this week this is what I'm lifting, next week I have to try and lift this and it goes up and up and up. Adam Wathan: For me that's what was able to keep me kind of motivated because I was seeing progress on paper because seeing progress in the mirror is a lot harder, it takes a lot longer and it's a lot more subtle and gradual, and if you're not taking the pictures of yourself topless in the mirror every week to compare like okay, do I actually look like I'm getting in better shape, but if you're just like blogging stuff in a notebook it's easy to say okay, I bench pressed 185 for six reps last week and this week I did it for eight reps, that's pretty cool. So I've kind of gone into this whole thing of getting stronger and lifting and eventually started competing in power lifting competitions because like with everything I do I have to take it to the extreme. Adam Wathan: So what started as like 185 pound like skinny fat kid to trying to like look better without his shirt off, turned into like a 260 pound dude deadlifting 600 pounds and winning nationals power lifting gold bells. That was just something ... I would still be doing that, but it's a hard ... Once you get there's like a point of diminishing returns, which I think I definitely hit, where you're just more likely to get injured than you are to make progress, and I've hurt myself a couple times and I have a nagging back injury now that doesn't bother me day to day, but any time I get back into lifting, no matter how light I start, after a couple weeks I do one rep not 100% perfect and my back is messed up for a week, it's really frustrating. Adam Wathan: So it's hard for me to really stay motivated into it these days because the thing that kept me going was like getting stronger. So going to the gym to lift less than I did before is like, whatever. I still need to get back into it more, but yeah, that was a big thing for me for a while. Matt Stauffer: It's funny because as you were saying that, a light was going off in my head. I switched to a new trainer about four months ago and it was the first time the trainer has been trying to teach me the skills to be able to stop working with him versus just kind of like giving himself job security by just kind of telling me what to do. And he's a Mark Rippetoe guy and he just moved to Chicago, or he's moving to Chicago this weekend and so he's like here's everything I know and he set me up with this thing called ... Have you ever heard of the 5-3-1? Adam Wathan: Yep, that's what I always used to do. Jim Wendler. Matt Stauffer: That's literally what I started it this week at the new gym on my own and I've got a 5-3-1 calculator. Adam Wathan: That's awesome. Matt Stauffer: I plug all my information in. Adam Wathan: It's amazing. Jim Wendler is like he's the DHH of weight lifting. Like he's just got that same like everyone over complicates things attitude and there's this quote that I ... So this is so funny because like so many people who get into power lifting are like super nerds about this stuff, right? Like the amount of like just nerds that get into this stuff is outrageous just because of the fact that you get to make spreadsheets, you get to calculate like your estimated one rep max based on how many reps you lift this way or whatever. Adam Wathan: And I'll never forget there's like a F.A.Q. section in one of Jim Wendler's books where someone asks a question and it's like, what is the best ... I can't remember exactly how it was phrased, but basically the question is like what incline should I be using on like

god canada chicago google canadian toronto states principles mac educators practices skype windows sonic patterns wa saas ram rpg excel slack api pascal cs street fighter python meetup eps java symposium vm celsius judo rails reaper band aids duh co creators christopher columbus basecamp googling knuckles php lua scholastic sega genesis meetups tighten vue irc tailwinds angular asp acer kitchener magento sounded tdd markdown justin jackson fort mcmurray xcode mortal combat winamp uncle bob ascii rsp laravel dhh geocities slacks ryan singer angelfire tailwind css mark rippetoe conestoga college adam wathan jim wendler thoughtbot qbasic agile practices gary bernhardt refactoring ui full stack radio steve schoger chris hartjes vehikl

Destroy All Software With Gary Bernhardt

Play Episode Listen Later Apr 30, 2018 52:06

Many developers enter the market from backgrounds that don't involve a computer science degree, which can lead to blind spots of how to approach certain types of problems. Gary Bernhardt produces screen casts and articles that aim to teach these principles with code to make them approachable and easy to understand. In this episode Gary discusses his views on the state of software education, both in academia and bootcamps, the theoretical concepts that he finds most useful in his work, and some thoughts on how to build better software.

software destroy linode gary bernhardt

Choosing A Conference Talk Topic

Zeal #Interestings Podcast

Play Episode Listen Later Mar 1, 2018 26:03

On today's episode we discuss "How to Choose a Talk Topic", an article written by Gary Bernhardt. We also go into the process Zeal team members Adam Cuppy and Randy Coulman use to come up with and choose their talk topics. "What within this is the simplest concept that should be known, and how can I build an experience around relaying that concept to an audience" - Adam Cuppy, COO and Co-Founder at Zeal Featured Article https://www.deconstructconf.com/blog/how-to-choose-a-talk-topic Leave a review and get stickers! 1. Go to our page on ITunes and leave a review 2. Take a screenshot of your review and email it to podcast@codingzeal.com 3. If you're one of the first 100 people, we'll get your mailing address and send you your stickers! This podcast is brought to you by Zeal

speaking co founders event conference code coo public speaking meetup zeal gary bernhardt

Episode 96: Teaching Burden and Unknown Unknowns

Soft Skills Engineering

Play Episode Listen Later Feb 17, 2018 27:49

This week Jamison and Dave answer these questions: I know that teaching others is important when working on a team so that the team can grow and get better. But what happens when one member of the team, despite being the friendliest person in the world, is missing so many required skills for his job that it becomes impossible for me to do anything besides teach him? I recently heard the concept of “known unknowns” and “unknown unknowns”. It’s the unknown unknowns that get me. Sometimes I ask a question of a seasoned developer and they seem annoyed because it’s something that I could have looked up. They knew it but I didn’t. Sometimes I ask a question and they are eager to help because the question is interesting and they know it will be good for me to learn. I struggle because I don’t want to waste my time or theirs, but I want to work through things and learn. How do I do this well? Wikipedia has a whole article on the origin of the phrase “unknown unknowns”. Also, Gary Bernhardt has a fantastic talk called Ideology about “unknown knowns” - things we believe in software without even realizing we believe them. Hoobastank.

teaching wikipedia burden ideology unknowns hoobastank gary bernhardt

Podlodka #37 – Рефакторинг

Podlodka Podcast

Play Episode Listen Later Dec 10, 2017 86:04

Скорее всего, вы любите рефакторить код, как свой, так и чужой. Вопрос в том, насколько правильно вы это делаете. В этом выпуске мы, с помощью iOS разработчика из Яндекса Виктора Брыксина, разобрали эталонный алгоритм рефакторинга по шагам и определились, как закрыться от большинства потенциальных проблем. Виды рефакторинга, частые заблуждения, роль юнит-тестов и архитектурные недостатки – весь набор юного рефакторера в одном месте. На правах рекламы: Приходите работать вместе с Виктором над секретным проектом Яндекса. Так как проект пока секретный, то используется вакансия браузера. Но, если вы подадитесь на нее, он абсолютно точно о вас узнает :) https://yandex.ru/jobs/vacancies/dev/dev_ios_bro/ Поддержи лучший подкаст про мобильную разработку: www.patreon.com/podlodka Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях!  Telegram-чат: https://t.me/podlodka Telegram-канал: https://t.me/podlodkanews Страница в Facebook: www.facebook.com/podlodkacast/ Twitter-аккаунт: https://twitter.com/PodlodkaPodcast Содержание: - 00:00:33 - Благодарности подписчикам на Patreon - 00:01:30 - Знакомство с гостем и детали про секретный проект Яндекса - 00:03:23 - Определение рефакторинга - 00:10:00 - Какие проблемы решает рефакторинг - 00:17:10 - Какие проблемы рефакторинг не решает - 00:19:43 - Эталонный алгоритм рефакторинга - 00:24:27 - Как обосновать рефакторинг менеджеру - 00:48:17 - Как оценить время на рефакторинг - 00:54:27 - Практические примеры рефакторинга - 01:00:52 - В каких случаях не надо думать про рефакторинг - 01:05:05 - Как рефакторить UI - 01:11:21 - Частые заблуждения - 01:16:30 - Где искать проблемы в архитектуре - 01:22:46 - Подведение черты выпуска Полезные ссылки: - JSQMessagesViewController https://github.com/jessesquires/JSQMessagesViewController - Как все починить и ничего не сломать: работа со сложным кодом при помощи тестов https://www.youtube.com/watch?v=-JGGw4SN6NA - Шедевр безумного водопроводчика: https://medium.com/@bober_maniac/masterpiece-of-a-mad-plumber-cd4e5107b8e0 - Boundaries by Gary Bernhardt https://www.youtube.com/watch?v=eOYal8elnZk - Чистый код. Создание, анализ и рефакторинг https://www.ozon.ru/context/detail/id/5011068/ - Рефакторинг. Улучшение существующего кода https://www.ozon.ru/context/detail/id/1308678/

boundaries ios telegram ui gary bernhardt

78: Ben Orenstein - Our All-Time Favorite Refactorings

Full Stack Radio

Play Episode Listen Later Dec 5, 2017 50:37

In this episode, Adam and Ben Orenstein share nine of their favorite refactorings that you can use to clean up your code. Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Codeship, check out how they performed in Forrester's latest Continuous Integration Tools report Links: Refactoring Rails, Ben's refactoring course The 30 Day Code Quality Challenge, Ben's free 30-day code quality course Refactoring from Good to Great, Ben's popular refactoring talk Decompose Conditional, an example of "make the implicit explicit" Introduce Parameter Object Replace Conditional with Polymorphism Chasing Perfect, Adam's talk about refactoring with polymorphism Introduce Null Object Replace Method with Method Object "Why Ruby Class Methods Resist Refactoring" from the Code Climate blog Collection Pipeline, Martin Fowler's article on replacing loops with array transformations Curing the Common Loop, Adam's talk on refactoring loops and conditionals Refactoring to Collections, Adam's book and video series Boundaries, Gary Bernhardt's talk about OO, functional programming, and immutability

collections forrester oo martin fowler ben orenstein gary bernhardt

Episode 17: The Elm Programming Language With Corey Haines

Tech Done Right

Play Episode Listen Later Aug 9, 2017 45:30

The Elm Programming Language With Corey Haines Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), and leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2). Guest Corey Haines (https://twitter.com/coreyhaines): CTO of Hearken (https://www.wearehearken.com/), creator of code retreats, and author of Understanding the Four Rules of Simple Design (https://leanpub.com/4rulesofsimpledesign). Summary Want to build great front-end apps without having to deal with the entire JavaScript ecosystem? Corey Haines joins the show to talk about Elm, a front-end language and framework that is type safe, has great build tools, and a full-fledged MVC framework to create client interactions with less hassle. Corey has been using Elm to build the site for his company, Hearken, and talks about why he picked it, and what has made Elm a success for them. For More Info We've got a blog post relating to the code examples in this episode, you can find it at https://medium.com/table-xi/union-types-in-elm-fb6a974ec427. Notes 02:25 - What is Hearken (https://www.wearehearken.com/)? 05:14 - The Elm Programming Language (http://elm-lang.org/) The ML Programming Language (https://en.wikipedia.org/wiki/ML_(programming_language)) Dealing with Time in Elm (https://medium.com/@lars.jacobsson81/dealing-with-time-in-elm-0-17-3af5274650fb) 08:06 - The Type System and The Compiler Editable (http://package.elm-lang.org/packages/stoeffel/editable/latest/Editable) F# (http://fsharp.org) If you want a really detailed overview of types in programming languages, here's one from Gary Bernhardt (https://www.destroyallsoftware.com/compendium/types?share_key=baf6b67369843fa2) Maybe type in Elm (http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Maybe) Union Types (https://guide.elm-lang.org/types/union_types.html) 21:27 - Elm as a Framework The Elm Architecture (https://guide.elm-lang.org/architecture/) Managed Effects and Elm (https://medium.com/@kaw2k/managed-effects-and-elm-36b7fcd246a9) 26:16 - Deciding to use Elm 28:37 - Elm: Gotchas and Technical Limitations? Uploading files with Elm (https://www.paramander.com/blog/using-ports-to-deal-with-files-in-elm-0-17) 32:37 - Styling and Working with Designers elm-css (https://github.com/rtfeldman/elm-css) 35:45 - The Elm Community Join Elm on Slack (https://elmlang.herokuapp.com/) 37:14 - Getting Started with Elm The Elm Guide (https://guide.elm-lang.org/) The Pragmatic Studio: Building Web Apps with Elm (https://pragmaticstudio.com/elm) Elm Remote Meetup (https://www.dailydrip.com/topics/elm-remote-meetup) Webpacker (https://github.com/rails/webpacker) Special Guest: Corey Haines.

time cto deciding getting started slack ml javascript styling elm mvc programming languages hearken four rules corey haines gary bernhardt webpacker

22. Optional Properties

Fatal Error

Play Episode Listen Later Mar 20, 2017 24:56

Soroush: That One Optional Property Massive View Controller Sandi Metz: Nothing is Something (RailsConf 2015) Finite State Machine (Wikipedia) StatefulViewController Soroush: a state machine where invalid transitions can't compile A gentle introduction to dependent types Less gently: Dependent Types at Work D Oisín Kidney: In which I Misunderstand Dependent Types Validated Andy Matuschak: A composable pattern for pure state machines with effects Functional core, imperative shell is from Boundaries by Gary Bernhardt

work boundaries wikipedia functional properties kidney optional finite colin campbell validated railsconf soroush sandi metz andy matuschak gary bernhardt

Episode 004: In The Testing Weeds With Sam Phippen and Justin Searls

Tech Done Right

Play Episode Listen Later Feb 22, 2017 49:16

Episode 004: Testing Summary Sam Phippen, Justin Searls, and Noel Rappin spend this episode talking about the value of test-driven development (TDD) as well as its cost. They discuss the kinds of problems that developers are likely to have after they learn TDD and attempt to apply it to a large application. Learn why Rails is both great and terrible for automated testing, and how testing can influence the structure of your code. Guests Sam Phippen (https://twitter.com/samphippen): Engineer at Digital Ocean (https://www.digitalocean.com/) and member of the RSpec (https://github.com/rspec) Core Team Justin Searls (https://twitter.com/searls): Writes bad code effortlessly and cofounder of Test Double (http://testdouble.com/). Maintainer of several testing tools, and frequent speaker on test related topics. Show Notes 01:30 - Intermediate Level Problems in Testing 04:58 - The Value of Testing Boundaries by Gary Bernhardt (https://www.youtube.com/watch?v=yTkzNHF6rMs) 15:15 - Isolated Unit Tests 17:52 - Structuring Applications 23:13 - Test-Driven Development (TDD) (https://en.wikipedia.org/wiki/Test-driven_development) Growing Object-Oriented Software, Guided by Tests (https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627) 33:22 - TDD in a Smalltalk (https://en.wikipedia.org/wiki/Smalltalk) Environment 35:00 - Isolating Tests in a Rails Environment Rake Without Rails (http://blog.testdouble.com/posts/2016-12-15-rake-without-rails.html) 36:54 - Test Tools minitest (https://github.com/seattlerb/minitest) Dan North: Introducing BDD (https://dannorth.net/introducing-bdd/) teenytest (https://github.com/testdouble/teenytest) RSpec (https://github.com/rspec) Tips & Resources: Sam: Sandi Metz: The Magic Tricks of Testing @ Rails Conf 2013 (https://www.youtube.com/watch?v=URSWYvyc42M) Test Smells (https://github.com/testdouble/test-smells#test-smells) Justin Searls: How to Stop Hating Your Test Suite @ RubyConf 2015 (https://www.youtube.com/watch?v=VD51AkG8EZw) Justin: Find some little problem and instead of implementing it in a Rails app, type bundle.gem and then make up a name and then practice and invent your own way of organizing code and tests so you can break things down. Noel: JUnit Test Infected: Programmers Love Writing Tests (http://junit.sourceforge.net/doc/testinfected/testing.htm) As you’re trying to test stuff, really try to focus on going back and forth between the tests and the code more rapidly than you’re probably doing so right now. Special Guests: Justin Searls and Penelope Phippen.

tips testing engineers tests guided weeds small talk writes rails digital ocean tdd maintainer test driven development tdd test double justin searls rspec gary bernhardt noel rappin sam phippen

9: Harry Percival : Testing Web Apps with Python, Selenium, Django

Test & Code - Python Testing & Development

Play Episode Listen Later Jan 19, 2016 45:14

Intro to Harry Percival, his background and story of how he got into TDD and ended up writing a book (http://amzn.to/1SqW1t3) Comparing using unittest and pytest with applicability to testing django projects. Functional end to end testing with selenium. The django test client for middle level tests. test isolation django and isolated unit tests unit tests vs integration tests Testing done by the development team without an external QA Double loop TDD: Functional test first, then unit tests Spikes: investigations without tests Harry's experience with having a freely available web version of a book that is also intended to be sold. Update: Comment from Harry Percival on 19-Jan-2014 I might have been a bit down on unit tests vs functional tests in that "unit tests never fail comment". Not true at all, particularly as we've just been thru upgrading django on our core system, and the unit tests really saved our bacon on that one... Links Test-Driven Development with Python (http://amzn.to/1SqW1t3) Obey the Testing Goat (http://pythontesting.net/obey-the-testing-goat) - Harry's site dedicated to the book and related posts. Python Testing with unittest, nose, pytest (http://pythontesting.net/book) Gary Bernhardt's talk, Boundaries talk (http://pythontesting.net/boundaries-talk) including a discussion of "Functional Core, Imperative Shell". Video of Boundaries talk on youtube (http://pythontesting.net/boundaries-talk-youtube) Special Guest: Harry Percival.

video boundaries testing functional python django web apps percival selenium tdd gary bernhardt python testing

181 JSJ The Evolution of Flux Libraries with Andrew Clark and Dan Abramov

JavaScript Jabber

Play Episode Listen Later Oct 14, 2015 81:38

Sign up for JS Remote Conf! Dan and Andrew's super awesome, helpful document that they made for the show during preparation 03:22 - Andrew Clark Introduction Twitter GitHub OpenGov flummox 03:39 - Dan Abramov Introduction Twitter GitHub JavaScript Jabber Episode #179: redux and React with Dan Abramov 04:03 - Flux Flux vs MVC 09:36 - Data Flow Why FluxComponent > fluxMixin Mixins Are Dead. Long Live Composition. Higher-order Components Sebastian Markbåge's Tweet 22:52 - Conceptualizing React and Flux React.js Conf 2015 - Flux Panel Does redux limit ambiguity that exists in Flux? 27:50 - Documentation 30:38 - The Elm Programming Language 32:34 - Making Patterns Explicit in Frameworks Tom Dale @ TXJS 2015 Let a 1,000 flowers bloom. Then rip 999 of them out by the roots. Sebastian Markbåge: Minimal API Surface Area @ JSConf EU 2014 36:31 - Getting Started with React and Flux Classes 42:42 - Where Flux Falls Short 58:23 - Keeping the Core Small; Making Decisions Picks Strange Loop 2015 Videos (Jamison) Typeset In The Future (Jamison) Open-source as a project model for internal work (w/ speaker notes) by Kevin Lamping (Jamison) Explanation of Zipf's Law (Dave) Will Conant's talk at UtahJS 2015 on Flux (Dave) The Legend of ZERO (3 Book Series) by Sara King (Joe) Camel Up (Joe) The Elm Programming Language (Joe) Boundaries: A talk by Gary Bernhardt from SCNA 2012 (Aimee) Nodevember (Aimee) TV Fool (Chuck) RCA Outdoor Digital HDTV VHF UHF Yagi Type Antenna (Chuck) The Michael Vey Book Series (Chuck) BusinessTown (Dan) Elon Musk: The World’s Raddest Man (Dan) Professor Frisby's Mostly Adequate Guide to Functional Programming (Dan) Abiogenesis (Dan) react-future (Dan) The Righteous Mind (Andrew) lodash-fp (Andrew) Inside Amy Schumer (Andrew) dataloader (Andrew) Careers at OpenGov (Andrew)

law evolution open videos careers getting started react classes explanation conf github libraries components flux frameworks documentation making decisions book series mvc ntt inside amy schumer strange loop righteous mind conceptualizing functional programming andrew clark dataflow camel up opengov abiogenesis dan abramov zipf gary bernhardt model e2 js remote conf nodevember javascript jabber episode mostly adequate guide tv fool professor frisby swlw

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

blog code hobbies lessons learned slack open source github future plans charities anniversary edition creativeasin brandon sanderson community impact hue fastly trade associations saron arko steve krug protomen bundler aaron patterson web usability gary bernhardt ruby central react rally ruby together angular remote conf

224 RR Ruby Together with André Arko

Play Episode Listen Later Sep 9, 2015 54:27

224 RR Ruby Together with André Arko

All Angular Podcasts by Devchat.tv

Play Episode Listen Later Sep 9, 2015 54:27

040 AiA ng-wat with Shai Reznik

Play Episode Listen Later Apr 30, 2015 40:15

02:02 - Shai Reznik Introduction [YouTube] Shai Reznik: ng-wat Talk from ng-conf 2015 Twitter GitHub HiRez.io YouTube Preparing for Angular 2.0 (Part 1) JavaScript Israel Meetup Group 06:58 - The Conception and Behind the Scenes of the Now Famous ng-wat Talk and the Talk Reception WAT (A lightning talk by Gary Bernhardt from CodeMash 2012) 29:18 - More Wats? Picks The Cat in the Hat by Dr. Seuss (Lukas) Pushing Daisies (Katya) StarCraft II (Joe) [Pluralsight Webinar] AngularJS 2.0: What you need to know with Joe (Joe) Angular 2 Google Docs Folder (Shai) Streamus (Shai)

israel talk preparing cat scenes seuss github conception shai angular starcraft ii pushing daisies angularjs hi rez codemash gary bernhardt registration page shai reznik javascript israel pluralsight webinar angularjs shai reznik introduction m wp 2xa9zu ilbllwm1dec

040 AiA ng-wat with Shai Reznik

Adventures in Angular

Play Episode Listen Later Apr 30, 2015 40:15

040 AiA ng-wat with Shai Reznik

Play Episode Listen Later Apr 30, 2015 40:15

Episode 203: 197 RR The Social Coding Contract with Justin Searls

Play Episode Listen Later Mar 4, 2015 71:18

Check out RailsClips on Kickstarter!! 02:23 - Justin Searls Introduction Twitter GitHub Blog Test Double @testdouble 03:02 - Justin Searls: The Social Coding Contract Open Source GitHub 04:58 - Transitive Dependences and Understanding Technical Debt RailsConf 2014 - Keynote: 10 Years! by Yehuda Katz The CAP Theorem 15:21 - Learning Outside Work Hours Tracking Time Micromanagement 21:21 - Understanding Transitive Dependencies (Cont’d) Gary Bernhardt 23:00 - Use Someone Else’s Framework or Write Your Own? “It Depends.” “A dirty code base is the sign of a well-monetized application.” - Matt Scantland 31:25 - When Does it Hurt to Use Tools You Don’t Completely Understand? Elasticsearch 34:14 - Leaving Code Behind 36:26 - Be a Responsible Open Source User Pull Request Sample Amount of Investment Community Management Communication cancan => cancancan GitX Graphical User Interface (GUI) rowanj GitX 47:22 - Reacting to Change Process and Ceremony Deming’s Common Cause and Special Cause Pair Programming [YouTube] Justin Searls and Aaron Patterson: The act of using vim, tenderly. 54:16 - Just Blog It! Picks Royalty Free Music by Kevin MacLeod (David) Rebif (David) Ruby Rogues Episode #188: Community Building with Pieter Hintjens (Jessica) Commercial Users of Functional Programming 2015: Call for Presentations (Jessica) James Clear: Forget About Setting Goals. Focus on This Instead. (Jessica) Screw motivation, what you need is discipline. (Jessica) A Wizard of Earthsea by Ursula K. Le Guin (Chuck) Conform: Exposing the Truth About Common Core and Public Education by Glenn Beck (Chuck) Sony NEX-5T Compact Interchangeable Lens Digital Camera (Justin) Justin’s Talk at RailsConf 2015: Boring Code (Sometimes a Controller is Just a Controller) (Justin) Alpine iLX-007 7-Inch In-Dash Receiver with Apple CarPlay (Justin)

Episode 203: 197 RR The Social Coding Contract with Justin Searls

boundaries ios folklore objective c gary bernhardt

Play Episode Listen Later Mar 4, 2015 71:18

33: Objective-C Folklore

Build Phase

Play Episode Listen Later Apr 1, 2014 29:39

The minutiae of initialization is the topic of this week's show as Gordon and Mark continue to refuse to get off Objective-C's lawn. iOS on Rails Book Obcd Objective-Clean Boundaries by Gary Bernhardt

22: Punk in Drublic

Build Phase

Play Episode Listen Later Jan 14, 2014 40:46

Mark and Gordon discuss their holiday vacations, striving for a good work/life balance, and resolutions for the new year. objc-run Playbook CocoaHeads Boston NSCoder Night Meetup NSNorth Noodle Learn you a haskell Ryan Nystrom's (not Nyquist) iOS 7 Best Practices blog post Functional Reactive Programming by Ash Furrow Model/View/View-Model Gary Bernhardt's Boundaries talk Gary Bernhardt on Giant Robots

best practices playbook noodle giant robots punk in drublic gary bernhardt functional reactive programming ash furrow ryan nystrom nsnorth

26: Deep into the psyche of Gary Bernhardt

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later Dec 9, 2012 41:06

Ben Orenstein is joined by Gary Berhardt from Destroy All Software Screencasts. Ben and Gary discuss DAS, how it has changed over the two years he's been doing it, and how his thinking has changed over that time. They then discuss Gary's thoughts on how to write software and tests, how we wants to "fix the kernel", and his exciting plans for the future. They also discuss his background, the production process behind Destroy All Software, and much, much more. Destroy All Software Screencasts Functional Core, Imperative Shell Erlang Follow @thoughtbot, @garybernhardt, and @r00k on twitter.

deep psyche erlang ben orenstein gary bernhardt

067 RR Gary Bernhardt’s Testing Style

style testing rogues gary bernhardt

Play Episode Listen Later Aug 21, 2012 74:41

The Rogues talk to Gary Bernhardt about his testing style.

067 RR Gary Bernhardt’s Testing Style

style testing rogues gary bernhardt

Play Episode Listen Later Aug 21, 2012 74:41

The Rogues talk to Gary Bernhardt about his testing style.

067 RR Gary Bernhardt's Testing Style

style testing rogues gary bernhardt

Play Episode Listen Later Aug 21, 2012 74:41

The Rogues talk to Gary Bernhardt about his testing style.

040 RR Text Editors and IDE’s with Gary Bernhardt

ides rogues text editors gary bernhardt

Play Episode Listen Later Feb 3, 2012 67:26

The Rogues talk about text editors and IDEs with Gary Bernhardt.

040 RR Text Editors and IDE's with Gary Bernhardt

ides rogues text editors gary bernhardt

Play Episode Listen Later Feb 3, 2012 67:26

The Rogues talk about text editors and IDEs with Gary Bernhardt.

040 RR Text Editors and IDE’s with Gary Bernhardt

ides rogues text editors gary bernhardt

Play Episode Listen Later Feb 2, 2012 67:26

The Rogues talk about text editors and IDEs with Gary Bernhardt.

Gary Bernhardt Interview – Teach Me To Code Podcast