Podcast appearances and mentions of sarah drasner

Meet Angie Jones

Jason Lengstorf, a developer media producer and host of the show Learn with Jason, joins Corey on this week's episode of Screaming in the Cloud to layout his ideas for creative developer content. Jason explains how devTV can have way more reach than webinars, the lack of inspiration he experiences at conferences these days, and why companies should be focused on hiring specialists before putting DevRels on the payroll. Plus, Corey and Jason discuss walking the line between claiming you're good at everything and not painting yourself into a corner as a DevRel and marketer.About JasonJason Lengstorf helps tech companies connect with developer communities through better media. He advocates for continued learning through collaboration and play and regularly live streams coding with experts on his show, Learn With Jason. He lives in Portland, Oregon.Links Referenced:Learn with Jason: https://www.learnwithjason.dev/Personal Website Links: https://jason.energy/linksTranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Before I went to re:Invent, I snuck out of the house for a couple of days to GitHub Universe. While I was there, I discovered all kinds of fascinating things. A conference that wasn't predicated on being as cheap as humanly possible was one of them, and a company that understood how developer experience might play out was another.And I also got to meet people I don't normally get to cross paths with. My guest today is just one such person. Jason Lengstorf is a developer media producer at Learn with Jason, which I have to assume is named after yourself.Jason: [laugh] It is yes.Corey: Or it's a dramatic mispronunciation on my part, like, no, no, it's ‘Learn with JSON' and it's basically this insane way of doing weird interchange formats, and you just try to sneak it through because you know I happen to be an XML purist.Jason: [laugh] Right, I'm just going to throw you a bunch of YAML today. That's all I want to talk about.Corey: Exactly. It keeps things entertaining, we're going to play with it. So, let's back up a sec. What do you do? Where do you start and where do you stop?Jason: I'm still learning how to answer this question, but I help companies do a better job of speaking to developer audiences. I was an engineer for a really long time, I went from engineering into developer advocacy and developer experience, and as of the last year, I'm doing that independently, with a big focus on the media that companies produce because I think that what used to work isn't working, and that there's a big opportunity ahead of us that I am really excited to help companies move into.Corey: It feels like this has been an ongoing area of focus for an awful lot of folks. How do you successfully engage with developer audiences? And if I'm being direct and more than a little bit cynical, a big part of it is that historically, the ways that a company marketed to folks was obnoxious. And for better or worse, when you're talking about highly technical topics and you're being loudly incorrect, a technical audience is not beholden to some of the more common business norms, and will absolutely call you out in the middle of you basically lying to them. “Oh, crap, what do we do now,” seemed to be a large approach. And the answer that a lot of folks seem to have come up with was DevRel, which… I've talked about it before in a bunch of different ways, and my one-liner is generally, “If you work in DevRel, that means you work in marketing, but they're scared to tell you that.”Jason: [laugh] I don't think you're wrong. And you know, the joke that I've made for a long time is that they always say that developers hate marketing. But I don't think developers hate marketing; they just hate the way that your company does it. And—Corey: Oh, wholeheartedly agree. Marketing done right is engaging and fun. A lot of what I do in public is marketing. Like, “Well, that's not true. You're just talking about whatever dumb thing AWS did this week.” “Well, yes, but then you stick around to see what else I say, and I just become sort of synonymous with ‘Oh, yeah, that's the guy that fixes AWS bills.'” That is where our business comes from, believe it or not.Jason: Ri—and I think this was sort of the heart of DevRel is that people understood this. They understood that the best way to get an audience engaged is to have somebody who's part of that audience engage with them because you want to talk to them on the level that they work. You're not—you know, a marketing message from somebody who doesn't understand what you do is almost never going to land. It just doesn't feel relatable. But if you talk to somebody who's done the thing that you do for work, and they can tell you a story that's engaging about the thing that you do for work, you want to hear more. You—you know, you're looking for a community, and I think that DevRel, the aim was to sort of create that community and give people a space to hang out with the added bonus of putting the company that employs that DevRel as an adjacent player to get some of that extra shine from wherever this community is doing well.Corey: It felt like 2019 was peak DevRel, and that's where I started to really see that you had, effectively, a lot of community conferences were taken over by DevRel, and you wound up with DevRel pitching to DevRel. And it became so many talks that were aligned with almost imagined problems. I think one of the challenges of working in DevRel is, if you're not careful, you stop being a practitioner for long enough that you can no longer relate to what the audience is actually dealing with. I can sit here and complain about data center travails that I had back in 2011, but are those still accurate in what's about to be 2024? Probably not.Jason: And I think the other problem that happens too is that when you work in DevRel, you are beholden to the company's goals, if the company employees you. And where I think we got really wrong is companies have to make money. We have to charge customers or the company ceases to exist, so when we go out and tell stories, we're encouraged by the company to focus on the stories that have the highest ROI for the company. And that means that I'm up on stage talking about some, like, far-future, large-scale enterprise thing that very few companies need, but most of the paying customers of my company would need. And it becomes less relatable, and I think that leads to some of the collapse that we saw that you mentioned, where dev events feel less like they're for devs and more like they're partner events where DevRel is talking to other DevRel is trying to get opportunities to schmooze partners, and grow our partner pipeline.Corey: That's a big part of it, where it seems, on some level, that so much of what DevRel does, when I see them talking about DevRel, it doesn't get around to DevRel is. Instead, it gets stuck in the weeds of what DevRel is not“. We are not shills for our employer.” Okay, I believe you, but also, I don't ever see you saying anything that directly contravenes what your employer does. Now, let me be clear: neither do I, but I'm also in a position where I can control what my employer does because I have the control to move in directions that align with my beliefs.I'm not saying that it's impossible to be authentic and true to yourself if you work for an employer, but I have seen a couple of egregious examples of people changing companies and then their position on topics they've previously been very vocal on pulled an entire one-eighty, where it's… it really left a bad taste in my mouth.Jason: Yeah. And I think that's sort of the trick of being a career DevRel is you have to sort of walk this line of realizing that a DevRel career is probably short at every company. Because if you're going to go there and be the face of a company, and you're not the owner of that company, they're almost inevitably going to start moving in a direction as business develops, that's not going to line up with your core values. And you can either decide, like, okay that's fine, they pay me well enough, I'm just going to suck it up and do this thing that I don't care about that much, or you have to leave. And so, if you're being honest with yourself, and you know that you're probably going to spend between 12 and 24 months at any given company as a DevRel, which—by the history I'm seeing, that seems to be pretty accurate—you need to be positioning and talking about things in a way that isn't painting you into that corner where you have to completely about-face, if you switch companies. But that also works against your goals as a DevRel at the company. So, it's—I think we've made some big mistakes in the DevRel industry, but I will pause to take a breath here [laugh].Corey: No, no, it's fine. Like, it's weird that I view a lot of what I do is being very similar to DevRel, but I would never call myself that. And part of it is because, for better or worse, it is not a title that tends to engender a level of respect from business owners, decision makers, et cetera because it is such a mixed bag. You have people who have been strategic advisors across the board becoming developer advocates. That's great.You also see people six months out of a boot camp who have decided don't like writing code very much, so they're going to just pivot to talking about writing code, and invariably, they believe, more or less, whatever their employer tells them because they don't have the history and the gravitas to say, “Wait a minute, that sounds like horse pucky to me.” And it's a very broad continuum. I just don't like blending in.Jason: Where I think we got a lot of this wrong is that we never did define what DevRel is. As you say, we mostly define what DevRel is not, and that puts us in a weird position where companies see other companies do DevRel, and they mostly pay attention to the ones who do DevRel really well. And they or their investors or other companies say, “You need a great DevRel program. This is the secret to growth.” Because we look at companies that have done it effectively, and we see their growth, and we say, “Clearly this has a strong correlation. We should invest in this.” But they don't—they haven't done it themselves. They don't understand which part of it is that works, so they just say, “We're hiring for DevRel.” The job description is nine different careers in a trench coat. And the people applying—Corey: Oh, absolutely. It's nine different things and people wind up subdividing into it, like, “I'm an events planner. I'm not a content writer.”Jason: Right.Corey: Okay, great, but then why not bill yourself as a con—as an events planner, and not have to wear the DevRel cloak?Jason: Exactly. And this is sort of what I've seen is that when you put up a DevRel job, they list everything, and then when you apply for a DevRel job, you also don't want to paint yourself into a corner and say, “My specialty is content,” or, “My specialty is public speaking,” or whatever it is. And therefore you say, “I do DevRel,” to give yourself more latitude as an employee. Which obviously I want to keep optionality anywhere I go. I would like to be able to evolve without being painted into a small box of, like, this is all I'm allowed to do, but it does put us in this really precarious position.And what I've noticed a lot of companies do is they hire DevRel—undefined, poorly written job description, poor understanding of the field. They get a DevRel who has a completely different understanding of what DevRel is compared to the people with the role open. Both of them think they're doing DevRel, they completely disagree on what those fundamentals are, and it leads to a mismatch, to burnout, to frustration, to, you know, this high turnover rate in this field. And everybody then starts to say, well, “DevRel is the problem.” But really, the problem is that we're not—we're defining a category, not a job, and I think that's the part that we really screwed up as an industry.Corey: Yeah. I wish there were a better way around there, but I don't know what that might be. Because it requires getting a bunch of people to change some cornerstone of what's become their identity.Jason: This is the part where I—this is probably my spiciest take, but I think that DevRel is marketing, but it is a different kind of marketing. And so, in a perfect world—like, where things start to fall apart is you try to slot DevRel into engineering, or you try to slot it into marketing, as a team on these broader organizations, but the challenge then becomes, if you have DevRel, in marketing, it will inevitably push more toward marketing goals, enterprise goals, top-of-funnel, qualified leads, et cetera. If you put them into engineering, then they have more engineering goals. They want to do developer experience reviews. They want to get out there and do demos. You know, it's much more engineering-focused—or if you're doing it right, is much more engineering-focused.But the best DevRel teams are doing both of those with a really good measure, and really clear metrics that don't line up with engineering or marketing. So, in a perfect world, you would just have an enterprise marketing team, and a developer marketing team, and that developer marketing team would be an organization that is DevRel today. And you would hire specialists—event planners, great speakers, great demo writers, probably put your docs team in there—and treat it as an actual responsibility that requires a larger team than just three or four ex-developers who are now speaking at conferences.Corey: There were massive layoffs across DevRel when the current macroeconomic correction hit, and I'd been worried about it for years in advance because—Jason: Mm-hm.Corey: So, many of these folks spent so much time talking about how they were not marketing, they were absolutely not involved in that. But marketing is the only department that really knows how to describe the value of these sorts of things without having hard metrics tied to it. DevRel spent a lot of time talking about how every metric used to measure them was somehow wrong, and if you took it to its logical conclusion, you would basically give these people a bunch of money—because they are expensive—and about that much money again in annual budget to travel more or less anywhere they want to go, and every time something good happened, as a result, to the company, they had some hand in it nebulously, but you could never do anything to measure their performance, so just trust that they're doing a good job. This is tremendously untenable.Jason: Mm-hm. Yeah, I think when I was running the developer experience org at Netlify, most of my meetings were justifying the existence of the team because there weren't good metrics. You can't put sales qualified leads on DevRel. It doesn't make any sense because there are too many links in the chain after DevRel opens the door, where somebody has to go from, ‘I'm aware of this company' to ‘I've interacted with the landing page' to ‘I've actually signed up for something' to ‘now I'm a customer,' before you can get them to a lead. And so, to have DevRel take credit is actually removing credit from the marketing team.And similarly, if somebody goes through onboarding, a lot of that onboarding can be guided by DevRel. The APIs that new developers interface with can be—the feedback can come from DevRel, but ultimately, the engineering team did that work the product team did that work. So, DevRel is this very interesting thing. I've described it as a turbocharger, where if you put it on an engine that runs well, you get better performance out of that engine. If you just plop one on the table, not a lot happens.Corey: Yeah, it's a good way of putting it. I see very early stage startups looking to hire a developer advocate or DevRel person in their seed stage or Series A, and it's… there's something else you're looking for here. Hire that instead. You're putting the cart before the horse.Jason: What a lot of people saw is they saw—what they're thinking of as DevRel is what they saw from very public founders. And when you get a company that's got this very public-facing, very engaging, charismatic founder, that's what DevRel feels like. It is, you know, this is the face of the company, we're showing you what we do on the inside, we're exposing our process, we're sharing the behind the scenes, and proving to you that we really are great engineers, and we care a lot. Look at all this cool stuff we're doing. And that founder up on stage was, I think, the original DevRel.That's what we used to love about conferences is we would go there and we would see somebody showing this thing they invented, or this new product they had built, and it felt so cool because it was these inspirational moments of watching somebody brilliant do something brilliant. And you got to follow along for that journey. And then we try to—Corey: Yeah I mean, that's natural, but you see booths at conferences, the small company startup booths, a lot of times you'll be able to talk to the founders directly. As the booths get bigger, your likelihood of being able to spend time talking to anyone who's materially involved in the strategic direction of that company gets smaller and smaller. Like, the CEO of GitHub isn't going to be sitting around at the GitHub booth at re:Invent. They're going to be, you know, talking to other folks—if they're there—and going to meetings and whatnot. And then you wind up with this larger and larger company. It's a sign of success, truly, but it also means that you've lost something along the way.Jason: Yeah, I think, you know, it's the perils of scale. And I think that when you start looking at the function of DevRel, it should sort of be looked at as, like, when we can't handle this anymore by ourselves, we should look for a specialty the same way that you do for any other function inside of a company. You know, it wouldn't make sense on day one of a startup to hire a reliability engineer. You're not at the point where that makes sense. It's a very expensive person to hire, and you don't have enough product or community or load to justify that role yet. And hopefully, you will.And I think DevRel is sort of the same way. Like, when you first start out your company, your DevRel should be the founding team. It should be your engineers, sharing the things that they're building so that the community can see the brilliance of your engineering team, sharing with the community, obviously, being invested in that community. And when you get big enough that those folks can no longer manage that and their day-to-day work, great, then look into adding specialists. But I think you're right that it's cart before the horse to, you know, make a DevRel your day-one hire. You just don't have enough yet.Corey: Yeah, I wish that there were an easy way to skin the cat. I'm not sure there is. I think instead we wind up with people doing what they think is going to work. But I don't know what the truth is.Jason: Mmm.Corey: At least. That's where I land on it.Jason: [laugh] Yeah, I mean, every company is unique, and every experience is going to be unique, so I think to say, “Do it exactly like this,” is—that's got a lot of survivorship bias, and do as I say—but at the same time, I do think there's some universal truths. Like, it doesn't really make sense to hire a specialist before you've proven that specialty is the secret sauce of your business. And I think you grow when it's time to grow, not just in case. I think companies that over-hire end up doing some pretty painful layoffs down the road. And, you know, obviously, there's an opposite end of that spectrum where you can grow too slowly and bury your team and burn everybody out, but I think, you know—we, [laugh] leading into the pandemic, I guess, we had a lot of free money, and I think people were thinking, let's go build an empire and we'll grow into that empire. And I think that is a lot of why we're seeing this really painful downsizing right now, is companies hired just in case and then realized that actually, that in case didn't come to be.Corey: What is the future of this look like? Easy enough to look back and say, well, that didn't work? Well, sure. What is the future?Jason: The playbook that we saw before—in, like, 2019 and before—was very event-driven, very, like, webinar-driven. And as we went into 2020, and people were at home, we couldn't travel, we got real sick of Zoom calls. We don't want to get on another video call again. And that led to that playbook not working anymore. You know, I don't want to get on a webinar with a company. I don't want to go travel to a company event, you know, or at least not very many of them. I want to go see the friends I haven't seen in three years.So, travel priorities changed, video call fatigue is huge, so we need something that people want to do, that is interesting, and that is, you know, it's worth making in its own right, so that people will engage with it, and then you work in the company goals as an incidental. Not as a minor incidental, but you know, it's got to be part of the story; it can't be the purpose. People won't sign up for a webinar willingly these days, I don't think, unless they have exactly the problem that your webinar purports to solve.Corey: And even if they do, it becomes a different story.Jason: Right.Corey: It's [high buying 00:19:03] signal, but people are constantly besieged by requests for attention. This is complicated by what I've seen over the last year. When marketing budgets get—cut, arguably too much, but okay—you see now that there's this follow-on approach where, okay, what are we going to cut? And people cut things that in many cases work, but are harder to attribute success to. Events, for example, are doing very well because you have someone show up at your booth, you scan their badge. Three weeks later, someone from that company winds up signing up for a trial or whatnot, and ah, I can connect those dots.Whereas you advertise on I don't know, a podcast as a hypothetical example that I'm pulling out of what's right in front of me, and someone listening to this and hearing a message from a sponsor, they might be doing something else. They'll be driving, washing dishes, et cetera, and at best they'll think, “Okay, I should Google that when I get back to a computer.” And they start hearing about it a few times, and, “Oh. Okay, now it's time for me to go and start paying serious attention to this because that sounds like it aligns with a problem I have.” They're not going to remember where they initially heard it.They're going to come in off of a Google search, so it sounds like it's all SEO's benefit that this is working, and it is impossible to attribute. I heard some marketer once say that 50% of your marketing budget is wasted, but you'll go bankrupt trying to figure out which half. It all ties together. But I can definitely see why people bias for things that are more easily attributed to the metric you care about.Jason: Yes. And I think that this is where I see the biggest opportunity because I think that we have to embrace that marketing signal is directional, not directly attributable. And if you have a focus campaign, you can see your deviation from baseline signups, and general awareness, and all of the things that you want to be true, but you have to be measuring that thing, right? So, if we launch a campaign where we're going to do some video ads, or we're going to do some other kind of awareness thing, the goal is brand awareness, and you measure that through, like, does your name get mentioned on social media? Do you see a deviation from baseline signups where it is trending upward?And each of those things is signal that the thing you did worked. Can you directly attribute it? No, but I think a functional team can—you know, we did this at Netlify all the time where we would go and look: what were the efforts that were made, what were the ones that got discussion on different social media platforms, and what was the change from baseline? And we saw certain things always drove a non-trivial deviation from baseline in the right direction. And that's one of the reasons that I think the future of this is going to be around how do you go broader with your reach?And my big idea—to nutshell it—is, like, dev TV. I think that developers want to see the things that they're interested in, but they want it to be more interesting than a straight webinar. They want to see other developers using tools and getting a sense of what's possible in an entertaining way. Like, they want stories, they don't want straight demos. So, my thinking here is, let's take this and steer into it.Like, we know that developers love when you put a documentary together. We saw the Vue documentary, and the React documentary, and the GraphQL documentary, and the Kubernetes documentary coming out of the Honeypot team, and they've got hundreds of thousands, and in some cases, millions of views because developers really want to see good stories about us, about our community. So, why not give the dev community a Great British Bake Off, but for web devs? Why not create an Anthony Bourdain Parts Unknown-style travel show that highlights various web communities? Why not get out there and make reality competition shows and little docuseries that help us highlight all the things that we're learning and sharing and building?Every single one of those is going to involve developers talking about the tools they use, talking about the problems they solve, talking about what they were doing before and how they've made it better. That's exactly what a webinar is, that's what a conference talk is, but instead of getting a small audience at a conference, or you know, 15 to 30 people signing up for your webinar, now we've got the potential for hundreds of thousands or even millions of people to watch this thing because it's fun to watch. And then they become aware of the companies involved because it's presented by the company; they see the thing get used or talked about by developers in their community, I think there's a lot of magic and potential in that, and we've seen it work in other verticals.Corey: And part of the problem comes down as well to the idea that, okay, you're going to reach some people in person at events, but the majority of engineers are not going to be at any event or—Jason: Right.Corey: Any event at all, for that matter. They just don't go to events for a variety of excellent reasons. How do you reach out to them? Video can work, but I always find that requires a bit of a different skill than, I don't know, podcasting or writing a newsletter. So, many times, it feels like it's, oh, and now you're just going to basically stare at the camera, maybe with someone else, and it looks like the Zoom call to which the viewer is not invited.Jason: Right.Corey: They get enough of that. There has to be something else.Jason: And I think this is where the new skill set, I think, is going to come in. It exists in other places. We see this happen in a lot of other industries, where they have in-house production teams, they're doing collaborations with actors and athletes and bringing people in to make really entertaining stories that drive underlying narratives. I mean, there's the ones that are really obvious, like, the Nikes of the world, but then there are far less obvious examples.Like, there was this show called Making It. It was… Nick Offerman and Amy Poehler were the hosts. It was the same format as the Great British Bake Off but around DIY and crafting. And one of the permanent judges was the Etsy trend expert, right? And so, every single episode, as they're judging this, the Etsy trend expert is telling all of these crafters and contestants, “You know, what you built here is always a top seller on Etsy. This is such a good idea, it's so well executed, and people love this stuff. It flies off the shelves in Etsy stores.”Every single episode, just perfectly natural product placement, where a celebrity that you know—Nick Offerman and Amy Poehler—are up there, lending—like, you want to see them. They're so funny and engaging, and then you've got the credibility of Etsy's trend expert telling the contestants of the show, “If you do DIY and crafting, you can make a great living on Etsy. Here are the things that will make that possible.” It's such subtle, but brilliant product placement throughout the entire thing. We can do that. Like, we have the money, we just spend it in weird places.And I think that as an industry, if we start getting more creative about this and thinking about different ways we can apply these marketing dollars that we're currently dumping into very expensive partner dinners or billboards or getting, you know, custom swag or funding yet another $150,000 conference sponsorship, we could make a series of a TV show for the same cost as throwing one community event, and we would reach a significantly larger group.Corey: Yeah. Now, there is the other side of it, too, where Lord knows I found this one out the fun way, that creating content requires significant effort and—Jason: Yes.Corey: Focus. And, “Oh, it's a five-minute video. Great, that could take a day or three to wind up putting together, done right.” One of the hardest weeks of my year is putting together a bunch of five-minute videos throughout the course of re:Invent. So much that is done in advance that is basically breaking the backs of the editing team, who are phenomenal, but it still turns into more than that, where you still have this other piece of it of the actual content creation part.And you can't spend all your time on that because pretty soon I feel like you become a talking head who doesn't really do the things that you are talking to the world about. And that content gets pretty easy to see when you start looking at, okay, what did someone actually do? Oh, they were a developer for three years, and they spent the next seven complaining about development, and how everyone is—Jason: [laugh].Corey: Doing it wrong on YouTube. Hmm… it starts to get a little, how accurate is this really? So, for me, it was always critical that I still be hands-on with things that I'm talking about because otherwise I become a disaster.Jason: And I agree. One of the things that my predecessor at Netlify, Sarah Drasner, put in place was a, what she called an exchange program, where we would rotate the DevRel team onto product, and we rotate product onto the DevRel team. And it was a way of keeping the developer experience engineers actually engineers. They would work on the product, they didn't do any DevRel work, they were exclusively focused on doing actual engineering work inside our product to just help keep their skills sharp, keep them up to date on what's going on, build more empathy for the engineers that we talk to every day, build more empathy for our team instead of us—you know, you never want to hear a DevRel throw the engineering team under the bus for not shipping a feature everybody wants.So, these sorts of things are really important, and they're hard to do because we had to—you know, that's a lot of negotiation to say, “Hey, can we take one of your engineers for a quarter, and we'll give you one of our engineers for a quarter, and you got to trust us that's going to work out in your favor.” [laugh] Right? Like, there's a lot that goes into this to make that sort of stuff possible. But I absolutely agree. I don't think you get to make this type of content if you've fully stepped out of engineering. You have to keep it part of your practice.Corey: There's no way around it. You have to be hands-on. I think that's the right way to do it, otherwise, it just leads to, frankly, disaster. Very often, you'll see people who are, like, “Oh, they're great in the DevRel space. What do they do?” And they go to two or three conferences a year, and they have a blog post or so. It's like, okay, what are they doing the rest of that time?Sometimes the answer is fighting internal political fires. Other times it's building things and learning these things and figuring out where they stand. There are some people, I don't want to name names, although an easy one is Kelsey Hightower, who has since really left the stage, that he's retired, but when he went up on stage and said something—despite the fact that he worked at Google—it was eminently clear that he believed in what he was saying, or he would not say it.Jason: Right.Corey: He was someone who was very clearly aware of the technology about which he was speaking. And that was great. I wish that it were not such a standout moment to see him speak and talk about that. But unfortunately, he kind of is. Not as many people do that as well as we'd like.Jason: Agreed. I think it was always a treat to see Kelsey speak. And there are several others that I can think of in the community who, when they get on stage, you want to be in that audience, and you want to sit down and listen. And then there are a lot of others who when they get on stage, it's like that this book could have been a blog post, or this—you know, this could have been an email, that kind of thing. Like you could have sent me this repo because all you did was walk through this repo line-by-line, or something that—it doesn't feel like it came from them; it feels like it's being communicated by them.And I think that's, again, like, when I criticize conferences, a lot of my criticism comes from the fact that, coming up, I feel like every speaker that I saw on stage—and this is maybe just memory… playing favorites for me, but I feel like I saw a lot of people on stage who were genuinely passionate about what they were creating, and they were genuinely putting something new into the world every time they got on stage. And I have noticed that I feel less and less like that. Also, I feel like events have gotten less and less likely to put somebody on stage unless they've got a big name DevRel title. Like, you have to work at a company that somebody's heard of because they're all trying to get that draw because attendance is going down. And—Corey: Right. It's a—like, having run some conferences myself, the trick is, is you definitely want some ringers in there. People you know will do well, but you also need to give space for new voices to arise. And sometimes it's a—it always bugs me when it seems like, oh, they're here because their company is a big sponsor. Of course, they have the keynote. Other times, it's a… like, hate the actual shill talks, which I don't see as much, which I'm thankful for; I'd stop going to those conferences, but jeez.Jason: Yeah, and I think it's definitely one of those, like, this is a thing that we can choose to correct. And I have a suspicion that this is a pendulum not a—not, like, the denouement of—is that the right—how do you say that word? De-NOW-ment? De-NEW-ment? Whatever.Corey: Denouement is my understanding, but that might be the French acc—Jason: Oh, me just—Corey: The French element.Jason: —absolutely butchering that. Yeah [laugh]. I don't think this is the end of conferences, like we're seeing them taper into oblivion. I think this is a lull. I think that we're going to realize that we want to—we really do love being in a place with other developers. I want to do that. I love that.But we need to get back to why we were excited to go to conferences in the first place, which was this sharing of knowledge and inspiration, where you would go see people who were literally moving the world forward in development, and creating new things so that you would walk away with insider info, you had just seen the new thing, up close and personal, had those conversations, and you went back so jazzed to build something new. I feel like these days, I feel more like I went and watched a handful of product demos, and now I'm really just waiting to the hallway track, which is the only, like, actually interesting part at a lot of events these days.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Jason: Most of what I share is on learnwithjason.dev, or if you want a big list of links, I have jason.energy/links, which has a whole bunch of fun stuff for you to find.Corey: Awesome. And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it.Jason: Yeah, thanks so much for having me. This was a blast.Corey: Jason Lengstorf, developer media producer at Learn with Jason. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that will no doubt become the basis for somebody's conference talk.Jason: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

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

The transition from coder to manager isn't easy for developers who love the creative satisfaction and thrill of coding. But both sides of the fence have unique challenges. Sarah Drasner, Senior Director of Engineering, Web, Android, iOS, and Multiplatform Core Infrastructure at Google, didn't seek out engineering leadership. Sarah admits that she sometimes misses the flow state of coding but has a new appreciation for management now that she is on the other side. She discusses the culture at Google, navigating the company's tech stack, and how much she values working with a dedicated and hardworking team. Beyond her tech pursuits, Sarah shines a light on She Code Africa, a nonprofit organization she supports, empowering women in tech. In this episode, Sarah talks to Robbie and Chuck about why she initially avoided Angular, the challenges of management, and the flow state she misses from coding. Key Takeaways [01:01] - Introduction to Sarah Drasner. [03:26] - A whiskey review: Brenne French Single Malt Whisky. [15:00] - Tech hot takes. [39:05] - What is going on with Angular. [47:09] - Sarah's experiences being a manager. [52:10] - The career Sarah would choose if she wasn't in tech. Quotes [22:48] - “I like the idea of being explicit, but I appreciate when languages are a little more bulletproof.” ~ Sarah Drasner [43:56] - “Dealing with change as a developer is the main reason why you use a framework.” ~ Sarah Drasner [45:58] - “That's the reason why so many senior devs go towards this ‘it depends' way of thinking because we see many different implementations over time.” ~ Sarah Drasner Links Sarah Drasner Sarah Drasner Twitter Sarah Drasner LinkedIn Engineering Management for the Rest of Us She Code Africa Ada Nduka Oyom RenderATL Sagamore Spirit GitHub React Vue JS Microsoft Netlify Google Apple Ember JS Angular Brenne French Single Malt Whisky Craigellachie Distillery Michter's American Peerless Distilling Co Willett Distillery Angel's Envy Bourbons Whiskey Del Bac Mountain Dew Solid JS Ryan Carniato YouTube Nuxt Next JS Tailwind CSS Vanilla CSS CSS-Tricks Jason Lengstorf First We Feast Soundcloud Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Promos Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message

Learn all about how a Developer Advocate uses data to solve the world's problems, one K-pop album at a time. Ceora has a passion for exploring topics she knows nothing about and sharing what she learns with others She shares tips around the best ways to share the things you learn and how to accept imposter syndrome The ultimate tip... how K-pop can help you prioritize your projects Resources: - Columbia University's Data Science Institute article: https://datascience.columbia.edu/news/2023/ai-art-is-here-to-stay-how-blockchain-can-help-creators-gain-control-over-their-work/ - Sarah Drasner's article about learning: https://css-tricks.com/learning-to-learn/ Where to find Ceora: Twitter: @ceeoreo_ Website: https://ceora.dev/ LinkedIn: https://www.linkedin.com/in/ceora-ford/ --- Support this podcast: https://podcasters.spotify.com/pod/show/nerdnourishment/support

Monica and Urban discuss what they've been up to in the last six months. Why Construction Projects Always Go Over Budget (https://www.youtube.com/watch?v=dOe_6vuaR_s) Release It! by Michael Nygard (https://pragprog.com/titles/mnee2/release-it-second-edition/) Engineering Management for the Rest of Us by Sarah Drasner (https://www.engmanagement.dev/) An Elegant Puzzle: Systems of Engineering Management by Will Larson (https://press.stripe.com/an-elegant-puzzle) Listener question: https://masto.ai/@edebill@wandering.shop/109501793033994252 (https://masto.ai/@edebill@wandering.shop/109501793033994252) Ask questions via our anonymous feedback form (https://forms.gle/MW8qZFD7RLYriqKj8) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). You can follow us on Twitter at @podcast_eb (https://twitter.com/podcast_eb). Where to find Monica on the internet: Website: monicag.me (https://monicag.me/) Mastodon: @nirnaeth@mastodon.online (https://mastodon.social/@nirnaeth@mastodon.online) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Mastodon: @ujh@masto.ai (https://masto.ai/@ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

This week Sarah Drasner joins us to talk about her book Engineering Management for the Rest of Us and her experience leading engineering at Zillow, Microsoft, Netlify, and now Google.

This week Sarah Drasner joins us to talk about her book Engineering Management for the Rest of Us and her experience leading engineering at Zillow, Microsoft, Netlify, and now Google.

Stephanie has a win and a gripe from her client project this week. In a previous episode, Joël talked about his work exploring how to model dependent side effects, particularly D&D dice rolls. He went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs. Then it will roll all the dice necessary and tell you did you successfully hit your target and, if so, how much damage you did. Together, they discuss how they think about fulfillment at work and what brings them fulfillment as developers. Obsidian (https://obsidian.md/) Joël's DnD dice roll app production (https://dnd-damage-roller.netlify.app/) site and repo (https://github.com/JoelQ/dungeons-and-dragons-damage-calculator) Engineering Management for the Rest of Us (https://www.engmanagement.dev/) The Five Love Languages (https://www.psychologytoday.com/intl/blog/click-here-happiness/202009/what-are-the-5-love-languages-definition-and-examples) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So I have a win, I suppose, and a gripe from my client project this week that I would love to share. So my win is that I've been working in React lately. And I might have mentioned this on a previous episode, but it's been a few years for me. So I'm kind of catching up on the new, hot tooling, you know, whatever is popular in that world these days, and having to read a lot of documentation to figure out how to use it and just in general, I think being a little bit outside my comfort zone. And I was working on an existing React component that was untested, and I had to change and extend some functionality in it. And we're also a little bit on a deadline. So there's like a little bit of pressure on the team to be delivering. And so when I got this ticket, I was like, okay, I am seeing this existing component that looks also a few years outdated. It's using some of the older technology that we've kind of moved on from. And I was just like, oh, I really should write tests for this before I go in and change some things just to feel confident that my changes don't break anything because it was pretty gnarly. But I was not in the mood for it. [laughs] And this was like two or three days ago. I was just very grumpy. And I was like, oh man, why do I have to do it? [laughs] I kind of wanted to just get into making the changes so I could deliver on this work. So, spoiler, I did not write the tests that day and just kind of went ahead with the changes. But then, the next morning, I woke up, and I was feeling inspired. I was like, I made those changes, but I'm actually not feeling that confident about it. So let me go back and try to write some tests. And I got to use the new tools I had been looking into, and that was part of my hesitation too. I was like, oh man, this is like a really old component. And I don't want to use the older ones that we're using for testing. But how is it going to play with the newer testing tools that we're using? And so there was just like a lot of, I think, barriers to me feeling excited about writing those tests. But with my renewed energy, I did it. And I feel very happy about it and proud of myself. Yeah, that's my little win. JOËL: That's a roller coaster of a journey there. That sort of deception when you find out that there are no tests for this and somebody else's problem has kind of become your problem. But then you decide you don't want it to be your problem, you know, kick it down the road for somebody else. And then you feel good about yourself, and you decide to backfill the test anyway. And you get that confidence, and now everything's better for everybody. That is quite the journey. STEPHANIE: Exactly. I listened to another podcast recently where they coined this term called tantrum logic, which is basically the idea that when you're kind of grumpy or something happens, and you're like, man, I don't want to do any of this, like, if I can't do it my way, then I don't want to do it at all. [laughs] And just the idea that the way you're thinking about the issue at hand may not be totally grounded in reality. And I think I needed that reset and just a good night's sleep and going to do something else to come back and be like, actually, I do want to write those tests, even if it will be challenging. I'm in a better mind space for it. Mind space? Headspace? [laughs] Headspace for it. And I overcame the tantrum logic. JOËL: A good night's sleep is just such a powerful tool for resetting. STEPHANIE: Yeah, I agree. Shout out to sleep. [laughs] It turns out that it can really have a positive effect on how you feel. JOËL: By the way, this is not an advertisement. We are not sponsored by sleep. We just both love it and recommend it. STEPHANIE: [laughs] To get into my gripe a little bit, so you and I are on the same client project we've mentioned before on the show. And I think I even talked a little bit about receiving a new computer from our client to do our client work on. So now I have many devices at home. And we had also chatted previously about a note-taking app that we both use called Obsidian. And one of the reasons that I really like it is because it's all local storage. So your notes are not being uploaded to the cloud or whatever. But that does make it hard to use on multiple, I mean, not just hard, impossible to use [laughs] on multiple devices unless you pay for it. They have a sync offering where you can use it on multiple devices. And I think it's also encrypted in a certain way. Anyway, sometimes I'll be working on my client laptop and have some idea or thought that I really want to note down, but I don't have Obsidian installed on this machine, and it's not synced to my other Obsidian. And I have just been kind of annoyed about having to go open another computer to write a thought down if I want to document it. And I'm curious how you deal with this problem. JOËL: So the downside of Obsidian not being a cloud product is that you don't just get that sync for free. The upside of it just being markdown files on your hard drive is that you can use any other product or tool that you want to manipulate these files. So I have my Obsidian vault, which is just the term for the directory where it keeps all of these files in a Dropbox directory. And so I have it sync across multiple machines just by being signed into my Dropbox account. STEPHANIE: That's smart. And that sync is pretty smooth for you? You don't have any issues with updating it in one spot and seeing those changes in another? JOËL: I have not had issues with that. Of course, I'm not jumping between machines within 30 seconds of each other. Generally, I'm also connected to the internet. So I haven't had a situation where I make a change to a machine not connected to the internet, and then later on, I edit an old version on a different machine that is connected to the internet, and now we have conflict. I've not run into that problem. STEPHANIE: Okay, cool. That sounds good. It's funny you mentioned that because it's just the other day, off-mic; you and I were on a call doing a little bit of pairing. And you were on both machines at the same time [laughs] because we had to use one for our call. And then you were looking something up on your client computer as well. And the thought of you just using two computers at once was very amusing to me. JOËL: It's the ultimate hacker move in...I was going to say bad, but that's maybe a little bit too judgmental, but yeah, in classic, I feel like police shows, things like that. STEPHANIE: I do have one more thought about note-taking that we haven't talked about before. But I'm really curious, how do you deal with thoughts you have on the road during a time you don't have a device on you? Do you go and write that down somewhere, or what do you do with those? JOËL: I have an absolutely awful solution, which is I add it to my mental stack and hope it doesn't overflow before I get to a computer. STEPHANIE: That's really funny because I used to do something similar where if I had a to-do list or something like that in my head, I would remember the number of items on my list to try to cue me into remembering what those items were. The worst thing that would happen is I would remember that I had three things on my to-do list but could only remember two. And so I had to just [laughs] deal with my existential anxiety about knowing that there was something else that I had forgotten about but could not remember [laughs] for the life of me what it was. JOËL: So I do that trick sometimes for my grocery list if I don't want to write it down. I'll just be like, oh yeah, go to the grocery store, make sure there are five items in my basket when I check out. And similar to you, sometimes I have that problem. I had a light-bulb moment the other day, which is that this trick is actually an example of hashing content. STEPHANIE: [laughs] JOËL: So if you're ever hashing the contents of a file and then wanting to compare if another file is the same and you check the hashes are the same. In a sense, you're kind of hashing your grocery list and your shopping cart and trying to see do they both hash to the same value? Now, a good hashing algorithm has an infinitesimally low chance of a collision. Counting the number of items in your list or cart has a fairly high chance of a collision. You could have a cart and a list that both have five items, but they're not the same items. Yet this comparison would still make you think that they're the same. STEPHANIE: This is a very funny metaphor to me. I think the other issue is that as a human and not a computer, I do not have the mental storage space to then also remember what algorithm [laughs] I'm using to hash my to-do list. JOËL: The algorithm is the count function. STEPHANIE: [laughs] True, true, a more sophisticated algorithm then. [laughs] JOËL: Yes, which is why I keep using this not very safe, but it's good enough. STEPHANIE: Sometimes, we just need to be good enough. So, Joël, what's new in your world? JOËL: So, in a previous episode, I think we talked about some work I was doing exploring how to model dependent side effects, particularly D&D dice rolls. So this week, I went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs, and then it will roll all the dice necessary and tell you did you successfully hit your target, and if so, how much damage did you do? And it takes into account all these edge cases. STEPHANIE: Cool. That's so exciting because I think we mentioned last time how that would be a really interesting exercise to write up that code. Did you get any insight from doing that? JOËL: I think a lot of the insight that I got came from the initial diagramming phase. And I think coding it out really solidified the things that I had learned from the diagramming. Of interest here is that there are effectively or potentially four separate dice-rolling phases that can happen. First, you're rolling to see can you hit your target? And depending on the situation, you're rolling one or two dice. And then after that, you're rolling to see if you do hit, how much damage you do. And you're either rolling one set of dice, or you might be rolling two sets of dice if you happen to do a critical hit. So I think that the diagram that I had clearly showed these are four sets of randomness that have to happen and then how they relate to each other. These two are dependent on each other; these two are independent. I think one thing that was really interesting that I learned from the code is that for something like a dice roller, you usually don't want to see just the result. Because if I just have a button that says how much damage did I do, and then I get a number back that says, "You did zero damage," or "You did three damage," as a person, that's not very satisfying. And I don't know that I fully trust it. I want to see all the intermediate results. So I want to see, oh, did I roll two different dice for that initial two-hit? What were the numbers? And then I can say, okay, well, I need to roll above a five or roll above a 10. And I rolled these two dice, and they were both under 10. That makes sense why I didn't hit. Or I rolled one of them above and one of them below, but I was rolling with disadvantage, which means I have to take the lower of the two numbers. So I could have hit, but I didn't. So I think that is really fun as a user to see the intermediate steps. But also, as a developer, it helps me to be confident that the code I wrote works the way I expect it to. STEPHANIE: Yeah, that's really neat. I think what I love about this is that you took something that, in some ways, could be really simple, right? And the implementation could have been just the first thing that you thought of, but you thought very deeply about it and made the dice roller that you wanted in the world. [laughs] I'm curious. Can anyone go check out this repo on the internet? JOËL: Yes. So we can link to the repo in the show notes. And also, the dice roller itself is up online at dnd-damage-roller.netlify.app. And we can link that as well for anybody who wants to go and check it out. STEPHANIE: Awesome. JOËL: I think my goal in this is it's more of a learning exercise. I don't think the world needs another D&D dice roller. There are better ones built into more comprehensive tools. But it was fun for me to work on this, to explore some ideas, and to dig into randomness. I've always had a fascination with random rolls. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: So it sounds like the Dice Roller app really scratched an itch for you and was a fulfilling exercise for you and just exploring randomness, like you mentioned, and just a theory that you had about writing good code. I'm curious about how you think about fulfillment at work in general and what brings you fulfillment as a developer. JOËL: Fulfillment is really interesting because I think it's a really kind of personal question. It probably varies a little bit from person to person. But there are probably also some aspects that are global to everyone. I know we've talked about things like psychological safety in the past. And if you don't have things like that, that baseline, it's going to be hard to feel fulfilled. STEPHANIE: Yeah, I agree. I am thinking of Maslow's hierarchy of needs, and in some ways, fulfillment is kind of the tip of the pyramid. If you are feeling safe and like you belong and get enough sleep, like we mentioned earlier, you can reach towards getting into what really feels fulfilling and gives you purpose in life. JOËL: I love that you brought up Maslow's pyramid because like you said, that top part is self-actualization. So you need all those lower layers before you can actually reach the point of true fulfillment on the job. One thing I recently realized about myself is how I tend to approach projects that are in a difficult place. I find a lot of fulfillment in sort of relative change. It doesn't matter if a project is in a bad place as long as the project on a week-by-week basis is moving in the right direction. It might still be in a bad place, but is it better than last week? And was I a part of making that better? That makes me feel good. STEPHANIE: Yes. I have always really admired your optimism around that and how you share even small wins. You're really good about that, actually, and celebrating that. And it's interesting to learn that it's like that process itself that has a lot of meaning for you. Because I think I'm a little bit different in the sense that I have an ideal version of working in my head, and if we're not there, even if we are making some incremental progress week to week, I think I struggle. Sometimes I feel frustrated or stressed because I think that we're just not where I want to be. And I've definitely been thinking about harnessing some of that optimism and celebration that you have around, just making things better a little bit at a time. JOËL: And I think we should be clear that this is not the way one has to be; this is just how I tend to feel on projects. STEPHANIE: Yeah, absolutely. JOËL: I know there are plenty of people who feel most fulfilled when they're on projects where things are mostly good. And then it's not about incremental improvement in the product, but maybe it's shipping a lot of features and feeling like they're moving very quickly. Maybe it's that feeling of speed that gives them fulfillment rather than the feeling of incremental progress. STEPHANIE: Yeah, absolutely. I think what is helpful for me in hearing about this from you and just from others (I love talking to other people and learning about what motivates them.) is seeing what else is possible outside of my own little universe inside my head and doing the self-reflection to be like, okay cool, this works for Joël, but maybe this doesn't work for me. But having the input from other people lets me discover more about myself in that way. JOËL: That is incredibly powerful. I love that. I think in a variety of aspects of my life, but especially when it comes to fulfillment in software and at work, talking to other people, seeing how they relate to a project or to a particular task, and, like you said, getting to see their perspectives that are sometimes totally different than mine. STEPHANIE: Yeah, absolutely. So you just mentioned one aspect of how you find fulfillment when a project is maybe in a tougher spot than usual. I'm curious if you can recall a time that you've been the most fulfilled at work. JOËL: Most fulfilled. I think one of the most fulfilling projects I did was several years ago. We built a dashboard for just exploring a lot of data from medical studies. And so the researchers would upload some time series data for things like heart rate, or skin electro-sensitivity, a bunch of other things, along with a video. It was a kind of an interview-style situation. They were doing a session with a patient. And we would then sync all of these data streams up. We would sync it up to the video, and then you could kind of explore the data. There were scrubbers, so you could kind of scrub through the video, and it would scrub through the time series data all at the same time in sync. You could scrub through the time series data. It would sync the video kind of like bidirectional. You could zoom in on the data. The idea is this is a high-level kind of exploratory tool. And you could then find the interesting bits of data that you could then do more quantitative analysis on. So you could then find a part of the stream and say, this is the interesting part. Clip from 10:55 to 11:10 in the stream, on all streams, and then export just that data in a zip file. And then I'm going to put that through a bunch of math and figure out, oh, is there a correlation between these moments? STEPHANIE: So what about that project was really exciting or fun for you? JOËL: I think the client was incredibly fun to work with. There was like an energy and excitement. This was part of their, I think, Ph.D. thesis. And they were really excited. They were incredibly knowledgeable, just delightful to work with. I think this was a fun...so we built this from scratch. It was a greenfield app. I think it had a lot of interactivity. It had a lot of visuals. It was one of the first projects I got to work on that used Elm. I think all those things combined to just make it a really fun project to work on. It was also a fairly short project. So we had a very kind of tight deadline. We were very pragmatic with absolutely everything on there. Like, what can we do to get this done quickly? Is this feature worth the time? It was kind of a classic MVP product. And I think it was one of the most fun things I've built. STEPHANIE: Cool. I'm also hearing there was probably some creative aspect of it that was really fulfilling for you, like exploring a lot of new things. Like, you said, you were working with Elm for the first time. And the project itself sounds very different from some of our other more typical consulting engagements and also the collaboration aspect. Like, you mentioned the tight deadline, which compelled you all to work really closely together to make this really cool thing in that short amount of time. JOËL: Exactly. Yeah, it was like a three or four-week project that I look back on really fondly. Like, oh, that was a good time with those two colleagues and that client, and we did a thing. It was really cool. STEPHANIE: That's awesome. JOËL: I think it's really interesting that just hearing that story, you're immediately picking up on, like, oh, I see elements of creativity and exploration. Do you have kind of an internal system that you use to analyze projects that you're on to be like, oh, this is a project I'm enjoying because of this element or that? Because you seem very self-aware around these types of things. STEPHANIE: I'm glad you asked that because I think I was trying to reflect back to you some of the things that I picked up about what you were sharing. I have been reading a book, surprise, surprise. JOËL: What? You read? STEPHANIE: I read. [laughs] It's called "Engineering Management for the Rest of Us" by Sarah Drasner. And I am not an engineering manager, and I don't necessarily know if I even want to be. But I really enjoy reading management books to better understand how to manage myself or how to be a person who is managed. And one of the things she talks about is understanding an individual's values and how those things end up being what motivates them and also likely what brings fulfillment. And so after I learned about the value of values, I started thinking, okay, what is it that I am motivated by? And really reflecting on when I have felt really good about work and also when I felt challenged or unhappy at work and what things were missing during that time. So the things that I have realized that I am very motivated by are human connection. I love spending quality time with people, and that is probably why I enjoy pairing so much. But also, in my one on ones with my manager, I really enjoy that time just being time for us to share space and get to know each other and talk. It doesn't necessarily need to be going through agenda items or a status report or even necessarily talking about my project. JOËL: So you mentioned that you value quality time with others. Is that a reference to "The Five Love Languages" concept? STEPHANIE: It is. It is. I think I also made a bit of a connection there too because what I like in my personal relationships also obviously applies to work. JOËL: Yeah, it's how you feel appreciated, how you feel fulfilled. And just for our listeners who may not have read this book, I think the concept is that there are five ways that people like to receive appreciation. STEPHANIE: Yeah, I think receive and both express appreciation and love. And quality time is one of them. JOËL: Yeah, yeah. And the other four, if I remember correctly, are acts of service, words of affirmation, physical touch. STEPHANIE: Gift-giving is the last one. Yeah, so that was a fun reflection on my part in being able to just know what makes me feel good. And then it also helps me communicate with other people how to work with me. I think that is super important. I love when people share with me what, I mean, I mentioned this earlier, just what drives them and how they like to be appreciated so that I can do my best to try to offer them that. And I guess this actually is a good transition into the next value of mine that really drives me. I was thinking about this because I mentioned just now that I was learning some new React tools, new to me, anyway. And I'm like, yeah, I like learning. But then I was like; I don't know if I like learning the way other people like learning in the sense that it's not the knowledge itself or the process of learning itself that drives me but learning as a tool to better understand myself. So I think personal development is very important to me. And that feels different from how other people might value learning. JOËL: Interesting. So you might be excited to learn a new React testing tool but not because you're chasing the latest, shiny tech but more because you feel like the process of learning this testing tool helps you learn something new about yourself. STEPHANIE: Yeah, I think that sounds right. One of the tools specifically...we're using MSW Mock Service Worker for mocking network requests in Jest. And I was able to use information about testing in Rails and Ruby and apply that to this new tool. And I got to kind of revel in the fact that I could use previous learnings to apply in this new context, and that was really cool to me. So it wasn't necessarily the tool itself or even the process of learning but kind of realizing that I was capable of applying one thing to this less familiar thing. JOËL: So kind of that realization that, hey, you're now far enough in your career, and you have enough experience. You have a broad base of knowledge that all of a sudden, you realize, wait a minute, I'm not starting from scratch anymore. I can apply lessons learned in the past to learn this new thing and make that easier. And that's a really validating feeling. STEPHANIE: Exactly. That was really cool to me, and I felt really good afterwards. I think this week at work has been very uplifting because I've been having all these little mini-revelations if you will. JOËL: I love that. I love that so much. STEPHANIE: So, one thing that I think is very easily conflated with fulfillment is the idea of success. And I kind of want to talk about the distinction between success and fulfillment. Does that bring up any thoughts for you? JOËL: Yes. I think the two are often entangled, but they're definitely not the same thing. It is possible to be fulfilled on a project that is not successful. And it's also possible to be on a successful project and yet not feel fulfilled. But oftentimes, the two go together because when things are going well on a project, they're probably also going well in a lot of other ways, and you might be feeling fulfilled as long as general parameters fit in, right? If values line up, things like that. I know for me I value quality and excellence and doing work that I'm proud of. So I think if I were working at a place that was doing kind of low-quality, low-cost work where it's just like, you know what? You want cheap and low-quality? Come to us. We'll just get it done quick and cheap. And yeah, it's not going to be great, but you get what you pay for. There's a reason this part of the market exists, and it's a totally valid way to build software. But I would not feel fulfilled there, even though maybe the clients are absolutely happy with the work that's being done. So I think that would be a situation where there is success, but I might not feel personally fulfilled. STEPHANIE: Yeah, I'm glad you brought that up because I think I really struggled in the beginning of my consulting career with equating client happiness with success. And I'm now just starting to kind of unlearn that a little bit and realizing that success means different things to different people. So even if we talk about thoughtbot for just a second, one of thoughtbot's values as a company is seeking fulfillment in everything that we do. And so even though, like you said, the client might be totally happy, for thoughtbot, that may not be a successful client engagement if you, Joël, as the developer staffed on that project, didn't find fulfillment. Because what's success for us here is that we are fulfilled in the project itself. And that was really helpful because, in some ways, I'm like, well, who cares? Who else cares besides me that I'm fulfilled? And to be like, oh, yeah, actually, what our collective success means is that I'm fulfilled, and you're fulfilled. That was really important to me and one thing that I really appreciate about working here. JOËL: Fulfillment comes partly from our environment, from maybe the project that we're working on, our colleagues, but also comes to a certain extent from ourselves. And to a certain extent, we can drive that ourselves as well. And I think that first step is a certain amount of self-awareness and self-understanding. You are clearly a master at this. What are some things that you do to drive that self-understanding, to build maybe a sense of how you become fulfilled, and identifying those values that make you feel fulfilled on a project? STEPHANIE: Listen, [laughs] I don't know if I would call myself a master at this, only that I'm very actively working on it in my life right now, in therapy, but also in talking to other people about this because, yeah, sometimes it has caused me a lot of turmoil. I'll be really stuck in a rut or feeling a lot of burnout, and that, ironically, actually motivates me to be like, how can this be different? And oftentimes, that means I have to look inward. But you and I had a conversation last week off-mic that was really helpful for me because I was feeling really bummed about my client work and it not going the way that I thought it would. And your insight helped me think about the project a little differently and think about metrics of success differently. For that project, I could not expect that project to look exactly like all of my past experiences. And success for those projects were not the same for this project. So yeah, talking to others, I highly recommend that. JOËL: I guess you mentioned that you read a lot of management books and a lot of books geared towards managers for discussing things like how to set up a one-on-one. Those are almost like...they're not really therapy, but they kind of lean a little bit towards that sometimes and trying to create fulfillment for your direct reports. So maybe seeing it from the other side helps you build understanding. STEPHANIE: Yeah, actually, that's totally a great call out because I highly recommend reading books about [laughs] management, even if you're not interested in management. Only because there's no guarantee that you'll have a good manager who can do all those things for you, so if you can equip yourself for doing those things, then you are likely to have a better workplace experience, in my opinion. JOËL: And I guess the obvious one that we have not talked about is if you do have a good manager, have these conversations with them. STEPHANIE: Yeah, absolutely. JOËL: Part of their job is to help you be more fulfilled. And they should be having conversations to maybe help you discover those ways that you are feeling fulfilled at work and how to get there. Here's one aspect that we have not talked about that I'm curious to explore a little bit: recognition. STEPHANIE: Ooh. Yeah, that's a good one. JOËL: How important is it for you to feel recognized, either by your colleagues or by the more official org structure? STEPHANIE: This is a great question. I do value recognition from people I trust. So I think we were talking about sometimes client projects are not successful, but you tried your best, and you did do valuable work. And you might not hear that from the client. They might think differently. But if a trusted co-worker can provide that validation for you, oftentimes, I find that more helpful. JOËL: That's an interesting distinction. And I think recognition has a very different weight depending on the source it's coming from. If it's somebody you look up to, and they just give you a shout-out or something, I'm riding that high all day long. STEPHANIE: Yeah, yeah, that's a great point. How do you like to receive recognition? JOËL: Hmm. So at thoughtbot, we have an internal system where we can give shout-outs to each other. They're called high fives. And they get shared directly to the team Slack channel. And it's a small thing, but I really appreciate it when somebody calls out like, "Hey, I appreciated this thing that you did," or "This is the thing that had an impact on me," or "I appreciated the thing that you shared." Those things make me feel really great. It's a small thing. It takes 30 seconds to do. But I really appreciate that. And it's something that I am looking to more intentionally do more of because it's fun to receive recognition, but it's also really valuable to give recognition. STEPHANIE: Yeah, I'm with you. I am also trying to be intentional about being even more generous with my positive feedback for others. And I think there's also some degree of recognition and validation to give to yourself. JOËL: Self-validation. STEPHANIE: Yeah, yeah. I mean, I'm definitely trying to do more of that. Because if I'm doing work that lines up with my values, I want to be able to pat myself on the back for it, even if no one else will do it for me. [laughs] JOËL: What does that look like? You're like standing in the mirror and saying, "Good job?" STEPHANIE: [laughs] JOËL: Do you have maybe a document where you kind of list the things that you feel proud of, even if nobody else has noticed? What does that look like for you? STEPHANIE: Ooh, yeah, a brag document. I think some folks at thoughtbot have recommended doing that. For me, it's going and getting myself a treat. JOËL: Oh, I like that. STEPHANIE: So maybe like a latte the next morning or going to get just a sweet thing. Yeah, that's my way of doing it. JOËL: So we've talked about self-recognition, recognition from colleagues. I think another element is recognition from management or the company that you're working at. That can be just praise. But oftentimes, I think when you're looking at recognition from something a little more corporate, it has a more kind of concrete aspect to it. And maybe that is come yearly evaluation time; there's a raise that recognizes the fact that you've done good work. I know for me, last year, I got a big promotion. And I felt like I had been performing at a level that was kind of pretty far above and beyond the title that I had. And getting that promotion, in some ways, was very much kind of validation and recognition of the fact that I had been performing at that high level. STEPHANIE: Yeah, it sounds like the acknowledgment for the expanded work that you've been doing was really motivating for you. JOËL: Yeah. It's interesting you mentioned that acknowledgment is really motivating because it really is, and sometimes the reverse is also true. You feel discouraged or unmotivated because the good work that you're doing is not recognized. Are you familiar with the idea of intrinsic versus extrinsic motivation? STEPHANIE: Yeah, I am. Being motivated by something externally, like someone offering a promotion, or a raise, or whatever, versus it coming from yourself. JOËL: Yeah. And I think for many people, you're probably not purely motivated by one or the other. There are some things where you're motivated by your own internal values, as we mentioned earlier, and some things where you're motivated by incentives offered at work. And that balance will probably shift over time and in different moments. But having a little bit of both can be really, really powerful. If you can be living up to your values and then get rewarded for it, that's kind of peak fulfillment right there. STEPHANIE: Yeah, that's the sweet spot. Yeah, I wish that for everyone in the world. [laughs] On that note, shall we wrap up? JOËL: Let's wrap up. [laughs] STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

In this supper club episode of Syntax, Wes and Scott talk with Sarah Drasner about her new book, Engineering Management for the Rest of Us, what it's like moving from management to coding and back, the book writing process, and her Fortnite VS Code theme. Show Notes 00:36 Welcome 01:59 Who is Sarah Drasner? @Sarah_Edo on Twitter @Sarah_Edo on Mastodon @Sdras on CodePen @SDras on GitHub SarahDrasnerDesign.com Google Engineering Management for the Rest of Us Amazon: Engineering Management for the Rest of Us Netlify 05:25 How did you figure out what to do in management? 07:20 How do you get out of engineer's way? The Engineer Manager pendulum 09:39 Do you spend time on making the person happy in the job? 15:51 Should managers code? 19:16 Was it difficult to step out of coding? 21:07 Why do people leave jobs? 24:04 Dealing with conflict and reorgs 28:36 What makes a good retro? 31:25 What was your process for writing a book? SVG Animations: From Common UX Implementations to Complex Responsive Animation Scrivener Egghead Mayfly Design Sarah Drasner's articles on CSS Tricks Sarah Drasner's articles on Smashing Magazine 43:44 Supper Club questions Sarah Drasner's VS Code snippets and themes Creating a VS Code theme Wes Bos Cobalt 2 VS Code theme Partytown beta 53:10 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Paper Koi Lantern: a DIY Kit Shameless Plugs Engineering Management for the Rest of Us Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Chris is getting ready to travel, and of course, Sagewell started the day with an incident, a situation, if you will... Steph talks books perfect for vacations and feels sufficiently scarred regarding still working with moving fixtures over to FactoryBot. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Back to Basics: Boolean Expressions (https://thoughtbot.com/blog/back-to-basics-booleans) Sarah Drasner tweet (https://twitter.com/sarah_edo/status/1538998936933122048) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: All right, I am now officially recording as well. Let me make sure my microphone is in front of my face. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: What's new in my world? Today is an interesting day. We are recording on a Friday, which is not normal for us, was normal for a long time and then stopped, but now it's back to being normal. But it's the morning, which is confusing. Also, I am traveling this evening. I leave on a flight going to Europe. So I'm going to do a red-eye, that whole thing. So I got a lot to pack into today, literally packing being one of those things. And then this morning, because obviously, this is the way the world should play out, we started the day with an incident at Sagewell, a situation. Some code had gotten out there that was doing some stuff that we didn't want it to do. And so we had to sort of call in the dev team. And we all huddled together and tried to figure it out. Thankfully, it was a series of edge cases. It was sort of one of those perfect storms. So when this edge case happens in this context, then a bad thing could happen. Luckily, we were able to review the logs; nothing bad happened. While I'm unhappy that we had this situation play out... basically, it was a caching thing, just to throw that out there. Caching turns out to be very hard. And the particular way it played out could have manifested in behavior that would have been not good in our system, or an admin would have inadvertently done something that would have been incorrect. But on the positive side, we have an incident review process that we've been slowly incubating within the team. One of our team members introduced it to us, and then we've been using it on a few different cases. And it's really great to just have a structured process. I think it's one of those things that will grow over time. It's a very simple; what's the timeline of what happened? What's the story as to why it happened and why it wasn't caught earlier? What are the actions that we're going to take? And then what's the appendix? What's the data that we have around it? And so it's really great to just have that structure to work within. And then similarly, as far as I can tell, the first even observable instance of this behavior in our system was yesterday morning. We saw it, started to respond to it, saw one more. We were able to chase it down in the logs. Overall, the combination of the alerting that we have in Sentry and the way in which we respond to the alerting in Sentry, which I think is probably the most critical part. Datadog is our log metrics tool right now. So we're able to go through Datadog, and we have Lograge configured to add more detail to our log lines. And so we're able to see a very robust story of exactly what happened and ask the question, did anything actually bad happen? Or was it just possible that something bad could happen? And it turns out just possible. Nothing actually happened. We were able to determine that. We were even able to get a more detailed picture of who were all the users who potentially could have been impacted. Again, I don't think there was any impact. But all total, it was both a very stressful process, especially as I'm about to go on vacation. It's like, oh cool, start to the day where I'm trying to wrap up things, and instead, we're going to spend a couple of hours chasing down an incident. But that said, these things will happen. The way in which we were able to respond, the alerting and observability that we had in place make me feel good. STEPH: I like the incident structure that you just laid out. That sounds really nice in clarifying what happened when it happened in the logs. And the fact that you're able to go through and confirm if anything really bad happened or not is really nice. And I was also just debating this is one of those things, right? Right when you're about to go on vacation, that's when something's going to break. And that's like, is that good or bad? Is it good that I was here to take care of it right before, or is it bad? Because I'd really like to not be here to take care of it. [laughs] You may have mixed feelings. I have mixed feelings. CHRIS: I think I'm happy. Unsurprisingly, this exists in one of the most complex parts of our codebase. And it involves caching. And I remember when we introduced the caching, I looked at it, and I was like, hmm, we have a performance hotspot that involves us making a lot of requests to an external system. And so we thought about it a little bit, and we were like, well, if we do a little bit of caching here, we can actually reduce that down from seven calls down to one over external HTTP. And so okay, that seems to make sense. We had a pull request. We did a formal review. And even I looked at the pull request where this was introduced initially, and my comments on it were like, yep, this all looks good. Makes sense to me. But it's caching-related. So let's be very careful and look very closely at it and determine if there's anything, but it's so hard to know. And in fact, the code that actually was at play here was introduced a month ago. And interestingly, the observable side effect only occurred in the past two days, which we find very surprising. But again, it's this weird like, if A happens and then within a short period after that B happens...and so it's not quite a race condition. But it was something where a lot of stuff had to happen in a short span of time for this to actually manifest. And so, again, we were able to look through the logs and see all of the instances where it could have happened and then what did happen. Everything was fine, but yeah, it was interesting. I feel actually good to have seen it. And I think we've cleared everything up related to it and been very proactive in our response to it so that all feels good. And also, this is the sort of thing we've done this a few times now where we've had what I would call lesser incidents. There was no customer-facing impact to this. Similarly, previous incidents, we've had no or very minimal customer-facing impact. So at one point, we had a situation where we weren't processing our background jobs for a little while. So we eventually caught up and did everything we needed to. It just meant that something may not have happened in as timely a fashion as necessary. But there were no deep ramifications to that. But in each of those cases, we've pushed ourselves to go through the incident process to make sure that we're building the muscle as a team to like, actually, when the bad one comes, we want to be ready. We want to have done a couple of fire drills first. And so partly, I viewed this as that because again, there was smoke, but no fire is how we would describe it. STEPH: Nice. And that also makes sense to me how you were saying y'all introduced this about a month ago, but you were just now seeing that observable side effect. I feel like that's also how it goes. Like, you implement, especially with caching, some performance improvement, and then you immediately see that. And it's like, yay, this is wonderful. And then it's not til sometime passes that then you get that perfect storm of user interactions that then trigger some flow that you didn't consider or realize that could create an issue with that caching behavior. So yeah, that resonates. That seems right. All caching problems usually take about a month or two when you've just forgotten about what you've done. And then you have to go back in. CHRIS: Yep. Yep, yep, yep. So now we've done the obvious thing, which is we've removed every cache from the system whatsoever. There are no caches anymore because it turns out we just can't be trusted with caches in any form whatsoever. ActiveRecord, we turned off caching, Redis we threw it out. No, I'm kidding. We still have lots of caching in the app. But, man, caching is so hard. STEPH: I would love if that's in the project README where it says, "We can't be trusted with caches. No caches allowed." [laughs] CHRIS: Yeah, we have not gone all the way to forbid caching within the application. It's a trade-off. But this does have that you get those scars over time. You have that incident that happens, and then forever you're like, no, no, no, we can't do X. And I feel like I'm just a collection of those. Again, I think we've talked about this in previous episodes. But consulting for as long as I did, I saw a lot of stuff. And a lot of it was not great. And so I basically just look at everything, and I'm like, urgh, no, this will be hard to maintain. This is going to go wrong. That's going to blow up someday. And so, I'm having to work on trying to be a little more positive in my development work. But I do like that I have that inclination to be very cautious, be very pessimistic, assume the worst. I think it leads to safer code in general. There was actually a tweet by Sarah Drasner that was really wonderful. And it's basically a conversation between her and another developer. It's a pretend conversation. But it's like, "But why don't you like higher-order components?" And then it's Squints. "Well, in the summer of 2018, something bad happened, Takes a long drag of a cigarette. something very bad." It's just written so well and captures the ethos just perfectly. Like, sit down. Let me tell you a tale of the time in 2018. [laughs] So I'll include a link to that in the show notes because she actually wrote it so well too. It's got like scene direction within a tweet and really fantastic stuff. But yeah, we'll allow some caching to continue within the app. STEPH: That's amazing. So I was just thinking where you're talking about being more pessimistic versus optimistic. And there's an interesting nuance there for me because there's a difference in like if someone's pessimistic where if someone just brings up an idea and someone's like, "Nope, like, that's just not going to work," and they just always shoot it down, that level of being pessimistic is too much. And it's just going to prevent the team from having a collaborative and experimental environment. But always asking the question of like, well, what's the worst that could happen? And what are the things that we should mitigate for? And what are the things that are probably so unlikely that we should just wait and see if that happens and then address it? That feels like a really nice balance. So it's not just leaning into saying no to everything. But sure, let's consider all the really bad things that could happen, make a plan for those, but still move forward with trying things out. And I realized I do this in my own life, like when someone asks me a question around if there's something that we want to do that's a bit kind of risky. And the first thing I always think of is like, well, what's the worst that could happen? And I think that has confused people that I immediately go there because they think that I'm immediately saying no to the idea. And so I have to explain like, no, no, no. I'm very intrigued, very interested. I just have to think through what's the worst that can happen. And if I'm okay with that, then I feel better about accepting it. But my emotional state, I have to think through what's the worst and then go from there. CHRIS: Wow, it's a very bottom-up approach for your life planning there. [chuckles] STEPH: Yep, I think that's, you know, it's from being a developer for so long. It has impacted now how I make other decisions. Good or bad? Who knows? Yeah, it turns out being a developer has leaked into my personal life. I've got leaky abstractions over here. So, good or bad? Who knows? CHRIS: Leaky abstractions all the way down. Yeah, circling back to, like, I don't think I'm pessimistic per se. The way that I see this playing out often is there will be a discussion of an architectural approach, or there's a PR that goes up. And my reaction isn't no, or this has a known failure point; it is more of uh, this makes me uncomfortable. And it's that like; I can't even say exactly why, and that's what makes it so difficult. And I think this is a place that can be really complicated for communication, particularly between developers who have been around for a little bit longer and have done this sort of thing and have gathered these battle scars and developers who are a bit newer. Having that conversation and being like, um, I can't say exactly why. I can tell you some weird stories. I might not even remember the stories. Some of it just feeds into just like, does this code make me uncomfortable? Or does this code make me happy? And I tend towards wildly explicit code for these reasons. I want to make it as clear as possible and match as close as possible to the words that we're saying because I know that the bugs hide in the weird corners of our code. So I try and have as few corners. Make very rounded rooms of code is a weird analogy that doesn't play, but here we go. That's what I do on this show is I make weird analogies. Actually, we were working on some code that was dealing with branching conditional things. So we had a record which has a boolean value on it. So we've got true or false, and then we've got two states, and then we've gotten an enum with three states. So all total, we have six possible states. But as we were going through this conversation, I was pairing with another developer on the team. And I was like, something feels weird here. And I actually invoked the name of Joël Quenneville because much of the data structure thought that I had here I associate with work that Joël has done around Maybe and things like that. And then also, my suggestion was let's build a truth table because that seems like a fun way to manage this and look at it and see what's true. Because I know that there are spots on this two-by-three grid that should never happen. So let's name that and then put that in the code. We couldn't quite get it to map into the data type, like into that Boolean in the enum. Because it's possible to get into those states, but we never should. And therefore, we should alert and handle that and understand, like, how did this even happen? This should never happen. And so we ended up taking what was a larger method body with some of the logic in it and collapsing it down to very explicitly enumerate the branches of the conditional and then feed out to a method. Like, call a method that had a very explicit name to say, okay, if it's true and we're in this enum state, then it's bad, alert bad. And then the other case like, handle the good case. And I was very happy with what we refactored down to because this is another one of those very complex parts of our code. Critical infrastructure-y is how I would describe it. And so, in my mind, it was worth the I'm going to go with pathological refactoring that we got to there. But yes, I was channeling Joël in that moment. I'm very happy to have had many conversations with him that help me think through these things. STEPH: That's awesome. Yeah, those truth tables can be so helpful. There's a particular article that, of course, Joël has written that then describes how a truth table works and ways that you can implement it into your habits. It's called Back to Basics: Boolean Expressions. I will be sure to include a link in the show notes. CHRIS: But yeah, I think that summarizes my day and probably the next couple of days as I prepare for an adventure over to Europe and chat about developer spidey sense. But yeah, what's new in your world? STEPH: Yeah, that's a big day. There's a lot going on. Well, I actually want to circle back because you mentioned that you're packing and you're going on this trip. And I'm curious, do you have any books queued up for vacation? CHRIS: I do, yeah. I'm currently reading Elantris by Brandon Sanderson. Folks might be aware of his work from the highest-funded Kickstarter of all time, which was absurd. Did you see this happen? STEPH: I don't think so, uh-uh. CHRIS: He did this fun, cheeky little Kickstarter. The video was sort of a fake around...oh, it almost sounded like he might be retiring or something like that. And then he's like, JK, I wrote five new books. And so the Kickstarter was for those books with different tiered packages and whatnot. I think he got just the right viral coefficient going on. And apologies for the spoiler if anyone's not seen the video, but it's been out there for a while. So he wrote some books, and that's what the Kickstarter is for. You get some books. You sort of join a book club, and you'll get one a quarter. A million dollars seems like that will be a bunch for that. That'd be great. If he raised a million dollars, that'd be amazing. $40 million four-zero million dollars. [laughs] I'm just watching it play out in real-time as well. It just skyrocketed up. The video, I think, was structured just right. He got it onto the...it was on Reddit and Twitter and just bouncing around, and people were sharing it. And just everything about it seemed to go perfectly. And yes, the highest-funded Kickstarter of all time, I believe, certainly within the publishing world. But yeah, Brandon Sanderson, prolific author, and his stuff ends up just being kind of light and fun. And so I was reading Elantris for that. It's been a little bit slower to pick up than I would like. So I'm now in the latter half. I'm hoping it'll go a little bit more quickly and be...I'm just kind of looking for a fun read, some fantasy thing to go on an adventure. But as the next book, I downloaded a second one just to make sure I'm covered. I have a book by John Scalzi, who's a sci-fi, fantasy, more on the sci-fi end of the spectrum. And I've read some of his other stuff and enjoyed it. And this particular book has a very consistent set of reviews. I've read the reviews a few times. And everybody who reviews it is just like, "This isn't the greatest book I've ever read, but man was it a fun ride." Or "Yeah, no, best book? No. Fun book? Yes." And just like, "This book was a fun ride. This was great." And I was like, perfect. That is exactly what I'm looking for on a European vacation. The book is called The Kaiju Preservation Society, which also plays on monsters, Pacific Rim Godzilla. Kaiju, I think, is the word for that category of giant dinosaur-like monster. And so it's the Kaiju Preservation Society, which, I don't know, means some stuff, and I'm going to go on a fun adventure. So yeah, those are my books. STEPH: Nice. I've got one that I'm reading right now. It's called Clementine: The Life of Mrs. Winston Churchill, written by Sonia Purnell. And Sonia Purnell tends to focus on female historical figures. And so it's historical fiction, which is a sweet spot for me. The only thing I'm debating on is because I'm realizing as I'm reading through it, I'm questioning, okay, well, what's real and what's not? Because I don't want to be that person that's like, did you know? And then, I quote this fictional fact about somebody that was made up for the novel. [laughs] So I'm realizing that maybe historical fiction is fun, but then I'm having to fact-check all the things because then I'm just curious. I'm like, oh, did this really happen, or how did it go down? So it's been pretty good so far. But then it makes me wish that historical fiction novels had at the back of them they're like, these are all the events that were real versus some of the stuff that we fictionalized or added a little flair to. I'm in that interesting space. I also like how you highlighted that you chose a fun book. I was having a conversation with a colleague recently about downtime. And like, do you consume more tech during downtime? Like, are you actively looking for technical blog posts or technical books to read or podcasts, things like that? And I was like, I don't. My downtime is for fun. Like, I want it to be all the things that are not tech. Maybe some tech sneaks in there here and there, but for the most part, I definitely prioritize stuff that's fun over more technical content in my spare time, which has taken me a little while to not feel guilty about. Earlier in my career, I definitely felt like I should be crunching technical content all the time. And now I'm just like, nope, this is a job. I'm very thankful that I really enjoy my job, but it's still a job. CHRIS: It is an interesting aspect of the world that we work in where that's even a question. In my previous life as a mechanical engineer, the idea that I would go home and read about mechanical engineering...I could attend a conference, but I would do that for very particular reasons and not because, like, oh, it's fun. I'll go meet my friends. For me, this was a big reason that I moved into tech because I am one of those folks who will, like, I will probably watch a video about Remix in particular because that's my new thing that I like to play around with and think about. But it needs to be a particular shape of thing I've found. It needs to be exploratory, puzzle-y. Fun code, reading, learning work that I do needs to be separated from my work-work in a certain way. Otherwise, then it feels like work, then it is sort of a drudgery. But yeah, my brain just seems to really like the puzzle of programming and trying to build things. And being able to come into a world where people share as much as they do blogs and conference talks and all of that is utterly fantastic. But it is a double-edged sword because I 100% agree that the ability to disconnect to, like, work a nine-to-five and then go home at the end of the day. Yeah, go home, you know, because you remember when we went to an office and then we would go home afterwards? I have to commute every once in a while into the city and -- STEPH: You mean go downstairs or go to another room? That's what you mean? [laughs] CHRIS: I used to commute every day, and it took a lot of time. And now when I do it, I feel that so viscerally because I'm like, it's just a lot easier to just walk to my office in my house. But yes, I 100% I'm aligned to that like, yeah, no, you're done with work for the day, walk away. That's that. And learning a new technology or things like that, that's part of the job. There shouldn't be the expectation that that just happens. There's continuing education in every other field. It's like, oh, we'll pay for your master's degree so you can go learn a thing. That's the norm in every other...not in every other industry but many, many, many industries. And yet the nature of our world the accessibility of it is one of the most wonderful things about it. But it can be a double-edged sword in that if there are the expectations that, oh yeah, and then, of course, you're going to go home and have side projects and be learning things. Like, no, that is an unreasonable expectation, and we got to cut that off. But then again, I do do that. So I'm saying two things at the same time, and that's always complicated. STEPH: But I agree with what you're saying because you're basically respecting both sides. If people enjoy this as a hobby, more power to you.; that's great. This is what you enjoy doing. If you don't want to do this as a hobby and respect it as a job, then that's also great too. There can be both sides, and no side should feel guilty or judged for whichever path that they pursue. And I absolutely agree, if there are new skills that you need to learn for a job, then there should be time that's carved out during your work hours that then you get to focus on those new skills. It shouldn't be an expectation that then you're going to work all day and then spend your evening hours learning something else. And same for interviews; there shouldn't be a field that says, "Hey, what are your side projects?" Or at least that should not be an important part of the interview. There should be an alternative to be like, "Or what work code do you want to talk about?" Or something else that's more in that nine-to-five window that you want to talk about. That way, there's a balance between like, sure, if you have something that you want to talk about on the side, great, but if not, then let's focus on something that you've done during your actual work hours because that's more realistic. CHRIS: I do think there's an interesting aspect at play because the world of development moves so rapidly and because it's constantly changing. And to frame it differently, I don't think we've got this thing figured out. And so many people lament how quickly it changes and that there's a new framework every other week. And there's a bit of churn that is perhaps unnecessary. But at the same time, I do not feel like as a community, as a working population, that we're like, yeah, got it, crushed it. We know how to make great software, no question about it. It's going to be awesome. We're going to be able to maintain it for forever, don't even worry about it. New feature? We can get that in there. They're actually still pretty rare. So we need to be learning, and evolving, and exploring new techniques. I think the amount of thinking is probably good mostly in the development world. But organizations have to make space for that with their teams. And thoughtbot obviously does that with investment days. That's just such a wonderful structure that embraces that reality and also brings happiness, and it's just a pleasant way to work. And frankly, my team does not have that right now. We do the crispy Brussels snack hour, which also now has a corresponding crispy Brussels work lunch, which is one week we think about it, and the next week we do the thing. We're trying to make space for that. But even that is still more intentional and purposeful and less exploratory and learning. And so it's an interesting trade-off. I deeply believe in this thing, and also, the team that I'm leading isn't doing it right now. Granted, we're an early-stage startup. We got to build a bunch of stuff. I think that's fine for right now. But it is a thing that...again, I'm saying two things at the same time, always fun. STEPH: Well, and there might be a nice incremental approach to this as well. So thoughtbot has the entire day, and maybe it's less than a full day. So perhaps it's just there's an hour or two hours or something like that where you start to introduce some of that self-improvement time and then blossom out from there. Because yeah, I understand that not all teams may feel like they have the space for that. But then I agree with everything else you said that it really does improve team morale and gives people a space to then be able to get to explore some of those questions that they had earlier. So then they don't feel like they have to then dedicate some weekend time or off hours' time to then look into a question. And I admit, I'm totally guilty too. I am that person that then I've worked extra hours, but it's because, like you said, if there's a puzzle that my brain is stuck on and I just feel the need to get through it. But then I look at that as am I doing this because I want to? Yes. Okay, then as long as I'm happy and I don't feel like this is increasing any concern around burnout, then I don't worry about it. MIDROLL AD: Debugging errors can be a developer's worst nightmare… but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! Circling back to your original question about what's going on in my world, and you mentioned scarring earlier. I feel sufficiently scarred [laughs] in regards to still working with moving fixtures over to FactoryBot. This week has really confirmed that fixtures don't trigger a lot of the callbacks, the model callbacks that exist. And so this really means that you can just create bad data that your application doesn't actually allow your application to create. So there are tests that are exercising behavior that should never exist. And then porting that over to FactoryBot then highlights that because then as soon as I move that record over and then try to create it or do something with it, then the app, the test, do the right thing and let me know saying no, no, no, we've added validations. You can't do that anymore. That has been grinding my gears in terms of trying to then translate. Because then I have to really dive into the code to understand it. And the goal here is to stay as high level as possible and not have to dive in too much. But then that means that I do have to dive in and understand more. So this has frankly just been one of those times in my career where you just kind of have to slog through the work. It's important work to be done. It'll be great once it's done. But it's a painful process. And the best way that I've found to make it more enjoyable is to be in heavy communication with Joël, who's on the project with me, just so if we get stuck on something, then we can chat with each other. And then also there's one file that's particularly gnarly. And so we moved over one test. We were successful, and which felt great because then we could at least document like, okay, when we come back to this, at least we have one example that highlights the wonkiness that we ran into. But we've decided, okay, we're done with that file. We're going to take a break. There's a lot there, but we're going to move on and give ourselves a break and do some of the easier ones, and then we'll circle back to the harder one. Which was, I think, just a bit of bad luck in terms of, like, as we're going down the list, that happened to be like the gnarliest one, and it was like the first one that Joël picked up. And so I'm going through a couple of files, and Joël is like, "What? [laughs] How are you making progress?" And we realize it's just because that file, in particular, is very hard to find all the mystery guests and then to move everything over. Finding a positive note through all of the cruft, I will say this is helping with some of my code sleuthing skills. So as I am running into these problems and then looking for mystery guests, I'm noticing ways that I can then, as quickly as possible, try to triage and identify as to why one test doesn't match another test. Some of it is more specific to the application setup, so it won't be as applicable to future projects. But then some other areas have been really helpful. Like, I'm using caller a lot more to understand, like, I know this is getting called, but I don't know who's calling you. So I can put in a line that basically outputs like, show me your stack traces to how you got here. So that's been really nice as well. So it has improved some of my code sleuthing skills and also my spidey sense in terms of it's typically mystery guests. Like when a test isn't passing, it's because fixtures are creating extra data that are getting pulled in when there are queries that are being run. But they're not explicitly referenced in the test setup itself. So that's typically then where I start is looking for what record looks relevant to this test that I haven't pulled over to my test setup. CHRIS: I appreciate you finding the silver lining, the positive bit of this. Because as you're describing, the work that you're doing sounds like I think you use the word slog, which seems like a very accurate term. But sometimes we have to do that sometimes for a variety of reasons. We end up either having to introduce new code or fix old code, but this is sometimes the work. And this is something that I think you and I share about this show is we get to show all sides of the work. And the work can be glamorous and new. And oh, I've got this greenfield app that I'm building, and it's wonderful. Look at the architecture. And I know in the moment that I'm building someone else's legacy code three years from now. [laughs] And so telling the other side of the story and providing that rounded point of view, because like, yeah, this is all part of it. Again, I don't believe that this is a solved problem, building robust software that we can maintain. And so yeah, you're doing the good work in there. And I thank you for sharing it with us. STEPH: Thanks. Just don't use fixtures in your test, I beg of you. Please don't do that to the legacy code that you're writing for future developers. [laughs] That is my one request. CHRIS: And I will maybe add on to that, sparingly use callbacks. Maybe don't use them at all, and certainly don't use the combination because, my goodness, that'll lead you into some fun times. But yeah, just two small recommendations there. STEPH: Oh, there's something else I wanted to share. I saw that Slack added a new audio feature that allows you to record the pronunciation of your name, which is the feature that I was so excited about when we added it to our internal tool called Hub at thoughtbot. And now Slack has it on their profile so that way you can upload the pronunciation. And then anyone looking at your profile can then listen to how to pronounce your name. There are a couple of other features that they released, I think just in June, so about a month ago from the recording of today. [laughs] That's weird to say, but here we are. So I'll include a link in the show notes so folks can see that feature in addition to others, but I'm super excited. CHRIS: Oh, that is nice. I also like all right, so Slack now has it. Hub now has it. But I don't have access to Hub anymore. And I don't have access to every Slack in the world yet. But here's my suggestion. All right, everybody, stick with me here. I want you to own a domain. I want you to have a personal site on it. And I want the personal site to include the pronunciation of your name. I get that that's a big ask. And I get that there are other platforms that are calling to you, and you may be writing on those. But you know what? Just stand up a little site, just a little place on the internet that you own. And if it includes the pronunciation of your name, I will be forever grateful. STEPH: I like this idea. I initially was taking your idea and immediately running with it as you were speaking it because then I wondered if everyone had their own YouTube channel. But I don't know how hard it is to create a YouTube channel. I am not a YouTube channeler, so I don't know what that looks like. [laughs] But not everybody will know how to purchase a domain. So that might be another approach. CHRIS: I think it's pretty easy to do a YouTube channel. I'm conflating a couple of things. This is my basket of beliefs about people on the internet, but I kind of think everybody should own their own little slice of the internet. And so totally, YouTube is a place where the people make some stuff, make videos, put them on YouTube, absolutely. But ideally, you own something. I see a lot of people that are on YouTube, and that's it, and so their entire audience lives on YouTube. And if YouTube someday decides to change or remove them or say Medium as an example, Medium actually, I think, does a more interesting version of this where your identity kind of gets subsumed into Medium. And I really think everybody should just have their own little, tiny slice of the internet that's there. It has their name that they own that no platform can decide; hey, we've shifted, and now your stuff is gone. Cool URIs don't change as they say, and that's what I want. And then yeah, if you can have the pronunciation of your name on there, that's extra nice. Although I say that, and I don't know that I would do it because my name feels very obvious. One day someone was like, "Oh, how do you pronounce your last name?" I forget if I actually replied with the pronunciation. Or if I was like, "I need to know what options you're considering. I'm so interested because I've really only got the one." Maybe I'm anchored. Maybe I'm biased. [chuckles] I've been doing this for a while. But I really cannot think of another pronunciation of my name. STEPH: You might hear another one that you really like, and you need to pivot. CHRIS: Oh gosh. STEPH: That's the point where you start pronouncing your name differently. CHRIS: Wow, that would be a lot. And then, I could have a change log on my personal site where people can see this is the pronunciation, and this is what the pronunciation used to be. STEPH: [laughs] I like this idea. I also like this idea that everybody has their own slice of internet land. I like this encouragement that you're providing for everyone. On a slightly different note, there's a blog post that I'm really excited to talk about. It's written by Eric Bailey, who's a former thoughtboter. It's called The Optics of Pair Programming. And given how much pair programming that I'm doing, especially with Joël on the current project, it was a really wonderful read. And it also helped me think about pairing from a different perspective because we do have a very strong pairing culture at thoughtbot. So there's a lot of nuance, especially social nuances that can go along with when you invite someone to pair with you that I had not considered until I read this wonderful post by Eric. And we'll be sure to include a link in the show notes. But to provide an overview, essentially, Eric shares that given coming from thoughtbot where we do have a very open approach to pairing where pairing sessions are voluntary and then also last as long as the problem will last...but then when you're at a new company, you could experience pushback if you're inviting someone to pair and then to consider why that pushback may exist. And some of the high-level areas that Eric highlighted are power dynamics, assessment, privacy, and learning styles. So to dive into each of some of those, there's a power dynamics of it's important to consider who's offering to pair. So if I've joined a team as a consultant, there may be a power dynamic there that someone is feeling where their team is paying for my time. So they may feel like they can't say no if I offered to pair. They feel like they need to say yes to the invitation, even if they don't really want to. Or probably a more classic example would be like, what if your boss wants to pair or someone that's just more senior than you? Then it could leave you feeling like, well, I can't say no to this person, can I? Which yes, you totally can say no to that person, but it may leave you in a place where you feel like you can't. And so, it puts you in this sort of uncomfortable and powerless position. The other one is assessment, so offering to pair with someone could feel like you are implying that you want to assess their skills or that you're implying that they're not up to the task and therefore they need your help. So then that could also place someone in an uncomfortable position. There's also privacy. So someone who isn't confident may not want someone to observe their behavior or observe how they're working. It could make them feel really anxious, which then I love that Eric points this out. Ironically, pairing is really good at addressing that lack of confidence because then you get to see how other people work through their problems or how they think, or they may also have some anxiety. Or it just helps you become more comfortable in talking and thinking through with other people. So that one is a tough one where it's hard to get over that initial hurdle. But actually, the more you pair, then the less anxious you'll feel when you pair. And then there's also learning styles because pairing really involves a lot of deep thinking but in our personal time. And it can be hard to balance both of those, and it's just not as effective for some people. So I know that even as much as I really enjoy pairing, I just need to sit with code on my own sometimes. I need to think about it. I need to run it; I need to look at it. So it's really nice to talk with someone. But then I also need that alone time to then just think through it on my own because I can't have that same deep focus if I'm also worried about how the other person is experiencing that session because then my mental energy is going towards them. So that covers a number of the social nuances that can be included or running through someone's mind when you extend an invitation to them to pair. And it really resonated with me the areas that Eric highlights in this blog post. He also talks about a couple of strategies, which I'd love to dive into as well. But I'm going to pause here and see what thoughts you have. CHRIS: Yeah, I love this post. And it got me thinking about pairing and the broader human backdrop of all of the processes and workflows that we have. Everything he highlighted about pairing feels true. Although similar to you and to Eric, I've worked in a context where pairing was a very natural, very regular part of the work and sort of from the very top-down. And so everyone pairing between developers of any different level or developers and designers or really anyone in the...it was just such a part of how we worked that no one really questioned it or at least not after the first couple of weeks. I imagine joining thoughtbot those first weeks; you're like, oh God. As I shared, I think in the previous episode that we recorded, my pairing interview was with Joe Ferris, the CTO of thoughtbot, [laughs] writing a book about good and bad code. And I was like, I don't know what anything is here but very quickly getting over that hurdle. And having that normalizing experience was actually really great, and then have been comfortable with it since. But the idea that there are so many different social dynamics at play feels true. And then as I think about other things, like stand-up is one that I think of as this very simple this is a way to communicate where we're at. And where necessary or where useful, allow people to interject or step in to say, "Oh, let me help you get unblocked there or whatever it is." But so often, I see stand-up being a ritual about demonstrating that you are, in fact, doing work, which is like, here's what I did yesterday. I don't know if it's useful. Then mention that you're working on this project. But the enumeration of look, obviously, work was done by me. You can see it; here are the receipts. It's very much this social dynamic at play. And retro is another one where like, if retro is very much owned by one voice and not a place that change actually happens where people feel safe airing their opinions or their concerns, then it's going to be a terrible experience. But if you can structure it and enforce that it is a space that we can have a conversation, that everyone's voice is welcome and that real change happens as a result of, then it's a magical tool for making sure we're doing the right things. But always behind these are the people, and feelings, and the psychology at play. And so this was just such an interesting post to read and ruminate on that a little bit more. STEPH: Yeah, I agree, especially with a comment that you made about those daily syncs where I really just want to focus on today and what you have that you're blocked on. So it's a really nice update in case there are any cross-collaboration opportunities. That's really what I'm looking for in a daily update. And so I appreciate when people don't go through a laundry list of what they did yesterday because it's like, that's great. But then, like you said, it's just like you're trying to prove here's what I've done, and I trust you; you're working. So just let me know what you're doing today, friend. So Eric does a wonderful job of also including some strategies for ways that then you can address some of these concerns and then how there may be some extra anxiety that's increased when you're inviting somebody to pair. There are some wonderful strategies. I'll let folks read through the blog post itself. There are a couple in particular that came to mind for me because I was then self-assessing how do I tend to approach pairing with someone? And some ways that I want them to feel very comfortable with that experience. And there's a couple. There's one where I recognize that I need to build trust with each person. I can't just go on to a team and expect everyone to know that I have good intentions and that I'm going to do my best to be a fun, helpful pairing partner, and that it's not a zone of judgment. And that has to be cultivated with each person. Because especially as a consultant, if I'm joining a team, the people who hired me are not necessarily the people that I'm working with. It's someone that's probably in leadership or management that has then brought on thoughtbot. And so then the people that I'm working with they don't know me, and they don't know what my pairing style is going to be. So looking for ways to build trust with each person and then also inviting them or asking for help myself. So there's a bit of vulnerability that has to be shown to build trust with someone to say," Hey, I'm stuck on a problem. I would love a second set of eyes. Would you be willing to help me out with this?" So then that way, they're coming in to help me initially versus I'm going in and saying, "Hey, can I help you?" I have found that to be an effective strategy. And there's one that I do really want to talk about, and that's not everyone is going to pair well together. Like, you may find someone who always leaves you feeling just stressed or demoralized. And while it's important to consider your role and why that's true, that does not mean it's your fault and necessarily your problem to fix. So similar to having to manage up, you may need to coach the person that you're pairing with in ways that help you feel comfortable pairing. But if they don't listen to your requests and implement any of that feedback, then just don't pair with that person. That is a very fine option to recognize people that are not receptive to your needs and, therefore, not someone that you need to then force into being a great pairing buddy. And I emphasize that last one because it took me a little while to become comfortable with that and accepting that it wasn't my fault that I wasn't having a great pairing session with people. Similar to when I'm learning from someone that if someone is explaining something to me and they're making me feel inadequate while they're explaining it to me, that's not necessarily my fault. Like, I used to internalize that as like, oh, I just can't get this. But I am now a very staunch believer in if you can't explain it to me in a way that I understand, then that's probably more on you than on me. And that has also taken me time to just really accept and embrace. But once you do, it is so freeing to realize that if someone's explaining a concept and you're still not getting it, it's like, hey, how can we try harder together versus you just making me try harder? CHRIS: I like that right there of like, if I don't understand this, it may actually be you, not me, or something to that effect. Let's get that on a bumper sticker and put that in The Bike Shed store so that everybody can buy it and put it on their cars or at least just us. But yeah, that starting from the bottom sometimes it's just not going to work great. There are even...I think what you're describing sounds a little more complicated, individuals who are personally not great at communicating or pairing or things like that. And that's going to happen. We're going to run into folks that...pairing is communication. That's just the core of it, and some folks, that may not be their strongest suit. But I think there's another category of just like different working styles. And whereas I might...judge is such a heavy word, but I'm going to use it. I might judge someone who is not doing a great job at communicating to someone else, or understanding their point of view, or striving to do that, or taking feedback. Like, those are not great things. Whereas there may just be two different development styles or backgrounds, or there are other reasons that actually they may be not an ideal fit. That said, I have definitely found that in almost every variation of pairing, I've seen work at some point. Like, when I was very early on in my career pairing with folks that are very senior, I didn't get most of it, but I got some stuff. And then folks that are very much on the same level or folks that have a deep knowledge in framework, code base language, whatever and folks that are new to it but have a different set of experiences. Basically, every version of that, I found that pairing is actually an incredibly powerful technique for knowledge sharing, for collaboration, for all of that. So although there are rare cases where there might be some misalignment, in general, I think pairing can work. I do think you hit on something earlier of there are certain folks that are more private thinkers, is how I would describe it, where thinking out loud is complicated for them. I'm very much someone who talks. That's how I figure out what I think is I say stuff. And I'm like, oh, I agree with what I just said. That's good. But I find I actually struggle. There's something I think of...maybe I'm just a loudmouth is what I'm hearing as I say it, but that is how I process things. Other folks, that is not true. Other folks, it's quite internal, and actually trying to vocalize that or trying to share the thought process as they're going may be uncomfortable. And I think that's perfectly reasonable and something that we should recognize and make space for. And so pairing should not be forced upon a team or an individual because there are just different mindsets, different ways of thinking that we need to account for. But again, the vast majority of cases...I've seen plenty of cases where it's someone's like, "I don't like to pair. That's not my thing." And it's actually that they've had bad experiences. And then when they find a space that feels safe or they see the pattern demonstrated in a way that is collegial, and useful, and friendly, then they're like, oh, actually, I thought I didn't like pairing. I thought I didn't like retro. I thought I didn't like stand-up. But actually, all of these things can be good. STEPH: Yeah, absolutely. It's a skill like anything else. You need to see value in it. And if you haven't seen value in it yet or if it's always made you anxious and uncomfortable, then it's something that you're going to avoid as much as possible until someone can provide a valuable, positive experience around how it can go. I'm going to pull back the curtains just a little bit on our recording and share because you've mentioned that you are very much you think out loud, and that's how you decide that you agree with yourself. And I think already at least twice while we've been recording this episode, I have started to say something, and I'm like, no, wait, I don't agree with that and have backed myself up. CHRIS: [laughs] STEPH: And I'm like, no, I just thought through it; I'm going to cancel it out, [laughs] and then moved in a different direction. So I, too, seem to be someone that I start to say things, and I'm like, oh, wait, I don't actually agree with what I just said [laughs], so let's remove that. CHRIS: Yep. You've described it as Michael Scott-ing on a handful of different episodes or maybe things that were cut from episodes. But where you start a sentence and then you're like, I don't know where I was going to end up there. I hoped I'd figure it out by the end, but then I did not get there. And yeah, I think we've all experienced that at various times. STEPH: That's some of my favorite advice from you is where you've been like, just lean into it, just see where it goes. Finish it out. We can always take it out later. [laughs] Because I stop myself because I immediately start editing what I'm trying to say and you're like, "No, no, just finish it, and then we'll see what happens." That's been fun. CHRIS: This is how you find out what you think. You say it out loud, and then you're like, never mind. That was ridic – STEPH: [laughs] CHRIS: I do. Actually, now I'm thinking back, and I have plenty of those where I'll say a thing, and I'm like, nope, never mind, send that one back. [chuckles] As an aside, so we do this thing where we host a podcast, and we get to talk. But we're both now describing the pattern where we'll start to say something, and we'll be like no, no, no, actually, not that. And I think, dear listeners out there, you probably don't hear any of this, the vast majority of it, because we have wonderful editors behind the scenes, Thom Obarski for many years, and now Mandy Moore, who's been with us for a while. And so once again, thank you so much to the editor team that allows us to, I think, again, feel safe in this conversation that we can say whatever feels true and then know that we'll be able to switch that around. So thank you so much to the editors who help us out and make us sound better than we are. STEPH: Yeah, that has made a big difference in my capabilities to podcast. If we were doing this live, ooh goodness, this might be a whole different, weird show. [laughs] CHRIS: I mean, the same is true for code, right? I deeply value the ability to make an absolute mess in my local editor and have nine different commits that eventually I throw two out. And then I revert that file, and then eventually, the PR that I put up that's my Instagram selfie. That's like, I carefully curated this, but what's behind the scenes it's just a pile of trash. So yeah, the ability to separate the creation and the editing that's a meaningful thing to have in life. STEPH: Oh, I can't unsee that now. [laughs] A pull request is now the equivalent of that curated Instagram selfie. That is beautiful. [laughs] CHRIS: To be clear, I don't think I've ever taken an Instagram selfie. But I get the idea, and I felt like it was an analogy that would work. Again, I try out analogies on this show, and many of them do not stick. But I think that one is all right. STEPH: It might even go back to pairing because then you've got help in taking that picture. So hey, you're making a mess with somebody until you get that right perfect thing, and then you push it up for the world to see. So safe spaces for all the activities, I think that's the takeaway. 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: 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.

In this supper club episode of Syntax, Wes and Scott talk with Shawn Wang about his thoughts on developer experience, why DX is important, and the importance of learning in public. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Show Notes 00:32 Welcome 01:56 Guest introduction swyx.io Why Temporal? 06:09 What is Developer Experience? Sarah Drasner 08:35 Is VS Code considered DX? 09:28 Why is internal DX important? Vercel NextJS 11:44 Is DX helpful to small organizations as well? 15:27 Parsimony Parsimony 16:43 Is productivity the main focus? 21:09 Sponsor: Hasura 22:48 What are your thoughts on React? 27:31 Designing for API success 30:44 Sponsor: LogRocket 32:07 What is external developer experience? 36:05 Learning in public 40:46 Supper Club questions dx.tips Retreon VS Code Theme Agnoster ZSH Theme freeCodeCamp Frontend Masters QConf Learn in Public ××× SIIIIICK ××× PIIIICKS ××× Scott: The Stormlight Archive Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

In this Hasty Treat, Scott and Wes talk about the new Browser CSS Page Transitions API proposal and what features it opens up for developers on the web. Prismic - Sponsor Prismic is a Headless CMS that makes it easy to build website pages as a set of components. Break pages into sections of components using React, Vue, or whatever you like. Make corresponding Slices in Prismic. Start building pages dynamically in minutes. Get started at prismic.io/syntax. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Show Notes WICG Shared Element Transitions 00:21 Welcome 01:33 Sponsor: Prismic 02:43 Sponsor: LogRocket 04:18 Browser animations on the web vs native apps 06:15 What is the targeted use case for it? 06:56 Shared Element to Root Transitions 11:14 Entry and Exit 17:33 How to enable this in Chrome Example Code Shared Element Transition history Sarah Drasner's demo async function doTransition() { let transition = document.createDocumentTransition(); // Specify offered elements. The tag below is used to refer // to the generated pseudo elemends in script/CSS. document.querySelector(".old-message").style.pageTransitionTag = "message"; // The start() call triggers an async operation to capture // snapshots for the offered elements, await transition.start(async () => { // This callback is invoked by the browser when the capture // finishes and the DOM can be switched to the new state. // No frames are rendered until this callback returns. // Asynchronously load the new page. await coolFramework.changeTheDOMToPageB(); // Clear the old message if that element is still in the page document.querySelector(".old-message").style.pageTransitionTag = ""; // Set new message as the shared element 'message' document.querySelector(".new-message").style.pageTransitionTag = "message"; // Set up animations using WA-API on the next frame. requestAnimationFrame(() => { document.documentElement.animate(keyframes, { ...animationOptions, pseudoElement: "::page-transition-container(message)", }); }); // Note that when this callback finishes, the animations will start with the tagged elements. }); } Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

About SharoneI'm Sharone Zitzman, a marketing technologist and open source community builder, who likes to work with engineering teams that are building products that developers love. Having built both the DevOps Israel and Cloud Native Israel communities from the ground up, today I spend my time finding the places where technology and people intersect and ensuring that this is an excellent experience. You can find my talks, articles, and employment experience at rtfmplease.dev. Find me on Twitter or Github as @shar1z.Links Referenced: Personal Twitter: https://twitter.com/shar1z Website: https://rtfmplease.dev LinkedIn: https://www.linkedin.com/in/sharonez/ @TLVCommunity: https://twitter.com/TLVcommunity @DevOpsDaysTLV: https://twitter.com/devopsdaystlv TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: DoorDash had a problem as their cloud native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, competence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud/C-H-R-O-N-O-S-P-H-E-R-E.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance. To learn more visit: snark.cloud/deployandgoCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I have been remiss by not having today's guest on years ago because back before I started this ridiculous nonsense that, well, whatever it is you'd call what I do for a living, I did other things instead. I did the DevOps, which means I was sad all the time. And the thing that I enjoyed was the chance to go and speak on conference stages. One of those stages, early on in my speaking career, was at DevOpsDays Tel Aviv.My guest today is Sharone Zitzman, who was an organizer of DevOpsDays Tel Aviv, who started convincing me to come back. And today is in fact, in the strong tradition here of making up your own job titles in ways that make people smile, she is the Chief Manual Reader at RTFM Please Ltd. Sharone, thank you for joining me.Sharone: Thank you for having me, Corey. Israelis love the name of my company, but Americans think it has a lot of moxie and chutzpah. [laugh].Corey: It seems a little direct and aggressive. It's like, oh, good, you are familiar with how this is going to go. There's something to be said for telling people what you do on the tin upfront. I've never been a big fan of trying to hide that. I mean, the first iteration of my company was the Quinn Advisory Group because I thought, you know, let's make it look boring and sedate and like I can talk to finance people. And yeah, that didn't last more than ten seconds of people talking to me.Also, in hindsight, the logo of a big stylized Q. Yeah, I would have had to change that anyway, for the whole QAnon nonsense because I don't want to be mistaken for that particular brand of nuts.Sharone: Yeah, I decided to do away with the whole formalities and upfront, just go straight [laugh]. For the core of who we are, Corey; you are very similar in that. So, yes. Being a dev first company, I thought the developers would appreciate such a title and name for my company. And I have to give a shout out here to Avishai Ish-Shalom, who's my friend from the community who you also know from the DevOpsDays community.Corey: Oh, yeah @nukemberg on Twitter—Sharone: Yes exactly.Corey: For those who are not familiar.Sharone: [laugh]. Yep. He coined the name.Corey: The problem that I found is that people when they start companies or they manage their careers, they don't bias for the things that they're really good at. And it took me a long time to realize this, I finally discovered, “Ah, what am I the best at? That's right, getting myself fired for my personality, so why don't I build a business where that stops being a liability?” So, I started my own company. And I can tell this heroic retcon of what happened, but no, it's because I had nowhere else to go at that point.And would you hire me? Think about this for a minute. You, on the other hand, had options. You are someone with a storied history in community building, in marketing to developers without that either coming across as insincere or that marked condescending accent that so many companies love to have of, “Oh, you're a developer. Let me look at you and get down on my hands and knees like we're going camping and tell a story in ways that actively and passively insult you.”No, you have always gotten that pitch-perfect. The world was your oyster. And for some godforsaken reason, you looked around and decided, “Ah, I'm going to go out independently because you know what I love? Worrying.” Because let's face it, running your own company is an exercise in finding new and exciting things to worry about that 20 minutes ago, you didn't know existed. I say this from my own personal experience. Why would you ever do such a thing?Sharone: [laugh]. That's a great question. It was a long one, but a good one. And I do a thing where I hit the mic a lot because I also have. I can't control my hand motions.Corey: I too speak with my hands. It's fine.Sharone: [laugh]. Yeah, so it's interesting because I wanted to be independent for a really long time. And I wasn't sure, you know, if it was something that I could do if I was a responsible enough adult to even run my own company, if I could make it work, if I could find the business, et cetera. And I left the job in December 2020, and it was the first time that I hadn't figured out what I was doing next yet. And I wanted to take some time off.And then immediately, like, maybe a week after I started to get a lot of, like, kind of people reaching out. And I started to interview places and I started to look into possibly being a co-founder at places and I started to look at all these different options. And then just, I was like, “Well…. This is an opportunity, right? Maybe I should finally—that thing that's gnawing at the back of my head to see if, like, you know if I should go for this dream that I've always wanted, maybe now I can just POC it and see if, you know, it'll work.”And it just, like, kind of exploded on me. It was like there was so much demand, like, I just put a little, like, signal out to the world that this is something that I'm interested in doing, and everyone was like, “Ahh, I need that.” [laugh]. I wanted to take a quarter off and I signed my first clients already on February 1st, which was, like, a month after. I left in December and that—it was crazy. And since then, I've been in business. So, yeah. So, and since then, it's also been a really crazy ride; I got to discover some really exciting companies. So.Corey: How did you get into this? I found myself doing marketing-adjacent work almost entirely by accident. I started the newsletter and this podcast, and I was talking to sponsors periodically and they'd come back with, “Here's the thing we want you to talk about in the sponsor read.” And it's, “Okay, you want to give people a URL to go to that has four sub-directories and entire UTM code… okay, have you considered, I don't know, not?” And because so much of what they were talking about did not resonate.Because I have the engineering background, and it was, I don't understand what your company does and you're spending all your time talking about you instead of my painful problem. Because as your target market, I don't give the slightest of shits about you, I care about my problem, so tell me how you're going to solve my problem and suddenly I'm all ears. Spend the whole time talking about you, and I could not possibly care less and I'll fast-forward through the nonsense. That was my path to it. How did you get into it?Sharone: How did I get into it? It's interesting. So, I started my journey in typical marketing, enterprise B2B marketing. And then at GigaSpaces, we kickstarted the open-source project Cloudify, and that's when I found myself leading this project as the open-source community team leader, building, kind of, the community from the ground floor. And I discovered a whole new world of, like, how to build experience into your marketing, kind of making it really experiential and making sure that everyone has a really, really easy and frictionless way of using your product, and that the product—putting the product at the center and letting it speak for itself. And then you discover this whole new world of marketing where it's—and today, you know, it has more of a name and a title, PLG, and people—it has a whole methodology and practice, but then it was like we were—Corey: PLG? I'm unfamiliar with the acronym. I thought tech was bad for acronyms.Sharone: Right? [laugh]. So, product-led growth. But then, you know, like, kind of wasn't solidified yet. And so, a lot of what we were doing was making sure that developers had a really great experience with the product then it kind of sold itself and marketed itself.And then you understood what they wanted to hear and how they wanted to consume the product and how they wanted it to be and to learn about it and to kind of educate themselves and get into it. And so, a lot of the things that I learned in the context of marketing was very guerilla, right, from the ground up and kind of getting in front of people and in the way they wanted to consume it. And that taught me a lot about how developers consume technology, the different channels that they're involved in, and the different tools that they need in order to succeed, and the different, you know, all the peripheral experience, that makes marketing really, really great. And it's not about what you're selling to somebody; it's making your product shine and making the experience shine, making them ensure that it's a really, really easy and frictionless experience. You know, I like how [Donald Bacon 00:08:00] says it; he calls it, like, mean time to hello world, and that to me is the best kind of marketing, right? When you enable people to succeed very, very quickly.Corey: Yeah, there's something to be said for the ring of authenticity and the rest. Periodically I'll promote guest episodes on this, where it's a sponsored episode where people get up and they talk about what they're working on. And they're like, “Great. So, here's the sales pitch I want to give,” and it's no you won't because first, it won't work. And secondly, I'm sorry, whether it's a promoted episode or not, I will not publish something that isn't good because I have a reputation to uphold here.And people run into challenges an awful lot when they're trying to effectively tell their story. If you have a startup that was founded by an engineer, for example, as so many of these technical startups were, the engineer is often so deeply and profoundly in love with this problem space and the solution and the rest, but if they talk about that, no one cares about the how. I mean, I fix AWS bills, and people don't care—as a general rule—how I do that at all if they're in my target market. They don't care if it's through clever optimization, amazing tooling, doing it on-site, or taking hostages in Seattle. They care about their outcome much more than they ever do about the how.The only people who care about the how are engineers who very often are going to want to build it themselves, or work for you, or start a competitor. And it doesn't resonate in quite the same way. It's weird because all these companies are in slightly different spaces; all of them tend to do slightly different things—or very different things—but so many of the challenges that I see in the way that they're articulating what they do to customers rhymes with one another.Sharone: Yeah. So, I agree completely that developers will talk often about how it works. How it works. How does it work under the hood? What are the bits and bytes, you know?Like, nobody cares about how it works. People care about how will this make my life better, right? How will this improve my life? How will this change my life? [laugh]. As an operations engineer, if I'm, you know, crunching through logs, how will this tool change that? What my days look like? What will my on-call rotation look like? What will—you know, how are you changing my life for the better?So, I think that that's the question. When you learn how to crystallize the answer to that question and you hit it right on the mark—you know, and it takes a long time to understand the market, and to understand the buying persona, and t—and there's so much that you have to do in the background, and so much research you have to do to understand who is that person that needs to have that question answered? But once you do and you crystallize that answer, it lands. And that's the fun part about marketing, really trying to understand the person who's going to consume your product and how you can help them understand that you will make their life better.Corey: Back when I was starting out as a consultant myself, I would tell stories that I had seen in the AWS billing environment, and I occasionally had clients reach out to me, “Hey, why don't you tell our story in public?” It's, “Because that wasn't your story. That was something I saw on six different accounts in the same month. It is something that everyone is feeling.” It's, people think that you're talking about them.So, with that particular mindset on this, without naming specific companies, what themes are you seeing emerging? What are companies getting wrong when they are attempting and failing to market effectively to developers?Sharone: So, exactly what we're talking about in terms of the product pitch, in that they're talking at developers from this kind of marketing speak and this business language that, you know, developers often—you know, unless a company does a really, really good job of translating, kind of, the business value—which they should do, by the way—to engineers, but oftentimes, it's a little bit far from them in the chain, and so it's very hard for them to understand the business fluff. If you talk to them in bits and bytes of this is what my day-to-day developer workflow looks like and if we do these things, it'll cut down the time that I'm working on these things, it'll make these things easier, it'll help streamline whatever processes that are difficult, remove these bottlenecks, and help them understand, like I said, how it improves their life.But the things that I've seen breakdown is also in the authenticity, right? So obviously, the world is built on a lot of the same gimmicks and it's just a matter of whether you're doing it right or not, right? So, there's so much content out there and webcasts and webinars, and I don't know what and podcasts and whatever it is, but a lot of the time, people, their most valuable asset is their time. And if you end up wasting their time, without it being, like, really deeply valuable—if you're going to write content, make sure that there is a valuable takeaway; if you're going to create a webinar, make sure that somebody learned something. That if they're investing their time to join your marketing activities, make sure that they come away with something meaningful and then they'll really appreciate you.And it's the same idea behind the whole DevOpsDays movement with the law of mobility and open spaces that people if they find value, they'll join this open space and they'll participate meaningfully and they'll be a part of your event, and they'll come back to your event from year to year. But if you're not going to provide that tangible value that somebody takes away, and it's like, okay, well, I can practically apply this in my specific tech stack without using your tool, without having to have this very deterministic or specific kind of tech stack that they're talking about. You want to give people something—or even if it is, but even how to do it with or without, or giving them, like, kind of practical tools to try it. Or if there's an open-source project that they can check out first, or some kind of lean utility that gives them a good indication of the value that this will give them, that's a lot more valuable, I think. And practically understandable to somebody who wants to eventually consume your product or use your products.Corey: The way that I see things, at least in the past couple of years, the pandemic has sharpened an awful lot of the messaging that needs to happen. Because in most environments, you're sitting at a DevOpsDays in the front row or whatnot, and it's time for the sponsor talks and someone gets up and starts babbling and wasting your time, most people are not going to get up and leave. Okay, they will in Israel, but in most places, they're not going to get up and leave, whereas in pandemic land, it's you are one tab away from something I actually want—Sharone: Exactly.Corey: To be doing, so if you become even slightly boring, it's not going to go well. So, you have to be on message, you have to be on point or no one cares. People are like, “Oh, well what if we say the wrong thing and people wind up yelling about us on Twitter?” It's like unless it is for something horrifying, you should be so lucky because people are then talking about you. The failure mode isn't that people don't like your product, it's no one talks about it.Sharone: Yeah. No such thing as bad publicity [crosstalk 00:14:32] [laugh]—Corey: Oh, there very much is such a thing is bad publicity. Like, “I could be tweeting about your product most days,” is apparently a version of that, according to some folks. But it's a hard problem to solve for. And one of the things that continually surprises me is the things I'm still learning about this entire industry. The reason that people sponsor this show—and the rates they pay, to be direct—have little bearing to the actual size of the audience—as best we can tell; lies, damn lies, and podcast statistics; if you're listening to this, let me know. I'd love to know if anyone listens to this nonsense—but when you see all of that coming out, why are we able to charge the rates that we do?It's because the long-term value of someone who is going to buy a long-term subscription or wind up rolling out something like ChaosSearch or whatnot that is going to be a fundamental tenet of their product, one prospect becoming a customer pays for anything, I can sell a company, it will sponsor—they can pay me to sponsor for the next ten years, as opposed to the typical mass-market audience where well, I'm here to sling Casper mattresses today or something. It's a different audience and there's a different perception there. People are starting to figure out the value of—in an age where tracking is getting harder and harder to do and attribution will drive you nuts, instead of go where your audience is. Go where the people who care about the problem that you have and will experience that problem are going to hang out. And it always is wild to me to see companies missing out on that.It's, “Okay, so you're going to do a $25 million billboard ad in spotted in airports around the world talking about your company… but looking at your billboard, it makes no sense. I don't understand what it's there for.” Even as a brand awareness play, it fails because your logo is tiny in the corner or something. It's you spent that much money on ads, and maybe a buck on messaging because it seems like with all that attention you just bought, you had nothing worthwhile to say. That's the cardinal sin to me at least.Sharone: Yeah. One thing that I found—and back to our community circuit and things that we've done historically—but that's one thing that, you know, as a person comes from community, I've seen so much value, even from the smaller events. I mean, today, like with Covid and the pandemic and everything has changed all the equilibrium and the way things are happening. But some meetups are getting smaller, face-to-face events are getting smaller, but I've had people telling me that even from small, 30 to 40 people events, they'll go up and they'll do a talk and great, okay, a talk; everybody does talks, but it's like, kind of, the hallway track or the networking that you do after the talk and you actually talk to real users and hear their real problems and you tap into the real community. And some people will tell me like, I had four concrete leads from a 30-person meet up just because they didn't even know that this was a real challenge, or they didn't know that there was a tool that solves this problem, or they didn't understand that this can actually be achieved today.Or there's so many interesting technologies and emerging technologies. I'm privileged to be able to be at the forefront of that and discover it all, and I if I could, I would drop names of all of the awesome companies that work for me, that I work with, and just give them a shout out. But really, there's so many amazing companies doing, like, developer metrics, and all kinds of troubleshooting and failure analysis that's, like, deeply intelligent—and you're going to love this one: I have a Git replacement client apropos to your closing keynote of DevOpsDays 2015—and tapping into the communities and tapping into the real users.And sometimes, you know, it's just a matter of really understanding how developers are working, what processes look like, what workflows look like, what teams look like, and being able to architect your products and things around real use cases. And that you can only discover by really getting in front of actual users, or potential users, and learning from them and feedback loops, and that's the little core behind DevRel and developer advocacy is really understanding your actual users and your consumers, and encouraging them to you know, give you feedback and try things, and beta programs and a million things that are a lot more experiential today that help you understand what your users need, eventually, and how to actually architect that into your products. And that's the important part in terms of marketing. And it's a whole different marketing set. It's a whole different skill set. It's not talking at people, it's actually… ingesting and understanding and hearing and implementing and bringing it into your products.Corey: And it takes time. And you have to make yourself synonymous with a painful problem. And those problems are invariably very point-in-time specific. I don't give a crap about log aggregation today, but in two weeks from now, when I'm trying to chase down 18 different Lambdas function trying to figure out what the hell's broken this week, I suddenly will care very much about log aggregation. Who was that company that's in that space that's doing interesting things? And maybe it's Cribl, for example; they do a lot of stuff in that space and they've been a good sponsor. Great.I start thinking about those things in that light because it is—when I started having these problems, it sticks in your head and it resonates. And there's value and validity to that, but you're never going to be able to attribute that either, which is where people often lose their minds. Because for anything even slightly complicated—you're going to be selling things to big bank—great, good on you. Most of those customers are not going to go and spin up a trial in the dead of night. They're going to hear about you somewhere and think, “Ohh, this is interesting.”They're going to talk about a meeting, they're going to get approval, and at that point, you have long since lost any tracking opportunity there. So, the problem is that by saying it like this, as someone who is a publisher, let's be very clear here, it sounds like you're trying to justify your entire business model. I feel like that half the time, but I've been reassured by people who are experts in doing these things, like, oh, yeah, we have data on this; it's working. So, the alternative is either I accept that they're right or I sit here and arrogantly presume I know more about marketing than people who've devoted their entire careers to it. I'm not that bold. I am a white guy in tech, but not that much.Sharone: Yeah, I mean, the DevRel measurement problem is a known problem. We have people like [unintelligible 00:20:21] who have written about it. We have [Sarah Drasner 00:20:23], we have a million people that have written really, really great content about how do you really measure DevRel and the quality. And one of the things that I liked, Philipp Krenn, the dev advocate at Elastic once said in one of his talks that, you know, “If you're measuring your developer advocates on leads, you're a marketing organization. If you're measuring them on revenue, you're a sales organization. It's about reach, engagement, and awareness, and a lot of things that it's much, much harder to measure.”And I can say that, like, once upon a time, I used to try and attribute it at Cloudify. Like, I remember thinking, like, “Okay, maybe I could really track this back to, you know, the first touch that I actually had with this user.” It's really, really difficult, but I do remember, like, when we used to go out into the events and we were really active in the OpenStack community, in the DevOps community, and many other things, and I remember, like, even after events, like, you get all those lead gen emails. All I would say now is, like, “Hey, if you missed us at the booth, you know, and you want still want a t-shirt, you know, reach out and I'll ship it to you.” And some of those eventually, after we continued the relationship, and we, you know, when we were friends and community friends, six months later, when they moved to their next role at their next job, they were like, “Oh, now I have an opportunity to use Cloudify and I'm going to check it out.”And it's very long relationship that you have to cultivate. It has to be, you know, mutual. You have to be, you have to give be giving something and eventually is going to come back to you. Good deeds come back to you. So, I—that's my credo, by the way, good deeds come back to you. I believe in that and I try to live by that.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: So, I have one last question for you and it is pointed and the reason I buried it this deep in the episode is so that if I open with it, I will get letters and I'm hoping to get fewer of them. But I met you, again, at DevOpsDays Tel Aviv, and it was glorious. And then you said, “This is fun. Come help me organize it next year.”And I, like an idiot said, “Sure, that sounds awesome because I love going to conferences and it's great. So, what's involved?” “Oh, a whole bunch of meetings.” “Okay, great.” “And planning”—things I'm terrible at—“Okay.” And then the big day finally arrives where, “Great, when do we get to get on stage and tell a story?” Like, “That's the neat part. We don't.” So, I have to ask, given that it is all behind-the-scenes work that is fairly thankless unless you really screw it up because then it's very visible, what is the point of being so involved in the community?Sharone: Wow, that's a big question, Corey.Corey: It really is.Sharone: [laugh].Corey: Because you've been involved in community for a long time and you're very good at it.Sharone: It's true. It's true. Appreciate it, thank you. So, for me, first of all, I enjoy, kind of, the people aspect of it, absolutely. And that people aspect of it actually has played out in so many different ways.Corey: Oh, you mean great people, and also me.Sharone: [laugh]. Particularly you, Corey, and we will bring you back. [laugh]. And we will make sure you chop wood and carry water because eventually it'll fill your soul, you'll see. [laugh] one of the things that really I have had the privilege and honor, and having come out of, like, kind of all my community work is really the network I've built and the people that I've met.And I've learned so much and I've grown so much, but I've also had the opportunity to connect people, connect things that you wouldn't imagine, un—seemingly-related things. So, there are so many friends of mine that have grown up with me in this community, it's been already ten years now, and a lot of folks have now been going on to new adventures and are looking to kickstart their new startup and I can connect them to this investor, I can connect them to this other person who is maybe a good, you know, partner for their startup, and hiring opportunities, and something—I've had this, like, privilege of kind of being able to connect Israel to the outer world and other things and the global kind of community, and also bring really intelligent folks into the community. And this has just created this amazing flywheel of opportunity that I'm really happy to be at the center of. And I think I've grown as a person, I think our community has grown, has learned, and there's a lot of value in that, I think, yeah. We got to meet wonderful folks like you, Corey. [laugh].Corey: It has its moments. Again, you're one of those rarities in that it's almost become a trope in VC land where VCs always like, “How may I be useful?” And it's this self-serving transparent thing. Every single time you have deigned to introduce me to someone, it's been a productive conversation and I'm always glad I took the meeting. That is no small thing.A lot of people say, “I'm good at community,” which is sort of cover for, “I'm not good at anything,” but in your case, it—Sharone: [laugh]. [I'm an entrepreneur 00:24:48].—Corey: Is very much not true. Oh, yeah. I'm a big believer that ‘entrepreneur' and ‘hero' and other terms like that are things people call you; you don't call yourself that. It always feels weird for, “Oh, he's an entrepreneur.” It's like, that's a pretty lofty word for shitposting, but okay, we'll roll with it.It doesn't work that way. You've clearly invested long-term in a building reputation for yourself by building a name for yourself in the space, and I know that whenever you reach out to me as a result, you are not there to waste my time or shill some bullshit. It is always something that is going to, even if I don't love every aspect of it or agree with the core of the message you're sending, great, it is never not going to be worth my time, which is why I'm so glad I got the chance to talk to you this show.Sharone: I appreciate that. It's something that I really believe in, I don't want to waste people's time and I really only will connect folks or only really will reach out to someone if I do think that there's something meaningful for both sides. It's never only what's in it for me, also. I also want to make sure that there's something in it for the other person and it's something that makes sense and it's meaningful for both sides. I've had the opportunity of meeting such interesting folks, and sometimes it's just like, “You must meet. [laugh]. You will love each other.” You will have so much to do together or it's so much collaboration opportunity.And so yeah, I really am that type of person. And I'll even say from a personal perspective, you know, I know a lot of people, and I've even been asked from the flip side, “Okay, is this a toxic manager? Or is this a, you know, a good hire? Is this”—and I tried to provide really authentic input so people make the right decisions, or make, you know, the right contacts, or make—and that's something I really value. And I managed to build trust with a lot of really great folks—Corey: And also me—Sharone: —and it's come back to me, also. And—[laugh] and particularly you, again. [laugh].Corey: If people want to learn more about how you see the world and the space and otherwise bask in your wisdom, where's the best place to find you?Sharone: So, I'm on Twitter as @shar1z, which is SharoneZ. Basically, everyone thinks it's such a smart, or I don't know what, like, or an esoteric screen name. And I'm like, no, it's just my name, I just—the O-N-E is… the one. [laugh].So yes, shar1z on Twitter, but also my website, rtfmplease.dev, you can reach out, there's a contact form there. You can find me on the web anywhere—LinkedIn. Reach out, I answer almost all my DMs when I can. It's very rare that I don't answer DMs. Maybe there'll be a slight lag, but I do. And I really do like when folks reach out to me. I do like it when people try and make contact.Corey: And you can also be found, of course, wherever find DevOps products are sold, on stage apparently.Sharone: [laugh]. The DevOps community, that's right. @TLVCommunity, @DevOpsDaysTLV—don't out me. All those are—yes, those are also handles that I run on Twitter, it's true.Corey: Excellent.Sharone: So, when you see them all retweeting the same tweet, yes, it's happening within same five minutes, it's me.Corey: Oh, that would have made it way easier to go viral. My God, I should have just thought of that earlier.Sharone: [laugh].Corey: Thank you so much for your time. I appreciate it.Sharone: Thank you, Corey, for having me. It's been a privilege and honor being on your show and I really do think that you are doing wonderful things in the cloud space. You're teaching us, and we're all learning, and you—keep up the good work.Corey: Well, thank you. I appreciate that.Sharone: I also want to add that on proposed marketing and whatever, I do actually listen to all of your openings of all of your shows because they're not fluffy and I like that you do, like, kind of a deep explanation, a deep technical explanation of what your sponsoring product does, and it gives a lot more insight into why is this important. So, I think you're doing that right. So, anybody who's sponsoring this show, listen. Corey knows what he's doing.Corey: Well, thank you. I appreciate that. Yay, “I know what I'm doing.” That one's going in the testimonial kit. My God.Sharone: [laugh]. That's the name of this episode, “Corey knows what he's doing.”Corey: We're going to roll with it, you know. No take-backsies. Sharone Zitzman, Chief Manual Reader at RTFM Please. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review of your podcast platform of choice, or if it's on the YouTubes smash the like and subscribe buttons, whereas if you've hated this show, exact same thing—five-star review wherever you happen to find it, smash both the buttons—but also leave an insulting comment telling me that I'm completely wrong which then devolves into an 18-page diatribe about exactly how your nonsense, bullshit product is built and works.Sharone: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

The Circles- product (incl integrations)- docs- content- community- UGCTALK ABOUT SVELTE SOCIETY STORYDimensions of the Circles- negative engineering? or dev exceptions- onboarding -> production -> prod-dev -> billing -?Other definitions of devx- single command do a lot -> until too magic- does what it says you would do- making some cycles faster -> esbuild 100x faster - bret victor inventing on principleFuture of Devx? integrate forward, or backward- content creation meta - video. shortgame + longgame.- backward -> going into docs, productListen to the DevX pod: https://devxpod.buzzsprout.com/1895030/10012425-the-radiating-circles-in-devx-with-swyx-head-of-developer-experience-temporalPauline: 0:00Hi, Shawn! Thank you so much for joining us for a DevX pod today. We're really excited to have you on board. I just wanted to point out this is one of those things where I tweeted about something and then someone was like, I recommend this person. And then I found you, so this is really exciting and we're going to have this awesome conversation about developer experience. Maybe for those who may not have heard of you before, can you give us a bit of an introduction on your story? What you're all about?Shawn: 0:31Yeah. Thanks for inviting me on. I'm Shawn also known as swyx online. I originally am from Singapore and, moved to the U S for college and pretty much the rest of my career and spent my first career in finance before changing careers to tech. And since I joined tech, I've been fairly known for learning in public, for speaking about reacts and serverless. And now I work as Head of Developer Experience at Temporal.Pauline: 0:55I have a follow-up question actually. What does it mean to be head of developer experience at Temporal?Shawn: 1:02It's a role that we basically, I created for myself because when they were reaching out to hire me, they didn't have something like that. And I don't think it's a common role at a startup as well. The bit of a background, which we can get into like how I got started into developer experience. I previously worked at Netlify where I originally joined as a developer advocate type person, but then when Sarah Drasner came along and started leading us as a VP she restructured the whole thing to make it more of a developer experience engineer. So I'm turning developer relations into something where you actually do a bit more engineering and are responsible for parts of the developer experience rather than talking about it. Then I continued that into AWS, whereas also a driver advocate for AWS Amplify. Well, I think for me, the role that I really thought would make the most sense to borrow was something that spans across docs and developer advocacy as well as community. And then I was also a product manager for our recent tax group STK. When you're in a smaller startup, you kind of have to wear many hats. And so, uh, this developer experience umbrella felt that the most descriptiveMike: 2:14I think you literally just covered the next two questions I wanted to go talk about. I wonder if you have any more details in terms of overall what DevX is to you?Shawn: 2:25Yeah. I've actually written some thoughts about this. I kind of think about it as a radiating circle out from the core product. And so part of this is influenced by me struggling with developer relations at Netlify and at AWS, because often there's a separate team that is responsible for docs. There's a separate team that's responsible for product. It's very hard actually, when you realize. A lot of the things that you do as a developer advocate is very it's downstream of everything else that's above you. And if they're shipped and organized by different teams, then you can get a very disjoint experience. Essentially like your impact as a developer advocate may not be as high because people don't see your stuff as much as they see the docs or the experience about it. So just think about it in terms of like, okay, you start with the core products, make sure that the product design and you get enough feedback. You make sure that API design is really solid. then you radiate out into the docs, which is your sort of first party content on how to use it. I consider docs secondary to products because the best doc's is the docs you don't have to read, right. That is intuitive experience, but still you need docs anyway. And then going out from the docs you need, you go into first party content, which is the role of a developer advocate. And that is anything that's ancillary to docs that explains the why instead of the, what or the how. But you can also dive into the what and the how as well. Like sometimes you just need to pitch the same thing, seven different ways before someone gets it. And then you go from the first party content, which is your blog posts and talks and stuff like that. It's very traditional DevRel fodder into community, which is going from one to many communication to many, to many communication. In other words, having a place where your users talk to other users and help each other out. And then the final tier is enabling third-party content, which is I think about it in terms of users writing blog posts and books, workshops and courses and tutorials about you, even posting jobs with your tool or your technology in the job description on anything like this, where it's very user initiated. I really like encouraging that because that's how you know that you start scaling developer experience beyond the sheer number of people that are working in your company because you have users working for you. But that only happens after you got all the core inner loop stuff right.Mike: 4:48I like the analogy with the radiator being in the middle and starting to do, send the heat out. I wonder, what's your take on in product developer experience, how do you make sure you don't have to ride this doc? Do you know that chapter in the documentation and how do you deal with that? Are you directly involved in the product to make certain changes that you think are more intuitive? Or how does that go?Shawn: 5:13Yeah, I think it depends on the maturity of the company. This role or this job changes very much depending on whether you're a seed stage or series B and maybe you're not a venture funded company, but depending on the maturity of the products, right? If the thing is mostly fully formed, then you have much less impact or possibility of changing things. But for me, I was directly involved in shaping every single part of the API that we shipped for the TypeScript and I wrote almost every single word of the docs. Very extremely involved! Because then after that it can flow from there to my DevRel efforts and community building efforts. So I think it really depends. The second thing it really depends on is how visual you are versus how much of a code base Platform you are. So we are very code based. In other words, we care much more about API design than user experience design or UI design. I think UI design for visual product makes sense. I think Gitpod probably more of a visual products because there's no Gitpod API. I mean, there's a config and there's no Gitpod API that I integrate into my app or anything like that. Netlify where I used to work as well. Yes, there's another Netlify config, but like the rest of the thing is just point and click. So in that sense, yes. The role of UI design, I think is very powerful. The last point I'll mentioned for you as well, is that another principle or API design principle that applies regardless of whether you're doing visual or programmatic SDK work, is that you want to try to enhance the power of a single command. So for us it was Netlify deploy or git commit, and that would create a whole new deploy preview. And that was a big revolution in front end development. There was other analogies in the CLI that we should, that we shift this well that I was involved in. But I always think about that in terms of like, okay, how do you increase the power of a single action and just pack as much as possible in there? I really liked that idea. I don't know if that is described as good developer experience, but to me, I think that really contributes to a wow moment that where you type a single command and something magical happens, because that would have typically taken many steps to accomplish.Mike: 7:27I think this is a great way to describe it. The other thing I like is when it does what you expect it to do, I think that's another huge one. You could have add whatever, but then, it does only half of the stuff or, yeah there's really good examples out there for sure. Nice.Shawn: 7:42There's a part of a developer experience, which I often talk about which is a developer exceptions. In other words, developer experience often we talk about happy paths. Like, oh, if you ask them, do I like this? Look at how amazing it is. Look at how awesome and how fast and how everything, how amazing everything is. But people in developer experience often don't talk about the, what happens when things go wrong and actually sometimes paying attention to giving you a nice remedial path when something goes wrong is actually also a really good experience that developer experience, which people don't talk. So improving observability, making sure that you don't have pricing mistakes or your pricing is predictable, at least. And doing things like having clear versioning and deprecation support policies, these all kind of boring and less headliner things that you want to ship, but it's actually very key for developer experience.Pauline: 8:35That's a really good point. You said having a wow moment and that I think is a really good explanation of what developer experience is. Why is it important to you that we have that wow moment? Why should we even care about developer experience? Why have that wow moment?Shawn: 8:54I think the wow moment is more of a marketing thing in the sense that there's a lot of developer tools out there and you need to stand out somehow and you need to get to that wow moment as quickly as possible because everyone has other things going on. They may click away if you don't get to that wow moment. so I think that's part of it. The other part, which is also like game design, in the sense that, you need to keep having rushes of endorphins to you, to make your job fun, to have the developers stay in flow and developers that stay in flow and more productive. As to why in general, should we even care about developer experience? I actually, yeah. There's a cynical view. And then there's a more genuine view. The one genuine view is that developer experience helps, developers be more productive, which helps ship more products and makes users happy and blah, blah, blah, develop a tooling companies are worth multiple billions of dollars. And if you can help a developer tools company improve the developer experience in whatever form, then that creates a lot of value for developers. That's the feel good, happy view. My secret problem with developer experiences that I don't think it's that important. Like it's, you're not curing cancer. You're not flying to Mars or anything like that. So I think it's intellectually, interesting and financially very rewarding career. But we should also be a bit humble about. Yeah. Like nobody wakes nobody else outside of developers cares about developing experience. We, they just care about, are you making the thing that helps me make the other thing go faster or ship faster, whatever. And that's it. All these other metrics around, like, I don't know, like number of people visiting your blog posts, like no one cares. So I'm very cynical about that sort of thing. OhMike: 10:45no, my analytics,Pauline: 10:49I was just going to say that's... That's probably the most refreshing take actually. Because I feel like a lot of other people have not mentioned it in that sort of way or describe developer experience in that way you are right.Shawn: 11:02Also, I wasn't interviewing there, I was talking with a very senior person at Cloudflare and, I told him this . And he was, I think he was like considering to hire me or whatever. And it wasn't an interview or anything, but I think I closed that door when I told him this, because he was like, what are you talking about? Developer Experience is everything. I'm like, dude, like, come on. Like, like developers are very pampered. Like we have like unlimited leave ,we have like six figure salaries. We're fine. Like, we don't, you don't have to pretend like this is the highest value thing in the world. But, I mean, it's still very valuable. It's just it's one of many possible things that smart people are. Oh, could you read it one more? Nice thing, which is that I think improving the developer experience for beginners is very important. Enables beginners to get started, to make the career, to, to transition their careers which is I'm a career changer myself. And if I did not have the help of people who focus so much on docs and community and, making things accessible to beginners, then I would not be here. I'm not against it. I'm just saying it's not, you know, there are also many other important things.Pauline: 12:09Absolutely. If you're like a doctor or a surgeon, or solving our pandemic . Yeah. No, thank you for that. A lot of our guests have said accessibility especially to begin as is why people should continue caring about developer experience and improving it and stuff like that. That's a good point.Shawn: 12:25Yes.Mike: 12:29No, no, I, I was, uh, I wanted to move on, but that's a good point. And it does make moving on a bit easier then on the previous note we talked about, so I think we talked about the commands that, you know, do a lot for you. What other kind of like excellent developer experience have you experienced or maybe build yourself or with the team that you can share about?Shawn: 12:49I feel like I should write this down because there's a number of nice develop experiences that stick in my head that I haven't really articulated very well. So in other words, single command doing multiple things that's good until the point that it becomes too magic and then that's bad. We've established that already. Another one that I really like is making some cycles faster, right? If you can make things in order of magnitude faster than you have better developer experience. Something that people bring up a lot is the benchmarks of IES built in the JavaScript ecosystem, comparing to Webpack or a parcel or roll-up. On the ESPP build website, they have a very prominent benchmark that shows that they are a hundred times faster than Webpack. And that is. And when anytime you increase things by orders of magnitude, that you unlock different usage of that tool. And so I think it's a very important thing to try to always look for areas in which you can speed up the feedback cycle because then you unlock opportunities for play. I think one of the best talks on developer experience that everybody has talked about is I think Bret Victor's inventing on principle talk, where he shows like, okay, if instead of jumping back and forth between your editor and your final output, why not just combine them and have your app or your writing be directly interactable so that you can shape it and play with it as you go along and discover new things because of the play. So I really am inspired by that. And there's a simple analogy to the shift left ideology that came out of IBM, which is that a lot of times when people discover bugs, they discover it very late in production, or even after they shifted in production. And if you shift things left, if you reduce the feedback loop of finding bugs, whether through tests or types or a QA or whatever, right? There's a whole bunch of techniques that are all developer tooling and development experience related. If you shift those items left from production back into the development time, then you enable the opportunity to increase the feedback loop in and correct your mistakes before they get too far out, or you build too much. So I really liked that feedback loop reduction, and then another developer experience thing, which I really like is this idea that everything is just there for you. In other words, you don't have to go out and assemble a bunch of different tools yourself, having an all in one package that with blessed the tools that are known to work together, I think is really helpful. One example of this is I'm actually going to venture out to the jobs review system and talk about Anaconda and Python. So Python is a fairly wide and huge community. But Anaconda is a specific distribution of hyphen with preselected pack packages that are all guaranteed to work together because dependency resolution was a huge problem for the Python ecosystem and the data scientists that were using Python, where it's spending so much time, like trying to say, like, does this work at the other thing? No, it doesn't. So I will have to both drop back to like an older version of the common thing, blah, blah, blah. Very common in JavaScript as well, by the way. But Anaconda actually managed to carve out a niche in Python and made Python, the de facto language for machine learning because they made that develop experience so much. And I actually genuinely think that they are, single-handedly responsible for making Python itself that much more popular. I think that's another interesting thing, which is like, where's the all-in-one for the 80% of use cases that don't need that much customization. Of course, if you want to customize sure, go ahead. You have the full power, but most people, they don't, they just have very standard needs. Let's just do this, just pave out the common path. And so that's how I went from using React. Which is the most popular Javascript framework, to Svelte, which Mike knows very well. And so has all the tools and tools included batteries included. And if I need to customize or drop out of it, I can. And I think that is also a really good developer experience in there so that the, all the ones who toolkit it, that doesn't constrain you too much.Mike: 16:57So really the question for 2022 is what's the Anaconda of JavaScript?Shawn: 17:01When Vercel talks about building the SDK for the web, that's what they mean.Mike: 17:04Yeah. Good point.Pauline: 17:05You gave me lots of flashbacks of playing around with Python over the past few years. I haven't really been in that ecosystem in a long time. Actually, Mike will be really proud of me, but I started learning and rebuilding one of my big projects. One of my, well, actually my blog, which is my biggest project, in Svelte, moving away from Nextjs. But, it's taking me quite a long time, longer than I thought, because there's so many. I don't know, there's so many different things that I need to learn how to use this Svelte way of doing things. But yeah, it's really interesting. It's a lot of fun. I understand why Mike and yourself love it so much. I think.Mike: 17:43We will talk offline about that Pauline.Pauline: 17:46So let's, let's do that. Yeah. Lots to, lots of talk about, yeah, it's messy. Yeah. Awesome. Thank you for sharing that.Shawn: 17:55One thing I'll share with you about this Svelte thing. I'm friends with Rich. I had come across Svelte, but actually ignored him for a year until I was like on a trip with him at Barcelona. And then he was like, he's still talking about Svelte. And I was like, okay, I have to try this because you can only be friends with someone so long before you have to try their things. And then I tried it and I was like, oh, okay. I'm an idiot for ignoring this for so long. But the other thing. Notice was that Svelte did not have a very strong community backing behind it. So actually started Svelte society as a part of the next stage of developer experience. So if you think about that reading radiating circle thing, had a very strong product already and it needed and it had pretty good docs. It needed the next level, which is community or DevRel, whatever that is. There is no first party DevRel for Svelte, but I guess Rich's the one had a one man show for that. The community part was the thing that I focused on and that's how Svelte society got started.Pauline: 18:45I was going to say, but this is what is this? Maybe the sixth or seventh episodes that we'll be posting on dev X pod and community has taken the lead every single time. It's always the thing that brings everything together. And it's also very validating because I focused on community at Gitpod so every time I hear it, I'm just like, yeah, that was great. Cool. Awesome. I wanted to move on to our next question, which is, where do you see DevX evolving? Will we be focused on tools or people or community?Shawn: 19:20I think, in line with the model that we've been developing, in this episode, either you integrate forward or integrate backwards, in other words, a typical typically develop experience is very tied to developer relations and a lot of first party content creation. So you integrate forward, meaning that talk a little bit more with community, you take on more community management roles or you encourage more, third party content by holding workshops and stuff like that. Or you integrate backwards, which is you get more involved with products. So I think that's an interesting way to think about this in terms of the radiating circles, but the other way to think about it as well is what's the shift within the content creation meta game, which I think about a lot as well. So for me right now is that I think a lot of people should be shifting towards video. I think that, the amount of time that how much time do you spend. You know, a week or a day I spent roughly an hour or two hours. Yeah,Pauline: 20:14exactly. I was going to say a bigger number than that, so, yeah. I'm glad you said your number first.Shawn: 20:19We all spend, we all spent a lot of time and a lot of times we're never going to spend on developer content because we're just on YouTube to veg out to. But I think people who do video very well are getting disproportionate attention. And I think it's a very scalable format. There are challenges with it, which I think Mike has maybe one up in the past before, which is that video is very expensive to produce and it gets outdated very quickly. There will be new tools that arise to fix that. But otherwise, I think the sheer reach of YouTube is just unparalleled. It is the second biggest search engine in the world. The content that lives on there, if you can get it to be evergreen, it can be extremely valuable. I still get comments on videos that I did two years ago, I always think about the half-life of content. The half-life of a tweet is four hours. The half-life of a blog post is maybe like a year or if it's a good blog post, if it's a normal. blog post that everyone is like treating us nothing special then. Yeah. It's probably a day or so. That will be irrelevant in a non-existent, but for videos. It's definitely very long. So I'm very interested in that. And I almost also interested in this idea of having a short game in the long game. It's kind of like tennis. If you only play long games, if you only stay at the back and you only love the ball and then you get killed on the, on the short game. Likewise. So in other words, do you have a short form game where you can pitch your startup in very short and concise detail? And do you have a long game where if people want to engage with you over very in-depth conversation, you also have ability to go deep and you have the content to offer them. I think having, so this is why I focus on having two minute videos and three hour workshops. you want to go extremes? There's a lot of 30 minute talks and podcasts out there. That's fine. But, I think the areas of relative under development are the short game and the long game.Mike: 22:12I had a conversation with a friend recently where she was asking me like, Hey, why don't we put some educational tech content on TikTok? And it was around the time when, TikTok had took over Google products in terms of like number of visits in 2021. And that was yeah, actually, why not? So I signed up for TikTok and I spent like 10 minutes watching videos. And I'm like, this is crap. Like what the heck? There's just too much stuff I don't care about. So I need a way to filter the stuff I care about. But then I started searching for things like web development, full stack development, and then whatnot. And there's a few things, but I think what you're saying in terms of the two minutes versus longer things, you can take that to an even other extreme of I'm going to take a real cheesy example, but array methods. One video, 15 seconds about each method and put it up there, see if it goes viral and people talk about it. But I think this is another platform that it's going to up and coming and currently not used for it, I think might be a really interesting play.Shawn: 23:11To see if it started watching it. I'm keeping eyes on it as well. The problem is that every, everybody knows array methods and you're not really doing anything for your work by explaining a writing methods. You might grow your own personal following, but that's also not a very valuable following. And let's just be real about that, right? If you get a whole bunch of beginners, then you will be incentivized to create more beginner content and you'll be stuck in beginner tutorial. And then I see a lot of people also get stuck to that because the numbers are only thing that matters to them. So I think, as far as philosophy of consecration goes, I definitely aim for some mix of intellectual curiosity and reach. And if you have only reach, then you may sell out yourself and you may burn out. You may not fall in love with the process. And I think that is the saddest thing in the world for someone to be in such a privileged job as a developer experience person, and to have your own personal intellectual curiosity, thrown by the wayside. I do, and they're doing courage to try to pursue some mix of reach plus first intellectual curiosity. I think the person that really does it best is Scott Hanselman. I don't know if you follow him. To talk as well. He does introductory stuff, but it's always authentic to him. He's not selling out. He's genuinely like, Hey, I think this is really important. And whether or not it happens to be advanced or intermediate or beginner, he's always very much that this is something he genuinely thinks in his.Pauline: 24:34The first thing that's on my mind is the fact that I love how in the past two episodes, actually we've been talking about, we've been bringing to light, content creation in developer experience because I don't think a lot of people think about that. Certainly until the previous episode, I didn't really think of developer experience, including content creation or including things like videos or tech talks, because the only thing I was thinking about was the products, like how can we make the product better? So that engineers on board quickly. So yeah, I really liked this conversation and it's really quite eye opening for me. I don't know. Mike, I wanted to say to your point, TikTok does get better after you train the algorithm. I was like, I don't know why anyone is on this app is just full of gen Z. I was just like, I don't understand this. But then after I started watching content that I actually liked it's really good it's really interesting. And now I've been hooked like at least an hour a day. I've been on it.Mike: 25:33But well, on the bright side, I have a lot of different methods to peel a pineapple now. So I learned aPauline: 25:43lot of, and the how to use an air fryer in all these different ways, how to cook all these different recipes. Oh, yeah, it's really cool. I just find it really interesting that content creation is included, but it really validates where my thoughts are in terms of content creation and develop experience as a whole.Shawn: 26:01This job, this industry is still very nascent, so it's not well-defined. So I don't think you should feel weird about it at all. I think for me, I came at it from my background, which is that we called this DevRel function, this content creation function at Netlify, we called it developer experience engineer. And so that's part of what we do. I should also mention that. Yeah, we were responsible for third-party integrations as well. So I guess.Pauline: 26:33Exactly.Shawn: 26:35But no, I think, at the end of the day, people wants to develop the tools. Companies want people to discover them and the best ways to, through content marketing. And that's why they hire people who are smart at that. And getting them down through that top of the funnel is very useful to them. I think probably where that we need to do better is that yes, I can pull a lot of people at the top of funnel, but if the product doesn't align with what they expect, then it's going to be a very leaky bucket. A lot of people going to come in, they're going to kick the tires and then they're going to leave. So how can we get a higher qualified audience or how can we get a product that is more intuitive or that retains people better? My own personal journey has been very much backward integrating into.Mike: 27:21Nice. Yeah, I feel like every episode we recorders, I always go away with it and I'm like, okay, let me think about all that again. And then I started researching and digging deeper and I'm like, there's a lot of interesting stuff. And we're really just getting started and five years from now, if we had another episode and talked about what is DevRel going? We would have a very interesting conversation, probably very different to today. Definitely looking forward to it. Cool. So one thing we tried to do is use kind of at the end of the podcast to wrap up with a fun thing that you recently came across with, or somebody you want to give a shout out to, that really made your day in the last couple of weeks or so? Um, yeah anything top of mind that you want to share?Shawn: 28:01I wasn't prepared for this, but I guess I'll shout out to obsidian. So I think for me, my personal note taking system is very much very important to me in terms of having it as a second brain where I store all the thoughts that I had that are still working progress or data points on some essay that I'm writing, but it's not done yet. And I moved around a lot from simple note to one note to notion. And most recently I made the shift to obsidian and the way I decided on this is that I really wanted to bet on mark down. I think mark down is a format that's going to. Longer than any of us. And that I also wanted it to sync, to GitHub and to have a good mobile application and obsidian match all of those things. Plus it has an optional service to publish your notes so I can share what I am thinking as I think it, for people who really care about, finding out before I publish something on my blog. Obsidian is a really good note taking.Pauline: 29:01I was going to say that is really interesting that you shared that for this week because Mike I'll just go next. But the thing that I wanted to share this week is actually LogSeq which is similar to obsidian. I don't know if you've heard of it. I think it's created by the same people or someone had left obsidian team and then built it. I'm not actually sure of the background. But I have been using it for the past two months now. And it's my favorite note taking app, just because, I think in bullet points. And I sometimes feel overwhelmed when I used to use other note taking apps where I would write like a long block of notes and then I try to organize it, but it just all felt overwhelming. Whereas when I have bullet points at the start of when I'm taking notes, it just like sinking things into my head better. I don't know. No, it just makes sense for my workflow. And then every single day, I don't need to worry about organizing my notes. I can just when I open up the app tomorrow, I will have a fresh, clean slate and I can start I'm taking notes of my day. And again, it's become my second brain because then I can just scroll back down and be like, what did they do yesterday again? And then everything is in one place. So yeah, LogSeq is my shout out of the week actually. And it was just really interesting that you brought up obsidian. Cause I think they go hand in hand. Well, but yeah, over to you, Mike, what's your fun thing about.Mike: 30:30Well, you really put me in a tough spot because I feel like I need to talk about my note taking,Pauline: 30:35I genuinely have this prepared in my notes. I was like, this is what I'm going to talk about, which is why I was really interested in,Mike: 30:42oh, I'll take the Liberty to do two things. One is my note taking app, which is Reflect.App. Exactly the same concept. You get a little graph every day. It gives you a new empty note, you take your note, but same idea. Markdown, I guess, for the win. The other thing I did have in my notes though to share is I don't even know if I should share it because I literally just found out about it two days ago when I read the landing page, but I want to dive deeper into it. It's swim.io with double M. And what they're saying is that they sync your talks with your code. So it's more of like a documentation tool for code, it seems well, the screenshot looks interesting. Let's say that. So I'm going to dive into it, but I figured this, is it something that is literally just top of mind, for today's podcast then? Um, I figuredShawn: 31:30out what share that. Yeah, we actually a hand-rolled we had wrote something like this for our own docs. I don't know if it's a startup. I remember this one because, swim, they raised a pretty big series, a 30 million, and also it's coming out of Israel. So it's just like a really it's the market, this big come on. But, uh, Hey, you know, it's a hard problem and it helps developer experience.Pauline: 31:53We'll link everything that we mentioned from this episode in the show notes, but we have reached the end of the podcast. Oh my gosh time has flown by. Thank you so much, Shawn, for joining us today, I'm excited to share this episode with everyone. So many things to think about, and Mike said earlier, I actually edit these podcasts, so I listen to them, quite a few times over. Every time I listened to them, I'm like, wow, there's so many ideas here that we can take on for Gitpod, for community or whatever it is. I'm really excited to re-listen to this multiple times, take the best bits and then share it with everyone. So yeah. Just want to say thank you again.Shawn: 32:30Well, thanks for having me pleasure. I'm really excited that you guys are doing this because people are dying for more DevX content. Every time I post something about it. You know, how I feel about that mix now? And so every time I posted about it, I always feel like a bit of a mix of like, okay, like, this is interesting, but also I don't want it to define who I am, but I think it, yeah, it's definitely very valuable and people are very interested.Pauline: 32:51Yes, absolutely. Absolutely. I'm sure it's going to be an interesting lesson to a lot of people!

This episode of Developer Experience is about Developer Education. It's a wonderful time to become a developer: the demand has never been higher, and there's a literal ocean of free and paid content to kick start a new career in tech. This firehose of educational content is a side-effect of such a high demand for developers, and it makes it difficult to spot actual quality content that's worth investing in.- What makes really great educational tech content?- How do beginner and advanced developers want to learn today?- And what does it teach us on communication and reaching clarity?To answer these questions, Sarah Dayan is joined today by Jason Lengstorf, VP of Developer Experience at Netlify, where he and his team ensure that developers make the most out of the platform. You may also know Jason from his dozens of lessons and workshops on Egghead.io, Frontend Master, and as the host of Learn With Jason, his fantastic developer show where he learns new technologies in 90 minutes with experts from the field.Jason Lengstorf: @jlengstorf / jason.af / Learn With JasonSarah Dayan: @frontstuff_io / sarahdayan.devNetlify: @geteslint / netlify.comAlgolia: @algolia / algolia.com"Learning to Learn", article by Sarah Drasner on CSS-Tricks

JS Party listeners and panelists celebrate our favorite moments from the past 100 episodes! You'll hear from over 20 of your favorite voices across 14 episodes. We also share some behind-the-scenes and read/hear from listeners! Here's to the last 200 episodes, and the next 200 as well.

JS Party listeners and panelists celebrate our favorite moments from the past 100 episodes! You'll hear from over 20 of your favorite voices across 14 episodes. We also share some behind-the-scenes and read/hear from listeners! Here's to the last 200 episodes, and the next 200 as well.

Former co-host Sara Chipps  now manages engineering teams at LinkedIn, but her best content is still on Twitter.Cassidy's former boss, Sarah Drasner, recently wrote a book to help engineers level up to management: Engineering Management for the Rest of Us. Cassidy's new favorite software tool is Astro, a single-site generator that looks to minimize the amount of client-side JavaScript in a site. The two books Ms. Chipps mention as the old standbys for new engineering managers are Peopleware and Smart and Gets Things Done. 

Former co-host Sara Chipps  now manages engineering teams at LinkedIn, but her best content is still on Twitter.Cassidy's former boss, Sarah Drasner, recently wrote a book to help engineers level up to management: Engineering Management for the Rest of Us. Cassidy's new favorite software tool is Astro, a single-site generator that looks to minimize the amount of client-side JavaScript in a site. The two books Ms. Chipps mention as the old standbys for new engineering managers are Peopleware and Smart and Gets Things Done. 

You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.) Steph needs some consulting help. So much to do, so little time. Sarah Drasner tweet about shared element transitions (https://twitter.com/sarah_edo/status/1431282994581413893) Article about Page Transitions API (https://developer.chrome.com/blog/shared-element-transitions-for-spas/) Svelte Crossfade layout demo (https://svelte.dev/repl/a7af336f906c4caab3936972754e4d6f?version=3.23.2) Svelte Crossfade tutorial page (https://svelte.dev/tutorial/deferred-transitions) (Note - click "Show Me" on the bottom left) Transcript: CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun? STEPH: Podcast battle. Here we go! 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, happy Friday. How's your week been? CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time. For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask? And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software. STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer. CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles] STEPH: Oh no, you're not a hacker any more. CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred. STEPH: What is your prompt? What did you say it is? CHRIS: Pure. STEPH: Pure, I don't know that one. CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great." STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite. CHRIS: Wow. STEPH: Wow. CHRIS: I mean, on the one hand… STEPH: You're welcome. [laughs] CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles] STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun. CHRIS: I don't know if you know this, but I am impervious to nerd sniping. STEPH: [laughs] CHRIS: So try as you might, I shall remain steady in my course of action. STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs] CHRIS: Nah, just one lie. It's easier. Everybody wins one lie. STEPH: [laughs] CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days. I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this. But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think? STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity? CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things. And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable. I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me. STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward. CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications. STEPH: So the normal application? [laughs] CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp. So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it's a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say. But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page. And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page. And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust. And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away. STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous. CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird. And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot. I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down. And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly. On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation. STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that? CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior. There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two. So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back. And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those. And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again. STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy? CHRIS: It's fair to call it grumpy, although you don't need to loop yourself in with me. I'm the grump today. STEPH: [laughs] CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude. STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround. So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content. CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL. So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful. So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people. And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please. Mid-roll Ad Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have? CHRIS: You have a fancy, though. STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind? CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello. And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this. So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems. And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same. STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages. CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot. And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that. I don't like if we have flashes of a layout that they can get ripped away b; it'secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things. Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases. STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world. I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations. CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph? STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have. And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise. CHRIS: So he's basically out of the puppy phase then. STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs] CHRIS: What about according to your lived experience? STEPH: He has calmed down a good bit. CHRIS: Okay, that's good. STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker's time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy. CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background. STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles] CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic. STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on. And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I'm at. What thoughts might you have, or what questions do you have? CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea. And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other. STEPH: It is both, my friend. It is both of those camps. [chuckles] CHRIS: Cool. That makes it way easier. STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go. But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we've done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up. So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing. So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff. CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?" So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving." And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at. Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to. What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can. But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer. There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that. And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard. STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related. One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well. So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough. So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it. CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs] STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying. We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?" The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like? And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I'd love to hear how your team tackled it. CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go? STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this. CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that. And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that. And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future. STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it's hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over. So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information. 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 at @_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: 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.

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.

Sarah Drasner's got a new book and we talk about her article on good meetings. Are front end problems more difficult than back end problems? GitHub's got an upgrade issues feature. How would you design a database for a new project? And where and what is data in 2021?

2021-07-13 Weekly News - Episode 111Watch the video version on YouTube at https://youtu.be/NzjspE5TDrU Hosts: Gavin Pickin - Senior Developer for Ortus SolutionsBrad Wood - Senior Developer for Ortus SolutionsThanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and almost every other Box out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Sign up for a free or paid account on CFCasts, which is releasing new content every week Buy Ortus's new Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Patreon SupportWe have 38 patreons providing 100% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. We are now 41% of the way to our next goal, fully funding the ForgeBox.io site.Now offering Annual Memberships, pay for the year and save 10% - great for businesses.News and EventsColdBox 6.5.0 ReleasedToday we are excited to release ColdBox v6.5.0 and its standalone companion libraries: CacheBox, LogBox and WireBox. This release has focused on stability and making sure all bugs are addressed especially when using our schedulers and asynchronous processes.https://coldbox.ortusbooks.com/intro/release-history/whats-new-with-6.5.0 https://www.ortussolutions.com/blog/coldbox-650-released CFConfig 1.4.0 ReleasedToday we've released a new version of CFConfig-- your friendly neighborhood CLI for configuring Adobe and Lucee servers.  CFConfig sees a lot of little releases that we don't announce, but they are usually very small little releases adding a single setting here or there.  Today's release has a nice collection of brand new features that seemed worth talking about.https://www.ortussolutions.com/blog/cfconfig-140-released Last chance to get your Into the Box Topic Submissions in Deadline for Call for Speakers JULY 15 - so submit ASAPhttps://docs.google.com/forms/d/e/1FAIpQLScXkZe7W-frEV5M4Id28Cz0wSr7meyJQfOnYEXgj7lzhcEA6g/viewform SUPER EARLY BIRD TICKETS STILL AVAILABLEGreat to see people taking advantage of this alreadyhttps://intothebox.orghttps://itb2021.eventbrite.comContentBox CLI Release and 5RC ReleaseContentBox 5 development is moving along nicely. 5.0.0-rc.2+34 was released July 6th and ContentBox-CLI was released June 30th.https://www.forgebox.io/view/contentbox-cli#versions https://www.forgebox.io/view/contentbox#versions Ortus Webinar for July - Building API Integrations with Hyper -Michael BornWednesday, July 21st Time: 11:00 AM CTLearn how to connect to a public API using Hyper in this webinar by Michael Born, where he'll cover API integrations from storing secrets to writing unit tests, to publishing the finished, reusable library on ForgeBox.Register https://us02web.zoom.us/meeting/register/tZ0rf-GurjMpE9cX63bZoFA-SqC4OXzDw6wK https://www.ortussolutions.com/events/webinars Adobe Developer Week Videos - Coming SoonAdobe announced the Dev Week videos would be appearing soon on their ColdFusion Portal site, on their video page. No official timeline on when they would be there, but we'll let you know as soon as we know.They have also added more of the API series videos there as well, 6 from that series, up from 2 videos last time we mentioned it.https://coldfusion.adobe.com/videos/ ICYMI - Lucee 5.3.8 ReleasedThis has been a very long release cycle, a massive thank you to everyone who has been helping us test and address regressions and performance problems…We have done a lot of work in 5.3.8 to optimise memory usage, the main two areas being improved was the template cache handling and parallel functionality.Highlights: structValueArray Array methods: shift(), unshift(), push(), pop(), splice() Reevaluate performance of locking overhead in pc.initApplicationContext() for every request Query of Query performance is very bad and single threaded for complex SQL https://dev.lucee.org/t/new-stable-release-5-3-8-189/8484Reminder - State of the CF Union SurveyHelp us find out the state of the CF Union – what versions of CFML Engine do people use, what frameworks, tools etc. We will share the summary results with everyone who completes the survey so that you can see how you compare with other CF developers.Spread the news so we can get as many responses as possible.https://teratech.com/state-of-the-cf-union-2021-survey 317 Results: https://teratech.com/state-of-the-cf-union-2021-results CFCasts Content Updateshttps://www.cfcasts.com Just Released Object-Oriented Programming with Nolan Erck (https://cfcasts.com/series/oop-series) NOW WITH CAPTIONS! CFC Docs with DocBox for Documentation Coding Guidelines and CFFormat Last videos of the series. Don't forget - the first 4 videos in this series are FREE Using DocBox Configuring DocBox Writing Great Documentation with DocBox Coming this weekQuick Workshop Videos with Eric PetersonComing up soon More What's new with ColdBox 6 More What's new in qb 8 More Using DocBox LogBox 101 What's new in Content 5 Send your suggestions at https://cfcasts.com/supportConferences and TrainingInto the Box 2021 - live in Person in Texas.September 23rd and 24th.No workshops this year.Deadline for Call for Speakers JULY 15 - so submit ASAP - https://docs.google.com/forms/d/e/1FAIpQLScXkZe7W-frEV5M4Id28Cz0wSr7meyJQfOnYEXgj7lzhcEA6g/viewformSelection Committee Meeting this week and Next - Speakers and or Schedule coming soon.SUPER EARLY BIRD TICKETS STILL AVAILABLEhttps://intothebox.orghttps://itb2021.eventbrite.comITB Latam 2021 - live in personDecember 2nd or 3rd 2021 (confirming dates asap)More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/CFML is now on the list - https://confs.tech/conferences/new Blogs, Tweets and Videos of the WeekBlog - Brad Wood - Ortus Solutions - CFConfig 1.4.0 released!Today we've released a new version of CFConfig-- your friendly neighborhood CLI for configuring Adobe and Lucee servers.  CFConfig sees a lot of little releases that we don't announce, but they are usually very small little releases adding a single setting here or there.  Today's release has a nice collection of brand new features that seemed worth talking about.https://www.ortussolutions.com/blog/cfconfig-140-released Tweet - Brad Wood - CFConfig EnhancementsFinishing some exciting enhancements to CFConfig. You'll soon be able to include/exclude(w/ wildcards) config to transfer.  Also choose to append data instead of overwrite & automatic replacements of ${ENV_VAR} placeholders in your JSON on export! #CFML #ColdFusion #CommandBoxhttps://twitter.com/bdw429s/status/1414707390885371908https://twitter.com/bdw429sBlog - Luis Majano - Ortus Solutions - ColdBox 6.5.0 ReleasedToday we are excited to release ColdBox v6.5.0 and its standalone companion libraries: CacheBox, LogBox and WireBox. This release has focused on stability and making sure all bugs are addressed especially when using our schedulers and asynchronous processes.https://www.ortussolutions.com/blog/coldbox-650-released Blog - Charlie Arehart - ColdFusion Portal - ColdFusion Security Code Analyzer now works with CF2021 Standard and Developer editionsIf you may not have used or even considered the CF Security Code Analyzer because it worked only with CF Enterprise, check out this change in CF2021. It now works with any CF2021 edition. And you may have a free license of CF Builder you could use for this.Whether you may be currently using the ColdFusion Security Code Analyzer feature or have never known of it or used it, this is a newsworthy discovery: the tool now works with ColdFusion 2021 when running even as the free Developer edition or Standard edition/license. Prior to CF2021, it worked only with CF's Enterprise license or Trial edition, and specifically NOT with a Standard license or the free Developer edition.https://coldfusion.adobe.com/2021/07/coldfusion-security-analyzer-works-with-standard-and-developer/ Blog - Charlie Arehart - ColdFusion Portal - What to try when Adobe site downloads or form submissions fail to work properlyHave you perhaps tried to download ColdFusion from the Adobe site, only to find after you fill out the CF dev/trial download form that the download would not start? You're just left at a page which offers no other means to download (Adobe could and should fix that by offering links on that page in case this could happen).Or perhaps you've tried to file a bug report at the Adobe Tracker site, only to find that the bug report fails to be submitted and you instead get an error, “Bug Submission Failed“.  Even trying to file a blog post on this very portal can sometimes be met with “submission failed“.WOW COOKIEShttps://coldfusion.adobe.com/2021/07/try-adobe-site-downloads-form-submissions-fail-work-properly/ Tweet - Ben Nadel - Gif SkillsPracticing my #GIF skills this morning with #Camtasia. Mostly, I just wanted to use this adorable quokka photo :D I love #ColdFusion. Deal with it

This Clubhouse-style Q&A was held as part of my support for React Summit 2021 (https://remote.reactsummit.com/). Moderated by Robert Haritonov, CEO of GitNation.Timestamps 2:30 How do you keep up with the changing landscape? 5:00 Balancing Learning Time with a Job 7:15 What are the top technical and soft skills to transition from junior to senior? 12:30 The Importance of Communication and How to Do it Well 17:30 Prioritization, Batching and Pair Programming 19:20 What can Seniors Do to Help Foster Juniors? Apprenticeships, Mentoring, Sponsorship and Allyship 23:15 How to convince older devs to try new tech? Address their concerns, do proofs of concept, know when to fold. 28:45 Nontraditional background. How to convince people to let you through the door? Networking and Personal Content Marketing. 34:00 How do you make technical decisions as a senior and avoid getting stuck? Innovation Tokens, Action Produces Information, Pay for Advice 40:30 Fall in Love with the Problem, Not the Solution 42:00 Can you still be a fullstack engineer? If you enjoyed this chat, you're welcome to check out our career community for 30% off!Mentioned Links Chapter 5 - Junior to Senior (free PDF) Gergely Orosz's Tech Resume Inside Out My Podcast Recommendations Every Public Engineering Career Ladder Sponsorship: https://larahogan.me/blog/what-sponsorship-looks-like/ Allyship: https://www.samanthabretous.com/blog/black-women-equal-pay-day-heres-how-you-can-help/  Diversity Resources (this is a work in progress list, hence not yet published, but i've been sharing these with pple who ask): https://gist.github.com/sw-yx/7aeedbeac1bb81017cd4f9d66b223b63 Ninah Mufleh Airbnb Resume Innovation Tokens If you'd like to see my React Summit talk, check out: https://youtu.be/yLgq-Foc1EE TranscriptRobert Haritonov: [00:00:00] So yeah, I'll let you get to your Shawn just, go ahead as you please? swyx: [00:00:03] Hey everyone. Hey, I'm Shawn,  also known as Swyx on the internet.I'm a React fan and but also a Svelte fan and one of my talks, that I speaking later on in an hour or so is seven Lessons to Outlive React. But this discussion room is a different topic. It's a non-technical topic. It's related to the book I published last year.Basically talking about how people can go from junior to senior, how the non-technical elements of the software engineering job is very relevant for our career progression and something that we don't really talk about enough. And yeah, I'm very interested in sharing my experience, the experiences of the people that I learned from.If you wanna check out the, the amount of research I did you can check out the site at LearnInPublic.org.I'm going to just explain a little bit of what I wrote on the junior and senior chapter. So essentially   part of what I was trying to do here was define what a senior engineer is.And  it's one of those things where everyone has a different opinion and  it's more of a pay scale than it is a well accepted metric. To some people you have to have at least three years at a high growth startup. Others can take up to eight years to become a senior engineer. Or there's, let's just say they don't care about the number of years, right? It's  more about what you can do. And ultimately I think for me is what I really care about is for everyone to have the prerequisite skills enough of the prerequisite skills, and accomplishments that you can make a strong case for a senior developer, but then also market yourself as meeting enough so that people notice you and hire you whether, internal promotion or externally when you do a lateral transfer to another company. And I think a lot of times it involves acting like a senior engineer before you officially become one. So it's a bit of a chicken and egg, right? And I think that's something that we have to recognize more and study more. . Because I don't think we have  enough of a conversation about how to convert juniors to seniors and It's the biggest gap in the industry, everyone wants to hire seniors,  but there are so many juniors trying to try to upskill themselves. 2:30 How do you keep up with the changing landscape?I've just invited avocado Mayo. Are you able to speak hi, can you hear me?  Hey, how's it going? Shawn? The eye. Good. Thank you. I'm a developer based in Canada. I am, I have a question for you a general career advice.So I, I feel that the front end landscape is constantly changing and the web is constantly evolving. A question that I have for you is what are some ways that you kept up with the cutting edge so that your call I'll still the learning and what are some ways that you kept up with the changing landscape in development?Great question. It's something I get a lot, but honestly I don't, I haven't really slowed down to like document a process. I just do whatever comes to mind. So this is a bit off the cuff. So something I care a lot about I think it would not be an exaggeration to say that I do get a lot of my tech news off of Twitter and the things that, so I tend to do this strategy, which I call following the graph, which is like figuring out what the smart people that have effect they have built, the things that you use, like the reacts and the babbles and the WebEx, figuring out what they, how they got where they are and what they're working on today, because they're also excited about other things they didn't stop just because they were done working on, on, on the tool.So I follow the graph, like I follow who they follow, and then I figured out who their influences are and try to understand the historical context of where these technologies fit in. And that's all an attempt to try to figure out like what themes I should focus on for the future. So every now and then I try to step back and go okay what am I interested in?Because I think honestly the reality is that there's too much to keep up on. And I think if you try to keep up on everything, it's a full-time job and you'll never go deep on any particular topic. And that's also really bad. It's not enough to just know the names of every project.You actually have to have tried it out to know the philosophy. You have an opinion when you're, in your company, you're asked for it. So that's why I try to do I tried to have a thesis. I tried to inform it by following people who I think are doing interesting things in the ecosystem. I think attending conferences actually really helps a lot because the people who are excited enough to give a talk about something, it's probably something I should at least be aware of, like what it's about.And I have this four-step framework that I borrow from thought bot I think, or thought works. Where it's it's like assess adopt, avoid. And I forget what the fourth category is, but basically just have an idea of what you are choosing to focus on what you're monitoring and not really getting into right now, but could be, and what you've just decided.Okay. Hey, there's just too much going on. I need to filter something out. And I think that's a very healthy way to stay on top of things.5:00 Balancing Learning Time with a JobThank you so much, Shawn. I have one follow-up question before I I go back to the audience. So as you mentioned, it's I feel like when I, whenever I get on Twitter, there's an overwhelming amount of information. And I find it also really hard with all these emerging technologies to balance. I like the, my actual job and learning these new things.Do you have any advice for how you manage your time for learning new things and actually, getting your job done? Wow. That's a, that's an awesome question. I think it will be it's very nice. A lot of companies have this idea of some learning time.For some companies that's half a day, every week. So I'm going to be just like one day, every two weeks, whatever it is. If your company can budget in some learning time on the side, I think that really is very helpful.  For me, I do a lot of side projects. I will dive into to things outside of company time.That's something that's not necessarily something that everyone can do because they have a life for her family outside of outside of work. But I don't know that there's, you can find ways to. I guess keep tabs. And if something's not working out for you, be okay with letting it go and try something else.So if you're doing X, if you're doing, if you're working out, there's plenty of podcasts, I can recommend to you. Just go on my blog and look for a podcast. I have list of like 250 podcasts. And and you can keep up that way, right? Like you, you could be doing something active and still learning.You could be, just experiment with different forms of learning, in, in different people learn in different ways. So I definitely think that I learned best by, by keeping my focus small on like the number of topics and themes I get excited about and just ignoring the rest and then actually trying stuff out because.You really only go get so much just like looking at tweets and reading, readme's. It's once you actually have tried the thing out, then you have a strong opinion. And you pretty soon find yourself like recommending it at work. And it's pretty cool when like the stuff you learn on the side comes in and actually has a positive impact on something you do at work.And that's where I think people start to really see the value of you learning during work as well. So you can make a case for that.Robert Haritonov: [00:06:56]  So Shawn,  I've been doing some discord management, created the channel. People can ask a question there as well. It's right. The whole discussion around what's called discussion. I'm going from junior to senior. There was one questionnaire, but we also have two people joining here with voice, so Kwan and dome.swyx: [00:07:12] I think Dom raised his hand first. I'll go first. 7:15 What are the top technical and soft skills to transition from junior to senior?Robert Haritonov: [00:07:16] So I have two questions. The first question would be what are like your top evaluation of skills for technical and soft skills for that transition from junior to senior.And second, my question is my second question is regarding how do you know you're in that same like level of senior after, when you start off as a junior without having that swyx: [00:07:39] imposter syndrome? The second one is it's closer to home. The first one, let me try and rephrase the first question. Cause I don't think I really got it.What level of technical skills are required? You said Robert Haritonov: [00:07:48] What do you think differentiates a junior dev on a technical level from a senior dev both texts like technical level swyx: [00:07:56] and soft skills. Yeah. It's it, obviously we're at a front end focus conference, but I try to keep my answers agnostic or front end or back end, and it's going to depend on, whatever team you work on.But here's the bottom line, right? I think that seniors should be able to independently ship something from beginning to end, like the buck stops with you. And for most things I can just give you an assignment and you can basically ship. That feature or that issue or that Epic basically on your own, without much guidance, whereas a junior obviously would be expected to to be given as much resources as possible.So that independence is a very, very key part of the senior definition. The non-technical elements there, there are a lot of other definitions as well. Mentorship is a key one. Once you get to a point where people start coming to you for advice that's a strong sign of a senior developer and being able to be a force multiplier for the rest of your team.So, you're not just concerned with your own performance. You're also concerned about your team's performance and working on. Either processes or even dev tools or infrastructure tools to make them all more productive. These are all qualities that people shout out as as positive aspects of a senior developer.I have this essay called junior engineers, senior engineer, and I have a list of like little quotes that distinguish things between junior and senior, which I could read out (see the PDF linked above). I don't know if that would be helpful. But then I can also talk about, I guess I'll squeeze in one more thing before I, I give I talk about the.The katas which is career letters, right? Study your company's career ladder. If your company doesn't have one, try to get involved in in creating, defining one, because if you get a hand in defining your own career ladder, then you get to, nudge things in a way that you like, which is very nice.But if you need help if a company doesn't have one, there are a lot of public career letters out there. So I have a blog posts. That's literally just Google every engineering career ladder. And it's, I've just compiled like 30 different career letters from the financial times Kickstarter rent, the runway medium all sorts of career letters that is done in public.And you can just study them Circle CI has a really, really good career ladder, by the way. And just study, like what they define to be the qualities of a software engineer, one versus two, versus a senior versus principal versus staff. You get to see the difference. There's more and more industry impact.There's more and more emphasis on communication. In fact, the more senior you go, it's the less technical elements are still a big part of it. But then you're also expected to be able to contribute on non technical elements, which I really. I want people to wake up to essentially even if you look at circle CII, which is one of the most technically rigorous companies out there something like 75% of their promotion criteria are essentially non-technical which people don't really realize.Like it's not something that you learn in bootcamp or in, your CS degree that, Hey, you should be good at communication or understanding how your technology fits into the broader business strategy. But that's something that people put on the career letter. And therefore you are incentivized to learn about that as you want to progress in your junior and senior path. Does that, I want to pause cause I've gone on for a bit does that help it? Yeah. Yeah, Robert Haritonov: [00:10:58] for sure. I'll have to. Search your your resources, swyx: [00:11:01] but I'll definitely check that out. By the way, talking with me is like this I always go I have a blog post of that, and that's a strategy to, you like straight up, like I'm someone making fun of myself, but think about what if you had that at work, right?What if you you had a conversation, but then you had a really well thought through written thing to back it up so you can send it to whoever you're talking to. Like people will just like you, you're not only sound smarter. I don't sound super smart right now because I haven't really been thinking about this topic recently but.You just sound more prepared like you've covered all your bases and like... the bit rate of trends of information transfer right now from me to you is not very high, right? Like it's just whatever I can think of. And I'm not very good on the wall, but while I'm writing, I can structure things, organize things, make links and follow up references and stuff like that.That's just really, really smart. Write things down and I think it's a really good skill of a senior developer. Yeah. Shawn, sorry, I'll Robert Haritonov: [00:11:53] stop you here. We've been swyx: [00:11:54] Hiked out. We have Robert Haritonov: [00:11:55] so many listeners here. There is all the questions and the ex chat as well. People do have some issues when they try to get on stage.So I suggest people also to ask the question in check, swyx: [00:12:07] And Shawn, the kitchen since there all the Robert Haritonov: [00:12:09] questions. Maybe let's live with one swyx: [00:12:11] question for the first time, Robert Haritonov: [00:12:12] Just to try covering water base as, yeah. There's just a swyx: [00:12:15] lot of Devin chatter here. People might have been with Q as first, Robert Haritonov: [00:12:19] like you.And swyx: [00:12:20] then there are questions. Yeah. And feel free to just ask stuff in and I can answer asynchronously on the text chat. 12:30 The Importance of Communication and How to Do it WellQuestioner: [00:12:34] Your previous answer really helps the transition  to this question.As far as I know, something super important to become a senior, our communication skills. Do you agree with this? I guess you do. If you do, what resources do you recommend and what tips do you have? The things that you wished you knew during the transition process, when you might've felt lost.swyx: [00:12:50] Oh, that's an interesting question. So of course I believe that communication skills are very important. In fact, it's probably one of the most common things that are in the career ladder. If you study them  so very important and I will also volunteer that. I don't think I'm very good at it.I'm decent. I, I don't fail my own evaluation, but I've seen people who are way better than me about it. So I think resources wise there's a lot about communication across cultures, which is something I think about a lot. One thing I can point you to is I think the lady bug podcast, I think a lady bug FM or something like that, they did a whole episode on communication skills, which I quite recommend the D they have some tips about just.Understanding how it comes across how you come across. And really having empathy for what the other person is thinking and feeling. A lot of the times we have to understand that we're not just, let's say you're doing a code review you and you're pointing out flaws in somebody's code.It doesn't reach them that you're trying to help. Unless you break down that barrier, that kid and remind them like, Hey, I'm on your side. You have to break, go past like the emotional  barrier of Hey, does this is this person a threat? Are they making fun of me? There's all sorts of things going on the other person's head.And you have to reassure them like, no, I'm really, I'm your partner. I'm here to help. And that's something that is, it is a skill as well. And particularly in some some cultures where. Sometimes the respect for authority is, can be very different. The the expectation of like your, the message that, that has received.If it, if you say something once, do they, is the responsibility on the recipient or on the deliverer to make sure that the message went through. These are all things where communication has led to real disasters before like planes crashing, because People thought that, the message was delivered and it wasn't.So I don't know. I don't like, this is a huge topic. I don't know if I've fully answered your question, but I think when in doubt, just write more whether it's like writing up your decision on, like, why you make a technical choice, they just write it in a comment, I think or just like your PR.One of my most popular interview blog posts when I was at Netlify was how we do feedback ladders.So I think if you do, if you look, if you Google, like Netlify code review or Netlify feedback ladders, you'll get this post where we actually have a system for encoding what we're trying to say, because it's when it, when you're in a, when you're in a cold, medium there's a difference between cold and hot mediums.When you're in a cold, medium, like a GitHub PR review, people can read a lot into, like, where do you put it? A period at the end of your sentence are you being passive aggressive right now or are you just, making a joke or are you, is there a sarcasm? Is there do you think this is a big deal and I should handle it right now? Or is this just a comment? Take it or leave it. There are all these little subtle nuances that you can skip. If you have a clear code that you communicate with your coworkers with. And I think the last point I'll make is for feedback reviews which I really like is preemptively review your own code. So that you save one round trip. So when you make a PR you just think about okay, what is this person going to say? I've worked with them enough. Let's like emulate them in my head and go like, all right, what are the typical comments that they would make and just anticipate them and then write your response.And just by the sheer act of doing that, people would really appreciate it. And they understand that you've addressed their concerns and now they can move on to you with the more important stuff that they sell them, get the chance to get to. So I there's a lot here, communication is a really deep topic.And I'm not the authority on that. Like I just think that people should practice it more and realize that it is as important to them as their coding skills. Questioner: No. Yeah. That makes a lot of sense. Thank you for your answer. Do you have any resources that you're looking at? I don't want it to be like a one way street.  Not me specifically. I'm trying to ask around as well, just to learn as much as possible. It has a communication resources. Just pop it in a discord channel. That's next to this room. That's a crowdsource. This thing. That sounds amazing, actually. Yes. Yes. On the same note you already answered this as well. How do you describe a senior? What should developers aim for mostly, if there's anything else you want to add and regarding the resources, how can we get your senior to junior coach?swyx: [00:16:37]  Oh yeah. So that's a chapter in the book. I can I will look at releasing I'll look at printing it out so that I can just release it for free in the channel. But essentially, yeah I, I wrote this, I wrote the, I wrote my book Linden, public.org. I wrote the whole thing just to address this answer of the principles, strategies, and tactics that I use to get to where I am, and also the behaviors that I observed in the people that I really admire.So I have about 1400 links for people that go down a lot of rabbit holes. Yeah, hopefully that helps. But I can read out, do I don't, do we have a lot of time left? I feel like we're, we might be a bit out of time. Cause we have, we can create, we can do Robert Haritonov: [00:17:18] like a microphone, 34 hours myself, but let's first go through the majority of general questions as an exit face. Yeah. So based on gone, sorry, I'll remove you from the audience so that people can ask questions. Thanks, CRS. Joining us for awhile. CRS, whatnot. And three eight, go ahead and ask your question.17:30 Prioritization, Batching and Pair Programming swyx: [00:17:36]   I guess they think that and answering questions for all your junior developers. How do you go about that? Yeah, it's a fair question. I think the vast majority of senior developers should be writing their own code still. There are more senior positions especially management as well as architects positions, where you might be writing a lot less code.But a lot of times you'll will be balancing between reviewing and mentoring others versus writing your own code and being an individual contributor. And that's a little bit challenging. But I think you should be able to find time like obviously mentoring and working with the team is very important.And then you should be able to figure it out. How to fit in your your individual work separately, on your own something I picked up from my ex boss, Sarah Drasner is that she actually batches her work. So if you look at her blog posts, CSS tricks, prioritization, just Google that she laid down this philosophy of basically batching this work, like individual work goes on Thursdays and maybe a bit of Fridays and then meetings are Mondays and Tuesdays, and she is coming at it from a management point of view.But I really think that it also applies to an individual contributor as senior dev, right? If you have a lot of sort of review work batch those meetings together and also try to upgrade your bandwidth again make it very, it's very easy to pair program. People don't do it. And th the every time you do it, both sides learn something about either the way you work, or learn a new trick in the editor.It's a very high bandwidth communication skill. I would recommend that batching and then pair programming.Robert Haritonov: [00:19:06] So have a role SKUs that I joined and then a super Shawn quick. Now it's there, there's some voice of community that's me as with you. So there's no big on nice push check, push. You brought up because it's constant sound from your diagnostics and they're all discussed definitely to not having to ask your question. 19:20 What can Seniors Do to Help Foster Juniors? Apprenticeships, Mentoring, Sponsorship and AllyshipQuestioner: [00:19:23] Okay. So my question is more coming from the other end. I'm a senior kind of more experienced developer and I'm wondering. Kind of what I can do to help people, or what are things senior does or not doing to help foster junior devs? Cause I don't, I want to know what I can do to make more people more diversity, like the industry, a better place to work in.Wow. Okay. This, so I thought there was this was a question about people already on your team, but you're still saying the industry as a whole. That's great. Questioner: [00:19:53] Yeah. I know. Like I can start with my team, but obviously one good safe, it's going to be a ripple effect.swyx: [00:20:01] So my direct answer is someone who changed.I changed careers at age 30, right? The right answer is more internships and apprenticeships for people with non-traditional backgrounds. We at tech companies have a lot of re entry routes for people for traditional degrees, like CS degrees. But then if you just went a different way and then came in to, to the tech industry later in life, you don't have those opportunities.And I think a lot of people, especially of, diverse backgrounds would benefit from that. So that's my immediate shout out. And my wishlist is if I could wave a wand and have every single company take in, two more. Interns or apprentices. I think that we do a lot better just because the main thing is to get people to experience, and after, six months, a year of apprenticing and interning under someone else, they will have a lot better of a resume to, to go job hunt. And that then they're off, they're they're off to the races.  I think the other thing I think is also opening up opportunities for people.So as someone who's a very plugged in and very capable. People will throw a lot of opportunities to you and you need to be aware of what you don't necessarily you, you could do in your sleep, but you don't necessarily have to do, and it doesn't have to be done right this second that you can actually hold off and just go - Hey and open up this opportunity for someone more junior on your team to let them do it and you can start supervising.So I hope that's not like too, I don't know. It's not like delegation. Yeah. More, so much as like mentoring, right? Because ultimately your success is you make another one of yourself. I always say the best way to be a 10 X developer is to teach everything, to 10 people around you.Rather than the individually 10 X and do everything yourself. So I hope that those are the immediate things that come to mind. Obviously, I think donating actually helps a lot, like your money goes a long way with free code camp. And and also getting your company to sponsor those those diverse organizations and hire make sure make sure you like the hiring pipeline is equally diverse.That I feel like  I feel like I'm saying obvious things, but how does that resonate when you think about your question? Questioner: No, that, that makes sense. Especially yeah, the letting go, the things like I know, as a know, sometimes it is hard to let go something where you're like, this would take me, very quickly this time, but the mentorship which takes, a little bit longer is way more beneficial to everyone in the long run.swyx: Yeah. Yeah, exactly, exactly. So I w I would call out, so some I actually forget who came up with this idea, I think was Lara Hogan. She defined a difference between sponsorship and mentorship and, or I think sponsorship in allyship as well. It's I feel like it's so weird for me to tell a woman this cause I'm not the expert on that myself.So I would recommend those resources as well. And I'm going to paste the list of diversity and tech organizations, which I've been really following and has been helping me learn a lot about this as well. Veni Kunche has a newsletter, which I encourage everybody here to sign up because she really has a balanced view, which I love which is okay, like we're not doing well.But she doesn't damn you for it. She just says, gives you a stern look and goes like you can do better in any way. Yeah. Yeah. We know. Vinnie crunchy of diversified tech. She has a great newsletter and if you want to, hire people of diverse backgrounds definitely go sponsor her.Awesome. Thank you so much. Thank you. 23:15 How to convince older devs to try new tech?Robert Haritonov: [00:23:16] know, let me try it on a museum. Supertramp can you Questioner: [00:23:21] ask your question? Yeah.  Okay, great. Hey Shawn. I had a question where essentially I don't enjoy working where I am right now.Mostly due to the lack of kind of the learning opportunities. Primarily my team, they really enjoy a very old version of PHP and I'm trying to convince them that there is some proof in the success of modern react or JavaScript or modern frameworks. I just wanted to ask if, did you have any tips to convince old PHP data's or old kind of web developers that it's okay to give some jobs could swyx: [00:23:57] Wow. Hmm. Why are they? I T I have to dig into that further. Why are they opposed to adding new frameworks and stuff? What is their stated reason. Questioner: [00:24:07] A lot of our products are very public facing. So they fear that if we make any kind of change that might affect like client facing products, they worry that it might break. So they just say, all right, we see what you're trying to do here. We want to, we understand that you want to improve our code, but it's currently working. So why do we need to fix it? swyx: [00:24:28] I have a lot of sympathy with the don't fix one in Brooklyn thing. I think that's actually something that people get to after a lot of pain.They're not necessarily wrong. But obviously what you're trying to do is also improve the user experience. And that's something that they should be prioritizing as well. Are they optimizing for their own comfort or are they really,  making a technical trade off.Here. So it's not clear to me, obviously I'm not in your situation. And I can't really speak for them. But ultimately I think there's only so much you can do as an engineer. That's probably junior to them. You make your case and you make a S a strong, where you can do is for example, like a proof of concept.I'll give you one example, the a friend of mine, Zach Argyle  he actually worked at Pinterest where he was trying to advocate really strongly for a progressive web app. And everyone at Pinterest was just like, no, like it's a waste of time, whatever. And he was ignored for two years. And the way he got through was he did a hackathon where he just built a basic Pinterest PWA and shown the really high.And, metrics that you can get in performance as a PWA, directly to the CEO and that impressed them so much that they converted themselves to a PWA. So sometimes you have to do a stunt like that to get through to people. But ultimately you cannot convince someone who doesn't want to be convinced.It just doesn't have an open mind. And I was already decided that their answer is right. And in that sense, you got to look out for yourself, right? So there are plenty of other developer companies will love to hire someone like you who's passionate about modern technology and no judgment on them.Right? Like they're B they probably, they think they know what's best. But you should also figure out what's best for you.Questioner: [00:26:05] Thank you. I like I totally. Yeah I'm totally happy to hear that. There are potential solutions for like more and water like solutions for  the problems that I'm facing at my convenience facing. But if he has, like, whenever I try to present them, they Shut me off because of the fact that I'm like more of a junior developerswyx: [00:26:23] You have to earn it, right? There's a given get here. Like they have to make room for you. And if they're not the they're making a mistake but then also you shouldn't come in and just have them listen, like demand that they listen to you have to earn it as well. Maybe also look for small projects, too side projects that that they could split off to let you experiment. That don't matter as much to them. Sometimes you can do a lot of this through internal tooling, right? What do your sales or marketing or product managers need, build that for them and see that, see the benefits internally before rolling it out externally, right? These are all things that I've actually done because people weren't letting me do it. People don't let you through the front door, go to the side, go on the back figure it out. That's cool. Yeah, Questioner: [00:27:02] I'm actually only point of that topic. I did design like a next JS version of a, so what we did here is generate like what forms for people to put their data.And then we we do lead generation based off that data. And I did take that initiative and create a kind of like a front end, like next JS project. But then they looked at it and they thought that this was cool, but then they didn't think it was scalable.And they, I tried to have like more of a conversation with them about that, but then they were well, yeah, we've been doing like HP or he needs it. He's older, like pretty much for a longer time. So it just felt like. At that point in, in the one that I was presenting the project I should also say that they were they're currently sponsoring me.I'm from Canada, I'm trying to like, I'm currently working in the UK. So at that point in time, I was thinking like, this is I think the third or fourth time, they disregarded my kind of my attempt, to improve the, let's just say the initial code base. swyx: [00:28:02] I appreciate your Tufts situation supertramp and happy to chat with you. Async as well on the discord. Yeah, of course. Thank you. Robert Haritonov: [00:28:09] All right. So if anyone else wants to ask a question, raise your hand. We'll set the stage. Meanwhile, Shawn, you can just cram maybe swyx: [00:28:16] through your questions Robert Haritonov: [00:28:17] in the  light. Maybe you get a big swyx: [00:28:21] face on that.If people were trying to hire a super Supertramp andIt's a good idea to, yeah. Honestly, I find a lot of people changing jobs at conferences. It's a really nice thing to see and good for labor mobility, but maybe not so good for employers sending people to conferences. I don't know, but if you're confident in your employer brand, then you should be a net hire from conferences.And if you're not, then it should not be so good for you. 28:45 Nontraditional background. How to convince people to let you through the door? Networking and Personal Content Marketing.questioner: Hey Lucy. Lucia. Yeah, Lucy was here. I don't know. So I'm actually a developer who came from a very non-traditional background. And they did a bootcamp to get into our changed careers about two years ago now. So I did a four-month bootcamp and I managed to secure my first job, which was amazing. When I was transitioning from my first job to my second job, the issue I was encountering was I wasn't even really being given the chance to get through the door for the interview.The few interviews I did get, I found that if I got to that stage, I was able to convince them that I was a good candidate. I got a couple of offers, which was amazing. So my question was like, how do you convince people to let you through the door? Just from your CV, if you're forming a more non-traditional background.Wow. Yeah, that's a challenging one and there are a number of ways, essentially networking is the one that comes to mind, it's my friend Gergely Orosz wrote a... Little, I think it's a free book called the tech resume inside out maybe. I'm not exactly sure. What his book is.I want it, someone, let me look it up. But he actually had this, he had he'd look at the numbers, and a lot of people don't get through the first screen, which is the resume review screen. Cause people take a look at your resume for 30 seconds. And it's a very inefficient  transmission format.Cause you're supposed to serialize your experience and your potential down to a single piece of paper. And you hope that they have the correct deserialization algorithm to, to do that and figure out that Hey, you're someone that they should be talking to. So I really liked the other way of networking within the company and getting a warm introduction so that they not only skip you to like the next step where you actually do a proper interview, a phone screen. They also give you a few hints as to what the company values and what you could be doing there because ultimately you want to have a good answer for like, why are you interested in working with us?And that's something that you really get from like understanding the company really well and talking to people internally within the company. So that's one thing, I it's, I think it's a very common thing to say Hey if I buy your coffee we we let me pick your brain. Don't use those exact words because picking your brain is extremely overrated in 2021, but you could go I'm interested in applying I, and I'd love to learn more about your day to day stuff like that. It's just a very genuine people know what you're trying to do.And we've all been in your shoes. That'd be not all, but we appreciate that. You're trying to get somewhere and I think people really appreciate the effort that you put in to even like a cold email, right? To say Hey, we've never met, but like you work at this company, I really interested in it.Do you have 15 minutes to chat? Most people will say yes. And I think that's a good way to get going. If we're doing this in person, I would actually not recommend coffee. I'd recommend a walk in the park which is something I used to do in New York. Okay. The other thing I really like is the permissionless application, right? You're applying through a CV and, you may have a portfolio if you're a more design and front end oriented person. But you can also do Like a breakdown. So some, a story I really liked was this woman who was very interested in working on marketing for Airbnb and realize that, she was wanting to show some in the middle East.And she realized that the Airbnb didn't really have an middle Eastern presence. So she mocked up a fake site. That just looked like Airbnb and just demonstrated her potential as someone who could do that. She worked in marketing, but you could equally work, do that for engineering, right?Like just do a simple CLO and talk about a specific algorithm that that you could work on. A friend of mine from my bootcamp actually broke down the collaborative filtering algorithm of Spotify and she got an interview there. Because it, it went viral.So like people were Spotify would definitely noticed. But it just shows a level of commitment and interest that most people don't have because you're not praying. It's the industry term is called spraying and praying, like anything that you think that you can do to show that you genuinely have interest, and you're not just like throwing your resume every which way.I think that actually just puts you in front of the line. So that's my quick take. Yeah. Ultimately, so ultimately you won't start this way, but ultimately what you want to get to is you want to be, you want to have your domain and your sort of expertise. So well-marketed that people come to you, right?Whatever you're particularly interested in winter where there's animation or accessibility, or responsive design, whatever it is, you want to be such an authority on that. And people come to you for things that you're interested in. And then the hiring conversation becomes very different.It's more about whether they're a fit for your interests whether as compared to, can you contort yourself to something that they need right now, which is at the end of the day, like if you apply to the company in the end, they're just not hiring. You're not getting in the middle of what so it's really dependent on those things, but hopefully I've given you some ideas here.Yeah. That actually has been really helpful because it actually talks with. My experience in that, one of the offers that I got was specifically because I've been to around them meetup talk and messaged someone who'd been talking and was basically saying saying things like I'm struggling to, to get people to listen to me, but I feel like I'm a really good candidate.Yeah. And then I just struck up a conversation with him online reading 10 and from that I then got an interview which then led to an offer which was awesome. But yeah, I actually hadn't really thought about it in that way, but actually yet it really does make sense. What we're really doing here for those interested is we're doing personal content marketing is the same thing that companies are doing for their brands and their products.And we can do it on a personal level. Cool. Lucy, thanks, sir. That's a great question.  Go ahead and answer your question.Just remember to push book. 34:00 How do you make technical decisions as a senior and avoid getting stuck? Innovation Tokens, Action Produces Information, Pay for AdviceQuestioner: [00:34:07] Hi I'm a big fan of your writing in your blog, Shawn, thank you. What I wanted to ask is related to in a situation where you're given a bit more responsibility as a senior, and you have to start making decisions, especially technical ones regarding the stack regarding specific things you need to accomplish for a client or a project.And how do you maybe are how do you not get stuck in that, in the, over analyzing the specific decision, not just to not make a mistake for your client or for your product, but also not bother your, or add overhead to your teammates as well and your colleagues in. To not to create issues later on, on a project, sometimes you get stuck in the decisions so much that you feel like you can move on. I dunno if there's something that all the time swyx: [00:34:57] Are you familiar with the concept of innovation tokens? And no, actually kind of her. Yeah. I think this camp I'm not sure where this idea came from, but people who'd go Google the source, but essentially the idea is to minimize risks but to allow some innovation, right?The tech stack that you work on work with for a client it should be something that you're mostly familiar with and you're confident that you can ship in time and on budget. But you allow yourself, to innovate or try new things in one or two areas of your tech stack, and that's your sort of innovation credit or innovation budget.And yeah, so to me, that's where you want to get to that may not necessarily be where you are right now. First job is to have a set of technologies, which are. Which the whole team is confident in, right? To me, I call this like a minimum spanning set of technologies that like, you can pretty much string together to accomplish any tasks.They may not be the best tool for the job. They might, wanna be the trendiest tool, but they do the job. And then you allow yourself in every project to try a new piece of technology that you want to include in your tech stack and try it out on a real project.So that's what comes to mind for now, I think obviously where I don't really understand why you're paralyzed. I think that there's something deeper there. Can you tell me more about the analysis paralysis or I forget what you call it, like the stalled decision.Questioner: Yeah, I guess it was not a, it's not just a specific  situation I'm talking about. Maybe,  Maybe does happen when you you were given more responsibility. I do not, you don't know how to approach it. It's not necessarily choosing a JavaScript framework, but making also bigger decision on on different elements of how the team is supposed to work together either technically or not. And sometimes it does happen. I don't have I don't want to go into very specific because there's multiple cases where it does happen. Maybe it's personal to me and just wanted to hear about maybe similar situation and how other people dealt with it. And you were, I mean, perfect example.swyx: [00:36:43] Yeah. If anyone has ideas let's cross source this as well. Cause I, I feel like I don't really it's so broad this question and it can go so many different ways.  To me, it's something that you have to agree on it as a team. If you have a.I guess if you're in the position of leadership, then obviously you're in charge of proposing and helping, having to serve as a tie breaker. If you have a client, sometimes they have a very strong opinion and you can present them, twice HSB and then let them choose. These are all really nice ways to basically offload the decision.Ultimately I think a lot of things are a lot of decisions are reversible, right? If you think about type one and type two decisions which is a Jeff Bezos type of framework, I'm trying to understand if your decision is reversible or not. And if it is then just doesn't matter which one you try it out, just try it, try something out for a few weeks.And then if you don't, if it's not going the way you think it is, then you can go try the other thing. Ultimately the way I approach any sort of analysis paralysis now is this idea which I got from the sun newsletter called common cog. It's called action produces information, right? If you've done any, if you've done all your research, you've asked everyone and you're still stuck between two options or three options.Then no amount of further studying and worrying and hand-wringing is going to help you. You need to take action, whether it is commitment to one thing. And then you realize that no, actually everyone did the other thing. Or it is taking ticket for this step of running a small proof of concept or asking for more mentorship somewhere within your organization or just your, an external mentors.These are all like, you can even go as far as like paying someone for their advice, right? These are, this is a super, highly underrated thing in the company environments. Like people are available for hire, like max Storybird is available for hire. If you want any react to architecture advice, he's not cheap.But he's available. And so what other people so yeah, that's  as much as I get, I can go I don't have much to work with on the question. Robert Haritonov: [00:38:35] That was very, very helpful actually. swyx: [00:38:37] From my perspective. So, thanks. Yeah. Thank you. It's given me something to think about as well, and hopefully I can write a better answer in the future. All right. We have a couple other questions and I have a few more minutes, so let's get this going. Pokey juice from Poland. I'm guessing.  I'm inviting them. I'm going to drop by the way for those still in the room, I'm going to drop the chapter for junior engineer versus CD engineer.And we can have a better discussion there because I feel like I didn't really do enough prep for that. Hey pokey.  Hello. So I would like to address the previous in person or in, at talk question, and because I had a very similar situation that I'm like slowly progressing to higher roles.And it sounds so overly stressful to decide yeah. And good to make the decisions. And the thing that helped me that, which I have recently found out is that unless you are in a company, which has two people and you are the most experienced one in that company, then there's always slept the bigger fish in the company, more experienced.And you can ask them for for help or you can ask older people who maybe are not to give them the seminar. But to have more expertise in certain fields, or they haven't been working with certain technology and you can ask them how we do work for them. Yeah. So I have no question.This one. No. That's great. Thank you for chiming in yeah, it's a challenging position to be in and that's why you've made more money. Hopefully they're paying you for all this stress that you're taking.  Great. All right.  I am, by the way, I'm extracting my junior to senior chapter so we can invite more questions.I see a lot of questions also piling up in the text chat and I will drop my PDF in there so people can talk more stuff.  Okay. All right. So yeah, I've just posted that in the room. What else can I say about this? 40:30 Fall in Love with the Problem, Not the SolutionSomething I really want to emphasize, and I've been really trying to find the best words for this which is essentially that we should. Fall in love with the problem rather than the solution.And I think that's juniors may be defined, maybe falling over themselves to define themselves by the solution, right? Like I'm a react developer. Whereas seniors have probably been through a few of these cycles where like they've had, they've been super into something else before, and then they had to change frameworks and get changed frameworks again.And by the time you get to your second or third framework, you're just like, all right, this is another tool to solve the same problem. And ultimately the thing that lasts longer than the solution itself is the problem, because that will never go away. It will. It w it will just have different solutions that come along and with, and solve it with different trade-offs.So I hope that's a message that I want to get across that seniors. Basically collect patterns and problems and juniors collect solutions. And I want to guide people towards understanding problems deeply. And that's a lot of the way that, that the way that I structured my thinking and learning and speaking as well.So the talk that I'm going to give later in about 30 minutes is focused on what problems does react solve, and what can we learn that will outlast react?  I think that's, that's one way to go from junior to senior. Okay. I don't see any other questions I do have okay. Robert Haritonov: [00:41:55] All right.I just want more,even the act of discussion I'll be full if there's a topic. Thank you so much for everyone. Who's come by. Thanks. Yep. Hey Darren. Hello. 42:00 Can you still be a fullstack engineer?Questioner:  Hey, how are you doing? I just asked the question in the discussion, but I thought maybe you could ask her near him suggested that. So myself, I'm a full stack engineer, but.And the more I look at these big companies. Now you see all the postings are from our backend or our front end and not really CFO's stacks. I was just wondering your opinion on maybe focusing on one of those things that you're more well versed in, or is it still that it's supposed to engineer still an achievable thing to work towards these days?swyx: Wow. Ah, great question. There are definitely people hiring full stack developers. You just got to find them. I don't know where you're getting this impression that people aren't hiring full stack. I feel like they're, it's actually a lot, it's a meme in the U S where they, once someone to do everything.I would say, yeah, I'd say it's definitely achievable. I just think it's not as realistic at some level of scale because ultimately there's, this is meme where it's like this. Horse where either your joint you're during the front end really well. And then the back end is like a really crappy children's drawing or are you drawing the back really well in the front is just like this really  really childish imitation version.There's some trade-off to be made. And ideally there's some level of specialization that you have where you can actually, market your skills in in, in a good way to and it probably involves specialization as well is what I'm trying to say. So full-stack is great for people who want generalists.And if you want to, for example, be a startup founder or an indie hacker yourself that's definitely something to pursue and to be well rounded. But if you want to be a specialist, a consultant an industry authority, you probably should specialize. And those two are not at odds, but you probably want to market yourself in some, in based on what you're trying to tell to your clients and your employers right now.Great. Thank you very much. Yeah, I've heard the thoughts on like specialization versus generalization. There's a separate chapter of mine but essentially the TLDR is that everyone is a generalist in some way. And when in doubt, you should be specializing because that's where you learn how to be an expert and learning to be an expert and crossing that sort of learning gap in itself is a skill.And then also marketing it's way easier to market yourself. So I have a friend who's called, who is Cory house. He's a reacts consultant. He specializes in transitioning big companies mostly from angular to react. But that's not his only interest. He's got a lot of other interests and he actually is a pretty full stack developer just based on a history, but he chooses to market himself as a reactive Oliver.And he, and when he did that, his consulting practice 15  in one year, And in terms of inbound inquiries, you can go look up his his tweet channel he'll he'll back that up.  And that's just because marketing a response to niches, it's like a specialization. If you see any expert in something people believe in more rather than I can do anything.Forget. Thanks very much for that. Yeah. Great questions everyone. I see a lot more in in the chat and I have to go through and answer them. But hopefully this is useful and this is fine. I had no idea what to expect a new media. Thanks all Shawn for drink. Hopefully we'll be able to replace it Robert Haritonov: [00:45:11] again.Yeah, the topic is really, really in demand. You had a really solid conference level audience and just this small room for joining these for all your insights. swyx: [00:45:20] So yeah, Robert Haritonov: [00:45:21] hopefully you'll be able to reply there. Any questions and shout whenever you have time. swyx: [00:45:27] 30 minutes. I'm excited.It's is yeah, I love the sock. All right. Thanks for having me, Robert. And thanks everyone for coming. Bye. See you soon. Robert Haritonov: [00:45:34] Cheers. swyx: [00:45:35] Bye.

Take a journey with Scott Hanselman, Wes Bos, Sarah Drasner, Troy Hunt, and Kent C. Dodds as they answer questions about getting from Junior to Senior!

Take a journey with Scott Hanselman, Wes Bos, Sarah Drasner, Troy Hunt, and Kent C. Dodds as they answer questions about getting from Junior to Senior!

The wonderful folks behind CSS-Tricks (maybe you’ve heard of it?) face off in our much beloved don’t-call-it-jeopardy game show. Can you out smart our intrepid contestants? Play along while you listen (or watch). It’s JS Danger time, y’all!

Take a journey with Scott Hanselman, Wes Bos, Sarah Drasner, Troy Hunt, and Kent C. Dodds as they answer questions about getting from Junior to Senior!

On this week's episode, Steph and Chris revisit their discussion about testing rack rewrite redirect logic, mystery guests, DNS configuration, and trying very hard to not be too dogmatic. Steph describes her recent work trying to debug failing deploys with Concourse, Kubernetes, and Google Cloud while touching on blue-green deployment and secrets management. Finally, Chris talks about porting a svelte project to typescript and the trade-offs of adding Types upfront vs types after the fact, and the parallels to testing and TDD. 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 Solo Stove (https://www.solostove.com/) rack_rewrite (https://github.com/jtrupiano/rack-rewrite) Climate Control (https://github.com/thoughtbot/climate_control) The Art of Code Comments talk by Sarah Drasner (https://www.youtube.com/watch?v=yhF7OmuIILc) Concourse (https://concourse-ci.org/) Kubernetes (https://kubernetes.io/) Google Cloud Platform (https://cloud.google.com/) git-crypt (https://github.com/AGWA/git-crypt) Rails encrypted secrets (https://blog.engineyard.com/encrypted-rails-secrets-on-rails-5.1) Tailwind CSS (https://tailwindcss.com/) InertiaJS (https://inertiajs.com/) Svelte (https://svelte.dev/) Rich Harris and Evan You on Undefined podcast (https://undefined.fm/radio/vue-vs-svelte-with-evan-you-and-rich-harris) ts-routes gem (https://github.com/bitjourney/ts_routes-rails) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

Vue Remote Conf 2020 October 6th to 9th The Views on Vue panel talks with Erik Hanchett, prolific VueJS educator, about his new Vue 360 course and other educational resources he provides to the VueJS comunity. We also talk about personal branding and how to get started building your own brand. Panel Steve Edwards Lindsay Wardell Guest Erik Hanchett Sponsors Cloudways | Use promo code "DEVCHAT" for 30% off for 3 months on all plans "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! Links Create Awesome Vue.js Apps With Nuxt.js witk Erik Vue.js in Action by Erik Hanchett Introduction to Vue.js with Sarah Drasner Ember.js Cookbook Picks Erik Hanchett: Follow Erik on Twitter > @ErikCH, YouTube, Blog, Vue 360 course It Doesn't Have to Be Crazy at Work | Basecamp Lindsay Wardell: Follow Lindsay on Twitter > @Yagaboosh Wayside School Beneath the Cloud of Doom by Louis Sachar What is Meet Now and how do I use it in Skype? Steve Edwards: Follow Steve on Twitter > @wonder95 Uptown Passover Follow Views on Vue on Twitter > @viewsonvue

Vue Remote Conf 2020 October 6th to 9th The Views on Vue panel talks with Erik Hanchett, prolific VueJS educator, about his new Vue 360 course and other educational resources he provides to the VueJS comunity. We also talk about personal branding and how to get started building your own brand. Panel Steve Edwards Lindsay Wardell Guest Erik Hanchett Sponsors Cloudways | Use promo code "DEVCHAT" for 30% off for 3 months on all plans "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! Links Create Awesome Vue.js Apps With Nuxt.js witk Erik Vue.js in Action by Erik Hanchett Introduction to Vue.js with Sarah Drasner Ember.js Cookbook Picks Erik Hanchett: Follow Erik on Twitter > @ErikCH, YouTube, Blog, Vue 360 course It Doesn't Have to Be Crazy at Work | Basecamp Lindsay Wardell: Follow Lindsay on Twitter > @Yagaboosh Wayside School Beneath the Cloud of Doom by Louis Sachar What is Meet Now and how do I use it in Skype? Steve Edwards: Follow Steve on Twitter > @wonder95 Uptown Passover Follow Views on Vue on Twitter > @viewsonvue

We’ve all been there, a project starts off simple, but quickly becomes more complex. In this episode, we are joined by Sarah Drasner to talk with us about how to deal with complex codebases and systems. Guests: Sarah Drasner - @sarah_edo Panelists: Ryan Burgess - @burgessdryan Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Stacy London - @stacylondoner Picks: Sarah Drasner - Handmaid’s Tale Ryan Burgess - Don’t F**K with Cats Ryan Burgess - Spotify: Failed #SquadGoals Jem Young - The Last Dance Jem Young - On Being a Senior Engineer Ryan Anklam - Effective TypeScript Ryan Anklam - Powerblock weight set Stacy London - Leaving the Grid by Ital Tek Stacy London - Video for Leaving the Grid by Ruben Fro Stacy London - Under the Table by Fiona Apple

In this episode, we are joined by Sarah Drasner and Gift Egwuenu to talk with us about the popular JavaScript framework, VueJS. Guests: Sarah Drasner - @sarah_edo Gift Egwuenu - @lauragift21 Panelists: Ryan Burgess - @burgessdryan Augustus Yuan - @augburto Jem Young - @JemYoung Stacy London - @stacylondoner Picks: Sarah Drasner - Greensock v3 Gift Egwuenu - Harry Potter and the Escape from Gringotts Ride Gift Egwuenu - Nigerian Playlist Ryan Burgess - Mike Giant podcast Ryan Burgess - Tombow Dual Brush pens Augustus Yuan - React adaptive hooks Augustus Yuan - Trader Joe’s Cauliflower Ravioli Jem Young - Buffet Lines Jem Young - Hap and Leonard Stacy London - Yearning for the Infinite - Max Cooper Stacy London - Immerse - Alex Banks

On this episode of Views on Vue the panelists discuss their preferences for their development environments and tools. They begin with their preferences for text editor, font, and theme in their Vue development environments. All three currently use Visual Studio Code as their main text editor. Ari Clark switched to VS Code from Atom because she prefers the support that it has for Vue and Ben Hong switched from Sublime. Ben prefers the night owl theme and the operator mono font. On the other hand, Ari prefers the one dark pro theme for its syntax highlighting and prefers dank mono as her font. The Views on Vue panelists then go on to discuss their preferences on using the terminal. They weigh the pros and cons of using the integrated terminal and when they turn to other shells. The other potential shells that the Vue panelists discuss are Bash, Zsh, and Fish. The panelists focus on the speed and performance of the shells, and make an important note that not all shell commands are valid on other shells and the user will have to be familiar with the shell they are using. The Vue experts discuss whether they use the command line interface (CLI) or VS Code version control to manage their git version control. The panelists then weigh the pros and cons of different terminal shells they like to use. The panelists also briefly discuss how open they are to changing their development environment setup.  The topic then shifts to extensions for VS Code. The Views on Vue podcasters mention their preferences for a bracket colorizer, extension packs, code snippets and other tools. They talk specifically about the following extensions: Vue VS Code Extension Pack and Vue VS Code Snippets by Sarah Drasner, and Vetur created by Pine Wu, the latter of which the panelists identify as a quintessential extension for writing Vue. They discuss the merits of code snippet extensions as reusable code and creating them in VS Code.  They also discuss some of the different types of snippets that exist and how to use them. The Views on Vue panelists discuss ways to enforce best practices in addition to code snippets. They talk about using code generators like Hygen to automatically fill out the template for specific types of files. They share that creating unit tests helps to ensure best practices and that the code works as intended, as well as the differences between unit tests and end to end tests. They go over the strengths of an end to end testing tool called cypress. Tools like Husky or Yorkie allow you to add pre commit hooks to the package.json file that will automatically manage all the linting for a project.  Finally the panelists share their preferences browser tooling for Vue projects in addition to browser developer tools and their browsers of choice. Ari says that she prefers the previous version (version 4) of Vue devtools than the current version (version 5) and her reasons why. Chris Fritz shares that he likes Vimium for setting up quick navigation and Ben shares that he likes to use Keyboard Maestro. Panelists Ben Hong  Ari Clark  Chris Fritz Sponsors Tidelift Sentry.io use code “devchat” for 2 months free React Round Up  Elixir Mix Links Atom  Sublime Vue VS Code Extension Pack by Sarah Drasner Vetur by Pine wu  Vue VS Code Snippets by Sarah Drasner  Hygen  Cypress  VoV 007: Testing Vue.js with Cypress with Gleb Bahmutov Husky Vimium Keyboard Maestro Vue devtools Picks Ari Clark Gris  Ben Hong Ralph Breaks the Internet Chris Fritz Spiderman: Into The Spiderverse Children of Ruin

On this episode of Views on Vue the panelists discuss their preferences for their development environments and tools. They begin with their preferences for text editor, font, and theme in their Vue development environments. All three currently use Visual Studio Code as their main text editor. Ari Clark switched to VS Code from Atom because she prefers the support that it has for Vue and Ben Hong switched from Sublime. Ben prefers the night owl theme and the operator mono font. On the other hand, Ari prefers the one dark pro theme for its syntax highlighting and prefers dank mono as her font. The Views on Vue panelists then go on to discuss their preferences on using the terminal. They weigh the pros and cons of using the integrated terminal and when they turn to other shells. The other potential shells that the Vue panelists discuss are Bash, Zsh, and Fish. The panelists focus on the speed and performance of the shells, and make an important note that not all shell commands are valid on other shells and the user will have to be familiar with the shell they are using. The Vue experts discuss whether they use the command line interface (CLI) or VS Code version control to manage their git version control. The panelists then weigh the pros and cons of different terminal shells they like to use. The panelists also briefly discuss how open they are to changing their development environment setup.  The topic then shifts to extensions for VS Code. The Views on Vue podcasters mention their preferences for a bracket colorizer, extension packs, code snippets and other tools. They talk specifically about the following extensions: Vue VS Code Extension Pack and Vue VS Code Snippets by Sarah Drasner, and Vetur created by Pine Wu, the latter of which the panelists identify as a quintessential extension for writing Vue. They discuss the merits of code snippet extensions as reusable code and creating them in VS Code.  They also discuss some of the different types of snippets that exist and how to use them. The Views on Vue panelists discuss ways to enforce best practices in addition to code snippets. They talk about using code generators like Hygen to automatically fill out the template for specific types of files. They share that creating unit tests helps to ensure best practices and that the code works as intended, as well as the differences between unit tests and end to end tests. They go over the strengths of an end to end testing tool called cypress. Tools like Husky or Yorkie allow you to add pre commit hooks to the package.json file that will automatically manage all the linting for a project.  Finally the panelists share their preferences browser tooling for Vue projects in addition to browser developer tools and their browsers of choice. Ari says that she prefers the previous version (version 4) of Vue devtools than the current version (version 5) and her reasons why. Chris Fritz shares that he likes Vimium for setting up quick navigation and Ben shares that he likes to use Keyboard Maestro. Panelists Ben Hong  Ari Clark  Chris Fritz Sponsors Tidelift Sentry.io use code “devchat” for 2 months free React Round Up  Elixir Mix Links Atom  Sublime Vue VS Code Extension Pack by Sarah Drasner Vetur by Pine wu  Vue VS Code Snippets by Sarah Drasner  Hygen  Cypress  VoV 007: Testing Vue.js with Cypress with Gleb Bahmutov Husky Vimium Keyboard Maestro Vue devtools Picks Ari Clark Gris  Ben Hong Ralph Breaks the Internet Chris Fritz Spiderman: Into The Spiderverse Children of Ruin

Quick show notes Our Guest: Laurie Barth What she'd like for you to see: Laurie's Blog | @laurieontech | Laurie's Egghead Tutorials Her JAMstack Jams: Gatsby Her musical Jam: The Taylor Swift Lover Album | Heather's the Musical soundtrack Other Tech mentioned Jekyll Netlify Transcript Bryan Robinson 0:30 Laurie, welcome to the show. I appreciate you taking the time to talk with us today. Laurie Barth 0:33 Yeah, absolutely happy to be here. Bryan Robinson 0:35 Cool. So So I know that about you, but go ahead and tell the audience who you are what you do for work what you do for fun, that sort of thing. Laurie Barth 0:42 Yeah, so I'm Laurie. I am a software engineer for a company called 10 Miles Squared Technologies in the DC metro area. And we're a small consultancy, so I kind of do whatever is asked of me. And then as part of that role and a little bit, because I enjoyed doing it, I convinced them that, you know, it was okay for me to do it at work as well. I do technical blogging and speaking and kind of community outreach interaction stuff. Bryan Robinson 1:11 Stuff. I was like a good good stuff. Yeah, yeah. Laurie Barth 1:14 Yeah. Like Egghead videos and contributing to some other publications. And if you hear a little jingling in the backg.round, that is our brand new puppy Avett, who is being a bit of a terror right now as she gets used to .. Oh, she just came up right by the side me. Hi, sweetheart. As we get used to our new house, Bryan Robinson 1:32 well, I have a 12 year old cat on my desk right now. So all pets are welcome. Laurie Barth 1:37 Yes, this is the PETjam podcast. Bryan Robinson 1:40 So cool. So what was kind of your entry point into this idea of the jam stack or static sites or whatever you like to call it? Laurie Barth 1:47 I blame Jennifer Wadella. And for those who don't know her, she is the founder of KCWiT and kind of a badass Angular JavaScript front end Dev. And she, I talked to her about, you know, maybe making a personal site, she had a really great one. And she said, here's my code for my Jekyll site like lift, whatever you need, make your own. And I did. And then she transitioned over to Gatsby and kind of spoke the gospel. And I was like, Okay, let me give that a try. And so from then on, I was like, this is the perfect kind of thing for my site. And and that's, that's kind of where I got into the JAMstack worlds because I wanted to be able to throw something up pretty quickly that was going to be performant that was going to have, you know, all kinds of nice dynamic behaviors. But but it didn't need to have all of this full back end content, as it were, Bryan Robinson 2:42 Sure, now you're a software engineer, so you're not necessarily afraid of the back end. So what what kind of draws you to something that doesn't need a back end? Laurie Barth 2:50 I don't have to do the setup of like a bunch of different components, getting deployed into the cloud and deal with like, HTTP back and forth. And all those things like, it's great. And I am do it all the time when it's necessary. But if it isn't necessary, why add all that bulk and nonsense? Bryan Robinson 3:07 Sure. And as a front end engineer, I definitely consider that nonsense in a lot of ways Laurie Barth 3:13 And don't get me wrong. I mean, I, I started in the Java back-end world. That was kind of my bread and butter. And so I've done Python, and I've done PHP, and I've done a bunch of different things. And they have their use cases. And they're incredibly important and incredibly powerful. But if all I'm doing is serving stuff that can exist in markdown, then there's absolutely no reason I need to build myself an API. Bryan Robinson 3:37 Definitely, definitely. And did you have any experience with markdown beforehand? Did you use it like in GitHub or what have you? Laurie Barth 3:44 Yeah, no, in fact, a lot of my site is in YAML. Bryan Robinson 3:49 Yeah, I didn't have a lot of experience. In fact, I looked at and I said, Man, I hate this markdown thing that like a couple of my friends we're talking about and then everything's written and markdown for me now. So... Laurie Barth 3:58 yeah, yeah, I I've gotten really used to it for formatting articles for Dev.to. But I still have not transitioned my site over. Because I'm not actually hosting that much in terms of content, I have kind of a YAML file for my speaking stuff, a YAML file for my Egghead lessons, a YAAML file for my blogs, and then I'm going to make a separate YAML file that's going to be like, external contributor publications, like CSS tricks, and that kind of stuff Bryan Robinson 4:29 Nice. So are you using the JAMStack at all professionally? Or is it all just these personal sites that you've kind of been doing? Laurie Barth 4:36 Um, I've had not necessarily JAM... I guess it's sort of qualifies. I've done some headless CMS stuff, which I think is kind of like, it's using the JAMstack front end and pretending like it doesn't have a back end in a lot of cases even though it does. So little, that's a little bit different. But I kind of think of in the same world, and the other thing I have done is some kind of the gym sack stuff with with an occasional, you know, lambda thrown in there or whatever. That's more. That's more just a few functions to round stuff out. I don't know. I mean, I'm sure you saw it as @sarah_edo's. Or Why do I always say that; Sarah Drasner's write up on kind of an e commerce site where basically she was just using a couple functions to provide that which was great. Bryan Robinson 5:27 Yeah, I'm super inside. I haven't had chance to do that sort of heavy lifting in lambda functions. But I want I want to make a store just from that tutorial. So Laurie Barth 5:36 right, yeah, there's a lot of power there, though. I joked when I was reading through it, and I just joked on Twitter that I'm just going to read a blog post where I explain what the heck the difference between Nuxt Next and Nest is. Because clearly, I know so well, and never get confused. When I see those million identically named things referenced. Bryan Robinson 5:55 I've never once been confused by that. Never one No, no. Laurie Barth 5:59 Definitely. Bryan Robinson 6:00 So so with with that kind of your you got a little bit in the cat professionals that you're using. But have you found that there's been any bleed over from the experiments and the personal site into the way that you do kind of more traditional software engineering? Laurie Barth 6:13 Oh, no question. Um, I mean, for one, the ease of deployment with things like Netlify and Firebase and all of that has a lot of use for our clients in certain cases, especially when they're trying to throw things up quickly, and be able to deploy them kind of consistently. And by themselves without a lot of engineering knowledge, those tools are really fabulous. Laurie Barth 6:38 And a lot of the, the way things are built in the JAMstack, and the fact that you're focused on kind of an insane level of separation of concerns, just because it's it's YAML; it's marked down. A lot of that architecture plays in and JAMstack got me comfortable with a lot of CSS concepts that I I hadn't had to play around with. Thank you grid, flexbox, transitions, all that kind of stuff, pseudo classes and stuff, were things that I in larger behemoth projects that had legacy CSS, and that kind of stuff weren't as applicable. And now that I was able to use them and kind of playground areas. I throw them in, in client projects all the time now. Bryan Robinson 7:23 Nice. Very nice. So so what what is your current like jam in the JAMstack? is a Gatsby or is it something? Laurie Barth 7:29 Yeah, it's Gatsby. Okay, me and everyone else, right. Sure. Yeah. Bryan Robinson 7:33 What draws you to Gatsby, Laurie Barth 7:36 I had my Jekyll site. And that was really easy to port over to Gatsby, there were a ton of tutorials online. And the hardest part about that was getting Gatsby image to work. And ever since I've written blog posts on it, I've contributed to the docs, all of that stuff. So hopefully, that won't be hard for the next set of people who try and set up all kinds of different Gatsby image things Laurie Barth 7:55 So, one of the appeals of Gatsby for me was that I didn't need to know much. I didn't need to know some of the React magic to make it work, at least for the use cases I have. And I actually feel like I've gotten a much better understanding of some of the React component architecture and similar things as a result of being in the Gatsby space. And again, it's one of those you have a personal site, you try things you do them, right, you do them wrong. And you end up dipping your toes into it and and having this playground where you discover a lot of concepts that you didn't necessarily understand before. Bryan Robinson 8:30 Nice. And I've got I've got this kind of this FOMO issue happening with Gatsby because I'm not a particularly strong React Dev. But I love the idea that they have so many plugins already available, and they've only really been around a couple of years. Laurie Barth 8:42 Yeah, their plugin ecosystem is insane. And themes are going to be equally impressive. Bryan Robinson 8:50 Yeah, definitely. And so so yeah, it seems like there's already something for every single use case you could possibly need almost it's almost getting to the point where it's like the early days of like, positive WordPress plugin ecosystem. Laurie Barth 9:01 Yeah, positive being the operative word there. Bryan Robinson 9:05 Exactly. Because it's all it's all developer focused, which is nice. So So what kind of is going to keep you in this JAMstack world? What what's what's, what's the thing that's going to anchor you in here, Laurie Barth 9:16 I am probably going to self host my blogs at some point. And I think there's kind of no better architecture pattern that exists right now for doing that in a lightweight, maintainable way. Bryan Robinson 9:27 Nice. Cool. And so so I know you've got you've got the dog Take care. So we'll we'll wrap things up here pretty soon. Laurie Barth 9:34 Sorry everyone! Bryan Robinson 9:35 Oh, no worries. No worries whatsoever. So So what's your what's your musical jam right now? What's your like? literal jam? So I'm listening to Laurie Barth 9:45 the Taylor Swift lover soundtrack. And the dog obviously. And the Heather's the musical soundtrack. Bryan Robinson 9:53 Really? Yeah. Okay, I didn't even know there was a musical Laurie Barth 9:55 there is it was off Broadway. And it's really kind of a fun, angry rock musical thing. Bryan Robinson 10:00 Very nice. Alright, and so So is there anything that you're doing right now that you really like to kind of promote and boost up? Laurie Barth 10:06 Yeah, I'm doing some egghead videos, I'm doing some blogging and contributor stuff to some publications and obviously writing my own stuff. So if you're interested in anything in the kind of JavaScript front end world and sometimes I write about other stuff. It's all on my site. LaurieonTech.com and a fair amount of it is also I always post it on Twitter @Laurieontech. Bryan Robinson 10:31 Cool. And we'll put both of those in the show notes. So I really appreciate you taking the time to talk with us especially with a new a new puppy. Laurie Barth 10:39 Yeah, for everyone who heard her in the background, she's she's sweet. You can see pictures of her online and maybe it'll be more forgiving of the interruptions Bryan Robinson 10:48 that @LaurieonTech account'ss gonna become a dog account, Laurie Barth 10:51 for sure. No question already there. Bryan Robinson 10:54 Very cool. Well, thanks again. And and we'll go from here. And we'll see online making cool stuff. Laurie Barth 10:59 Thanks so much, Bryan. Laurie Barth 11:00 Thanks. Bryan Robinson 11:04 also want to thank you, dear listener, for listening through the end of the podcast and being sure to go into your pod catcher of choice, whether that be iTunes, the Google Play Store or some third party that I'm not even familiar with, and hitting that like button and leaving us a positive review to let everyone know that this is one of the better podcasts listen to for the jam step. So until next time, keep making amazing things on the web and keep things jammyTranscribed by https://otter.aiIntro/outtro music by bensound.com

In this episode, Sarah Drasner shows us her particular journey as a developer, through many different environments over the years. We talk about change, dogma and ways to grow as a developer and stay relevant. Sarah also shares her experience and insights into the delicate art of managing other engineers. See acast.com/privacy for privacy and opt-out information.

Sponsors Netlify Sentry use the code “devchat” for $100 credit Triplebyte offers a $1000 signing bonus Panel Natalia Telpuhina Ben Hong Chris Fritz Joined by Special Guest: Piero Borrelli Episode Summary Today’s episode features special guest Piero Borrelli. Piero is not currently using Vue but has experience with multiple frameworks.Currently he is a full-stack NodeJS developer and uses a lot of Angular as well. In this episode, the panel discuss Piero’s article 10 Things Programming Has Taught Me About Life. Piero leads the discussion, inviting the panel to reflect on their choice to use Vue. They begin by discussing how Vue works for use cases and some weaknesses to look out for. Each of the panelists reflects on how they got started working with Vue. They give advice to people just starting out with Vue that they wish they would have done differently when they began. The panelists share some of their first projects they built in Vue and what made those projects fun. They discuss how they see Vue’s position in the market. Vue has been the fastest growing open source software project for the past 3 years or so, and grows by about 10% each month. They talk about why they think Vue is so popular, with the consensus being that it is because it is very easy to get started. Chris says that if an employer is looking for Vue developers, hire a JS developer and give them a day to learn Vue. The panel discusses the best and worst parts of using Vue and how they think the framework will evolve in the future. They share resources for listeners who want to start learning Vue immediately (see links). They discuss the characteristics of a good learner. The panel agrees that the best way to learn a new framework is to build something to share with someone you care about. Links 10 Things Programming Has Taught Me About Life Node.js Angular 1.6.5 jQuery Ember Typescript Slots Listeners Single root element Vue official documentation Frontend Masters Course by Sarah Drasner The Vue School Vue Mastery: Introduction to Vue The Complete Guide to Vue by Maximillian Schwarzmuller Vue Land (official Vue Discord channel) Find Piero on Twitter and on his website Follow DevChat on Facebook and Twitter Picks Natalia Telpuhina: Love, Death, and Robots Follow on Twitter @N_Telpuhina Ben Hong: Form Validation in Under an Hour with Vuelidate Make It Stick book Twitter and GitHub @bencodezen Chris Fritz: The OA Natalia and Ben’s workshops (bencodezen.io and Vue Vixens ) Piero Borelli: Listening to music while coding (Neotic or ChilledCow) Tools of Titans Ten Developers Share Their Stories from All Over The World

Sponsors Netlify Sentry use the code “devchat” for $100 credit Triplebyte offers a $1000 signing bonus Panel Natalia Telpuhina Ben Hong Chris Fritz Joined by Special Guest: Piero Borrelli Episode Summary Today’s episode features special guest Piero Borrelli. Piero is not currently using Vue but has experience with multiple frameworks.Currently he is a full-stack NodeJS developer and uses a lot of Angular as well. In this episode, the panel discuss Piero’s article 10 Things Programming Has Taught Me About Life. Piero leads the discussion, inviting the panel to reflect on their choice to use Vue. They begin by discussing how Vue works for use cases and some weaknesses to look out for. Each of the panelists reflects on how they got started working with Vue. They give advice to people just starting out with Vue that they wish they would have done differently when they began. The panelists share some of their first projects they built in Vue and what made those projects fun. They discuss how they see Vue’s position in the market. Vue has been the fastest growing open source software project for the past 3 years or so, and grows by about 10% each month. They talk about why they think Vue is so popular, with the consensus being that it is because it is very easy to get started. Chris says that if an employer is looking for Vue developers, hire a JS developer and give them a day to learn Vue. The panel discusses the best and worst parts of using Vue and how they think the framework will evolve in the future. They share resources for listeners who want to start learning Vue immediately (see links). They discuss the characteristics of a good learner. The panel agrees that the best way to learn a new framework is to build something to share with someone you care about. Links 10 Things Programming Has Taught Me About Life Node.js Angular 1.6.5 jQuery Ember Typescript Slots Listeners Single root element Vue official documentation Frontend Masters Course by Sarah Drasner The Vue School Vue Mastery: Introduction to Vue The Complete Guide to Vue by Maximillian Schwarzmuller Vue Land (official Vue Discord channel) Find Piero on Twitter and on his website Follow DevChat on Facebook and Twitter Picks Natalia Telpuhina: Love, Death, and Robots Follow on Twitter @N_Telpuhina Ben Hong: Form Validation in Under an Hour with Vuelidate Make It Stick book Twitter and GitHub @bencodezen Chris Fritz: The OA Natalia and Ben’s workshops (bencodezen.io and Vue Vixens ) Piero Borelli: Listening to music while coding (Neotic or ChilledCow) Tools of Titans Ten Developers Share Their Stories from All Over The World

Sunil Pai is a Software Engineer at Facebook, React team member, and the creator of Glamor. He joins us on The Undefined to talk about the state of the web, the past, present, and future of text editors and IDEs, how he learned to code, and how our community needs to evolve to survive.FeaturingSunil Pai – Twitter, GitHubKen Wheeler – Twitter, GitHub, WebsiteJared Palmer – Twitter, GitHub, WebsiteLinksStop writing code - Sunil's talk at React Europe 2018The “Something” Statements - Sunil's talk at React Rally 2018Visual BasicNeopetsAdobe FlashAtom EditorVisual Studio CodeList of mergers and acquisitions by MicrosoftTypeScriptPrettier - Opinionated Code FormatterVSCode IntelliCode Extension - AI-assisted productivity features for Python, TypeScript/JavaScript and Java developersVSCode Color Picker Extension (aka "Fady Gradient "F**ker)Framer XGlamor - Sunil's CSS-in-JS library for react et alJSSAtlaskit by Atlassian - Atlassian's official component librarySalesforce's Commerce Cloud (formerly Demandware)Sketch SymbolsGlamor's CSS selectors (e.g. ":hover")JSX specVue-loader Scoped CSSReact Hooks - They let you use state and other React features without writing a class."My Coding Journey" - Revel Carlberg West @ ReactNYCReact createClassCreate React App - Set up a modern React web app by running one command.Codesandbox.io - CodeSandbox is an online editor that helps you create web applications, from prototype to deployment.AWS Cloud9 - A cloud IDE for writing, running, and debugging codeWeb Audio APIAndroid Studio/SDKService Worker APIWeb Components API"Tumblr will ban all adult content on December 17th" by Shannon Liao, The Verge, Dec 3, 2018Codepen.io - A front end web development playground.Sunil's Gist on CSS-in-JS: "How does writing CSS in JS make it any more maintainable?" - (Hacker News Thread, Original Tweet)Addy Osmani, Sarah Drasner, and Dan Abramov (blessed be he)Mozilla Firebug Editor Extension for Firefox"What is a JavaBean exactly?" - Stack OverflowArray.prototype API on MDNKen Wheeler on Spotifykenwheeler/cash - Ken's absurdly small jQuery alternative for modern browsersFormidableLabs/react-music - Make beats with React!Rust Programming Language TutorialPicksTical by Method ManTile appCalifornia by Blink 182birkir/prime - Open Source GraphQL CMS

Sponsors: Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan CacheFly Panel Divya Sasidharan Chris Fritz Charles Max Wood Special Guest: Dobromir Hristov Episode Summary  In this episode of Views on Vue, the panelists talk to Dobromir Hristov, a frontend developer from Bulgaria working for hypefactors. Dobromir is also the organizer of VueJS Bulgaria and he created a Vue Beginners Workshop to increase the size of Vue community in Bulgaria. Dobromir describes the workshop’s development stage and his preparation process for the curriculum. He explains that for this workshop, they targeted developers with very little JavaScript experience. The workshop is also available on GitHub for people to check out and contribute. The panel then compares different workshop styles and best methods to keep the audience interested in the workshop content. Dobromir then gives details on the setup and concept of his workshop. He explains that he used Game of Thrones as the concept which the audience really enjoyed. He then describes what he would do differently next time. The panel talks about best practices and tips to prepare a good workshop and share anecdotes about their experiences addressing an audience in a workshop. Links Vue.js Dobromir’s Twitter Dobromir's GitHub Dobromir's Medium Dobromir's Workshop on GitHub VueJS Bulgaria Vuelidate Error Extractor Vue.js Beginners Workshop Facebook Dobromir's Blog Post: A brief review of Vue learning resources — State of 2018 Slides VueSchool Dopamine Vue Mastery Intro To Vue Chris' Slides Sarah Drasner Project voice from diaphragm https://twitter.com/mhartington https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue Picks: Divya Sasidharan: Summerland by Hannu Rajaniemi Making and Breaking the Grid: A Graphic Design Layout Workshop by Timothy Samara Sarah Soueidan Chris Fritz: https://opencollective.com/vuejs http://www.vueconf.us/workshops/ https://www.patreon.com/vuevixens Charles Max Wood: Fart Bomb Charles' GitHub: New devchat.tv Build on Eleventy  Dobromir Hristov: Testing Vue.js Applications by Edd Yerburgh Testing Vue.js components with Jest by Alex Morales Ditto Keyboard App Gyazo Slides  

Sponsors: Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan CacheFly Panel Divya Sasidharan Chris Fritz Charles Max Wood Special Guest: Dobromir Hristov Episode Summary  In this episode of Views on Vue, the panelists talk to Dobromir Hristov, a frontend developer from Bulgaria working for hypefactors. Dobromir is also the organizer of VueJS Bulgaria and he created a Vue Beginners Workshop to increase the size of Vue community in Bulgaria. Dobromir describes the workshop’s development stage and his preparation process for the curriculum. He explains that for this workshop, they targeted developers with very little JavaScript experience. The workshop is also available on GitHub for people to check out and contribute. The panel then compares different workshop styles and best methods to keep the audience interested in the workshop content. Dobromir then gives details on the setup and concept of his workshop. He explains that he used Game of Thrones as the concept which the audience really enjoyed. He then describes what he would do differently next time. The panel talks about best practices and tips to prepare a good workshop and share anecdotes about their experiences addressing an audience in a workshop. Links Vue.js Dobromir’s Twitter Dobromir's GitHub Dobromir's Medium Dobromir's Workshop on GitHub VueJS Bulgaria Vuelidate Error Extractor Vue.js Beginners Workshop Facebook Dobromir's Blog Post: A brief review of Vue learning resources — State of 2018 Slides VueSchool Dopamine Vue Mastery Intro To Vue Chris' Slides Sarah Drasner Project voice from diaphragm https://twitter.com/mhartington https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue Picks: Divya Sasidharan: Summerland by Hannu Rajaniemi Making and Breaking the Grid: A Graphic Design Layout Workshop by Timothy Samara Sarah Soueidan Chris Fritz: https://opencollective.com/vuejs http://www.vueconf.us/workshops/ https://www.patreon.com/vuevixens Charles Max Wood: Fart Bomb Charles' GitHub: New devchat.tv Build on Eleventy  Dobromir Hristov: Testing Vue.js Applications by Edd Yerburgh Testing Vue.js components with Jest by Alex Morales Ditto Keyboard App Gyazo Slides  

Sponsors: KendoUI Sentry use the code "devchat" for $100 credit TripleByte Panel: Divya Sasidharan Erik Hanchett Chris Fritz Joe Eames John Papa Charles Max Wood Special Guest: John Datserakis Episode Summary In this episode of Views on Vue, the panelists talk to John Datserakis, a full stack developer from North Shore Massachusetts. John has been programming for 9 years and works for Promosis, Inc. a company that develops and designs sweepstakes programs and other marketing tools. After leaving jQuery, John wrote a detailed tutorial comparing Vue and React. He felt that there weren’t enough tutorials available that show the issues developers face while coding in real time. With this tutorial he wanted to go through all the challenges a developer can face while learning a new framework from scratch. Comparing his favorite and least favorite parts using React, he mentions he didn’t “fall in love with it” enough to leave Vue. John then compares his experiences with Create React App and Vue CLI and talks about his most recent project, Best Meta which helps pick the most popular items on Amazon. John also talks briefly about his experiences using Vuex and Redux. Writing the detailed comparison tutorial helped John sharpen his JavaScript skills but he reveals that, at the end of the day, he will use Vue for his next project. Links Vue.js React.js John's GitHub John's Twitter John's LinkedIn Promosis, Inc. https://webpack.js.org/ https://angular.io/cli/update https://cli.vuejs.org/ https://redux.js.org/ https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue John's Recent Project: Best Meta John Datserakis' Article - Comparing Vue and React John Datserakis’ open-source projects on GitHub that pertain to the article: koa-vue-notes-api koa-vue-notes-web koa-react-notes-web John Datserakis' Other Recent GitHub Projects: vue-simple-context-menu vue-cookie-accept-decline vue-programmatic-invisible-google-recaptcha Picks John Papa: A book by Chris Noring on React Chris Noring's Twitter Divya Sasidharan: Framework Summit Sarah Drasner’s Workshop Design for Developers Ghost Erik Hanchett: AWS Amplify Chris Fritz: Google Fi Referral Code Ball Lightning by Cixin Liu FrontendMasters Joe Eames: ng-conf Minified – YouTube Framework Summit John Papa - AngularConnect Charles Max Wood: Eleventy Nunjucks John Datserakis: John's Recent Project: Best Meta Netlify Anthony Gore's Website        

Sponsors: KendoUI Sentry use the code "devchat" for $100 credit TripleByte Panel: Divya Sasidharan Erik Hanchett Chris Fritz Joe Eames John Papa Charles Max Wood Special Guest: John Datserakis Episode Summary In this episode of Views on Vue, the panelists talk to John Datserakis, a full stack developer from North Shore Massachusetts. John has been programming for 9 years and works for Promosis, Inc. a company that develops and designs sweepstakes programs and other marketing tools. After leaving jQuery, John wrote a detailed tutorial comparing Vue and React. He felt that there weren’t enough tutorials available that show the issues developers face while coding in real time. With this tutorial he wanted to go through all the challenges a developer can face while learning a new framework from scratch. Comparing his favorite and least favorite parts using React, he mentions he didn’t “fall in love with it” enough to leave Vue. John then compares his experiences with Create React App and Vue CLI and talks about his most recent project, Best Meta which helps pick the most popular items on Amazon. John also talks briefly about his experiences using Vuex and Redux. Writing the detailed comparison tutorial helped John sharpen his JavaScript skills but he reveals that, at the end of the day, he will use Vue for his next project. Links Vue.js React.js John's GitHub John's Twitter John's LinkedIn Promosis, Inc. https://webpack.js.org/ https://angular.io/cli/update https://cli.vuejs.org/ https://redux.js.org/ https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue John's Recent Project: Best Meta John Datserakis' Article - Comparing Vue and React John Datserakis’ open-source projects on GitHub that pertain to the article: koa-vue-notes-api koa-vue-notes-web koa-react-notes-web John Datserakis' Other Recent GitHub Projects: vue-simple-context-menu vue-cookie-accept-decline vue-programmatic-invisible-google-recaptcha Picks John Papa: A book by Chris Noring on React Chris Noring's Twitter Divya Sasidharan: Framework Summit Sarah Drasner’s Workshop Design for Developers Ghost Erik Hanchett: AWS Amplify Chris Fritz: Google Fi Referral Code Ball Lightning by Cixin Liu FrontendMasters Joe Eames: ng-conf Minified – YouTube Framework Summit John Papa - AngularConnect Charles Max Wood: Eleventy Nunjucks John Datserakis: John's Recent Project: Best Meta Netlify Anthony Gore's Website        

ROCK AND ROLLLLL cause Vue.js is here and we are back with Burke's BFF and Vue.js core team member, Sarah Drasner. This week we bring you Five Vue.js libraries that will melt your face off and or rock your socks. This one was filmed in the late afternoon in the hottest possible place on earth (Building 25 cafeteria in Redmond to be exact) and there was much sweating and discussion of said sweating.Follow Sarah on TwitterLinks from the show:Vuelidate: https://monterail.github.io/vuelidate/Vuetify: https://vuetifyjs.com/en/Vue Test Utils: https://vue-test-utils.vuejs.org/Vue Apollo: https://github.com/Akryum/vue-apollocuid: https://github.com/ericelliott/cuid

Panel: Chris Fritz Charles Max Wood In this episode, the panel consists of Chris and Charles who talk about developer freedom. Chuck talks about his new show called The DevRev. The guys also talk about time management, answering e-mails, being self-employed, and their goals/hopes/dreams that they want to achieve in life. Check it out! Show Topics: 0:00 – Advertisement – Kendo UI 0:30 – Chuck: Hi! Today our panel is Chris and myself. My new show is The DevRev. There is a lot of aspect of our job that boil down to freedom. Figure out what they like to do and eliminate the things that they don’t like to do. I think it will be 5x a week and I will have a guest every week. What does freedom mean to you? What is your ideal coding situation where you don’t starve? 2:10 – Chris: Let me take a step-back. Why I got into coding it was even before that and it was education. I wanted to work with schools and not necessarily tied to only one school. As a programmer I cannot be asked to do things that I don’t agree with. 3:21 – Chuck: A lot of this thought-process came up b/c of my initial steps into my self-employment. I wanted to go to my son’s activities. I saw freelancing as an option and then had to do that b/c I got laid-off. I hate being told what to do. I have an HOA in my neighborhood and I hate it. They tell me when and how to mow my lawn. This is how I operate it. I hate that they tell me to mow my lawn. I want to talk to people who I want to talk to – that’s my idea of freedom. Everyone’s different idea of what “freedom” is will be different. 5:36 – Chris: I want more time to create more free stuff. Chris talks about DEV experience. 6:28 – Chuck: How did you get to that point of figuring out what you want to do? 6:44 – Chris: I still am figuring that out. I do have a lot of opportunities that are really exciting for me. It’s deciding what I like at that moment and choosing what I want to do vs. not what is going to wear me down. I don’t want to die with regret. There is a distinction between bad tired and good tired. You weren’t true to what you thought was right – and so you don’t settle easy. You toss and turn. I want to end with “good tired” both for the end of the day and for the end of my life. 8:00 – Chuck: I agree with that and I really identify with that. 8:44 – Chris: How do you measure yourself? 8:54 – Chuck: It’s hard to quantify it in only one idea. It’s hard to measure. I list out 5 things I need to do to get me closer to my [one] big goal. I have to get those 5 things done. Most of the time I can make it and I keep grinding on it before I can be done. 9:51 – Chris: My bar is pretty low. Is there more joy / more happiness in the world today in the world b/c of what I’ve done today? I know I will make mistakes in code – and that hurts, no day will be perfect. I try to have a net positive affect everyday. 10:53 – Chris: I can fall easily into depression if I have too many bad days back-to-back. 11:03 – Chuck: I agree and I have to take time off if that happens. 11:13 – Chris talks about open source work and he mentions HOPE IN SOURCE, also Babel. 12:23 – Chuck: When I got to church and there is this component of being together and working towards the same goals. It’s more than just community. There is a real – something in common that we have. 12:57 – Chris: Do you think it’s similar to open source? 13:05 – Chuck: You can watch a podcast in-lieu of an actual in-person sermon. In my church community it’s – Building Each Other Up. It’s not the same for when I contribute to open source. 13:43 – Chris: I ask myself: Is it of value? If I were to die would that work help progress the humankind? By the time I die - I will be completely useless b/c everything in my head is out there in other peoples’ heads. 14:35 – Chuck: When I am gone – I want someone to step into my void and continue that. These shows should be able to go on even if I am not around. I want to make sure that these shows can keep going. 15:48 – Chris: How can we build each other up? We want to have opportunities to grow. I try to provide that for members of the team and vice versa. The amount of respect that I have seen in my communities is quite amazing. I admire Thorsten on the Vue team a lot. (Thorsten’s Twitter.) He talked about compassion and how to communicate with each other and code with compassion. That’s better community and better software. You are forced to thin from multiple perspectives. You want to learn from these various perspectives. 17:44 – Chuck: The ideas behind the camaraderie are great. 17:56 – Chris: And Sarah Drasner! 18:38 – Chuck: She probably feels fulfilled when she helps you out (Sarah). 18:54 – Chuck: We all have to look for those opportunities and take them! 19:08 – Chuck: We have been talking about personal fulfillment. For me writing some awesome code in Vue there is Boiler Plate or running the tests. 19:52 – Chuck: What tools light you up? 20:02 – Chris: I am a bit of a weirdo. I feel pretty good when I am hitting myself against a wall for 9 hours. I like feeling obsessed about something and defeating it. I love it. 21:21 – Chuck: The things that make you bang your head against the wall is awful for me. I like writing code that helps someone. (Chris: I like the challenge.) We will be charged up for different things. You like the challenge and it empowers me to help others out. 22:21 – Chris: I like learning more about how something works. I want to save people a lot of work. There has to be a social connection or I will have a hard time even attempting it. 22:52 – Chris: I also play video games where there are no social connections. I played the Witness a few months ago and I loved the puzzles. 23:45 – Chuck: What other tools are you using? 23:57 – Chris: Webpack is the best took for creating the ideal development scenario. 24:47 – Chuck mentions Boiler Plate. 25:00 – Chris: It was built to help large teams and/or large applications.  I built some other projects like: Hello Vue Components & (with John Papa) Vue Monolith Example. 27:07 – Chuck: Anything else that you consider to be “freeing?” 27:13 – Chris: I like working from home. I like having my routines – they make me happy and productive. Having full control over that makes me happy. The only thing I have is my wife and my cat. 28:12 – Chuck: Yeah I don’t miss driving through traffic. 28:44 – Chris: I don’t like to be around people all day. 30:40 – Advertisement: Get A Coder Job! 31:05 – Chris: Online I get a couple dozen people reaching out to me for different things: completely out-of-the-blue. I want to respond to most of those people but... 33:12 – Chuck: If it’s not on my calendar it won’t happen. I will get those e-mails that can be very time consuming. 33:35 – Chris: When they are asking for something “simple” – it’s not always simple. 34:30 – Chuck: I want to help everybody and that can be a problem. 35:02 – Chris: They are reaching out to me and I want to help. 35:56 – Chuck and Chris go back-and-forth. 36:18 – Chris: How do you figure out how to write a short enough response to the email – to only do 30 minutes? 36:44 – Chuck: Can I answer it in one minute? Nope – so it will go into another pile later in the week. I’ve replied saying: Here is my short-answer and for the long-answer see these references. I star those e-mails that will take too long to respond. 37:50 – Chris and Chuck go back-and-forth. 38:06 – Chuck: Your question is so good – here is the link to the blog that I wrote. 38:37 – Chris: I want to document to point people HERE to past blogs that I’ve written or to someone else’s blog. I feel guilty when I have to delegate. 39:35 – Chuck: I don’t have a problem delegating b/c that’s why I’m paying them. Everyone has his or her own role.  40:40 – Chris: Yeah that makes sense when it’s their job. 41:30 – Chuck: I know working together as a team will free me up in my areas of excellence. 41:49 – Chris: I am having a hard time with this right now. 43:36 – Chuck: We are looking for someone to fill this role and this is the job description. This way you can be EXCELLENT at what you do. You aren’t being pulled too thin. 44:19 – Chris: I have been trying to delegate more. 45:04 – Chuck: Yeah I have been trying to do more with my business, too. What do I want to do in the community? What is my focus? What is my mission and values for the business? Then you knock it out of the park! 45:51 – Chris: As a teacher it is really helpful and really not helpful. You are leading and shaping their experiences. You don’t have options to delegate. 46:27 – Chuck: Yeah my mother is a math teacher. 46:37 – Chuck: Yeah she has 10 kids, so she helps to delegate with force. She is the department head for mathematics and she does delegate some things. It’s you to teach the course. 47:18 – Chris: What promoted you to start this podcast? Is it more personal? 47:30 – Chuck talks about why he is starting this new podcast. 48:10 – Chuck: My business coach said to me: write a mission statement. When I did that things started having clarity for me. Chuck talks about the plan for the DevRev! 55:20 – Chris: I am looking forward to it! 55:34 – Chuck: It will be recorded via video through YouTube, too, in addition to iTunes (hopefully). 55:52 – Chris & Chuck: Picks! 55:58 – Advertisement – Fresh Books! DEVCHAT code. 30-day trial. Links: Vue React JavaScript C# C++ C++ Programming / Memory Management Angular Blazor JavaScript DevChat TV VueCLI Boiler Plate Hello Vue Components Vue Monolith Example Thorsten’s Twitter Sarah’s Twitter Ben Hong’s Twitter Jacob Schatz’ Twitter Vue Vixens The DevRev Sponsors: Fresh Books Cache Fly Kendo UI Get A Coder Job! Picks: Chris Vue Vixens Charles repurpose.io MFCEO Project Podcast Game - Test Version

Panel: Chris Fritz Charles Max Wood In this episode, the panel consists of Chris and Charles who talk about developer freedom. Chuck talks about his new show called The DevRev. The guys also talk about time management, answering e-mails, being self-employed, and their goals/hopes/dreams that they want to achieve in life. Check it out! Show Topics: 0:00 – Advertisement – Kendo UI 0:30 – Chuck: Hi! Today our panel is Chris and myself. My new show is The DevRev. There is a lot of aspect of our job that boil down to freedom. Figure out what they like to do and eliminate the things that they don’t like to do. I think it will be 5x a week and I will have a guest every week. What does freedom mean to you? What is your ideal coding situation where you don’t starve? 2:10 – Chris: Let me take a step-back. Why I got into coding it was even before that and it was education. I wanted to work with schools and not necessarily tied to only one school. As a programmer I cannot be asked to do things that I don’t agree with. 3:21 – Chuck: A lot of this thought-process came up b/c of my initial steps into my self-employment. I wanted to go to my son’s activities. I saw freelancing as an option and then had to do that b/c I got laid-off. I hate being told what to do. I have an HOA in my neighborhood and I hate it. They tell me when and how to mow my lawn. This is how I operate it. I hate that they tell me to mow my lawn. I want to talk to people who I want to talk to – that’s my idea of freedom. Everyone’s different idea of what “freedom” is will be different. 5:36 – Chris: I want more time to create more free stuff. Chris talks about DEV experience. 6:28 – Chuck: How did you get to that point of figuring out what you want to do? 6:44 – Chris: I still am figuring that out. I do have a lot of opportunities that are really exciting for me. It’s deciding what I like at that moment and choosing what I want to do vs. not what is going to wear me down. I don’t want to die with regret. There is a distinction between bad tired and good tired. You weren’t true to what you thought was right – and so you don’t settle easy. You toss and turn. I want to end with “good tired” both for the end of the day and for the end of my life. 8:00 – Chuck: I agree with that and I really identify with that. 8:44 – Chris: How do you measure yourself? 8:54 – Chuck: It’s hard to quantify it in only one idea. It’s hard to measure. I list out 5 things I need to do to get me closer to my [one] big goal. I have to get those 5 things done. Most of the time I can make it and I keep grinding on it before I can be done. 9:51 – Chris: My bar is pretty low. Is there more joy / more happiness in the world today in the world b/c of what I’ve done today? I know I will make mistakes in code – and that hurts, no day will be perfect. I try to have a net positive affect everyday. 10:53 – Chris: I can fall easily into depression if I have too many bad days back-to-back. 11:03 – Chuck: I agree and I have to take time off if that happens. 11:13 – Chris talks about open source work and he mentions HOPE IN SOURCE, also Babel. 12:23 – Chuck: When I got to church and there is this component of being together and working towards the same goals. It’s more than just community. There is a real – something in common that we have. 12:57 – Chris: Do you think it’s similar to open source? 13:05 – Chuck: You can watch a podcast in-lieu of an actual in-person sermon. In my church community it’s – Building Each Other Up. It’s not the same for when I contribute to open source. 13:43 – Chris: I ask myself: Is it of value? If I were to die would that work help progress the humankind? By the time I die - I will be completely useless b/c everything in my head is out there in other peoples’ heads. 14:35 – Chuck: When I am gone – I want someone to step into my void and continue that. These shows should be able to go on even if I am not around. I want to make sure that these shows can keep going. 15:48 – Chris: How can we build each other up? We want to have opportunities to grow. I try to provide that for members of the team and vice versa. The amount of respect that I have seen in my communities is quite amazing. I admire Thorsten on the Vue team a lot. (Thorsten’s Twitter.) He talked about compassion and how to communicate with each other and code with compassion. That’s better community and better software. You are forced to thin from multiple perspectives. You want to learn from these various perspectives. 17:44 – Chuck: The ideas behind the camaraderie are great. 17:56 – Chris: And Sarah Drasner! 18:38 – Chuck: She probably feels fulfilled when she helps you out (Sarah). 18:54 – Chuck: We all have to look for those opportunities and take them! 19:08 – Chuck: We have been talking about personal fulfillment. For me writing some awesome code in Vue there is Boiler Plate or running the tests. 19:52 – Chuck: What tools light you up? 20:02 – Chris: I am a bit of a weirdo. I feel pretty good when I am hitting myself against a wall for 9 hours. I like feeling obsessed about something and defeating it. I love it. 21:21 – Chuck: The things that make you bang your head against the wall is awful for me. I like writing code that helps someone. (Chris: I like the challenge.) We will be charged up for different things. You like the challenge and it empowers me to help others out. 22:21 – Chris: I like learning more about how something works. I want to save people a lot of work. There has to be a social connection or I will have a hard time even attempting it. 22:52 – Chris: I also play video games where there are no social connections. I played the Witness a few months ago and I loved the puzzles. 23:45 – Chuck: What other tools are you using? 23:57 – Chris: Webpack is the best took for creating the ideal development scenario. 24:47 – Chuck mentions Boiler Plate. 25:00 – Chris: It was built to help large teams and/or large applications.  I built some other projects like: Hello Vue Components & (with John Papa) Vue Monolith Example. 27:07 – Chuck: Anything else that you consider to be “freeing?” 27:13 – Chris: I like working from home. I like having my routines – they make me happy and productive. Having full control over that makes me happy. The only thing I have is my wife and my cat. 28:12 – Chuck: Yeah I don’t miss driving through traffic. 28:44 – Chris: I don’t like to be around people all day. 30:40 – Advertisement: Get A Coder Job! 31:05 – Chris: Online I get a couple dozen people reaching out to me for different things: completely out-of-the-blue. I want to respond to most of those people but... 33:12 – Chuck: If it’s not on my calendar it won’t happen. I will get those e-mails that can be very time consuming. 33:35 – Chris: When they are asking for something “simple” – it’s not always simple. 34:30 – Chuck: I want to help everybody and that can be a problem. 35:02 – Chris: They are reaching out to me and I want to help. 35:56 – Chuck and Chris go back-and-forth. 36:18 – Chris: How do you figure out how to write a short enough response to the email – to only do 30 minutes? 36:44 – Chuck: Can I answer it in one minute? Nope – so it will go into another pile later in the week. I’ve replied saying: Here is my short-answer and for the long-answer see these references. I star those e-mails that will take too long to respond. 37:50 – Chris and Chuck go back-and-forth. 38:06 – Chuck: Your question is so good – here is the link to the blog that I wrote. 38:37 – Chris: I want to document to point people HERE to past blogs that I’ve written or to someone else’s blog. I feel guilty when I have to delegate. 39:35 – Chuck: I don’t have a problem delegating b/c that’s why I’m paying them. Everyone has his or her own role.  40:40 – Chris: Yeah that makes sense when it’s their job. 41:30 – Chuck: I know working together as a team will free me up in my areas of excellence. 41:49 – Chris: I am having a hard time with this right now. 43:36 – Chuck: We are looking for someone to fill this role and this is the job description. This way you can be EXCELLENT at what you do. You aren’t being pulled too thin. 44:19 – Chris: I have been trying to delegate more. 45:04 – Chuck: Yeah I have been trying to do more with my business, too. What do I want to do in the community? What is my focus? What is my mission and values for the business? Then you knock it out of the park! 45:51 – Chris: As a teacher it is really helpful and really not helpful. You are leading and shaping their experiences. You don’t have options to delegate. 46:27 – Chuck: Yeah my mother is a math teacher. 46:37 – Chuck: Yeah she has 10 kids, so she helps to delegate with force. She is the department head for mathematics and she does delegate some things. It’s you to teach the course. 47:18 – Chris: What promoted you to start this podcast? Is it more personal? 47:30 – Chuck talks about why he is starting this new podcast. 48:10 – Chuck: My business coach said to me: write a mission statement. When I did that things started having clarity for me. Chuck talks about the plan for the DevRev! 55:20 – Chris: I am looking forward to it! 55:34 – Chuck: It will be recorded via video through YouTube, too, in addition to iTunes (hopefully). 55:52 – Chris & Chuck: Picks! 55:58 – Advertisement – Fresh Books! DEVCHAT code. 30-day trial. Links: Vue React JavaScript C# C++ C++ Programming / Memory Management Angular Blazor JavaScript DevChat TV VueCLI Boiler Plate Hello Vue Components Vue Monolith Example Thorsten’s Twitter Sarah’s Twitter Ben Hong’s Twitter Jacob Schatz’ Twitter Vue Vixens The DevRev Sponsors: Fresh Books Cache Fly Kendo UI Get A Coder Job! Picks: Chris Vue Vixens Charles repurpose.io MFCEO Project Podcast Game - Test Version

Panel: Joe Eames John Papa Erik Hatchett Charles Max Wood Special Guest: Miriam Suzanne In this episode, the panel talks with Miriam Suzanne who is an author, performer, musician, designer, and web developer who works with OddBird, Teacup, Gorilla, Grapefruit Lab, and CSS Tricks. She’s the author of Riding SideSaddle and the Post-Obsolete Book, co-author of Jump Start Sass, and creator of the Susy and True Open-Source toolkits. The panel and the guest talk about Fonts! Show Topics: 0:00 – Advertisement – Kendo UI 0:53 – Guest: Hello! 1:01 – Guest: I am a designer and a developer and started a business with my brother. We are two college dropouts. 2:00 – Panel: Is that’s why it’s called OddBird? 2:05 – Guest: Started with Vue and have been talking at conferences. 2:31 – Chuck: Chris invited you and he’s not here today – go figure! 2:47 – Panel: You are big in the CSS world. 2:58 – Guest: That’s where I’ve made my name. I made a grid system that was popular at one moment in time. 3:17 – Panel. 3:27 – Panel: Grid Systems are... 3:36 – Guest talks about her grid system and how it looked. 4:20 – Panel. 4:24 – Panel goes back-and-forth! 5:24 – Chuck. 5:27 – Guest: That’s why grid systems came out in the first place b/c layout was such a nightmare. When I built Susy... 6:02 – How much easier is design today on modern browsers compared to ten years ago when you created Susy? 6:14 – Guest: It can look daunting but there are great guides out there! 7:04 – Panel asks a question. 7:11 – Guest: We recommend a stack to our clients. We had been using backbone Marinette for a while and we wanted to start messing with others. Looking at other frameworks. Looking at design, I like that Vue doesn’t hide it from me and I can see what I need. 8:41 – Panel: I love that about Vue. I knew this guy named, Hue. 8:54 – Guest: I have been friends with Sarah Drasner. 9:07 – Panel: Sarah is great she’s on my team. 9:39 – Guest: I had been diving into JavaScript over the summer. I hadn’t done a lot of JS in the past before the summer. I was learning Vanilla JavaScript. 10:21 – Guest: I don’t like how it mixes it all together (in reference to the JSX). 10:44 – Panel mentions Python and other things. Panelist asks a question. 10:54 – Guest: That would be a question for someone who writes that. 11:30 – Panel: I am going to change topics here for a second. Can you talk about your talk? And what is a design system? 11:48 – Guest answers the question. 13:26 – Panel follows-up with another question. 13:35 – Guest talks about component libraries. 15:30 – Chuck: Do people assume that the component that they have has all the accessibility baked-in b/c everything else does – and turns out it doesn’t? 15:48 – Guest answers. Guest: Hopefully it’s marked into the documentation. 16:25 – Panel. 16:36 – Guest: If you don’t document it – it doesn’t exist. 17:01 – Panel. 17:22 – Guest: “How do we sell clients on this?” We don’t – we let them come back and say, “we had to do less upkeep.” If they are following our patterns then... 17:57 – Panel: We’ve had where guides are handed off and it erodes slowly over time. Then people are doing it 10 different ways and not doing it the way it was designed. 18:31 – Guest: Yes, it should be baked-into the design and it shouldn’t be added to the style guide. 19:02 – Chuck: I really love Sass – and CSS – how do you write SASS or CSS with Vue? 19:12 – Guest answers the question. 19:23 – Chuck: You made my life better! 19:31 – Guest: If you have global files...you can have those imported among other things. 20:11 – Panel: What’s the best way to go about that? 20:24 – The guest talks about CSS, global designs, among other things. 21:15 – The guest mentions inverted triangles CSS! 22:12 – Guest: The deeper we get the narrower we get! 22:49 – Guest mentions scope styles. 23:12 – Panel: That makes total sense! We are using scope everywhere. 23:30 – Guest. 23:36 – Panel: How would you approach this? I start with scope and then I take them out of scope and then usually promote them to import for mix-ins. I wonder where is that border? 24:30 – Advertisement – Get A Coder Job! 25:09 – Guest answers the question. 25:53 – Panel: It sounds easy at first but when you are designing it you say: I know that isn’t right! 26:13 – Guest: I try to go through a design proposal. 26:27 – Guest defines the term: reused. 27:04 – Panel. 27:10 – Guest. 27:30 – Panel: We used to have this problem where we got the question of the following: splitting up the CSS bundles. 28:27 – Guest: That is the nice thing of having CSS in components. 28:49 – Panel asks Miriam a question. 29:02 – Guest: That’s often when someone wants a redesign. 29:54 – Panel: How do you decide on how many fonts to deliver so they don’t take over the size of the browser? 30:09 – Guest: The usual design rule is no more than 2-3 fonts works out well for performance. Try to keep that rule in mind, but you have to consider every unique project. What is more important for THAT project? 31:46 – Panel. 32:21 – Guest gives recommendations with fonts and font files. 33:37 – Chuck: What are you working on now with Vue? 33:45 – Guest answers the question. The guest talks about collaborative writing. 34:10 – Miriam continues. 34:55 – Chuck: What was the trickiest part? 35:00 – Guest answers the question. 36:03 – Guest: It’s called Vue Finder and it’s through open source. 36:39 – Chuck: Any recent talks coming up for you? 36:49 – Guest: I have one tonight and later one in California! 37:02 – Guest: There were several Vue conferences this year that I was sad to have missed. 37:40 – Guest: Are you doing it again? 37:49 – Panel: How many do you attend? 37:57 – Guest: Normally I do 8-10 conferences and then a variety of Meetups. 38:33 – Chuck: Picks! How do people find you? 38:41 – Guest: OddBird.net and Twitter! 38:58 – Advertisement – Fresh Books! DEVCHAT code. 30-day trial. Links: Vue React JavaScript C# C++ C++ Programming / Memory Management Angular Blazor JavaScript DevChat TV JSX VueConf US 2018 CSS Tricks – By Sarah Drasner Real Talk JavaScript FX Miriam’s Twitter Miriam’s Website OddBird Sponsors: Fresh Books Cache Fly Kendo UI Get A Coder Job! Picks: Joe Indoor Rock Climbing Getting back into what you enjoy RoboTech History of Robotech Vue.JS In Action John Papa How To Import a SASS file into every Vue Component in an App Real Talk JS Podcast Erik AWS Amplify Doctor Who Charles Dungeons and Dragons Stuff Extreme Ownership Miriam Pose New DND Game - Test Version

Panel: Joe Eames John Papa Erik Hatchett Charles Max Wood Special Guest: Miriam Suzanne In this episode, the panel talks with Miriam Suzanne who is an author, performer, musician, designer, and web developer who works with OddBird, Teacup, Gorilla, Grapefruit Lab, and CSS Tricks. She’s the author of Riding SideSaddle and the Post-Obsolete Book, co-author of Jump Start Sass, and creator of the Susy and True Open-Source toolkits. The panel and the guest talk about Fonts! Show Topics: 0:00 – Advertisement – Kendo UI 0:53 – Guest: Hello! 1:01 – Guest: I am a designer and a developer and started a business with my brother. We are two college dropouts. 2:00 – Panel: Is that’s why it’s called OddBird? 2:05 – Guest: Started with Vue and have been talking at conferences. 2:31 – Chuck: Chris invited you and he’s not here today – go figure! 2:47 – Panel: You are big in the CSS world. 2:58 – Guest: That’s where I’ve made my name. I made a grid system that was popular at one moment in time. 3:17 – Panel. 3:27 – Panel: Grid Systems are... 3:36 – Guest talks about her grid system and how it looked. 4:20 – Panel. 4:24 – Panel goes back-and-forth! 5:24 – Chuck. 5:27 – Guest: That’s why grid systems came out in the first place b/c layout was such a nightmare. When I built Susy... 6:02 – How much easier is design today on modern browsers compared to ten years ago when you created Susy? 6:14 – Guest: It can look daunting but there are great guides out there! 7:04 – Panel asks a question. 7:11 – Guest: We recommend a stack to our clients. We had been using backbone Marinette for a while and we wanted to start messing with others. Looking at other frameworks. Looking at design, I like that Vue doesn’t hide it from me and I can see what I need. 8:41 – Panel: I love that about Vue. I knew this guy named, Hue. 8:54 – Guest: I have been friends with Sarah Drasner. 9:07 – Panel: Sarah is great she’s on my team. 9:39 – Guest: I had been diving into JavaScript over the summer. I hadn’t done a lot of JS in the past before the summer. I was learning Vanilla JavaScript. 10:21 – Guest: I don’t like how it mixes it all together (in reference to the JSX). 10:44 – Panel mentions Python and other things. Panelist asks a question. 10:54 – Guest: That would be a question for someone who writes that. 11:30 – Panel: I am going to change topics here for a second. Can you talk about your talk? And what is a design system? 11:48 – Guest answers the question. 13:26 – Panel follows-up with another question. 13:35 – Guest talks about component libraries. 15:30 – Chuck: Do people assume that the component that they have has all the accessibility baked-in b/c everything else does – and turns out it doesn’t? 15:48 – Guest answers. Guest: Hopefully it’s marked into the documentation. 16:25 – Panel. 16:36 – Guest: If you don’t document it – it doesn’t exist. 17:01 – Panel. 17:22 – Guest: “How do we sell clients on this?” We don’t – we let them come back and say, “we had to do less upkeep.” If they are following our patterns then... 17:57 – Panel: We’ve had where guides are handed off and it erodes slowly over time. Then people are doing it 10 different ways and not doing it the way it was designed. 18:31 – Guest: Yes, it should be baked-into the design and it shouldn’t be added to the style guide. 19:02 – Chuck: I really love Sass – and CSS – how do you write SASS or CSS with Vue? 19:12 – Guest answers the question. 19:23 – Chuck: You made my life better! 19:31 – Guest: If you have global files...you can have those imported among other things. 20:11 – Panel: What’s the best way to go about that? 20:24 – The guest talks about CSS, global designs, among other things. 21:15 – The guest mentions inverted triangles CSS! 22:12 – Guest: The deeper we get the narrower we get! 22:49 – Guest mentions scope styles. 23:12 – Panel: That makes total sense! We are using scope everywhere. 23:30 – Guest. 23:36 – Panel: How would you approach this? I start with scope and then I take them out of scope and then usually promote them to import for mix-ins. I wonder where is that border? 24:30 – Advertisement – Get A Coder Job! 25:09 – Guest answers the question. 25:53 – Panel: It sounds easy at first but when you are designing it you say: I know that isn’t right! 26:13 – Guest: I try to go through a design proposal. 26:27 – Guest defines the term: reused. 27:04 – Panel. 27:10 – Guest. 27:30 – Panel: We used to have this problem where we got the question of the following: splitting up the CSS bundles. 28:27 – Guest: That is the nice thing of having CSS in components. 28:49 – Panel asks Miriam a question. 29:02 – Guest: That’s often when someone wants a redesign. 29:54 – Panel: How do you decide on how many fonts to deliver so they don’t take over the size of the browser? 30:09 – Guest: The usual design rule is no more than 2-3 fonts works out well for performance. Try to keep that rule in mind, but you have to consider every unique project. What is more important for THAT project? 31:46 – Panel. 32:21 – Guest gives recommendations with fonts and font files. 33:37 – Chuck: What are you working on now with Vue? 33:45 – Guest answers the question. The guest talks about collaborative writing. 34:10 – Miriam continues. 34:55 – Chuck: What was the trickiest part? 35:00 – Guest answers the question. 36:03 – Guest: It’s called Vue Finder and it’s through open source. 36:39 – Chuck: Any recent talks coming up for you? 36:49 – Guest: I have one tonight and later one in California! 37:02 – Guest: There were several Vue conferences this year that I was sad to have missed. 37:40 – Guest: Are you doing it again? 37:49 – Panel: How many do you attend? 37:57 – Guest: Normally I do 8-10 conferences and then a variety of Meetups. 38:33 – Chuck: Picks! How do people find you? 38:41 – Guest: OddBird.net and Twitter! 38:58 – Advertisement – Fresh Books! DEVCHAT code. 30-day trial. Links: Vue React JavaScript C# C++ C++ Programming / Memory Management Angular Blazor JavaScript DevChat TV JSX VueConf US 2018 CSS Tricks – By Sarah Drasner Real Talk JavaScript FX Miriam’s Twitter Miriam’s Website OddBird Sponsors: Fresh Books Cache Fly Kendo UI Get A Coder Job! Picks: Joe Indoor Rock Climbing Getting back into what you enjoy RoboTech History of Robotech Vue.JS In Action John Papa How To Import a SASS file into every Vue Component in an App Real Talk JS Podcast Erik AWS Amplify Doctor Who Charles Dungeons and Dragons Stuff Extreme Ownership Miriam Pose New DND Game - Test Version

Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan In this episode, the panel talks amongst themselves on the topic: how does one contribute to opensource work? They discuss the various ways that they contribute, such as speaking at conferences, recording videos for YouTube, podcasting, among others. Check-out today’s episode to get some insight and inspiration of how YOU can contribute to YOUR community!  Show Topics: 1:11 – We have decided we haven’t completed this topic 1:23 – Last time we went around the panel and see how we contribute? One of the ways I contribute to opensource is organizing events and conferences. Divya, you write some code – a little bit? 2:05 – Divya. 2:11 – Panelist: Divya, you speak at conferences, write blog posts, and code. Super top-secret project? 2:33 – Divya: I am trying to grow. Maybe I can talk about the secret project later? 2:56 – Panelist: Yes, I contribute through videos and education. I’ve tried in the past seeing issues in opensource, but I find that I am better at teaching. Charles you run a Vue Podcast? 3:29 – Chuck: Yeah, that’s what they say. I work on the podcasts, online conferences, eBooks, and online summits. Lastly, Code Badges that is on Kickstarter. 4:06 – Panelist: How we can contribute to opensource and still make a living. What is free and what we charge for? Finding a balance is important – we covered that last time. How to get into opensource in a variety of ways: How do you start speaking at conferences? How to you write code for opensource? Divya, how do they start? Do you need a public speaking degree? 5:29 – Divya: It might help. To get started with public speaking – it’s deceptively easy but then it’s not at the same time. You submit a proposal to a conference and it’s either accepted or declined. You have to learn how to CRAFT your ideas in a CFP to show the panel that this topic is RELEVANT to the conference and that you are an expert. It’s not the speaking that’s the hard part it’s the writing of the proposal. 7:00 – Panelist: You have talked about CFP – what is that? 7:09 – Divya: It’s a Call For Papers (CFP). It’s just a process of being accepted at a conference. Sometimes conferences have an open call – where they might have a Google form or some software to fill out some details. They will ask for your personal details, a short draft, the title of your talk, and a longer description (why you should be the speaker, etc.). It’s a multi-step process. Even though YOU are the right person to talk about X topic – you don’t have to be – you just have to SOUND like you know what you are talking about. Show that you’ve done your researched, and that you have some understanding. Also, that you are capable of presenting the information at the conference. That’s what I mean by being “THE BEST” person. 9:33- Charles: They aren’t looking always for the expert-level of explaining X topic. Even if it’s at the basic level that’s great. If you can deliver it well then they might pick your proposal. I have spoken at a number of conferences, and I started talking at Meetups. Most organizers are desperate for people to give talks. If you talk at these informal settings – then you get feedback from 10:47 – Divya: Yes, lightning talks are great for that, too. This way you are flushing out what you do and don’t want to talk about. 11:07 – Charles: A lot of people don’t realize that they are good speakers. The way to get better is to do it. I am a member of Toast Masters. You gain experience by talking at many different events. 12:23 – Panelist: I don’t know much about Toast Masters – what is it? 12:29 – Charles: Toast Masters, yes, they collect dues. As you sit in the meeting you have time to give feedback and get feedback. They have a “MM” master, and a grammatical master, and another specialist that they give you feedback. It’s a really constructive and friendly environment. 13:42 – I’ve been to Toast Masters and the meetings are early in the morning. 7:00 or 7:30 AM start time. Everything Chuck just said. I went to a couple and they don’t force you to talk. You can go just to see what it’s about. 14:21 – Charles makes more comments. 14:48 – Meetups is a great way to get into the community, too. What if Toast Masters sounds intimidating, and you don’t think you can speak at a Meetup just, yet. Are there more 15:18 – You can be the town crier. Stand on the soapbox and... 15:32 – There is someone sitting on a soapbox and screaming to a crowd. 15:43 – Chuck: You can do a YouTube video or a podcast, but I think getting the live feedback is super important. Toastmasters are so friendly and I’ve never been in front of a hostile crowd. You get up and they are rooting for you. It’s not as scary as you make it out to be. You aren’t going to ruin your reputation. 16:48 – Local Theater! That helps a lot, to me, because you have lines to read off of the script. You are a character and you get to do whatever you want. Also, teaching really helps. You don’t have to be a professional teacher but there are volunteer areas at a local library or your community centers and libraries. Find opportunities! 18:18 – Divya: Improvisation is good for that, too, back to Chris’ point. Improvisation you don’t have the lines, but it forces you to think on the spot. It helps you practice to think on the spot. 19:04 – Teaching is good for that, too. It makes you think on the spot. You have to respond on the fly. Life teaching is Improvisation. 19:31 – Charles: You learn the patterns that work. 19:57 – Panelist: There are some websites that can track your CFP due dates. You can apply to talk to 5-6 different conferences. You pitch the same idea to 5-6 conferences and you are bound to get picked for at least 1 of those conferences. 20:51 – Divya: There is an account that tweets the CFP due dates that are closing in 1-2 weeks. Check Twitter. 21:25 – Chuck: Take your CFP and have someone else look at it. I know a bunch of conference organizers and ask them for their feedback. 21:48 – Title and description need to be there. 22:48 – Divya: Look at past events to see what was already done in past conferences. This is to see what they are kind of looking for. Divya talks about certain conferences and their past schedules. 23:52 – Eric was saying earlier that you could send in more than 1 proposal. Another one suggests sending in 3 proposals. Someone would love to accept you, but say there is someone else you beats you by a hair. 24:31 – Divya: The CFP process is usually blind and they don’t “see” you until later. Most conferences try to do this so there is no bias. They will ask for no name, but only focusing on content. 25:28 – Sarah May has some great suggestions. Look at the show notes under LINKS. 25:57 – Advertisement – Get A Coder Job! 26:34 – We have talked about how you submit your proposals. Maybe let’s transition into another topic, like education. Eric – do you have any tips into writing blog posts and such? 27:36 – Eric: Find a topic that you want to learn and/or you are expert on. Going out there and putting out content for something you are learning. If you get something wrong then someone will probably call you out. Like Reddit you might get more criticism then vs. your own blog. I look for topics that interest me. 28:30 – Panelist: How do you get people to see it? 28:40 – Eric: Consistency – sharing on your social media channels. Reddit, Frontend, and/or other sites. I’m doing this for myself (first), and secondary I am teaching other people. 29:23 – Getting feedback from people is great. 29:40 – Eric: It’s a process to build that audience, build quality content, and keep up with it. Facebook groups – hey I put this content out there. Another way you can do it is work with a publisher and try going to a site called PluralSite. 30:47 – Do you have to be famous, like Joe, to get onto their site? 31:09 – Chuck: The audition process I got screwed on. They ask you to record a video, fix anything in the video, and then they will tell you if they will accept your courses or not. 31:37 – People who will distribute your content, there is a screening process. Guest blog, too, will get your name out there. 32:23 – Chuck: You just have to be a level above the reader. 32:37 – Odds are that you can explain it better than someone who learned it 5 years ago. Even if it’s a basic JavaScript thing that you JUST learned, who cares put it out there. If you made X mistake then I’m sure thousands of other developers have made the same mistake. 33:17 – Twitter is a great platform, too. A short and sweet Tweet – show them your main idea and it can get 34:01 – Comments. 34:04 – I use Ghost for my blogging platform. You can start off on Wordpress and others write on Medium. 34:25 – Divya: I like to own my own content so I don’t write on Medium anymore. 34:40 – I like my content on my OWN site. That’s why I haven’t been using Medium anymore. There are more pop-ups and such, too, so that’s why I don’t like it. 35:06 – Divya: If you don’t want to start up your own site, Medium is nice. Other users pick it up, which is an easy way to spread content right away. 37:13 – Chuck: Some of them will pay you for that. 37:23 – Sarah Drasner on the Vue team is an editor of CSS tricks. Good way to get your content out there. 37:48 – Divya: Sarah will work with you. Not only do you get access to put content out there, but then you get feedback from Sarah, too! 38:19 – Remember if you are doing a guest post – make sure to put out solid examples and good content. You want to put time and effort into it, so put more 39:02 – Any more advice on educational content? 39:11 – Chuck: I am always looking for guests for the podcasts and topics. You reach out and say I would like to be a guest on such and such a show. 39:39 – I thought back in the day – oh those podcast hosts are for THOSE famous people. They must have some journalism degree, and here I AM! It apparently is not that bad. 40:19 – Chuck: When I was coding semi-professionally for 1 year and my friend Eric Berry (Teach Me To Code – website) he was looking for someone to record videos for him. I submitted a video and I just walked through how to do basic routing. Basic for Ruby on Rails users, and I said that this is my first video. I tweeted that information. Screen Flow reached out to me because I mentioned their name, and I got a license and a microphone to help me record my videos! That gave me the confidence to start podcasting. It’s scary and I’m thinking I will screw this up, I don’t have professional equipment, and look at me now! 42:46 – To be a podcast host it isn’t much. 42:55 – Chuck: I am trying to make podcasting easier. The hard part is preparing the content, get it edited, getting it posted. It’s all the other stuff. Recording and talking isn’t that bad. 43:28 – What are my steps if I want to start a new podcast? 43:39 – What microphone should I get? 43:48 - $100-$130 is the Yeti microphone. Do I need a professional microphone? People can’t tell when guests talk on their iPhone microphone or not. Especially if you already have those then you won’t be out if you don’t want to continue with podcasting. Record for free with Audacity. Have something to talk about and somewhere to post it. 45:01 – Panelist asks Chuck more questions. 45:13 – Divya. 45:29 – It’s easier if everyone is in the same room. If the sound quality is good enough then people will stay, but if the quality is poor then people will go away. I recommend Wordpress - it’s super easy. You can host on Amazon, but if you will host long-term then use Libsyn or Blubrry. Great platforms will cost you less then some others. 46:58 – iTunes? 47:04 – Podcast through iTunes you just give them a RSS feed. All you do is fill out some forms. Submit that and it will run – same for Google Play. You might want to get some artwork. In the beginning for me I got a stock image – edited it – and that was it. One I got one of my headshots and put the title on there. 48:06 – Then when people will hear this... 48:23 – Summary: microphone, content, set up WordPress, submit it to iTunes, and record frequently. Keep improving. 48:46 – Anything you are doing anything online – make sure your mantra is “this is good enough.” If you spend tons of hours trying to perfect it – you might drive yourself crazy. 49:18 – Not everyone will enjoy podcasting or YouTubing – so make sure you don’t invest a lot of money at first to see where you are. 50:06 – Educational content topic continued. Contributing to coder depositories. What’s the best way to get into that? 50:28 – Chuck: Some will say: This one is good for a newbie to tackle. You just reach out – don’t just pick it up and tackle it – I would reach out to the person first. Understand what they need and then work on it, because they might have 2 other people working on it. 51:11 – Divya: Hacktoberfest – Digital Ocean – they publish opensource projects. 52:22 – Yeah check it out because you can get a free t-shirt! 53:50 – Chuck: Doing the work that the hotshots don’t want to do. It helps everyone out, but it might not be the most glamorous job.  55:11 – Spelling mistakes – scan the code base. 55:43 – Divya: If you do small contributions that people DON’T want to do – then these contributors will see you and you will be on their radar. You start building a relationship. Eventually people will start giving you more responsibilities, etc. 56:59 – Chuck: I have seen people been contributors through Ruby on Rails. They got the gig because the core team sees your previous work is reliable and good work. 57:26 – Is there a core contributor guideline? 57:37 – Good question. If Divya likes you then you are in. 57:47 – It’s Evan who makes those decisions, but we are working on a formal guideline. 58:52 – Will they kick you out? 59:00 – Unless they were doing bad stuff that means pain for other people you won’t get kicked out. 59:33 – Representing Vue to some degree, too. The people who are representing Vue are apart of it. We are trying to get a better answer for it, so it’s complicated, but working on it. 1:00:02 – How did you get on the team? Well, I was contributing code, I was discussing ways to better x, y, and z. Evan invited me to come into the core team. Basically he did it so he wouldn’t have to keep babysitting us. 1:01:06 – Chuck. 1:01:20 – Panelist. 1:01:48 – Panelist: One of our core team members got his job because he was answering questions from the community. He is not a software developer by training, but his background is a business analyst. You don’t have to contribute a ton of code. He was a guest so check out the past episode. See show notes for links. 1:03:05 – Chuck: We need to go to picks and I think that topic would be great for Joe! 1:03:24 – Advertisement – Fresh Books! Links: Vue React Angular JavaScript DevChat TV GitHub Meetup Ghost.Org Miriam Suzanne’s Twitter Sarah Mei’s Article: What Your Conference Proposal is Missing WordPress Sarah Drasner’s Twitter CSS Tricks Netlify Sponsors: Get A Coder Job! Cache Fly Kendo UI Picks: Eric Headless CMS Dyvia Blogspot - Building a 3D iDesigner with Vue.js The Twitch Streamers Who Spend Years Broadcasting to No One Chris Cat Content Twitter Account https://www.patreon.com/akryum The Great British Baking Show Charles Embrace the Struggle SoftCover.io getacoderjob.com swag.devchat.tv

Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan In this episode, the panel talks amongst themselves on the topic: how does one contribute to opensource work? They discuss the various ways that they contribute, such as speaking at conferences, recording videos for YouTube, podcasting, among others. Check-out today’s episode to get some insight and inspiration of how YOU can contribute to YOUR community!  Show Topics: 1:11 – We have decided we haven’t completed this topic 1:23 – Last time we went around the panel and see how we contribute? One of the ways I contribute to opensource is organizing events and conferences. Divya, you write some code – a little bit? 2:05 – Divya. 2:11 – Panelist: Divya, you speak at conferences, write blog posts, and code. Super top-secret project? 2:33 – Divya: I am trying to grow. Maybe I can talk about the secret project later? 2:56 – Panelist: Yes, I contribute through videos and education. I’ve tried in the past seeing issues in opensource, but I find that I am better at teaching. Charles you run a Vue Podcast? 3:29 – Chuck: Yeah, that’s what they say. I work on the podcasts, online conferences, eBooks, and online summits. Lastly, Code Badges that is on Kickstarter. 4:06 – Panelist: How we can contribute to opensource and still make a living. What is free and what we charge for? Finding a balance is important – we covered that last time. How to get into opensource in a variety of ways: How do you start speaking at conferences? How to you write code for opensource? Divya, how do they start? Do you need a public speaking degree? 5:29 – Divya: It might help. To get started with public speaking – it’s deceptively easy but then it’s not at the same time. You submit a proposal to a conference and it’s either accepted or declined. You have to learn how to CRAFT your ideas in a CFP to show the panel that this topic is RELEVANT to the conference and that you are an expert. It’s not the speaking that’s the hard part it’s the writing of the proposal. 7:00 – Panelist: You have talked about CFP – what is that? 7:09 – Divya: It’s a Call For Papers (CFP). It’s just a process of being accepted at a conference. Sometimes conferences have an open call – where they might have a Google form or some software to fill out some details. They will ask for your personal details, a short draft, the title of your talk, and a longer description (why you should be the speaker, etc.). It’s a multi-step process. Even though YOU are the right person to talk about X topic – you don’t have to be – you just have to SOUND like you know what you are talking about. Show that you’ve done your researched, and that you have some understanding. Also, that you are capable of presenting the information at the conference. That’s what I mean by being “THE BEST” person. 9:33- Charles: They aren’t looking always for the expert-level of explaining X topic. Even if it’s at the basic level that’s great. If you can deliver it well then they might pick your proposal. I have spoken at a number of conferences, and I started talking at Meetups. Most organizers are desperate for people to give talks. If you talk at these informal settings – then you get feedback from 10:47 – Divya: Yes, lightning talks are great for that, too. This way you are flushing out what you do and don’t want to talk about. 11:07 – Charles: A lot of people don’t realize that they are good speakers. The way to get better is to do it. I am a member of Toast Masters. You gain experience by talking at many different events. 12:23 – Panelist: I don’t know much about Toast Masters – what is it? 12:29 – Charles: Toast Masters, yes, they collect dues. As you sit in the meeting you have time to give feedback and get feedback. They have a “MM” master, and a grammatical master, and another specialist that they give you feedback. It’s a really constructive and friendly environment. 13:42 – I’ve been to Toast Masters and the meetings are early in the morning. 7:00 or 7:30 AM start time. Everything Chuck just said. I went to a couple and they don’t force you to talk. You can go just to see what it’s about. 14:21 – Charles makes more comments. 14:48 – Meetups is a great way to get into the community, too. What if Toast Masters sounds intimidating, and you don’t think you can speak at a Meetup just, yet. Are there more 15:18 – You can be the town crier. Stand on the soapbox and... 15:32 – There is someone sitting on a soapbox and screaming to a crowd. 15:43 – Chuck: You can do a YouTube video or a podcast, but I think getting the live feedback is super important. Toastmasters are so friendly and I’ve never been in front of a hostile crowd. You get up and they are rooting for you. It’s not as scary as you make it out to be. You aren’t going to ruin your reputation. 16:48 – Local Theater! That helps a lot, to me, because you have lines to read off of the script. You are a character and you get to do whatever you want. Also, teaching really helps. You don’t have to be a professional teacher but there are volunteer areas at a local library or your community centers and libraries. Find opportunities! 18:18 – Divya: Improvisation is good for that, too, back to Chris’ point. Improvisation you don’t have the lines, but it forces you to think on the spot. It helps you practice to think on the spot. 19:04 – Teaching is good for that, too. It makes you think on the spot. You have to respond on the fly. Life teaching is Improvisation. 19:31 – Charles: You learn the patterns that work. 19:57 – Panelist: There are some websites that can track your CFP due dates. You can apply to talk to 5-6 different conferences. You pitch the same idea to 5-6 conferences and you are bound to get picked for at least 1 of those conferences. 20:51 – Divya: There is an account that tweets the CFP due dates that are closing in 1-2 weeks. Check Twitter. 21:25 – Chuck: Take your CFP and have someone else look at it. I know a bunch of conference organizers and ask them for their feedback. 21:48 – Title and description need to be there. 22:48 – Divya: Look at past events to see what was already done in past conferences. This is to see what they are kind of looking for. Divya talks about certain conferences and their past schedules. 23:52 – Eric was saying earlier that you could send in more than 1 proposal. Another one suggests sending in 3 proposals. Someone would love to accept you, but say there is someone else you beats you by a hair. 24:31 – Divya: The CFP process is usually blind and they don’t “see” you until later. Most conferences try to do this so there is no bias. They will ask for no name, but only focusing on content. 25:28 – Sarah May has some great suggestions. Look at the show notes under LINKS. 25:57 – Advertisement – Get A Coder Job! 26:34 – We have talked about how you submit your proposals. Maybe let’s transition into another topic, like education. Eric – do you have any tips into writing blog posts and such? 27:36 – Eric: Find a topic that you want to learn and/or you are expert on. Going out there and putting out content for something you are learning. If you get something wrong then someone will probably call you out. Like Reddit you might get more criticism then vs. your own blog. I look for topics that interest me. 28:30 – Panelist: How do you get people to see it? 28:40 – Eric: Consistency – sharing on your social media channels. Reddit, Frontend, and/or other sites. I’m doing this for myself (first), and secondary I am teaching other people. 29:23 – Getting feedback from people is great. 29:40 – Eric: It’s a process to build that audience, build quality content, and keep up with it. Facebook groups – hey I put this content out there. Another way you can do it is work with a publisher and try going to a site called PluralSite. 30:47 – Do you have to be famous, like Joe, to get onto their site? 31:09 – Chuck: The audition process I got screwed on. They ask you to record a video, fix anything in the video, and then they will tell you if they will accept your courses or not. 31:37 – People who will distribute your content, there is a screening process. Guest blog, too, will get your name out there. 32:23 – Chuck: You just have to be a level above the reader. 32:37 – Odds are that you can explain it better than someone who learned it 5 years ago. Even if it’s a basic JavaScript thing that you JUST learned, who cares put it out there. If you made X mistake then I’m sure thousands of other developers have made the same mistake. 33:17 – Twitter is a great platform, too. A short and sweet Tweet – show them your main idea and it can get 34:01 – Comments. 34:04 – I use Ghost for my blogging platform. You can start off on Wordpress and others write on Medium. 34:25 – Divya: I like to own my own content so I don’t write on Medium anymore. 34:40 – I like my content on my OWN site. That’s why I haven’t been using Medium anymore. There are more pop-ups and such, too, so that’s why I don’t like it. 35:06 – Divya: If you don’t want to start up your own site, Medium is nice. Other users pick it up, which is an easy way to spread content right away. 37:13 – Chuck: Some of them will pay you for that. 37:23 – Sarah Drasner on the Vue team is an editor of CSS tricks. Good way to get your content out there. 37:48 – Divya: Sarah will work with you. Not only do you get access to put content out there, but then you get feedback from Sarah, too! 38:19 – Remember if you are doing a guest post – make sure to put out solid examples and good content. You want to put time and effort into it, so put more 39:02 – Any more advice on educational content? 39:11 – Chuck: I am always looking for guests for the podcasts and topics. You reach out and say I would like to be a guest on such and such a show. 39:39 – I thought back in the day – oh those podcast hosts are for THOSE famous people. They must have some journalism degree, and here I AM! It apparently is not that bad. 40:19 – Chuck: When I was coding semi-professionally for 1 year and my friend Eric Berry (Teach Me To Code – website) he was looking for someone to record videos for him. I submitted a video and I just walked through how to do basic routing. Basic for Ruby on Rails users, and I said that this is my first video. I tweeted that information. Screen Flow reached out to me because I mentioned their name, and I got a license and a microphone to help me record my videos! That gave me the confidence to start podcasting. It’s scary and I’m thinking I will screw this up, I don’t have professional equipment, and look at me now! 42:46 – To be a podcast host it isn’t much. 42:55 – Chuck: I am trying to make podcasting easier. The hard part is preparing the content, get it edited, getting it posted. It’s all the other stuff. Recording and talking isn’t that bad. 43:28 – What are my steps if I want to start a new podcast? 43:39 – What microphone should I get? 43:48 - $100-$130 is the Yeti microphone. Do I need a professional microphone? People can’t tell when guests talk on their iPhone microphone or not. Especially if you already have those then you won’t be out if you don’t want to continue with podcasting. Record for free with Audacity. Have something to talk about and somewhere to post it. 45:01 – Panelist asks Chuck more questions. 45:13 – Divya. 45:29 – It’s easier if everyone is in the same room. If the sound quality is good enough then people will stay, but if the quality is poor then people will go away. I recommend Wordpress - it’s super easy. You can host on Amazon, but if you will host long-term then use Libsyn or Blubrry. Great platforms will cost you less then some others. 46:58 – iTunes? 47:04 – Podcast through iTunes you just give them a RSS feed. All you do is fill out some forms. Submit that and it will run – same for Google Play. You might want to get some artwork. In the beginning for me I got a stock image – edited it – and that was it. One I got one of my headshots and put the title on there. 48:06 – Then when people will hear this... 48:23 – Summary: microphone, content, set up WordPress, submit it to iTunes, and record frequently. Keep improving. 48:46 – Anything you are doing anything online – make sure your mantra is “this is good enough.” If you spend tons of hours trying to perfect it – you might drive yourself crazy. 49:18 – Not everyone will enjoy podcasting or YouTubing – so make sure you don’t invest a lot of money at first to see where you are. 50:06 – Educational content topic continued. Contributing to coder depositories. What’s the best way to get into that? 50:28 – Chuck: Some will say: This one is good for a newbie to tackle. You just reach out – don’t just pick it up and tackle it – I would reach out to the person first. Understand what they need and then work on it, because they might have 2 other people working on it. 51:11 – Divya: Hacktoberfest – Digital Ocean – they publish opensource projects. 52:22 – Yeah check it out because you can get a free t-shirt! 53:50 – Chuck: Doing the work that the hotshots don’t want to do. It helps everyone out, but it might not be the most glamorous job.  55:11 – Spelling mistakes – scan the code base. 55:43 – Divya: If you do small contributions that people DON’T want to do – then these contributors will see you and you will be on their radar. You start building a relationship. Eventually people will start giving you more responsibilities, etc. 56:59 – Chuck: I have seen people been contributors through Ruby on Rails. They got the gig because the core team sees your previous work is reliable and good work. 57:26 – Is there a core contributor guideline? 57:37 – Good question. If Divya likes you then you are in. 57:47 – It’s Evan who makes those decisions, but we are working on a formal guideline. 58:52 – Will they kick you out? 59:00 – Unless they were doing bad stuff that means pain for other people you won’t get kicked out. 59:33 – Representing Vue to some degree, too. The people who are representing Vue are apart of it. We are trying to get a better answer for it, so it’s complicated, but working on it. 1:00:02 – How did you get on the team? Well, I was contributing code, I was discussing ways to better x, y, and z. Evan invited me to come into the core team. Basically he did it so he wouldn’t have to keep babysitting us. 1:01:06 – Chuck. 1:01:20 – Panelist. 1:01:48 – Panelist: One of our core team members got his job because he was answering questions from the community. He is not a software developer by training, but his background is a business analyst. You don’t have to contribute a ton of code. He was a guest so check out the past episode. See show notes for links. 1:03:05 – Chuck: We need to go to picks and I think that topic would be great for Joe! 1:03:24 – Advertisement – Fresh Books! Links: Vue React Angular JavaScript DevChat TV GitHub Meetup Ghost.Org Miriam Suzanne’s Twitter Sarah Mei’s Article: What Your Conference Proposal is Missing WordPress Sarah Drasner’s Twitter CSS Tricks Netlify Sponsors: Get A Coder Job! Cache Fly Kendo UI Picks: Eric Headless CMS Dyvia Blogspot - Building a 3D iDesigner with Vue.js The Twitch Streamers Who Spend Years Broadcasting to No One Chris Cat Content Twitter Account https://www.patreon.com/akryum The Great British Baking Show Charles Embrace the Struggle SoftCover.io getacoderjob.com swag.devchat.tv

Panel: Alyssa Nicholl Joe Eames John Papa Ward Bell Special Guests: Martin Jakubik In this episode, the Adventures in Angular panel talk with Martin Jakubik and he has been working with Angular for the last three years. He has one large and one small Angular application, which the panel talks about. Show Topics: 2:31 – Alyssa likes to be called... 2:40 – Alyssa: You have a large and small application – what makes it small? Is it the user-base? 2:56 – Martin: It is one module out of ten or twenty components. 2: 59 – Panelist: Only 1 Angular module? 3:47 – Panelist: Joe went off on how much he hates modules. I am sorry JP we had to throw that in that? 4:04 – Joe: I am an anti-modulist. 4:11 – Martin: Just one module. 4:21 – Panelist: When you are building an application with one module – start us from the beginning, what does it look like? 4:38 – Martin: It is actually quite special. It has to run in an iFrame, and all it does it allows the user to add into the experiment. 5:05 – Alyssa: Is it like a CMS? 5:10 – Martin: It is like Google Optimize. The application is quite simple and every component is in that one module. 5:36 – Panelist: How many do you have? 5:44 – Martin: There are less than 10 services and 20 components at most. 5:57 – Panelist: I feel personally, I feel like that I a decent size? 6:11 – Panelist: That makes perfect sense. If there is no routing or nothing... 6:40 – Panelist: Asks a question, and clarifies the question to Martin. 7:48 – Panelist: It is nice and clean. 7:55 – Panelist: I do, too. 8:08 – Alyssa: How new is it? 8:15 – Panelist: June/July? 8:32 – Martin: I am using the new style. 9:01 – Panelist: I am leery of using it. 9:13 - Panelist: I would like to clarify. When you mention you have 20 components... 9:40 - Panelist: Do it. 10:34 – Panelist: Webpack. Can you explain what that is and how you solved it? 10:57 – Martin: I don’t think I did anything special. I wanted to know how it works. I used webpack and used their configurations. Several months into the project then I... 11:40 – Panelist: Why did you decide not to use the CLI? This is like an Iron Man thing. 11:55 – Panelist: I think it’s a pain thing. 12:05 – Martin: I wanted to know how it works. 12:32 – Martin: I started from scratch, I can’t remember. 12:44 – Panelist: Whenever I use webpack it makes my head spin. 12:56 – Martin: The application was very simple. I was doing more blogging. 13:45 – Panelist: It is doing more configurations on the fly for you. It’s wonderful if it works and if it doesn’t work then I don’t know what you’d do. 14:17 – Martin: That’s why I did it, so I can appreciate all the magic. 14:30 – Panelist: How big is big? 14:36 – Martin: Enterprise level. 100 different components. 15:06 – Panelist chimes in. 15:13 – Panelist: That is complex. 15:28 – Panelist: let’s add more modules to add to the complexity... 15:55 – Alyssa: When you took your app to the CLI was that hard? 16:06 – Martin: That took me one whole day. The module is so simple that’s why. 16:32 – Panelist talks about this topic. 17:39 – Panelist asks a question. 17:53 – Panelist: Fixing any problem ... ever work on tooling help people if they have their stuff in the right file name? 18:18 – Martin: I used Cypress. 18:58 – Panelist: Under what situation would you recommend it to anyone? Do it your own webpack configuration? 19:23 – Martin: Only if... 19:51 – Alyssa: What if you wanted to add a watermark to each file, do you have to stop adding the CLI? 20:13 – Panelist: So am I...what are the boundaries, I don’t know what they are? I’m curious. 20:41 – Panelist: Are you asking, Alyssa, how you would customize it? 21:09 – Panelist: You won’t loose all the features that you get. You now elected out of that place where they had it; webpack configurations. 22:12 – Panelist: What happened to it ejecting? How do you get it out of there? 22:26 – Good question! I have – I like to play with scissors. 22:43 – Advertisement 23:32 – Panelist reads a message from the company. How do you get that voice? 24:10 – First you have to have a really deep sinus cold. 25:00 – Panelist: Do you live without eject? I really don’t care. What I care about...Scratch that! I want to know what kinds of things you can’t do with a CLI that would drive you to do your own application? What other things could you not do in webpack. 25:50 – Martin: I wanted to see how it works. 25:56 – Panelist: Now I use CLI and all it’s features except testing. I use Cypress completely separate than CLI. 26:46 – Panelist: I feel like it’s talking to the one person without a cellphone. 27:01 – Panelist: Wow! I had no concept that life could be like that! I thought you had to have a cellphone. 27:29  – Martin: What does anyone use the CLI for anyways? 27:44 – Martin: I use it for unit tests. 27:52 – Panelist: Another question. 28:30 – Alyssa: You write things out by hand because it’s easier?! 28:44 – Panelist: You copy, and paste and it’s less work. 29:06 – Panelist: It feels easier. 29:22 – Joe: No, I am serious. 29:48 – Joe: Yes, I am amazing. 30:30 – Martin talks about another topic. 30:48 – Alyssa: When you generate a component do you put it into a different file? 31:29 – Panel: We are all friends here and we aren’t shaming anyone here. We are joking here. 32:00 – Alyssa: It’s that he can write it from memory. 33:08 – Panelist: I have been using Vue lately. He also talks about Angular and mentions Sarah Drasner, too. 34:26 – Panelist: Not everyone has a memory like him, though. 35:32 – Panelist: The fourth version of Renderer. 36:28 – Panelist: We are not talking about Nirvana the band, here. 36:46 – Alyssa: It will be the new Renderer. It’s out for you to try. Check out Angular Air. He was trying out IB yourself right now. People are flipping out about it. I am excited to see how my Angular app runs differently now. Here is the code that was generated, here is the code that... I am not sure that there is a promise date. Any secrets heads-up on when it will come out? 38:22 – Panelist: The big question what does this mean for my existing code? Do I have to change my existing code? 38:48 – Alyssa: The Angular team is working so that there are minimal changes. I don’t have a good answer. NGGC. For third-party libraries you run it through and it... I don’t know what that means for the community. 39:49 – Panelist: My hope is that they... 40:03 – Alyssa: For your third-party... 40:18 – Panelist: Question: between your small and large pack? What architectural differences are there? 40:44 – Martin: I have a template edit. 41:03 – Panelist: Come to my... 41:32 – Panel talks about talks that Jon can do. 42:13 – Panelist: True story... The panel is having fun going back and forth with jokes. 43:03 – Panelist: This kind of stuff creeps into production code. That’s the great thing about copy and paste. 43:21 – Panelist: We had a rule, though, if it happens more than once let’s put into our build. 44:20 – It’s 3 hours if you have a CI process, if you don’t... 44:33 – Console.log 44:49 – Martin chimes in. 45:14 – Panelist: Let’s talk about an iFrame in your app? 45:27 – Martin: The point is to be able to do it with any... Make sure that it doesn’t collide. The CSS wasn’t separated. I had to put my application inside an iFrame. 46:27 – Panelist: Thanks for coming on for us, Martin. 46:37 – Picks! 46:44 - Advertisement Links: Martin Jakubik’s Medium How to Copy, Cut, Paste for Beginners by Melanie Pinola Art Joker Blog @AngularMine Cypress Vue Renderer Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Alyssa Question as my pick – About Angular 7...(47:52) True or False? Martin Thank you for having me today. Present your work more. I challenge you all to cook. Blog: Bratislava Angular Ward How to Copy, Cut, and Paste Joe Brian Holt – Eleven Tips to Scale Node.js NPM scripts – I relearned something “new” lately.

Panel: Alyssa Nicholl Joe Eames John Papa Ward Bell Special Guests: Martin Jakubik In this episode, the Adventures in Angular panel talk with Martin Jakubik and he has been working with Angular for the last three years. He has one large and one small Angular application, which the panel talks about. Show Topics: 2:31 – Alyssa likes to be called... 2:40 – Alyssa: You have a large and small application – what makes it small? Is it the user-base? 2:56 – Martin: It is one module out of ten or twenty components. 2: 59 – Panelist: Only 1 Angular module? 3:47 – Panelist: Joe went off on how much he hates modules. I am sorry JP we had to throw that in that? 4:04 – Joe: I am an anti-modulist. 4:11 – Martin: Just one module. 4:21 – Panelist: When you are building an application with one module – start us from the beginning, what does it look like? 4:38 – Martin: It is actually quite special. It has to run in an iFrame, and all it does it allows the user to add into the experiment. 5:05 – Alyssa: Is it like a CMS? 5:10 – Martin: It is like Google Optimize. The application is quite simple and every component is in that one module. 5:36 – Panelist: How many do you have? 5:44 – Martin: There are less than 10 services and 20 components at most. 5:57 – Panelist: I feel personally, I feel like that I a decent size? 6:11 – Panelist: That makes perfect sense. If there is no routing or nothing... 6:40 – Panelist: Asks a question, and clarifies the question to Martin. 7:48 – Panelist: It is nice and clean. 7:55 – Panelist: I do, too. 8:08 – Alyssa: How new is it? 8:15 – Panelist: June/July? 8:32 – Martin: I am using the new style. 9:01 – Panelist: I am leery of using it. 9:13 - Panelist: I would like to clarify. When you mention you have 20 components... 9:40 - Panelist: Do it. 10:34 – Panelist: Webpack. Can you explain what that is and how you solved it? 10:57 – Martin: I don’t think I did anything special. I wanted to know how it works. I used webpack and used their configurations. Several months into the project then I... 11:40 – Panelist: Why did you decide not to use the CLI? This is like an Iron Man thing. 11:55 – Panelist: I think it’s a pain thing. 12:05 – Martin: I wanted to know how it works. 12:32 – Martin: I started from scratch, I can’t remember. 12:44 – Panelist: Whenever I use webpack it makes my head spin. 12:56 – Martin: The application was very simple. I was doing more blogging. 13:45 – Panelist: It is doing more configurations on the fly for you. It’s wonderful if it works and if it doesn’t work then I don’t know what you’d do. 14:17 – Martin: That’s why I did it, so I can appreciate all the magic. 14:30 – Panelist: How big is big? 14:36 – Martin: Enterprise level. 100 different components. 15:06 – Panelist chimes in. 15:13 – Panelist: That is complex. 15:28 – Panelist: let’s add more modules to add to the complexity... 15:55 – Alyssa: When you took your app to the CLI was that hard? 16:06 – Martin: That took me one whole day. The module is so simple that’s why. 16:32 – Panelist talks about this topic. 17:39 – Panelist asks a question. 17:53 – Panelist: Fixing any problem ... ever work on tooling help people if they have their stuff in the right file name? 18:18 – Martin: I used Cypress. 18:58 – Panelist: Under what situation would you recommend it to anyone? Do it your own webpack configuration? 19:23 – Martin: Only if... 19:51 – Alyssa: What if you wanted to add a watermark to each file, do you have to stop adding the CLI? 20:13 – Panelist: So am I...what are the boundaries, I don’t know what they are? I’m curious. 20:41 – Panelist: Are you asking, Alyssa, how you would customize it? 21:09 – Panelist: You won’t loose all the features that you get. You now elected out of that place where they had it; webpack configurations. 22:12 – Panelist: What happened to it ejecting? How do you get it out of there? 22:26 – Good question! I have – I like to play with scissors. 22:43 – Advertisement 23:32 – Panelist reads a message from the company. How do you get that voice? 24:10 – First you have to have a really deep sinus cold. 25:00 – Panelist: Do you live without eject? I really don’t care. What I care about...Scratch that! I want to know what kinds of things you can’t do with a CLI that would drive you to do your own application? What other things could you not do in webpack. 25:50 – Martin: I wanted to see how it works. 25:56 – Panelist: Now I use CLI and all it’s features except testing. I use Cypress completely separate than CLI. 26:46 – Panelist: I feel like it’s talking to the one person without a cellphone. 27:01 – Panelist: Wow! I had no concept that life could be like that! I thought you had to have a cellphone. 27:29  – Martin: What does anyone use the CLI for anyways? 27:44 – Martin: I use it for unit tests. 27:52 – Panelist: Another question. 28:30 – Alyssa: You write things out by hand because it’s easier?! 28:44 – Panelist: You copy, and paste and it’s less work. 29:06 – Panelist: It feels easier. 29:22 – Joe: No, I am serious. 29:48 – Joe: Yes, I am amazing. 30:30 – Martin talks about another topic. 30:48 – Alyssa: When you generate a component do you put it into a different file? 31:29 – Panel: We are all friends here and we aren’t shaming anyone here. We are joking here. 32:00 – Alyssa: It’s that he can write it from memory. 33:08 – Panelist: I have been using Vue lately. He also talks about Angular and mentions Sarah Drasner, too. 34:26 – Panelist: Not everyone has a memory like him, though. 35:32 – Panelist: The fourth version of Renderer. 36:28 – Panelist: We are not talking about Nirvana the band, here. 36:46 – Alyssa: It will be the new Renderer. It’s out for you to try. Check out Angular Air. He was trying out IB yourself right now. People are flipping out about it. I am excited to see how my Angular app runs differently now. Here is the code that was generated, here is the code that... I am not sure that there is a promise date. Any secrets heads-up on when it will come out? 38:22 – Panelist: The big question what does this mean for my existing code? Do I have to change my existing code? 38:48 – Alyssa: The Angular team is working so that there are minimal changes. I don’t have a good answer. NGGC. For third-party libraries you run it through and it... I don’t know what that means for the community. 39:49 – Panelist: My hope is that they... 40:03 – Alyssa: For your third-party... 40:18 – Panelist: Question: between your small and large pack? What architectural differences are there? 40:44 – Martin: I have a template edit. 41:03 – Panelist: Come to my... 41:32 – Panel talks about talks that Jon can do. 42:13 – Panelist: True story... The panel is having fun going back and forth with jokes. 43:03 – Panelist: This kind of stuff creeps into production code. That’s the great thing about copy and paste. 43:21 – Panelist: We had a rule, though, if it happens more than once let’s put into our build. 44:20 – It’s 3 hours if you have a CI process, if you don’t... 44:33 – Console.log 44:49 – Martin chimes in. 45:14 – Panelist: Let’s talk about an iFrame in your app? 45:27 – Martin: The point is to be able to do it with any... Make sure that it doesn’t collide. The CSS wasn’t separated. I had to put my application inside an iFrame. 46:27 – Panelist: Thanks for coming on for us, Martin. 46:37 – Picks! 46:44 - Advertisement Links: Martin Jakubik’s Medium How to Copy, Cut, Paste for Beginners by Melanie Pinola Art Joker Blog @AngularMine Cypress Vue Renderer Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Alyssa Question as my pick – About Angular 7...(47:52) True or False? Martin Thank you for having me today. Present your work more. I challenge you all to cook. Blog: Bratislava Angular Ward How to Copy, Cut, and Paste Joe Brian Holt – Eleven Tips to Scale Node.js NPM scripts – I relearned something “new” lately.

Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Jacob Schatz and Taylor Murphy who are apart of the GitLab Team. Jake is a staff developer, and Taylor is a manager at GitLab who started off as a data engineer. To find out more about the GitLab Team check them out here! Also, they are looking to hire, so inquire about the position through GitLab, if interested! The panel talks about Vue, Flux, Node, Flask, Python, D3, and much...much more! Show Topics: 1:51 – Chuck: Introduce yourselves, please. 1:55 – Backgrounds of the guests. 2:45 – Chuck. 2:51 – GitLab (GL): We first adapted Vue at the GitLab team for 2 years now. 3:34 – Chuck: What’s your workflow like through Vue? 3:50 – GL: We are using an application that...Using Python and Flask on the background. Vue CLI throughout the development. 4:35 – Panel asks a question. 4:40 – GitLab answers the question. 5:38 – Panel: Tell us about your secret project? 5:49 – GL: The data team at GL we are trying to solve these questions. How to get from resume to hire? There is data there. So that’s what Meltano helps with. Taylor has a Ph.D. in this area so he knows what’s he’s talking about. 7:30 – Taylor dives into this project via GitLab. 8:52 – GL: Super cool thing is that we are figuring out different ways to do things. It’s really cool stuff that we are doing. 9:23 – Panel: I’ve worked on projects when the frontend people and the data people are doing 2 different things. And they don’t know what each other group is doing. It’s interesting to bring the two things together. I see that teams have a hard time working together when it’s too separated. 10:31 – Panel: Can we get a definition of data scientist vs. a data engineer. 10:44 – Panel: Definitions of DATA SCIENCE and DATA ENGINEER are. 11:39 – GL: That is pretty close. Data science means different things to different people. 12:51 – Panel chimes in. 13:00 – Panel asks a question. 13:11 – GL: When I started working on Meltano... 14:26 – Panel: Looker is a visualization tool; I thought: I bet we can make that. I have been recreating something like Looker. We are trying to replace Looker. We are recreating a lot of the functionality of Looker. 15:10 – Panel will this be called...? 15:31 – Meltano analyze it’s apart of Meltano. Cool thing about Looker it has these files that show the whole visualization – drag and drop. With these files we can do version control. It’s built in – and if you drag it’s apart of a database. We took these files and we... 17:37 – Panel: Define Vue for that, please? 17:49 – GL dives into this topic. 18:40 – GL mentions Node. 18:52 – Chuck: What format does your data take? Do you have different reports that get sent? How does that work? 19:13 – GL: It tells a list of measures and dimensions. I setup our database to... 20:13 – Panel: Question. You chose Vue and it’s working. The reality you could have chosen any other tools. Why really did you choose Vue? 20:30 – GL: I know Vue really well. In the early 2000s I had my... If I have to repeat a process I always use Vue, because it’s the thing I am most comfortable with. This is how I program things very quickly. 21:10 – Panel: How has Vue met or exceeded or not met those expectations? 21:20 – GL: It has exceeded my expectations. One of the things is that as I am trying to staff a team I am trying to write Vue so when people see it they don’t think, “why would he do that?” 22:53 – Flux inspired architecture. 23:07 – GitLab continues the talk. 23:21 – Everything is Flux inspired in the sense that it was an idea to start with and then everybody made alterations and built things on top of that. 23:48 – Panel chimes in. 24:35 – Panel: Can you speak on the process of the workflow and process you work in Taylor and the data science and the frontend of it? 24:54 – GL: It’s the same but different. GitLab talks about Meltano some more, and also Taylor. GL: Taylor is trying to solve all these problems through Meltano. Maybe we can build our own tools? 26:05 – Panel: What’s a Lever Extractor?! 26:14 – GL: Answers this question. 26:25 – Panel: So it’s not a technical term...okay. 26:30 – GitLab continues the talk and discusses different tools. 27:18 – Panel: You are grabbing that data and Taylor is doing his magic? Or is it more integrated? 27:32 – GL answers this question. 29:06 – GitLab: In the beginning we are building that extractors for the other team, but later... The cool thing about Meltano is making it like Word Press. We have an extractor, different directories other things will be discovered by Meltano and discovered by the Gooey. If you write it correctly it can hook on to it. 30:00 – Digital Ocean Advertisement 31:38 – Panel: Meltano is a mix between Python and JavaScript or Vue? 30:43 – GL: Yeah... 31:20 – Panel asks question. How are you orchestrating the data? 31:32 – GL: Eventually it will happen with GitLab CUI. We are thinking we can orchestrate other ways. Right now it’s manually. 32:33 – GL: I like finding some sort of language that doesn’t have an extension...and writing... 32:54 – GL: I’m excited to use a tool that does things the right way like loading and transforming data but the frontend can be a joy to use. A previous company that I worked with and thought: It would be a joy to work with and connect to things that make sense, and do things the “right way”. I hope that’s what we can do with Meltano. I’m not a frontend person, but I appreciate it. 34:03 – GL: This is what I’m going to do...we will have these conversations between Taylor, myself, and our teams. 34:53 – Panel: This is a tool that people need to DL, maybe will you guys host this somewhere as a service. 35:10 – GL: We are trying to get this running. Small steps. It’s not out of the question and it’s not out of the question for this to be a service. 35:33 – GL: What do you want to do with the data warehouse? Your data is yours. 36:06 – Panel: Yeah, you don’t want to be in-charge of that. 36:17 – Panel: Have we asked where the name Meltano came from? 36:30 – GL: It sounds like a weird name. Here is the background of the name of “Meltano” came from. First name was from a sperm whale, it’s a unique name: Cachalot. 38:02 – GL: Conversation continues. 38:38 – Panel chimes in. 38:58 – GL: What does this program offering and doing...This was to help me with the name. 39:27 – GL: Acronym for Meltano: Model / Extract / Load / Transform / Analyze / Notebook / Orchestrate 39:47 – GL continues. They talk about notebooks. 40:19 –Sounds like a Daft Punk album! 40:28 – GL: I am trying to get more on the data science side. 40:57 – Panel: Question. Is Meltano super responsive and quick? 41:17 – GL: It depends on the size of the data, of course, but it is very responsive. 42:11 – GL: That job took 7-8 hours to extract everything for that specific project. 42:39 – GL: There are a lot of moving parts, so that could depend on it slowing it down or speeding it up. 43:01 – When you were building Meltano for your team, for the visualization how do you make decisions on what exactly you are visualizing? 43:18 – GL: That is the tricky part...you are one team. We are trying to find at a point where the data team is happy. One thing for example I put out a bar chart. Team member said that bar charts should always be vertical. So I am learning how they work and their wealth of information on visualization. 44:33 – Panel: Chris always does visualization. 44:48 – GL: Emily is on the team, and knows a lot about that. The correct way to visualize data so it doesn’t just look “cool.” You want it to be useful. Chart JS is what I use. 45:32 – Panel: I have used Chart JS before, too. 46:00 – Chris: I really like... 46:37 – Panel continues this conversation. 47:01 – Panel: Keynote will be given by...at this conference. 47:11 – GL continues to talk about this conversation. From nothing to something in a short amount of time. When I showed people: 47:55 – Panel: are you using Vue transitions? 48:09 – GL: Nope not even slightly. My plan was to use Vue transitions but it’s icing on the cake. Just get it working. 48:29 – Panel: A link of how I use... 49:14 – GL: This is a very small amount of code to where you are. It’s not like you had to re-implement triangles or anything like that. 49:36 – Panel: It does take some time but once you get it – you get it. 49:59 – Panel: When working with axis it can get hairy. 50:52 – GL: D3 really does a lot of the math for you and fits right it once you know how it works. You can draw anything with HTML. Check Links. 52:19 – Panel: There are a million different ways to do visualizations. There is math behind... 53:08 – Panel: D3 also helps with de-clustering. 53:25 – Panel: Any recommendations with someone who wants to dive into D3? 53:37 – GL: Tutorials have gotten better over time. 53:57 – Panel continues the conversation. 54:19 – GL: D3 Version 4 and 5 was one big library. You have C3 – what’s your opinion on C3? 55:00 – GL: have no strong opinions. 55:03 – Chuck chimes in. 55:18 – Panel continues this conversation. She talks about how she had a hard time learning D3, and how everything clicked once she learned it. 55:55 – GL: Main reason why I didn’t use D3 because... 56:07 – GL: If you were a “real” developer you’d... 56:35 – Panel: Let’s go to Picks! 56:40 – Advertisement – Code Badges Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Meltano Looker Node Flux Taylor Python Chart JS React Chris Fritz – JS Fiddle D3 Chris Lema – Building an Online Course... Vuetify The First Vue.js Spring Vue CLI 3.0 Online Tutorials To Help You Get Ahead Hacker Noon – Finding Creativity in Software Engineer Indiegogo Create Awesome Vue.js Apps With... Data Sketches Vue.js in Action Benjamin Hardy’s Website Data Intensive: Don’t Just Hack It Together Article: How to Pick a Career...By Tim Urban Taylor A. Murphy’s Twitter Email: tmurphy@gitlab.com GitLab – Meet our Team Jacob Schatz’s Twitter Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Joe Ben Hardy on Medium Set Goals Chris Vue CLI 3 Vue CLI 3 on Medium Vue Dev Tools Get a new computer John Vuetify Divya Data Sketch One climb Finding Creativity in Software Engineering Erik Create Awesome Vue.js Vue.js in action Charles Get a Coder Job Building an online course Jacob Alma CCS Read source code Allen Kay Taylor Designing Data-Intensive Applications Wait But Why

Panel: Alyssa Nicholl Joe Eames John Papa Ward Bell Special Guests: Martin Jakubik In this episode, the Adventures in Angular panel talk with Martin Jakubik and he has been working with Angular for the last three years. He has one large and one small Angular application, which the panel talks about. Show Topics: 2:31 – Alyssa likes to be called... 2:40 – Alyssa: You have a large and small application – what makes it small? Is it the user-base? 2:56 – Martin: It is one module out of ten or twenty components. 2: 59 – Panelist: Only 1 Angular module? 3:47 – Panelist: Joe went off on how much he hates modules. I am sorry JP we had to throw that in that? 4:04 – Joe: I am an anti-modulist. 4:11 – Martin: Just one module. 4:21 – Panelist: When you are building an application with one module – start us from the beginning, what does it look like? 4:38 – Martin: It is actually quite special. It has to run in an iFrame, and all it does it allows the user to add into the experiment. 5:05 – Alyssa: Is it like a CMS? 5:10 – Martin: It is like Google Optimize. The application is quite simple and every component is in that one module. 5:36 – Panelist: How many do you have? 5:44 – Martin: There are less than 10 services and 20 components at most. 5:57 – Panelist: I feel personally, I feel like that I a decent size? 6:11 – Panelist: That makes perfect sense. If there is no routing or nothing... 6:40 – Panelist: Asks a question, and clarifies the question to Martin. 7:48 – Panelist: It is nice and clean. 7:55 – Panelist: I do, too. 8:08 – Alyssa: How new is it? 8:15 – Panelist: June/July? 8:32 – Martin: I am using the new style. 9:01 – Panelist: I am leery of using it. 9:13 - Panelist: I would like to clarify. When you mention you have 20 components... 9:40 - Panelist: Do it. 10:34 – Panelist: Webpack. Can you explain what that is and how you solved it? 10:57 – Martin: I don’t think I did anything special. I wanted to know how it works. I used webpack and used their configurations. Several months into the project then I... 11:40 – Panelist: Why did you decide not to use the CLI? This is like an Iron Man thing. 11:55 – Panelist: I think it’s a pain thing. 12:05 – Martin: I wanted to know how it works. 12:32 – Martin: I started from scratch, I can’t remember. 12:44 – Panelist: Whenever I use webpack it makes my head spin. 12:56 – Martin: The application was very simple. I was doing more blogging. 13:45 – Panelist: It is doing more configurations on the fly for you. It’s wonderful if it works and if it doesn’t work then I don’t know what you’d do. 14:17 – Martin: That’s why I did it, so I can appreciate all the magic. 14:30 – Panelist: How big is big? 14:36 – Martin: Enterprise level. 100 different components. 15:06 – Panelist chimes in. 15:13 – Panelist: That is complex. 15:28 – Panelist: let’s add more modules to add to the complexity... 15:55 – Alyssa: When you took your app to the CLI was that hard? 16:06 – Martin: That took me one whole day. The module is so simple that’s why. 16:32 – Panelist talks about this topic. 17:39 – Panelist asks a question. 17:53 – Panelist: Fixing any problem ... ever work on tooling help people if they have their stuff in the right file name? 18:18 – Martin: I used Cypress. 18:58 – Panelist: Under what situation would you recommend it to anyone? Do it your own webpack configuration? 19:23 – Martin: Only if... 19:51 – Alyssa: What if you wanted to add a watermark to each file, do you have to stop adding the CLI? 20:13 – Panelist: So am I...what are the boundaries, I don’t know what they are? I’m curious. 20:41 – Panelist: Are you asking, Alyssa, how you would customize it? 21:09 – Panelist: You won’t loose all the features that you get. You now elected out of that place where they had it; webpack configurations. 22:12 – Panelist: What happened to it ejecting? How do you get it out of there? 22:26 – Good question! I have – I like to play with scissors. 22:43 – Advertisement 23:32 – Panelist reads a message from the company. How do you get that voice? 24:10 – First you have to have a really deep sinus cold. 25:00 – Panelist: Do you live without eject? I really don’t care. What I care about...Scratch that! I want to know what kinds of things you can’t do with a CLI that would drive you to do your own application? What other things could you not do in webpack. 25:50 – Martin: I wanted to see how it works. 25:56 – Panelist: Now I use CLI and all it’s features except testing. I use Cypress completely separate than CLI. 26:46 – Panelist: I feel like it’s talking to the one person without a cellphone. 27:01 – Panelist: Wow! I had no concept that life could be like that! I thought you had to have a cellphone. 27:29  – Martin: What does anyone use the CLI for anyways? 27:44 – Martin: I use it for unit tests. 27:52 – Panelist: Another question. 28:30 – Alyssa: You write things out by hand because it’s easier?! 28:44 – Panelist: You copy, and paste and it’s less work. 29:06 – Panelist: It feels easier. 29:22 – Joe: No, I am serious. 29:48 – Joe: Yes, I am amazing. 30:30 – Martin talks about another topic. 30:48 – Alyssa: When you generate a component do you put it into a different file? 31:29 – Panel: We are all friends here and we aren’t shaming anyone here. We are joking here. 32:00 – Alyssa: It’s that he can write it from memory. 33:08 – Panelist: I have been using Vue lately. He also talks about Angular and mentions Sarah Drasner, too. 34:26 – Panelist: Not everyone has a memory like him, though. 35:32 – Panelist: The fourth version of Renderer. 36:28 – Panelist: We are not talking about Nirvana the band, here. 36:46 – Alyssa: It will be the new Renderer. It’s out for you to try. Check out Angular Air. He was trying out IB yourself right now. People are flipping out about it. I am excited to see how my Angular app runs differently now. Here is the code that was generated, here is the code that... I am not sure that there is a promise date. Any secrets heads-up on when it will come out? 38:22 – Panelist: The big question what does this mean for my existing code? Do I have to change my existing code? 38:48 – Alyssa: The Angular team is working so that there are minimal changes. I don’t have a good answer. NGGC. For third-party libraries you run it through and it... I don’t know what that means for the community. 39:49 – Panelist: My hope is that they... 40:03 – Alyssa: For your third-party... 40:18 – Panelist: Question: between your small and large pack? What architectural differences are there? 40:44 – Martin: I have a template edit. 41:03 – Panelist: Come to my... 41:32 – Panel talks about talks that Jon can do. 42:13 – Panelist: True story... The panel is having fun going back and forth with jokes. 43:03 – Panelist: This kind of stuff creeps into production code. That’s the great thing about copy and paste. 43:21 – Panelist: We had a rule, though, if it happens more than once let’s put into our build. 44:20 – It’s 3 hours if you have a CI process, if you don’t... 44:33 – Console.log 44:49 – Martin chimes in. 45:14 – Panelist: Let’s talk about an iFrame in your app? 45:27 – Martin: The point is to be able to do it with any... Make sure that it doesn’t collide. The CSS wasn’t separated. I had to put my application inside an iFrame. 46:27 – Panelist: Thanks for coming on for us, Martin. 46:37 – Picks! 46:44 - Advertisement Links: Martin Jakubik’s Medium How to Copy, Cut, Paste for Beginners by Melanie Pinola Art Joker Blog @AngularMine Cypress Vue Renderer Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Alyssa Question as my pick – About Angular 7...(47:52) True or False? Martin Thank you for having me today. Present your work more. I challenge you all to cook. Blog: Bratislava Angular Ward How to Copy, Cut, and Paste Joe Brian Holt – Eleven Tips to Scale Node.js NPM scripts – I relearned something “new” lately.

Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Jacob Schatz and Taylor Murphy who are apart of the GitLab Team. Jake is a staff developer, and Taylor is a manager at GitLab who started off as a data engineer. To find out more about the GitLab Team check them out here! Also, they are looking to hire, so inquire about the position through GitLab, if interested! The panel talks about Vue, Flux, Node, Flask, Python, D3, and much...much more! Show Topics: 1:51 – Chuck: Introduce yourselves, please. 1:55 – Backgrounds of the guests. 2:45 – Chuck. 2:51 – GitLab (GL): We first adapted Vue at the GitLab team for 2 years now. 3:34 – Chuck: What’s your workflow like through Vue? 3:50 – GL: We are using an application that...Using Python and Flask on the background. Vue CLI throughout the development. 4:35 – Panel asks a question. 4:40 – GitLab answers the question. 5:38 – Panel: Tell us about your secret project? 5:49 – GL: The data team at GL we are trying to solve these questions. How to get from resume to hire? There is data there. So that’s what Meltano helps with. Taylor has a Ph.D. in this area so he knows what’s he’s talking about. 7:30 – Taylor dives into this project via GitLab. 8:52 – GL: Super cool thing is that we are figuring out different ways to do things. It’s really cool stuff that we are doing. 9:23 – Panel: I’ve worked on projects when the frontend people and the data people are doing 2 different things. And they don’t know what each other group is doing. It’s interesting to bring the two things together. I see that teams have a hard time working together when it’s too separated. 10:31 – Panel: Can we get a definition of data scientist vs. a data engineer. 10:44 – Panel: Definitions of DATA SCIENCE and DATA ENGINEER are. 11:39 – GL: That is pretty close. Data science means different things to different people. 12:51 – Panel chimes in. 13:00 – Panel asks a question. 13:11 – GL: When I started working on Meltano... 14:26 – Panel: Looker is a visualization tool; I thought: I bet we can make that. I have been recreating something like Looker. We are trying to replace Looker. We are recreating a lot of the functionality of Looker. 15:10 – Panel will this be called...? 15:31 – Meltano analyze it’s apart of Meltano. Cool thing about Looker it has these files that show the whole visualization – drag and drop. With these files we can do version control. It’s built in – and if you drag it’s apart of a database. We took these files and we... 17:37 – Panel: Define Vue for that, please? 17:49 – GL dives into this topic. 18:40 – GL mentions Node. 18:52 – Chuck: What format does your data take? Do you have different reports that get sent? How does that work? 19:13 – GL: It tells a list of measures and dimensions. I setup our database to... 20:13 – Panel: Question. You chose Vue and it’s working. The reality you could have chosen any other tools. Why really did you choose Vue? 20:30 – GL: I know Vue really well. In the early 2000s I had my... If I have to repeat a process I always use Vue, because it’s the thing I am most comfortable with. This is how I program things very quickly. 21:10 – Panel: How has Vue met or exceeded or not met those expectations? 21:20 – GL: It has exceeded my expectations. One of the things is that as I am trying to staff a team I am trying to write Vue so when people see it they don’t think, “why would he do that?” 22:53 – Flux inspired architecture. 23:07 – GitLab continues the talk. 23:21 – Everything is Flux inspired in the sense that it was an idea to start with and then everybody made alterations and built things on top of that. 23:48 – Panel chimes in. 24:35 – Panel: Can you speak on the process of the workflow and process you work in Taylor and the data science and the frontend of it? 24:54 – GL: It’s the same but different. GitLab talks about Meltano some more, and also Taylor. GL: Taylor is trying to solve all these problems through Meltano. Maybe we can build our own tools? 26:05 – Panel: What’s a Lever Extractor?! 26:14 – GL: Answers this question. 26:25 – Panel: So it’s not a technical term...okay. 26:30 – GitLab continues the talk and discusses different tools. 27:18 – Panel: You are grabbing that data and Taylor is doing his magic? Or is it more integrated? 27:32 – GL answers this question. 29:06 – GitLab: In the beginning we are building that extractors for the other team, but later... The cool thing about Meltano is making it like Word Press. We have an extractor, different directories other things will be discovered by Meltano and discovered by the Gooey. If you write it correctly it can hook on to it. 30:00 – Digital Ocean Advertisement 31:38 – Panel: Meltano is a mix between Python and JavaScript or Vue? 30:43 – GL: Yeah... 31:20 – Panel asks question. How are you orchestrating the data? 31:32 – GL: Eventually it will happen with GitLab CUI. We are thinking we can orchestrate other ways. Right now it’s manually. 32:33 – GL: I like finding some sort of language that doesn’t have an extension...and writing... 32:54 – GL: I’m excited to use a tool that does things the right way like loading and transforming data but the frontend can be a joy to use. A previous company that I worked with and thought: It would be a joy to work with and connect to things that make sense, and do things the “right way”. I hope that’s what we can do with Meltano. I’m not a frontend person, but I appreciate it. 34:03 – GL: This is what I’m going to do...we will have these conversations between Taylor, myself, and our teams. 34:53 – Panel: This is a tool that people need to DL, maybe will you guys host this somewhere as a service. 35:10 – GL: We are trying to get this running. Small steps. It’s not out of the question and it’s not out of the question for this to be a service. 35:33 – GL: What do you want to do with the data warehouse? Your data is yours. 36:06 – Panel: Yeah, you don’t want to be in-charge of that. 36:17 – Panel: Have we asked where the name Meltano came from? 36:30 – GL: It sounds like a weird name. Here is the background of the name of “Meltano” came from. First name was from a sperm whale, it’s a unique name: Cachalot. 38:02 – GL: Conversation continues. 38:38 – Panel chimes in. 38:58 – GL: What does this program offering and doing...This was to help me with the name. 39:27 – GL: Acronym for Meltano: Model / Extract / Load / Transform / Analyze / Notebook / Orchestrate 39:47 – GL continues. They talk about notebooks. 40:19 –Sounds like a Daft Punk album! 40:28 – GL: I am trying to get more on the data science side. 40:57 – Panel: Question. Is Meltano super responsive and quick? 41:17 – GL: It depends on the size of the data, of course, but it is very responsive. 42:11 – GL: That job took 7-8 hours to extract everything for that specific project. 42:39 – GL: There are a lot of moving parts, so that could depend on it slowing it down or speeding it up. 43:01 – When you were building Meltano for your team, for the visualization how do you make decisions on what exactly you are visualizing? 43:18 – GL: That is the tricky part...you are one team. We are trying to find at a point where the data team is happy. One thing for example I put out a bar chart. Team member said that bar charts should always be vertical. So I am learning how they work and their wealth of information on visualization. 44:33 – Panel: Chris always does visualization. 44:48 – GL: Emily is on the team, and knows a lot about that. The correct way to visualize data so it doesn’t just look “cool.” You want it to be useful. Chart JS is what I use. 45:32 – Panel: I have used Chart JS before, too. 46:00 – Chris: I really like... 46:37 – Panel continues this conversation. 47:01 – Panel: Keynote will be given by...at this conference. 47:11 – GL continues to talk about this conversation. From nothing to something in a short amount of time. When I showed people: 47:55 – Panel: are you using Vue transitions? 48:09 – GL: Nope not even slightly. My plan was to use Vue transitions but it’s icing on the cake. Just get it working. 48:29 – Panel: A link of how I use... 49:14 – GL: This is a very small amount of code to where you are. It’s not like you had to re-implement triangles or anything like that. 49:36 – Panel: It does take some time but once you get it – you get it. 49:59 – Panel: When working with axis it can get hairy. 50:52 – GL: D3 really does a lot of the math for you and fits right it once you know how it works. You can draw anything with HTML. Check Links. 52:19 – Panel: There are a million different ways to do visualizations. There is math behind... 53:08 – Panel: D3 also helps with de-clustering. 53:25 – Panel: Any recommendations with someone who wants to dive into D3? 53:37 – GL: Tutorials have gotten better over time. 53:57 – Panel continues the conversation. 54:19 – GL: D3 Version 4 and 5 was one big library. You have C3 – what’s your opinion on C3? 55:00 – GL: have no strong opinions. 55:03 – Chuck chimes in. 55:18 – Panel continues this conversation. She talks about how she had a hard time learning D3, and how everything clicked once she learned it. 55:55 – GL: Main reason why I didn’t use D3 because... 56:07 – GL: If you were a “real” developer you’d... 56:35 – Panel: Let’s go to Picks! 56:40 – Advertisement – Code Badges Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Meltano Looker Node Flux Taylor Python Chart JS React Chris Fritz – JS Fiddle D3 Chris Lema – Building an Online Course... Vuetify The First Vue.js Spring Vue CLI 3.0 Online Tutorials To Help You Get Ahead Hacker Noon – Finding Creativity in Software Engineer Indiegogo Create Awesome Vue.js Apps With... Data Sketches Vue.js in Action Benjamin Hardy’s Website Data Intensive: Don’t Just Hack It Together Article: How to Pick a Career...By Tim Urban Taylor A. Murphy’s Twitter Email: tmurphy@gitlab.com GitLab – Meet our Team Jacob Schatz’s Twitter Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Joe Ben Hardy on Medium Set Goals Chris Vue CLI 3 Vue CLI 3 on Medium Vue Dev Tools Get a new computer John Vuetify Divya Data Sketch One climb Finding Creativity in Software Engineering Erik Create Awesome Vue.js Vue.js in action Charles Get a Coder Job Building an online course Jacob Alma CCS Read source code Allen Kay Taylor Designing Data-Intensive Applications Wait But Why

In this Hasty Treat, Scott and Wes talk about positivity in the web industry - how it can affect you, your work, and the people around you. NativeScript - Sponsor NativeScript is an open source framework for building truly native mobile apps with Angular, Vue.js, TypeScript, or JavaScript. It’s is a great way for front-end developers to get started building native mobile apps. Get started today at nativescript.org/syntax. Show Notes The tech industry is always on the cutting edge and we’re starting to see a shift in how we deal with positivity and negativity. 3:18 - The effects of negativity and how the web industry is improving Mental health awareness is very real Stack overflow sees that it needs to change Linus Torvalds’ apology Negativity is a disease, and it spreads Positivity is a force as well You can be constructive while still being nice Dan Abramov, Addy Osmani, Sarah Drasner are all amazing examples of people pushing the web forward while having a smile on their face 11:50 - Healthy ways to approach disagreements Never assume malice Kill them with kindness Take note of the people you admire and how they deal with aggressiveness 17:08 - The power of positivity Inspire the change you want to see It’s good for your productivity - it makes you feel good Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

Flute 360 | Episode 26: “A Journal Entry” (24:09) Today, Heidi talks about various subjects in this “Journal Entry” episode. She discusses her thoughts on education, hobbies such as reading, writing show notes for her husband’s business, and how all of these things can be related to flute performance. It’s an episode where she get’s personal and “jots” down her ideas via this podcast episode. Enjoy! Episode 26 – Main Points: Introduction (0:43) Unwinding (1:28) Espresso (2:06) Dear Journal (2:25) Writing is one of my passions. (2:48) Reading “Hans Brinker” (3:08) Words are powerful! (4:12) Current studio (5:00) I am proud to be their teacher. (6:41) Grateful for past teachers (6:53) Small tribute to Dr. Lisa Garner Santa (8:20) Time is precious (9:23) Find ease and comfort in the present. (10:21) Tarrant County College – Music Appreciation Course (10:56) How can “X” help me help be a better teacher or performer? (12:19) Writing show notes for husband’s business. (13:02) Value in those part-time jobs. (14:07) Practice anywhere / Mental practice (16:00) Inspired by Sarah Drasner (17:26) Reading to help with creativity! (19:49) Conclusion (22:15) Episode 26 – Resources Mentioned: Vietnamese Cuisine – Pho Soup Nespresso Pods Hans Brinker or the Silver Skates by Mary Mapes Dodge Views on Vue – Episode 029 – Guest Artist: Sarah Drasner Time Stamp – 34:28 Contact Information: Heidi Kay Begay’s Website Email: heidikaybegay@gmail.com J&K Productions’ Website

Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Sarah Drasner, and John Papa is my boss! Sarah talks about the Vue alongside the panel. She goes into her many passions, and talks about how education and being a teacher is something that is quite important for her. Check out today’s episode to hear all of these topics, plus more! Show Topics: 1:42 – Chuck: Let’s talk about your February article, Sarah! 1:57 – Sarah: Sure! I have a great relationship with SMASHING magazine. They reached out to me and we started talking, because they noticed that people had questions about... It probably was one of my most popular articles. People were ready to graduate from jQuery. 3:36 – Panelist: I have gotten a lot of great feedback from people on this article, too. 4:00 – Sarah: it is a baseline. If they have heard about Vue and don’t’ know where to go from there. 4:15 – Panelist: It’s a great way to introduce yourself to people who don’t know you. 4:30 – Sarah continues the conversation. jQuery for a while was the “cheese stands alone” for a long time. 5:39 – Panelist chimes in. 6:15 – Like a long-term support system. 6:46 – Chuck: I am usually writing apps for myself. Lots of To Do Apps. 7:18 – Chuck I wonder how much I can run off of jQuery? 7:37 – Sarah: jQuery to Vue? I mean personally think that it’s much more obtainable. The improvements are great. I feel like I am more in-control when I use Vue. I tell people to try a project for a certain amount of time. I can tell you that how much I like the frameworks, but you have to try it. 9:34 – Panelist: Less code in Vue. 9:59 – Chuck: I do like the fact that... 10:14 – Panelist: you have to be disciplined. I am not always disciplined if I want to be honest. Where should I put a state that depends on another state? 10:42 – Sarah to Chris – Your style guide is helpful, Chris. If you really don’t mind in a certain framework, look at what people suggest based on their experience. Then you are not making those decisions for yourself, but you can see what works for others. 11:33 – Panelist: The style guides help them feel more confident for the people that he has talked to. They made more comfortable to feel more vulnerable. 12:13 – Sarah: That’s why I made those snippets for VS code. If it gives me a template then those little pieces of helpers can help keep your code more attainable. To make sure that the code review is on the up-and-up. 13:05 – Panelist: I do love those snippets. It does help me not to worry about missing certain things. I use the snippets for Live Demos. The feedback is that they don’t want to use Vue, but the snippets make it look really cool. 13:47 – Panelist: Many people don’t know this, but... 14:05 – Chuck: I know people are fans of jQuery...why do you hate jQuery? 14:26 – Sarah: I got some negative feedback and positive feedback. A debate started actually within these conversations. It happened around me, actually. What people know vs. what people don’t know. It was an interesting discussion, too. 15:26 – Panelist: Vue has this easy drop and save tag. Sarah, in your opinion... 15:58 – Sarah: Scotch IO has great articles out there. There are tons of writers out there. Actually, because there is nice ramp-up, that does help with adaption; just all together. That has had a lot to do with it, in addition through word-of-mouth. Whether if they, do or don’t, know how to use framework. 17:35 – Panelist: One number one thing they don’t’ like about Angular is that 99.9% time is that they are struggling with setup, bill process, when to set up different flags. It’s actually using the tool. 18:35 – Sarah: I wasn’t looking out to switch to Vue. At first, I was thinking: “Do I really have to try this out...? Why do I have to learn this, too?” I actually fell in love with it during the process. You can see this “falling in-love” on my Twitter. That for me has been one of the best experiences for me. Programs: Babble, Sass. This I would have to install one-by-one. To note that the developer’s experience is pretty important. 20:15 – Panelist: To have something there can create some anxiety for them. Even if they don’t need to know what those folders are can create anxiety. 20:59 – Sarah continues this conversation with her insights and comments. 22:00 – Panelist asks Sarah a question. 22:12 – Sarah Drasner: It really varies depending on the users’ experience. 23:17 – Panelist: If you are happy doing what you are doing – keep it. Don’t change. 23:32 – Sarah: The company dictates a lot of things for you. Lots of people don’t get to decide. If you are working with one giant build, then maybe... 24:27 – Panelist talks about a Vue template, and other topics. 25:16 – Sarah: Code Pen. 26:05 – Code Pen continues to be the topic of this conversation. 27:43 – Digital Ocean’s Advertisement. 27:21 – Chris to Sarah: You get people super excited about Vue because your demos are the BEST demonstrations.  30:30 – Fidget Spinner. 31:16 – Are you into animation? 31:28 – Sarah mentions: Smashing Magazine. Sarah’s dream job was to be in computer animation. She went to college and didn’t want to draw every frame. I can’t keep doing this. Eventually this led to we development. Full circle, I am back to what I originally fell in-love with. Coding is one of my favorite things. In animation anything can happen! In real-life you are limited, but with animation you can let your mind go wild. You can do anything. That is exciting for me. The web has so many different capabilities. 34:19 – Can you talk about your background as an educator? 34:28 – Sarah Drasner: I was a professor in the Greek Islands. I think teaching gives me so much joy. Especially for me to see the light in your student’s eyes. I think learning is really hard, so making that process easier for people is a goal of mine. I want to make materials easier for them to comprehend a certain topic or the material-at-hand. At first, I thought JavaScript was hard. Connecting the dots for people is worth it to me. It’s scaling my understanding. It’s moving things through the community – scale that knowledge. 36:43 – Creating resources for students that they never had. People, I am sure, are grateful for that. 37:19 – Sarah: t’s a really valuable thing to share this with one another. You can be a little bit selfish and when you have to teach a concept to a student this material will be embedded into you easier/better because you have to explain it. 38:12 – Sarah: What does the H Stand for? This article came up, because I had to answer someone’s question. Writing an article really solidifies your knowledge! 39:02 – Where do you like to teach? 39:07 – Sarah: Frontend Masters is one of them. It continues afterwards. 40:35 – Sarah: I still like making online content, the feedback you get in-person is very wonderful. 41:13 – Panelist adds comments. 41:47 – Sarah continues the conversation and talks about a specific conference. She talks about Nigeria and Nigerians. 43:06 – Sarah: It’s actually a huge venue. We rented a media company to help with stable Internet and web access. Just making sure that everything will be stable. It’s a real conference; it’s just free to them. It’s in a couple of days. I am feeling like that it’s a lot of stuff, but I know it will be valuable. We are looking for sponsorships!! It’s a great cause and totally engaging. 44:22 – Are you guys ready for your talks? 46:42 – Sarah: Her talk is going to be one of the best talks there. It can be quite political, but she doesn’t do that. What changes for the developer? It is quite masterful. She is doing a repeat performance. 47:16 – Panelist: I try... 47:24 – Sarah Drasner: I will be talking, too. 48:28 – Dumb jokes. 48:50 – Sarah: I feel that jokes don’t translate well across different countries. You have to find something more universal. I pick things that are universal to the human experience. 49:40 – Sarah: I guess in the introduction, I say who I am and then I bring Clippy on the stage... In addition, sometimes, TERRIBLE jokes go a long way! To show that you are actually human! 51:36 – A Wiki later... 51:48 – I put the bad jokes into the delivery. People need something to lighten the mood. 52:21 – Clippy and Microsoft Bob. 52:32 – E-Book Code Badges! 53:12 – Picks! Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Sarah Drasner’s Article Sarah Drasner’s Twitter Sarah Drasner’s Website Sarah Drasner’s GitHub Sarah Drasner’s LinkedIn Sarah Drasner’s CSS-Tricks Sarah Drasner’s Medium Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Divya Sasidharan Article - Build a State Management Article - Where Vim Came From? Chris Fritz Dev Tools – Routing Tab and others Open Collective Sarah Drasner My friend’s speech / coworker, Ozcon Conference in Kenya the following year! Erik Hanchett Fidget Spinner Coder.Com Charles Max Wood Code Badge Notion.So

Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Sarah Drasner, and John Papa is my boss! Sarah talks about the Vue alongside the panel. She goes into her many passions, and talks about how education and being a teacher is something that is quite important for her. Check out today’s episode to hear all of these topics, plus more! Show Topics: 1:42 – Chuck: Let’s talk about your February article, Sarah! 1:57 – Sarah: Sure! I have a great relationship with SMASHING magazine. They reached out to me and we started talking, because they noticed that people had questions about... It probably was one of my most popular articles. People were ready to graduate from jQuery. 3:36 – Panelist: I have gotten a lot of great feedback from people on this article, too. 4:00 – Sarah: it is a baseline. If they have heard about Vue and don’t’ know where to go from there. 4:15 – Panelist: It’s a great way to introduce yourself to people who don’t know you. 4:30 – Sarah continues the conversation. jQuery for a while was the “cheese stands alone” for a long time. 5:39 – Panelist chimes in. 6:15 – Like a long-term support system. 6:46 – Chuck: I am usually writing apps for myself. Lots of To Do Apps. 7:18 – Chuck I wonder how much I can run off of jQuery? 7:37 – Sarah: jQuery to Vue? I mean personally think that it’s much more obtainable. The improvements are great. I feel like I am more in-control when I use Vue. I tell people to try a project for a certain amount of time. I can tell you that how much I like the frameworks, but you have to try it. 9:34 – Panelist: Less code in Vue. 9:59 – Chuck: I do like the fact that... 10:14 – Panelist: you have to be disciplined. I am not always disciplined if I want to be honest. Where should I put a state that depends on another state? 10:42 – Sarah to Chris – Your style guide is helpful, Chris. If you really don’t mind in a certain framework, look at what people suggest based on their experience. Then you are not making those decisions for yourself, but you can see what works for others. 11:33 – Panelist: The style guides help them feel more confident for the people that he has talked to. They made more comfortable to feel more vulnerable. 12:13 – Sarah: That’s why I made those snippets for VS code. If it gives me a template then those little pieces of helpers can help keep your code more attainable. To make sure that the code review is on the up-and-up. 13:05 – Panelist: I do love those snippets. It does help me not to worry about missing certain things. I use the snippets for Live Demos. The feedback is that they don’t want to use Vue, but the snippets make it look really cool. 13:47 – Panelist: Many people don’t know this, but... 14:05 – Chuck: I know people are fans of jQuery...why do you hate jQuery? 14:26 – Sarah: I got some negative feedback and positive feedback. A debate started actually within these conversations. It happened around me, actually. What people know vs. what people don’t know. It was an interesting discussion, too. 15:26 – Panelist: Vue has this easy drop and save tag. Sarah, in your opinion... 15:58 – Sarah: Scotch IO has great articles out there. There are tons of writers out there. Actually, because there is nice ramp-up, that does help with adaption; just all together. That has had a lot to do with it, in addition through word-of-mouth. Whether if they, do or don’t, know how to use framework. 17:35 – Panelist: One number one thing they don’t’ like about Angular is that 99.9% time is that they are struggling with setup, bill process, when to set up different flags. It’s actually using the tool. 18:35 – Sarah: I wasn’t looking out to switch to Vue. At first, I was thinking: “Do I really have to try this out...? Why do I have to learn this, too?” I actually fell in love with it during the process. You can see this “falling in-love” on my Twitter. That for me has been one of the best experiences for me. Programs: Babble, Sass. This I would have to install one-by-one. To note that the developer’s experience is pretty important. 20:15 – Panelist: To have something there can create some anxiety for them. Even if they don’t need to know what those folders are can create anxiety. 20:59 – Sarah continues this conversation with her insights and comments. 22:00 – Panelist asks Sarah a question. 22:12 – Sarah Drasner: It really varies depending on the users’ experience. 23:17 – Panelist: If you are happy doing what you are doing – keep it. Don’t change. 23:32 – Sarah: The company dictates a lot of things for you. Lots of people don’t get to decide. If you are working with one giant build, then maybe... 24:27 – Panelist talks about a Vue template, and other topics. 25:16 – Sarah: Code Pen. 26:05 – Code Pen continues to be the topic of this conversation. 27:43 – Digital Ocean’s Advertisement. 27:21 – Chris to Sarah: You get people super excited about Vue because your demos are the BEST demonstrations.  30:30 – Fidget Spinner. 31:16 – Are you into animation? 31:28 – Sarah mentions: Smashing Magazine. Sarah’s dream job was to be in computer animation. She went to college and didn’t want to draw every frame. I can’t keep doing this. Eventually this led to we development. Full circle, I am back to what I originally fell in-love with. Coding is one of my favorite things. In animation anything can happen! In real-life you are limited, but with animation you can let your mind go wild. You can do anything. That is exciting for me. The web has so many different capabilities. 34:19 – Can you talk about your background as an educator? 34:28 – Sarah Drasner: I was a professor in the Greek Islands. I think teaching gives me so much joy. Especially for me to see the light in your student’s eyes. I think learning is really hard, so making that process easier for people is a goal of mine. I want to make materials easier for them to comprehend a certain topic or the material-at-hand. At first, I thought JavaScript was hard. Connecting the dots for people is worth it to me. It’s scaling my understanding. It’s moving things through the community – scale that knowledge. 36:43 – Creating resources for students that they never had. People, I am sure, are grateful for that. 37:19 – Sarah: t’s a really valuable thing to share this with one another. You can be a little bit selfish and when you have to teach a concept to a student this material will be embedded into you easier/better because you have to explain it. 38:12 – Sarah: What does the H Stand for? This article came up, because I had to answer someone’s question. Writing an article really solidifies your knowledge! 39:02 – Where do you like to teach? 39:07 – Sarah: Frontend Masters is one of them. It continues afterwards. 40:35 – Sarah: I still like making online content, the feedback you get in-person is very wonderful. 41:13 – Panelist adds comments. 41:47 – Sarah continues the conversation and talks about a specific conference. She talks about Nigeria and Nigerians. 43:06 – Sarah: It’s actually a huge venue. We rented a media company to help with stable Internet and web access. Just making sure that everything will be stable. It’s a real conference; it’s just free to them. It’s in a couple of days. I am feeling like that it’s a lot of stuff, but I know it will be valuable. We are looking for sponsorships!! It’s a great cause and totally engaging. 44:22 – Are you guys ready for your talks? 46:42 – Sarah: Her talk is going to be one of the best talks there. It can be quite political, but she doesn’t do that. What changes for the developer? It is quite masterful. She is doing a repeat performance. 47:16 – Panelist: I try... 47:24 – Sarah Drasner: I will be talking, too. 48:28 – Dumb jokes. 48:50 – Sarah: I feel that jokes don’t translate well across different countries. You have to find something more universal. I pick things that are universal to the human experience. 49:40 – Sarah: I guess in the introduction, I say who I am and then I bring Clippy on the stage... In addition, sometimes, TERRIBLE jokes go a long way! To show that you are actually human! 51:36 – A Wiki later... 51:48 – I put the bad jokes into the delivery. People need something to lighten the mood. 52:21 – Clippy and Microsoft Bob. 52:32 – E-Book Code Badges! 53:12 – Picks! Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Sarah Drasner’s Article Sarah Drasner’s Twitter Sarah Drasner’s Website Sarah Drasner’s GitHub Sarah Drasner’s LinkedIn Sarah Drasner’s CSS-Tricks Sarah Drasner’s Medium Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Divya Sasidharan Article - Build a State Management Article - Where Vim Came From? Chris Fritz Dev Tools – Routing Tab and others Open Collective Sarah Drasner My friend’s speech / coworker, Ozcon Conference in Kenya the following year! Erik Hanchett Fidget Spinner Coder.Com Charles Max Wood Code Badge Notion.So