AMA: Developer Experience, DevRel, Jamstack, JavaScript, and more!

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of "Learn with Jason." Today on the show we're going to do an Ask Me Anything. It's been a while since we've done one of these. I feel it's always kind of fun to hang out, you and me chat, that's it. And just kind of go through any questions and stuff. I feel like a lot of times we don't have time to dig into the real tangent stuff, because we don't want to derail the guests too much, right? I do a good enough job of that on my own. So, given some space like this is always a lot of fun for me. I love just hearing what everybody has on their mind, and, you know, it's super fun for me to talk to y'all about, you know, whatever it is you're interested in. So, please, feel free to fire away with any questions. And content security policy. Just going right for it. So, content security policy is one of those things that is very cool to set up. A little tricky to set up. I am not an expert on this, because to be completely honest, I have only read through articles on it. I haven't even bothered to set it up on my own, because, unfortunately, at this point in time, I just haven't had the opportunity to really think through it. I'm guilty of not having paid this the proper attention. It is hard. It's hard the way that cores is hard. Cross-origin requests, the mechanic of it is not hard, but the mental model of it is hard. And what I've found with it, it's one of those things that what helps me -- here's how I finally understood CORs. I drew a map. What is CORs actually doing? Sending options across to figure out whether or not you're allowed to get the thing, if it doesn't get back the headers, there's all this stuff happening, and it makes sense. Basically, you're saying, hey, server, can I have this content, and the server says here's who's allowed to have the content, and the browser says, oh, that's me, and sends the full request. I feel like the content security policy is kind of the same thing, you're sending headers that define permissions, what's allowed, what's not, and that's about as much as I remember off the top of my head. So, maybe try actually mapping the journey of the browser says this, server says this, header says this, and this is how the stuff actually makes that all work. But, yeah. I see some first-time chatters in here. Welcome, Ian Douglas, welcome Nartc. Yeah, what's up, having a great day. I'm in a good mood today. I stole Marissa's mug, look at this one, this one makes me smile. Alexander, how are you doing today? I'm doing great. I'm seeing questions come in.

So, Ian Douglas says, which companies do you know that use DevRel as an education tool, work on open source, et cetera, that are also hiring? Let's see, yeah, I think it might help to just frame DevRel in general, right, to kind of talk about what the role of it is. And what I found is that when you think about developer relations, it falls into multiple buckets, depending on the company. So, there is Developer Relations as a, like, as a pure marketing role. Your job in DevRel is to go to an event, give a talk, and collect leads. And you'll see that at some of the bigger companies where DevRel is basically their job description, go scan badges at events. And that can be fun, you get to go to a lot of events, meet a lot of people. If you're into that travel lifestyle, you want to see a lot of cities, it is a great way to go. As the pandemic came in, and also just as like the community has matured a little bit, we started to understand one of the bigger benefits of Developer Relations is the community building of it. So, me giving a talk at an event is great. I'm going to talk to, you know, 50 to maybe 1,000 people at a really big event, and we'll have a good conversation, but who knows how many of those people are actually paying attention, who knows how many of them are at the right place in time to actually need the content that I'm sharing, whether or not they are paying attention, whether or not it's relevant to their job, because tech conferences usually cover quite a bit of breadth. And, so, you know, for an ops engineer or an SRE, it might not be as interesting to hear me talk about the front end. Or maybe it's interesting, but not actionable, right? So, when you start thinking about community, it's less about me talking to you and more about creating a space where all of us can talk to each other. And I think that's really the strength of Developer Relations, as a lot of companies are starting to embrace it, is that you're not trying to create a marketing channel. You're trying to create a space for discussion, where people are interested in the things that you are involved in. So, for example, at Netlify, one of the ways we think about Developer Relations, developer experience, is less on can I sell you Netlify, and more on can I help you connect the dots of why we care about this Jamstack architecture with the value that you want to create at your job. You know, we want to ship quickly, we want to have less maintenance, nobody wants pager duty, we want fewer production bugs. All those sorts of things. Can we talk about how the architecture can solve the problem and not just Netlify, but, you know, frameworks like Astro and the strength that they have for shipping less JavaScript, which is a better user experience. And for, you know, same with 11-D, right, we're trying to put more investment in our open source stuff, both in educating people about it, because one of the big challenges we run into is companies have whole marketing budgets behind framework. When you have a VC-funded framework with a cloud behind it, of course you're going to hear about it. They have people paid full time to do that. Open-source frameworks don't have that. You don't have anybody full time behind solid JS, who can just do marketing campaigns to explain the benefits. So, you know, how do funded companies like Netlify try to lend some of our resources to benefit open source in those ways? And you see that happen across a lot of different companies in the DevRel space, so that creation of community, that support of the ecosystem, is a really important way to start approaching just community in general and the strength of the community. If everybody is feeling supported here, and this is the best way for you to move forward and build things, then Netlify is an incidental at that point. You're in this community, and we're confident that we provide one of the best experiences, so that as you start using this way of building things, you'll also start using Netlify, because it's a natural place for you to land. So, I'm not selling you on Netlify. I'm selling you on the benefits of using this approach, and hopefully if you agree it solves the problems we believe it solves, then you'll land on Netlify. So, it's an indirect marketing play. It's no longer me saying, hey, use Netlify today, here's a discount code, let me scan your badge. It's more of trying to get real value connected to the actions and real value of why we started this company in the first place. Why do we offer Netlify out there. All of those things are really beneficial to people. So, when you talk about DevRel that way, that leads into education and kind of are we out in the community teaching people, are we helping people connect the dots, are we trying to get people to their first experience. Companies that do this really well, like Apollo is a great example of this. Peggy Razus was incredible DevRel before she moved out, now Kurt Kemple has taken over in her stead. Good movement from Demetrius Clarke, they've done good work. Demetrius just joined us at Netlify. We're happy to have him over working on Jamstack community meetup stuck, so if you're interested in working a Jamstack meetup, you get to work with Dom, which is a great reason to start a meetup, because he's excellent. You have the Rust community. I don't know how many communities are actively doing DevRel for Rust, but oh, my good, are they good at being inclusive and welcoming. I've seen good work out of Algolia. Brian Robinson, that's a great crew, you know, the Contentful team is good, if you've ever met them, they are good at this. There's a lot of companies doing it. I don't know who's hiring, because I don't keep track of that, but I know a lot of them are. The industry is hurting right now for folks who can do this kind of stuff. So, if you do feel like you are the right kind of generalist to dive in, yeah, please do.

So, sorry, I know that's not a direct, hey, go apply here, but that is a very long-winded answer to the education in DevRel piece. But I do think it's starting to become more prevalent. More companies value it that way. I would just, when you apply, if you get into the interview process, ask how they measure a DevRel. And the answers they give you will be very indicative of what the culture is there. So, yeah. That's one way to take it. Someone asks what technology am I currently investing in to implement in your project. So, currently, I have a few things that I'm really excited about. I am just very excited about the next generation of underlying build tools. So, things like ES Build and Veep, tools like the Rust ecosystem and what it's enabling. I know like Apollo just dropped a Rust compiler, or what is it, you can use GraphQL in Rust. I thought that was great. We're seeing a really good air handling and surfacing for Rust. So, the Rust ecosystem in general is wonderful. And if you are not familiar with Chris, who I talk about a lot on here, he just dropped Rustadventure.dev, which I'll drop a link to in the chat. That's a really great way to get into the Rust ecosystem with some solid lessons and things that you can learn there. But, yeah, I'm also excited about the -- what's being called the islands architecture or transitional app. So, things like Svelt, Astro, Solid JS, a few others coming in, where you should build using the thing that has the best developer experience. You get to write in components. So, for example, I'm very fast in React, so I'm going to write React components. But then when I feed those into Astro, Astro is going to compile those away and only ship HTML and CSS, unless I opt into interactivity, at which point I'm only loading that one little bit of JavaScript, instead of having to hydrate a whole page into a React app to kind of function there. So, it's very powerful in that way, where you have -- yeah, it's really exciting, because it basically means that we're eliminating more of the tradeoffs. I get to work as a developer with a developer experience I like, which is writing my preferred flavor of JavaScript component, whether View, Svelte, Angular, whatever. And because of tools like Astro, they can compile away the components and just ship HTML and CSS for most of the informational stuff out there. And that means there's no user experience tradeoff. Right now, when you use something like Nuxt, you get a great developer experience and you ship a lot of JavaScript that leads to a degraded customer experience. It's not an unsurmountable tradeoff, like this is the worst thing in the world, but if you start playing the game of inches where you want the first Contentful paint, largest, cumulative layout shift, all these little things, interactivity blocking, all that stuff that extra JavaScript can input, you can use all the same components in Gatsby, Next, or created app, and drop into React, suddenly you're shipping ten to 30 kilobytes of JavaScript. This is the paradigm that shifts forward. This next generation of frameworks is really exciting to me. Can't wait to see what people do with it. Let's see. Kind of run on down here. We've got -- what's up, Zander? Doing great, how are you? Do AMAs stress me a little bit? Not -- okay, so, I think I'm a little bit weird, because I don't get drained by doing live-streams. When I do the show, it's not a big stressful thing for me. It's honestly something that gives me energy, one of the few times that gives me a chance to socialize and talk to people. I spend a lot of my week in meetings, so this is a chance for me to joke around, to do coding. I don't know, I like having these conversations about how stuff works, how I make decisions. For me, AMAs are really fun. It's energizing rather than draining or stressful. Let's see. Just kind of scanning through the chat, making sure I don't miss any. How do you know you're ready for your first JavaScript web dev job? The answer is, you don't. You're ready for if you feel you can build a project. The important thing to remember is there will always be more things to learn. I've been doing this close to 20 years, and I still feel there's a ton of stuff I don't know and if you asked me to do it, I couldn't do it. I don't think I could write a binary tree from memory. I know what it is. I don't know how to build one, you know? So, there's a ton of stuff that I just don't know, and I won't know, but I'm really good at Googling now, right? So, I think getting a job, your first job, is about believing in yourself enough not to know things, but to find the answer to things. And remembering, you know, you're not going to go in and interview for a senior-level job. So, you're not expected to be able to work entirely unassisted. You're on a team, so you should be proactive, able to learn, and people shouldn't have to teach you things twice, and you should probably know baseline vocabulary, but you don't need to be completely self-sufficient as a developer to be an early career dev. You should be capable of working on a team, following instructions, and picking things up quickly. And that requires some baseline understanding. You know, sort of like if you were going to go and be a writer. Being able to read, being able to understand the words on the page, that is important. Being the best writer in the world is not important. You just need to be able to string together thoughts. You will improve over time with coaching, have an editor, those sorts of things. And coding is the same way. You'll start out by being able to accomplish things in the way you've found. You'll Google it, have done it before, seen it done, and you'll be able to do it that one way. With coaching, you'll learn alternatives and different ways of thinking about it, start to learn some of the foundational stuff, some of the theory, and that gives you lateral movement and that's how you become more senior, is when your thought process about things isn't like I've seen it done like this, so I can emulate that, and more what are we trying to accomplish, there's a lot of different ways to get to the goal you're talking about. That's the path and seniority. At the beginning, it's like, hey, can you go fix this home page, we've got a broken link, can you do that? Great, you're ready to be a junior dev, 100%. It's very much get the basic vocabulary and jargon so you can have a conversation how you can go about finding something and look for a company looking for people that do that. There are a lot of companies willing to invest in early career devs, because they get to train you on their way of doing things, opposed to bringing in somebody that's been doing this for a long time, has their own habits, and is going to be potentially challenging to work with, because they want to do it a certain way and the company does it a different way. Hardest part is getting the offer. Networking and figuring out how to speak the language, so you can inspire confidence that you're capable of doing the job, that's almost more challenging than the skill set itself, because you're trying to get somebody -- you don't have a portfolio yet, right, so basically all you have is whether or not you project competence that you can figure it out in your interview. That makes it really important that you're able to have that conversation and get that stuff right. Let's see here, another first-time commenter, Gaston. What do you think is a good place to focus on for developers? Beginners need to focus, what's a good path? My preference for learning is always to take on something practical. So, don't worry about learning just in case. There's a conversation that I've heard in a few different channels about the idea of just in case learning versus just in time learning. And what I found with just in case learning is that it sort of becomes a hobby or a compulsion. It's like watching a documentary that has nothing to do with you. You're gathering information, but it's not information that you're acting on. So, it's almost a form of procrastination to learn without doing. So, instead, especially professionally, it's good to be aware of what's going on, but you should try to learn things when you need them. So, have a project in mind, have a goal you want to accomplish, and pursue that goal. That kind of just in time learning means that you'll actually cement that information into your head. I think the thing that's important to keep in mind, web development and working in tech in general is a big broad field, and there's just no way that any of us can know, especially when we're brand-new to the field, what the best fit is for us. So, when I came in, I started as a designer and a front-end dev, and I would help people build marketing pages for their business. And as I did that, I learned that it was actually pretty fun for me to build the back end of stuff, so I started doing more back end dev and became a PHP dev, learned about databases, MySQL, and learned how to string that together. Then I realized that isn't what I really wanted to do. I just liked the dynamic nature of that stuff, so I started moving back to the front end, thinking about node, and when I realized serverless was capable, I moved towards serverless. That's just on the dev side. On the career side, I ran an agency. Then I didn't want to be an agency runner anymore, because that was sales and admin and stuff I didn't like, so I switched to being a contractor. I worked for a company, they had one project, paid me a contract, that's what I worked on. It wasn't big enough. I wanted to do more ambitious stuff, so I went to work for IBM. Really liked the product work for IBM, but found myself doing more educational internally teaching people how to do stuff. Kind of fun to talk to devs about this stuff and explain the benefits of different architectures. That led me to DevRel. I went to Gatsby to work on building community and getting people aware of the benefits. When I came to Netlify, it was more formal. Very much like, okay, let's do this. Now my job is almost no day-to-day coding and almost entirely education about proof to concept on stuff, learn about things, talk to devs, teach devs, and that's not at all what I would have thought when I joined the industry. So, when you're learning, focus on things that are interesting to you. As you start to learn about what's possible, pick a project and start chasing these curiosities and learn more. Especially at the beginning, having a general understanding of how things fit together, it gives you latitude to start in one direction and say, okay, I learned about that, turns out that's not what I wanted, so let me move this way and try this thing that seemed interesting, and that broad set of skills gives you the ability to shuffle around. Careers aren't linear, especially in tech. Careers are very, you know, start this way, wait, I'm going to go this way, then I'll try this again, just kidding, I did like that, let's go here. You should explore that. Remember that going into tech as a developer, you're going to learn things about the product side, and the sales side, and the business side, and all these other pieces. Every single one of those is also another career path. A lot of developers move into product management because they love the process making sure the right thing gets built. They like thinking through the product market fit, thinking through how to scope it down and break it into digestible pieces. That's product management. You know, that's an ultra valuable, ultra viable skill that a lot of developers are really good at. Especially when you get into platforms like software as a service. It's hard to find product managers that have development skills. So many transitions and pivots in this industry to find the right fit for you. So, a lot of it is about learn something when it's interesting, and push forward on that. And that will start to open more doors as you go. Don't worry about learning at all, don't worry about whether or not you're learning the right things. Learn the things that make sense, and, you know, if it's for your job, obviously, learn the thing you need to know for your job. If it's for continued learning, learn what you accomplish in your next side project. Let's see. Allen says how does DevRel tend to work with support and feature requests? If you're out there it's easier to connect than sending to generic support. So, the idea of DevRel is, you know, we're sort of like the bridge between different parts of the company. And, you know, we will hear what's coming from product and from engineering, and our goal is to figure out how do we not just say here's a feature, but why did this feature get made, what problems is it solving, and we work with marketing on that and take that out into the community. Then we'll also be the first ones to see what the community thinks about it. We're going to see the discussions, we're going to get feedback, and, so, a lot of times we're bringing that feedback back into the company. And sometimes that means, you know, connecting support to a customer who's having a problem. Sometimes that means directing the customer to the right place to get the support that they need. Sometimes that means going to product and saying, hey, we totally missed on the implementation of this. Here's what people wanted and here's what we did, can we adjust this to fit their needs? And other times we get to do fun stuff like celebrate, because we launched something, people love it, and we get to go around to the company and show people all the happy folks that we're seeing in the community that are like, oh, so glad this thing finally exists, I needed this. That's what makes this job fun, you get to do a little bit of everything. I think there are some personas here, and I can't remember who, I think it was Simon -- crap, what's his name? I'm going to have to look this up. Simon -- Simon -- what's his last name? I don't know where I'm going to find this, but he's a consultant on building maps for your business, how to do strategic mapping of a landscape. But one of the ways he talks about career development, I think it's him, I might be getting this all wrong. Anyways, not the important part. The important part is there are three major buckets people fall into, and it's a spectrum, so you're not going to fall into cleanly one of the buckets. One end of the spectrum are what's classified as pioneers. That's the idea you're the person that wants to go out into the unknown, work with no rules, lots of ambiguity, and try stuff, see what's possible, figure this out. You could put this in as inventors, as R&D, somebody that likes to work on a team of one, they'll be the first engineer where someone has an idea, we want this tool, I don't know how it works, but I'll figure it out and see if you can make it work. That is for some people fulfilling work. That's for other people the most stressful kind of work. So, more towards the other column here is that you've got people who would fall more into, I guess, the settlers, meaning after somebody has proven a concept is possible, the pioneers discover this area. The settlers say, okay, you've got something, but this isn't a product. This is a concept. So, let's make it into a product. These are the people that get the edge cases, mature the idea, think through how's this actually fit into the world and take it from a promising proof of concept to an actual usable, sellable product. Then the third kind of people, city planners. These are the people that like to take functional products and scale them. How do we build the process, how do we build the documentation, the systems, and support networks that will make this thing scale to all of our customers? These are folks that really excel in high-volume environments. What I found is everybody I've met falls into one of these buckets, more or less. And sometimes it's on a spectrum. You like doing a little city planning, but really like the process. You kind of like taking it to maturity, but really want to find how do we make this thing hum, make sure we eliminate all these things where somebody is in a Slack channel going who does this work? And others, I find myself more on the pioneer side. I love to try stuff and have ideas, but I'm really bad at doing the last 15% of taking my child idea to a functional, usable product. So, I can do it, I have done it, but I have the most fun when I'm out exploring, the ambiguity, hey, no parents, no rules, let's figure this thing out. So, thinking through, too, where you fit on that spectrum can be really helpful. I find DevRel in general tends to sit more on the exploration and chaos side of that, so makes it a good fit to be in the role we're in, because we do a little bit of everything, and that can be really engaging, if this is a thing that doesn't stress you out, right? If not really having a clearly defined work stream and knowing a lot of the work you do is reacting to the changing landscape, then DevRel can be a good fit. I know there's a ton of questions in here, I'm going long winded. Let me do a quick thing, because I haven't done it yet. I'm going to do a quick shout-out to the sponsors, because we've had live captioning with us all day. Ashly is here from White Coat Captioning writing down all the things that I'm saying, so if you want a written record of the AMA today, you can find that on learnwithJason.dev. That is made possible through the support of our sponsors, Netlify, Fauna, and Auth0, who all kick in to make the show more accessible to more people. Talking about Rust adventures, so let me throw that up one more time since we're here. Yeah, let's switch back. I don't know why I opened up the interview mode instead of the other one. I meant to open up this one here. Nope, not that one either. This one! Yeah, that's the one, so everybody can actually see what's going on. Yeah, here's the sponsors, Netlify, Fauna, Auth0. Here's the captioning, White Coat Captioning. You see it on the learnwithJason.dev there. And with that, I'm going to switch back into this view, because I don't have anything to show just yet. And, yeah, sort of a generic question, but what's your day-to-day like as a DevRel and Developer Experience engineer? My job is significantly different now that I'm in the VP role. I will say it's not the same job that it was when I was an individually contributor. I'm happy to answer questions about the VP role. I feel like that's probably less interesting than the IC role. So, I will quickly recap. As an IC in DevRel or Developer Experience, you spend a lot of your time moving between different parts of the ecosystem. Talking to support, product, sales and marketing, also to active customers, the community, the ecosystem, open source frameworks, and other partners that are in the space. Trying to talk about how do we make this whole thing better. And then your job as a DevRel is to kind of pull those things together, and that can be through writing content, it can be through videos and live-streaming, it can be through, you know, putting together a proposal internally for how we can build some things that will solve a pain point in the community. It can be setting up some co-marketing, hey, we're going to work with, for example, we're going to do a stream with planet scale soon, because one of the pain points we hear is people have trouble with databases, because how do you put a Jamstack database together? Seem like they don't really match, because Jamstack is no servers, everything is short running, and it's all static assets, but databases are the opposite. They are long running, and they've got lots of variable data. How do those things fit together? We're going to get planet scale together, Netlify together, and we're going to talk about that and kind of show how we can make this work. Welcome, Semantics Dev, thanks for coming in, Ben, friends. So, yeah, there's a ton of stuff there worth digging into.

Let's see. Just looking at -- am I an extrovert? I'm an amnivert. I like being around people slightly less than half the time. I like to go to events, hang out with people, do big social things, but after a couple days of that, I will then spend a few days locked in my office, listening to music, working on a project and not speaking to anyone for a few days. Drives my partner nuts, because she'll be like, hey, let's go out -- she's a full extrovert. She wants to go all the time, meet people, have people around. And I like that half the time, and then I like to switch flips. No, no, I'm staying home. You go do whatever you want, but I have to sit quietly and stare at a wall for a while. That's been kind of interesting, because I, depending on the day, I'm an introvert or an extrovert. That, I think, can be a little frustrating for people that have to hang out with me. Tom Tom fit, first-time chatter, thank you, hello. Asks do you feel like being in DevRel has dulled my engineering skills, improved them, or kept them the same? Looking at moving over from engineering -- from engineering to DevRel, worried about losing the technical chons. Depends on the role. For example, for me, I would say I have gotten stronger as a general front-end architect, gotten stronger in the broad sense of I can fit different technologies together because of the way my role has structured. I've gotten weaker on the back end, because I don't do any back-end work at all anymore. I've gotten weaker on the fine-tuning ultra perf stuff, because it's not part of the job that I do anymore. I would say that it depends how you define the role. I very much defined my role, even when I moved into the VP slot, of making sure the work I do is still engineering, that's why I run Learn With Jason twice a week, it's engineering work, I'm trying things, building things, because I feel it's important to me to continually be learning what's out there, see how things fit together, keep up with trends that I might not have a chance. I might not have a chance to write TypeScript professionally, but I learn on the show as a way of making sure I'm exposed to the technologies and get a chance to learn them. I would say that it is possible. We have DevRels -- some of the developer experience engineers on the team straight-up work on our product, and that work they are ultra sharp as engineers. Ben Hong, for example, on the Vue core team, ultra strong engineer always improving his development skills. Others of us, we are really interested in engineering and do a lot of engineering work, but I don't think either of us really wants to go deep into product work anymore. We've done that, we've been there. For us, we're focused more on the high-level trends and making sure that we understand it, but not necessarily that it's something that we have the ultra deep, you know, principle engineer understanding of exactly how that technology works. So, I think you can set levels and goals for yourself and make sure the role you move into is built around those goals. Yeah, it's a conversation you have to have with your team is the shorter answer to that. What's the path to seniority in DevRel? This is a great question, Brandon. The path to seniority in DevRel, if we look at the ladder that we have in DevRel, and I can switch over actually to this really excellent tool here, which is career ladders. Is it careerladders.dev? Sarah Drasner, who was the VP of Developer Experience before I took over, she wrote up these really good career ladders, and in doing this, set me up to have the easiest job ever, because I get to refer to her work whenever I need to answer a question. She did a great job of writing up a ladder of what changes between the entry level. So, early career DX would be, you know, you're going to advocate, you're going to make samples and demos and you're going to do some debugging. Just kind of like a positive point of presence in the community to help people get connected to the experience. As you move up the chain, when you get to principal, these are the folks who they are building systems, they are building out strategies, they are designing whole campaigns. They've got contacts across the industry, and cannot just answer questions, but can, literally, connect different people together. Oh, we're trying to do a partner push? Great. If we're doing a thing about the Jamstack, let's get the Sanity team and see if they want to work together on this, and we can take Sanity as the CMS, and Netlify as the platform, and maybe the Nuxt team wants to work on how we'll do this with Nuxt. That's the front end, get some serverless functions in there and start thinking about how do we get all the different things to fit together in a meaningful way. And all of that leads to us having the ability to do strategic, company-wide efforts. And that will happen. This is another big one, you know, really senior developer experience engineer, they are going to show up on sales calls as closers. Our job is to talk to the architects at a company that's considering moving to this architecture, and help talk through the challenges that they are going to have and how do we do incremental migration, how do you think about your existing system and how this would fit into it without having to boil the ocean? All of those are very kind of advanced level things. Hey, what's up, Alex and friends, welcome. We're doing an AMA today. If you have questions, fire them off.

To put a very fine point on it, this is true of Developer Experience, engineering, any tech role that I've seen, the early career is are you capable of working by yourself? To get to senior means you're effectively self-sufficient on your own projects. You can do work without a lot of oversight, you can, you know, somebody can hand you a project, and you can execute on that project. As you get further up the level, you now have a team-wide impact. You, as say a staff engineer, are capable of not just being productive on your own, but you can work with the early career engineers on your team in, say, a project where three of you are working on it. The three of you now can function, because the staff engineer is able to provide enough direction to the other engineers to make sure everybody knows what they are working on and what they need to do. When you get into senior staff or principal, now you've got org-wide, maybe they are driving initiatives at the whole developer organization experience or engineering level. And when you get to the highest levels, you're going company wide or industry wide impact by the way you're being strategic, sitting in on product meetings, sitting in on road map meetings, and customer and marketing and monetization meetings to think about, okay, how's this going to impact the community? How is the way that we're going to change this pricing going to affect this group of customers, and how do we make sure this client knows about it, so that all of these people feel like they were considered and taken care of as part of the exchanges. So, there's a lot of high level strategic stuff there. In terms of advancing, as much as it sucks, show up to meetings. Look at what the senior people are talking about, look at where they are paying attention, what questions and concerns they are bringing up. And ask why. Start trying to get an understanding of why when we talk about this really cool technical feature, why did we spend so much time on the rollout plan? Couldn't we just show everybody this thing is great and we're done? Why did they spend so much time on drawing a mental map from zero to this concept? And start to, you know, pick out what the difference is between the way even when you talk to engineers, when you talk to, you know, an engineer at like the DX engineer II level and at the principal level, the conversations are both going to be good, but the focuses are going to be different. What's different? What level is somebody thinking at and what level are they asking questions at, so you can start to really understand where do I need to grow my strength, what instincts do I need to develop as an engineer, to move to that next level, to start having a team-wide, a company-wide, industry-wide impact on the way that people are thinking about and talking about these ideas. Allen, you asked about just in case versus just in time. The idea of instead of trying to gather information before you need it, gathering information at the time that you are doing something that you need it. Oh, you found that later. Okay. So, I'm just scanning through questions here. I'm a ways back. So, everybody, bear with me. I see a subscribe. Thank you so much for the sub. I see a question from Hakuna Matata. I work with a marketing agency, flushed out a proof of concept. To my experience, I don't see there being many DevRel positions at an agency. Do you see this in the future popping up in the agency space? So, maybe. I think there is room for this sort of work at an agency. I think it's harder with agencies, because agencies tend to make their money off of client projects, and a client is not going to pay for outreach. So, it makes projects more expensive to employ different folks around the agency that aren't working on client projects. So, that can make it hard, because it messes with margins. That is a disincentive for an agency to start actually creating this role. This being said, doing it is a very big net positive for any company that does it. If you have somebody active in the community and draws a lot of good will and helps get you into conversations, that does have a big impact on your top of funnel, on your leads, on your ability to convert. All those things are very good things, so it can be worth it, but it's a difficult -- that first step is hard. You're basically saying, yeah, I know we have our margins now and we charge what we charge now. Can you carve enough out to create a salary for somebody that's not going to work on client? That's a hard sell. If you can make that sell, it's going to pay off and be worth it. If you're going to be the one to propose the role, be sure you have a clear path how you're going to do a return on investment, because you'll be under a lot of scrutiny if you start messing with margins, but it is the sort of thing that can be worth money, you can absolutely make it work, but it will be an uphill battle to get it started. If you have a clear plan and can show the revenue down the line, yeah, I think you can make that case and you could be very successful at it. Another way to look at it, it might be more instead of seeing agencies creating dev ex roles, we'll see DevEx agencies. Cory Quinn is a good example. He works for himself, but he's also kind of doing a lot of work that raises awareness about other companies, and he gets paid through sponsorships, through -- I don't know, contracts and consulting, but I think a lot of the sponsorship money is effectively DevRel for hire. By sponsoring Cory's work, you're raising awareness because he's going to be talking about your product and Cory Quinn is well known in the AWS space, a lot of people look to him for opinions and insight. He's got a great voice, he's really funny. So, paying Cory is a great way to not spend a full salary, but still get a lot of benefits in DevRel. So, you could offer that as a service and make that as something somebody is willing to pay you for, because it's easier to justify than a full-time salary right out of the gate. So, it can be a way for companies to test the water with DevRel and DevEx. So, who knows? I think we're starting to see most companies in the tech space recognize the value of having DevRel and Dev Experience. Both seem to be in alignment what the best value and role is. So, we're seeing more people write books and guidance about how it should work. We're seeing, you know, more discussion, more dedicated spaces to talk about it, and I think that's going to lead to evolution and growth. So, I'm very curious to see how that kind of grows over time. What else we got in here? What is up, Henri, I see in the chat. Let's see. Is there potentially a pay cut to start as a new DX engineer? Very much depends where you're coming from and what level of skill you're bringing to the DX. It's a career change, like moving into management. Management is not a promotion, management is a career change. If you're a really, really good engineer but never managed before, it's possible you'll take a pay cut to become a manager, because you have to learn a lot of skills. Same for developer experience, product, anything like that, because being a good engineer is only a portion of being good at developer experience. You need to be an engineer, but there's also skills in storytelling, and in creating safe spaces, and understanding community dynamics and being able to create trust. What you could call bedside manner in the sense that people are always working to -- how do I present bad news, how do I present controversial opinions in a way that doesn't make somebody feel they are being called out or slighted, but in a way that is an objective discussion of this technology. And that's important, too. When I talk about frameworks and stuff, if I talk about how cool I think Astro is, that's not me saying, oh, that's because Next sucks. That's not what I believe at all. Being in DevRel, there's a tricky line to walk where we do have opinions, and we do have things we want to express, but we shouldn't, and, honestly, sustainably can't express those opinions in a way that says I like X because Y is terrible. You know what I mean? That idea of tearing people down and going for -- going low and trying to trash other technologies, that doesn't fly over time, because, ultimately, makes you look mean. And nobody wants to hang out with somebody who could turn on you any second. As a DX engineer, as a DevRel, a lot of your value is in how do you handle it when somebody attacks the framework that you use? You can go high, doesn't mean other people are going to stay with you. We'll get an odd tweet about somebody really mean about Netlify or "Learn with Jason." How do I deal with that, how's that work? I think part of seniority being in a public-facing role is realizing most of the time when somebody is mean, it's not about you. Especially when they are talking about technologies. If somebody is attacking Netlify, they are not talking about me. If they are talking about me, that's different. If somebody attacks the tech stack I like, the company that I work for, or somebody attacks a thing that I'm a fan of, doesn't mean that they think the people who use it are bad. Sometimes they'll say stuff like that, and I have to be willing to not engage. That can be really challenging. You want to go defend yourself because somebody is being mean, hurts your feelings. That's a whole skill set you have to build. If you're not super skilled in that, it could mean you're going to go from being a senior engineer to an entry-level DX engineer. Really strong on the engineering side of the Venn diagram and maybe you have a lot to learn on the social dynamics, building community, and creating safety side. That can also be the opposite. You could be a good engineer who's really good at community, and you might actually get promoted into a higher level of DX because you showed a ton of capability in that space, and engineering was not the right role for you. So, very much depends on the situation. Also depends on the company. Some companies pay really aggressively for DX, because they know DX is a specialized skill, involves being a generalist in a lot of places, so that can be expensive to find somebody who can do all of those things. Other companies see it more as a marketing function and pay less than engineering, so you'd take a pay cut. Very much depends how the company frames it and values it. Again, kind of a case-by-case conversation that you have to have. Let's see. Dive on into these questions here. Orbit putting out a list of community tools. Let's take a peek at this. I love these. These are always really useful. Orbit, if you're not familiar with it, is a kind of community measurement tool. It can show you who's super engaged and who's -- if somebody is becoming more engaged, less engaged, you can identify your top community members and who's putting the most effort into your community, so that you make sure people don't fall through the cracks and that kind of thing. It's really, really powerful stuff. It's really cool. I'm a big fan of the product. Looks like they have a free report on this. That's cool, you can get a physical copy. This is maybe a cool thing to look at, especially if you're interested in DevRel. What else do we see here? I have a question about Netlify dev. All right, let's talk code. Developing a blazer project with Netlify functions, manage to configure to host dotnet status, holy crap, you're doing stuff I didn't know about. Problem is dot net shows input such as restart or abort, and there's no way to interact with it. Woof. Okay. So, that one I'm not going to be able to respond to. However, open an issue on the CLI repo, that is monitored, and our team is going to be able to dive into that and try to help and see what they can do to back you up there. Everybody tried the CLI, by the way? I know that I bring this up every once in a while on the show. I'm just such a big fan of the CLI. I use it all the time now and makes me feel like a superhero, because it's just very -- lets me not ever leave my terminal. It's so good. Anyways, go check that out, it's fun. Conflicts and opinionated conversation become an interesting conversation where you can empathize but build constructive feedback.

Yeah, and that is a serious skill, because how can you engage with somebody who's not happy, right? And do it in a way that's not amplifying the discomfort. If somebody comes and says your product is crap, I have to migrate to other service, you can say, well, I'm not going to engage with that at all. They are clearly grumpy, I'm not going to get in the middle of this. You can, you know, get mad and say don't talk crap about me, I'll talk crap about you, right? Or there's this middle ground, hey, really sorry you're having a hard time. Do you want to tell me what's going on and we can see if we can figure it out? And sometimes you can really take the anger out of a conversation and make it productive. Because a lot of times when people get grumpy, you know, I've been trying something for two hours, keeps breaking, and I don't understand why. At a certain point, I hit a level of frustration, I hate this, I'm done, then you put a grumpy tweet on Twitter, that's okay, that's a perfectly valid thing to do. But if I can notice you're having a hard time and I can try to get to not you shouldn't be grumpy, but what happened, what happened under the hood that made this bad for you, then maybe I can help you solve that problem. And I've found when you take the time to do that, you can turn around a conversation and somebody who was really upset can become one of your biggest fans, because they feel like they got heard and helped and not just kind of ignored or told, you know, whatever, screw you. It's very -- this is challenging, because sometimes people don't want help. You'll show up and they'll be like, oh, this product sucks. You'll say how can I help, you suck. Oh, let's let that one go then. But, you know, that's a skill that is hard to build, because it's really tough to not get worked up when other people are worked up. Humans are very good at reflecting behavior. So, if somebody is really worked up, you know, your stress response is going to rise and your desire to mirror that energy is going to rise. So, you have to constantly work against your instincts to try to not let them get a rise out of you, because you're trying to get them to mirror your calmer response. That's challenging. It's really hard when somebody is yelling at you. Hey, I'm so sorry you're having a bad day. You suck. I'm so sorry you're feeling that way, how can I help. It's hard. It can be really hard to have that conversation with somebody and to know, you know, sometimes you're not going to win. You're going to leave feeling bad because somebody yelled at you. That can be rough. Let's see here. Questions about WASM. Have I seen any evangelism about WASM on the Jamstack? I have found that WASM is one of those things that when you have a use case for it, it is incredible. There are tools I've seen that built processing stuff with WASM and that causes them to execute really quickly and powerfully in the web, which means, yeah, it's Jamstack, right, because you can deploy it to the web. Sometimes I find that WASM is kind of a solution in want of a problem, because we'll apply it to things that aren't sufficiently expensive enough to merit the level of difficulty that currently exists to getting things with WASM. That's getting easier. I think that we are seeing a huge amount of -- there's a huge amount of potential in the tooling space in Rust. I mentioned so much work to make NPM a good piece of software, NPX, and things that made NPM great came out of their head. And now CAT is dedicating their time to the Rust ecosystem. They are not the only one. We have really, really smart people who built a lot of the foundational stuff that lives in JavaScript. They are all starting to explore Rust as a way to do some of those things, but faster, and with, you know, additional benefits and additional type safety and things that are beneficial. That maybe I won't learn as a JavaScript dev, but I'm really happy somebody else is doing it. You can say this is expensive, make it WASM, and Rust can just do that. That's incredibly powerful stuff that we have access to. I think right now WASM is one of those things that a lot of times it's going to be enough of a lift to get the WASM in place, at least right now, that it's potentially not worth it, because the tradeoff is too high in terms of maintainability and understandability of the system. Again, it very much is a case-by-case sort of thing that has a lot of potential and a lot of room to grow. So, I think we'll see more of it as the future unfolds in front of us here. Is it better to have loved and lost or never to have loved at all? I'm a big fan of loved and lost. I think that, you know, I know that you were potentially joking and this is me giving a serious answer to a joke question, but I'm going to do it anyways. I feel very strongly that the value of being alive is not getting to the end of it, but having the experience of it. Right? And, so, I'm not trying to get to the finish line with a clean score card. I'm trying to get to the end with as much experience as I can get. So, I want to try everything that I can, I want to do everything I can do, and any time that I see something, that little spark goes off in my heart or brain that says you can try that, I want to find a way to try it. Honestly, this is a good example. I made rubber dog, because I drew this little rubber corgi duck, and I did this a while back. Let's actually go back to -- let's go to the tape. So, a while back I did this sticker, where I drew the corgi duck. Then I thought to myself, I basically made a rubber duck, and I always make jokes about talking to a rubber duck about your problems, help solve them, rubber ducking is a thing in the developer community as a way to get through a problem. How do you debug it? Explain to a rubber duck, talking through it will help you find a solution. As I was looking at this thing, I was like, man, I wish this was a real toy. A lot of folks in Discord said, hey, what if this was real, how do you make this real? I was like -- the light went on in my head. I got to find out how to make this real. So, I went and talked to a company that can source toys, I worked with them to get a clay model made, figured out a manufacturer who could do it, and I made a whole bunch of rubber corgi ducks. Now they are real. You can buy these things. So, this is one of those things that was foolish. It was absolutely foolish. It cost me a ton of money. I lose money on every one of these that I sell, because the shipping is included. It's very expensive to make and ship these things. And I have zero regrets. Took me a ton of time and effort, cost me money, but in doing it, I was able to -- it's a story. I'm never going to regret being able to show somebody this silly rubber duck that I made. It makes me smile every time I think about t. I'm not going to get to my death bed, I wish I saved my time and money, but I will think I wish I would have made that stupid duck. I think those are the sorts of things that are worth it. I don't regret experiences. Only regrets that I have are the things that I want and didn't. I try not to get myself in that situation too often. I can feel, oh, I really want to try that. Oh, but it could be hard. Oh, it could be scary. Screw it, try it.

Sorry, Saboteu, I went off on a tangent there. Can you tell I spend some of my time reading weird philosophy books? Nikki asking how soon is too soon for Christmas lights? I guess whenever you want them is when you can put them up. My partner put them up yesterday, which is November 1st, which I had previously thought you weren't allowed to do Christmas decorations until after U.S. Thanksgiving, which is the end of November. Turns out I was incorrect about that, and the Christmas lights are now up. You can even see -- I think I got the tweet -- should be on my homepage here. Right here, I think. There it is. This is the tweet that Nikki is referring to about my house decorated in Christmas lights already. And I do want to point out, if you look closely here, this is the Halloween skeleton that Marissa didn't even bother taking off the front porch before she put up the Christmas lights. So, we are both decorated for Christmas and Halloween right now. Yeah, here's a pumpkin. We're decorated for all the seasons. We've got the harvest, Halloween, we've got the holidays. So, you know, I guess the answer is whenever you want Christmas lights is the right time.

A little tree in the background of your streams is a great idea. Really fun. Die Hard is a Halloween movie, Gremlins is a Halloween movie. People have to get this right. Glowing mushrooms at music festivals. Kindred spirits. Go make things that make you smile. The story is worth the money, in my opinion. I'm not going to do something that puts me at risk of financial ruin, I'm not going to do something -- I have to make choices between food and this idea or rent and this idea. If I have disposable income on something silly that makes me smile, what else am I going to do with the money? I'm going to spend it on something. Knowing me, it's going to be food, some impulse furniture purchase, or something that's fun. And I like balancing that. You know, I want to have great food and the experiences of eating with people and all that fun. I like having furniture that I enjoy in my house. I like decorating my house, it's kind of fun. But I don't want that to be the only thing I do. I also want to have stories and I think paying for stories, whether that's travel or experiences like doing something weird, like making a rubber duck, or even if it's like, you know, just little stuff. Can I, you know, do a thing that lets somebody -- how do I unblock a story, make a story come true? Those sorts of things, too. It's worth the time, the money. I never, never regretted that. Glowy glowy mushrooms. I kind of want to see the mushrooms. Let's take a look. Risky click of the day. Oh, wow! These are really cool. I love that. That's a super fun thing to do. I love stuff like this, these fun decorations and things like that. Thank you for actually sending me pictures of the mushrooms. Love you, chat. Treat me good. Yeah, this is really cool. These are LEDs, 3D printed? I love this. Over 700 at one point. Oh, my goodness. What an adventure. Handmade? Oh, my good -- wow. Wow. That is an investment! These are really cool. Yeah, this is great. These are a great idea. Oh, these are made out of ping-pong balls? Wow, this is so much more low tech than I thought, and it looks amazing. You know what, have you ever seen the show "Making It"? It's Nick Offerman and Amy Poehler. Sort of like The Great British Bake-Off, but they do crafting. First of all, all the vibes of love, where it's a contest, ostensibly, but not like American reality TV, where everything is cut throat and people are talking trash. This is way more collaborative, people like each other, helping each other. The other thing I love about it, you see people do stuff, oh, that's going to look cheap and crappy. I found this old rope and this wicker basket, then they make something incredible that looks really, really expensive, and it's like, oh, man, I love how creative people can be. It's kind of wonderful. Yeah, I kind of want to make these mushrooms, too. One of the things I'm hoping for when the pandemic has lifted enough that we can safely just kind of gather and things like that, I really want to do some in-person Learn With Jasons, where we can bring guests into a studio of some sort and do whatever. I've long wanted to do cooking shows. I thought that would be super fun to bring in guest chefs and learn how to make something. Who knows. We'll see how it goes and whether or not I can make a studio work with good enough streaming set up to actually function. I think that's going to be really expensive, and I don't know that I can do that story without having to make a choice between eating. LWG, yeah, let's do it. I actually do kind of love that idea. I've kicked around the idea, we were going to do at Jamstack conf a Learn With Jason track. As evens start being more in person, I like the idea. If you have ideas, let me know. What would you want to see? Plumbing tube and ping-pong balls. That's brilliant.

All right, y'all. We're at the 15-minute warning. If you have burning questions, fire them off. What do you want to know? We can talk about anything. I listed off the JavaScript, Jamstack, DevRel, things like that, but we can talk about whatever. You want to talk about something on your mind, you let me know. Favorite Disney movie, that's a great question. The one I've watched the most is "Moana." I love the music in that one. It's really well done. You know what else I love? "Coco." That's Pixar Disney, right? I think so. Go-to database hosting provider? Oh, I don't have a go-to, I have an it depends answer, and I'm very sorry for this. I like to use purpose-built tools when it makes sense. If I'm doing page-based data, I'm probably reaching for something like Sanity or Contentful, because I'm building pages. They have a bunch of tools built around that. You know, Sanity has cool stuff like multiple people can be editing the same document and it doesn't break or cause issues. You have granular roll back, different things that really make it easy to function on that data. If I'm working on something more free form or something that's like voting, I'm probably reaching for Fauna or Hasura or something like that. There's other really interesting tools. If I want authentication, maybe Supa Base. It's pretty dope, has a lot of authentication stuff, has a very fire-based like API, which is powerful. We've got shows on Firebase. I'm really curious about Planet Scale. I have an upcoming episode with them, and they have promises that are really interesting. One of them is that they are posting a Postgres database at multiple places around the world. Theoretically speaking, instead of being hit in whatever database it's in, in U.S. east, you'll have multiple points of presence for your database around the world. They are also allowing this idea that I think a lot of people have been asking for, which is the ability to quickly branch and merge databases the way you branch and merge source code. So, something cool with Planet Scale I'm excited about is there's a potential you have the Jamstack site and open a pull request, and as part of it you get a branch version of your database that's synced with that pull request. You can go through it, make changes, do tests, whatever, and then you merge it. And if it's just testing, like your QA branch, you would discard the database branch and go back to production. If it's your deployment branch, where you've added a new feature, then you're able to build out the feature and make the database changes to support it all in this deploy preview, and when you merge it, you also merge to the database, so it all goes live at once, which is really, really exciting. That's a really powerful way to do things, and it feels like the sort of thing that has the potential to move the whole industry forward. So, I'm excited to see how it works, give it a try. We have an episode coming up with John Myers, I think the second week of January. So, I'm really excited about that. We're going to do an episode there. Yeah, the database space is hot right now. Later this week I've got Natalia Venditto coming on to talk about MongoDV, and they are doing a distributed databases place, where they have databases around the world, they should be really fast. Mongo, unlike Postgres, they call it no SQL, or document-based store, where it's a little less database architect-y, where you don't have to do a lot of strong structuring. So, if you like fire base, MongoDB is a great way to get that same experience. Hey, you can put whatever you want here. That can be nice for when you have a project with a lot of custom fields or you're not 100% sure what the data is going to look like, because you're tracking block-based stuff or anything like that. It can be really useful in that way. Yeah, come check that episode out. I basically just named every database out there, but to be completely honest, I use a lot of different databases, because they all serve different purposes really well, and I tend to look for not the technology that I like, but for the technology that solves the problem. And that's why I feel like it's very much an "it depends" kind of answer. More DB centers in Canada, you're probably right. Prisma runs in serverless now, which is cool. Prisma can sit on top of Postgres and a couple other databases and give you very cool type script autocomplete for your database. It's really, really powerful. I'm actually giving a talk at the Prisma serverless event, which is in like two weeks. Let's see. Prisma serverless, where are you? Maybe I need to write event. Where are you at, Prisma? Serverless conference. I was looking right at it. This is the Prisma serverless conference. Oh, yeah, Anthony is already all over it. So, I'll be at this one if you want to see -- you should go watch this with or without me, because the information about Prisma is going to be really interesting. But there's a lot of good stuff coming in here. I'm going to be looking specifically at how to build on the Jamstack with Prisma and serverless. Don't exactly know what I'm covering yet, because I definitely haven't written my talk yet, but it's going to be great, I promise. Let's see here. Any other good questions? Yeah, talk-driven development, 100%. Yeah, Cassidoo. Yeah, they want me to turn it in by Friday. So, yeah. It's going to be great. I'm going to do a good job. Maybe I'll do a good job. I'm going to do a job, and you can determine whether or not I did a good job. Also, welcome, Cassidy, I see you didn't even need to drop a boop to trigger a boop storm. You're a legend, a legend.

Let's see, fun to build talks with Prisma. What's up, Taylor, how are you? Taylor is going to come on the show, and we're going to play. Going to be a lot of fun. Taylor, were you here when I was talking about Planet Scale just now? Oh, Anthony, your sub expired. I want to give back to the community and pay it forward by creating content. If you had to start over from zero, how would you tackle this now? That's a great question. I think right now one of the most interesting spaces for people to be in is, as you are learning something, share what you're learning. I think that the challenge in doing that is that it's easy to think that anything you're learning other people already know, because as you're learning it, you're going to read other people's blog post, see documentation, all these resources, so it's easy to say, yeah, somebody's already covered this, if I do it, I'm repeating what everybody else said. I think that the strength in writing as you're learning is not necessarily fa you're producing new material, but anybody who's writing from the position of a learner, especially on the --

You can do it. Come on little compooper.

JASON: See it chugging? As you are learning, writing from the perspective of a new learner, nobody who knows this technology can get into a beginner's mindset. I've been writing React for five years now. For me to try to think about what it's like to learn React, I just can't remember anymore. I don't have a memory of what it's like to be brand-new to React. I don't have a memory of what it's like to be brand-new to JavaScript, HTML, or CSS. So, what you can do as you're learning something, as you're diving in, you can bring a fresh perspective, and you bring new analogies, new ways of thinking, you ask questions that I would never think to ask, and that is content that is really beneficial for people learning at the same level you are. I think it's always easier to learn from somebody who's a step or two ahead of you, opposed to somebody who's a decade ahead of you, because the context gap is narrower. There's also benefit from me reading from somebody who's learning from the experience right now has to say. Because when you talk about what you struggled with, some of the things that you're going to struggle with are things I struggled with and then just printed on my memory. So, I just know we do this silly work around that's not documented anymore. It's in the back of my head. I will never remember that's just a thing I know and not a thing somebody has to painstakingly learn, unless I see you talking about where you struggle, and that can help me improve my own documentation. Now when I write, I remember, oh, yeah, I remember I read this article where this person was struggling with this thing, and I forgot, yeah, let me include a caveat. If you've never seen this before, this is what it is. Those are the sorts of things that really move the industry forward and help people by doing that. So, if it was me, I would do that, and I would work on submitting to lots of different publications. So, publish on your own site, syndicate that to dev.2. You can import posts to dev.2, and that's a really great way to do it. Submit to Smashing Magazine, CSS, LeadDev. There's a decent number of publications out there that are reputable, do great editing, pay you for articles, and it's a great way to get a name out there and go. Let's get it on down to Ben with the gift sub, look at that. Scrolling through a wall of boops to make sure I didn't miss any questions. If you want to watch terrible programming on the struggle bus, do me a follow now. Everybody go follow -- let's do a shout-out to Ryan. There you are. Go follow that. And then let's see, more and more boops. We're all junior devs. The curse of knowledge. Absolutely, Taylor. I think there's a huge benefit of learning from beginners. It's super helpful. Let's see. All right, Ryan, I'm glad that we're saying the same thing. But, yeah, always do a code along. You know what, where a pro tells a newbie what to do, that's the premise of "Learn with Jason." Find somebody who knows things, I'm going to ask the questions I'm going to ask, push the things, try to let the chat ask questions, as well, so that the expert is able to guide us through, and we're here to ask the beginner questions and try to understand what's this for, where did this decision come from. Those are really valuable things. So, yeah, yeah. Got a lot of good stuff.

My experience learning blank. 100%. Do that all the time. Don't worry about making these posts perfect or encyclopedic or even particularly polished. It is really helpful to just write up your experience of learning things when you're learning it as a collection of notes. There's a concept called digital gardening. Maggie has a great post on this. I would definitely check out this stuff. Dig in there, look at this idea. One of the things that I think is really interesting is if you look at Maggie's site, for example, she has this idea of evergreen being a really well-considered post, and a seedling being -- she wrote -- you know, basically taking notes on what she's done. And there's a lot of coming soon stuff in here. And this one, yeah, look at this. This one is just a couple notes, some references, some slides, and all of this is very -- hey, there she did an illustration. Got a tweet. Little bit of notes, right, actually, this is a great post to go and read. The seedling thing, you don't have to get it perfect. Don't even have to get it done. You can say this is a work in progress if you want to read about it. And that can be useful to folks. So, yeah, I think what Ben is saying, too, it's important to get something out and learn from it and improve. I think a big block that I see for a lot of people is they don't want to ship it until it's right. The sad fact of the matter is nothing will ever be right and nothing will ever be perfect. You'll always ship it and find one more typo, one more sentence, one more point you wanted to clarify. The better way, in my opinion, the better way to approach this is to ship lots of things and build a story on that content. You know, instead of trying to ship one post that houses all of your world view, ship 15 posts, each containing one thought, and all building that. You can even ship a post about one of your previous posts with a clarification based on something that you've learned. I've written plenty of blog posts. A while back I wrote this post, you know, here's what I was trying to get across, here's some things pointed out to me where I was off the mark. So, I'm going to clarify. That's a great way to have this discussion. And it also embraces the same thing that we want in engineering, which is we shouldn't be sitting on our ideas until they are perfect. We should be collaborative about them. Take the idea and put the idea out, and get feedback. Show it to somebody. See what they think, find out what questions they ask. Usually, the questions they ask are great topics for your next post. So, you can start building this body of work by starting a conversation. And a problem I've run into in the past, I would sit and workshop my posts until I felt they were ironclad, and I'd taken out anything that was discussible. Boiled them down to just facts and that was it. There wasn't any discussion. If you're thinking about this, not really sure where I'm going with this, but I think I'm on to something, that sparks a discussion, because somebody else will say I've been thinking about that, too, here's my take. Now you start to have an actual engaging conversation and not somebody saying I agree with your point or disagree with your point. I think that's a thing worth doing.

Oh, yeah, Anne Lamott's Shitty First Drafts is great for that. Yeah, brain picking, this is a good one. Oh, this is rebranded, brain picking is now the -- okay. Bird by bird is a good book. It's on the creative process. I've written a post on shitty first drafts, as well. Somewhere in here. I don't even know if this is a good post. I wrote it a long time ago. So, sorry. Yeah, I also just realized I attributed this to precision nutrition, because I hadn't read bird by bird when I was contracting for Precision Nutrition. Huh, well, I need to update this, because I misattributed it. Cool. Anyways. Lots and lots of -- see, we're learning today. Like two weeks ago they rebranded. Okay. I'm glad I'm not years late to that rebrand. It's good fertilizer. That's a poop joke. PDF with the actual post text as well, that's great. I can drop that into the show notes. But the general idea, get something out there and try. An idea that's good but never shared doesn't have a lot of value. A half-formed idea that's maybe just okay that's actually shared is going to do more to have an impact. That's an important way to look at things. I think that's a good ending point for us, right? We're out of time, so it is now time to wrap this thing up. So, let me do a quick shout-out to our sponsors. So, first of all, we've had live captioning all day, we've had Ashly hanging out with us. Thank you so much, Ashly, for being here and writing down all these things. That's from White Coat Captioning. White Coat is with us every week, at every show. So, that is very helpful. That's made possible through the support of our sponsors, Netlify, Fauna, and Auth0. All kick in to make this show more accessible to more people, and that means a lot to me. And then we've got a schedule with a lot of good stuff coming up. So, make sure you go over to the schedule page on the site and hit this add on Google Calendar button or follow on Twitch. What we're going to do next, later this week, Natalia is coming on, We're going to talk about distributed databases in MongoDB in serverless and it's going to be a lot of fun. Next week, Pato on the show, progressive web apps and if you're not familiar, this is going to be really fun, we're going to jump in here and play around. Segun is going to teach us about Chakra UI. This is going to be fun. I don't use a lot of these front end tools, so I'm excited to see what it's about. We're going to keep it rolling. Login for Svelte, also Michael Chan is a delight to hang out with. So, you know, if you are not familiar with his work, you should definitely show up here and get familiar with it. Then, yeah, we've got -- I haven't even added everything yet. So much coming. I have ten more episodes in my inbox I need posted to the site. It's going to be great. Make sure you head over, get these figured out. And with that, everybody, thank you so much for hanging out with us today. We will be back on Thursday. And for now, we're going to go find somebody to raid. We will see you next time. Thanks, everyone.