Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Brian: Hi, I'm Brian. I'm hosting this podcast. You've probably heard me before. With me is Laurie Barth. Hi, Laurie. Laurie Barth: Hi, everyone. Should I introduce myself? Brian: Yeah, you might as well. I know who you are. Laurie Barth: Okay, cool. So I'm Laurie. I am a senior software engineer at Netflix. I am also a content creator, so I'm an Egghead instructor, I do a lot of technical blogging, I occasionally appear on podcasts, and I'm on Twitter a lot. If you follow me there, you'll probably see pics of my dog, pictures of the Lego sets that I've built, and a lot of random subtweeting based on whatever random thing is happening in my day. Brian: I can confirm because we're on Zoom, I can see the Lego sets in the background, so they do exist. I don't know if she built them. I assume she did. Laurie Barth: I did. Brian: So, we actually have a bunch of stuff to talk about today. I don't know how much we'll get to. We'll start with I think probably the philosophical topic and it's the middle-end. What is a middle-end developer? Because you consider yourself to be a middle-end developer, yes? Laurie Barth: In a bit of a tongue-in-cheek way, yes, but I do. Brian: Okay. So I'm curious about two things. One, what you would consider a middle-end developer, and then why is it tongue-in-cheek? Laurie Barth: Okay. So it's tongue-in-cheek a little bit because one, the middle doesn't have an end. So it doesn't really make sense. Brian: Oh, yeah, I guess so, yeah. Laurie Barth: But also because theoretically, I could call myself full stack like most people do, but I don't really think that captures it because it's more constrained than full stack. I used to be full stack. There was a time in my career that I would touch databases and DevOps and all of these other things at a shallow level, but I've gotten more in depth in certain areas and that's what constructs my middle-end ideology. Funny enough, I thought I'd made up this term and I think maybe I made up the word, but a bunch of my friends have been like, "Oh yeah, that's what I am. Oh yeah, that what I am." And my colleague made me put it on an internal document once. He was like, "No, put it, please. Please, validate my existence." Laurie Barth: So middle-end is the backend of front end, and the frontend of backend, which is really confusing. But what does that mean? That means the tooling and pipeline workflow around frontend is an area that I have a particular expertise in. So that means in JavaScript land, Babble and ESLint and Webpack and CI and all of those things, and compilers and blah, blah, blah, blah, blah, as well as the JavaScript end. Can I make the CSS and make the pages work? Yes. Is that my area of expertise? Not really. Laurie Barth: And then on the backend side, it's a lot of creation of APIs. It's CLI work. It's all of these things that, they're not the database and they're not working with pooling threads and that sort of thing. They're a little bit more on the surface, but they require extensive knowledge and lots of consideration of developer experience and user experience and all of these things. And so when you combine those two pieces, they make this really deep and meaty middle of the stack that doesn't necessarily focus on the extremes of either end. So that is what I describe as middle-end development, and that is what I think is my area of knowledge and focus. Brian: So one thing that I've heard lately, so I actually have this conversation a lot, either on this podcast with Kaelan in the past or just for work because I do think it's interesting, but I've heard it described that the middle-end is basically the interface. I'm wondering if that's something that makes sense to you or not really. Laurie Barth: It does. Pieces of it are, but I don't know that that encompasses everything. So the interface that developers interact with, that's absolutely true. It's how are they interfacing with the build pipeline and the developer workflow for making the frontend? How are they interfacing with the API, which is where they grab their data? All of that is true, but I think it encompasses a little bit more than that because it can extend to some user interactivity and not just developer interactivity, but it depends a little bit what you're building. Brian: How so? Laurie Barth: So if you are working on, I'll use the examples of what my jobs have been. So when I was working on the Gatsby framework, most of the things that I built were developer facing because it's a tool to build a website. So there wasn't really any end user involved. The project that I'm working on now, I'm creating a bunch of things for our contributors to hook into and work with, but there's also a level of tooling and other things I'm creating that are going to be for the users of the platform, like the end users of the platform. And it's just about who the customers are and where the different hooks are for them to interact with the project. Brian: What does that mean for hiring, or at least building a team? I would assume Netflix, for example has a lot of engineers. So somebody's thinking about, all right, so we need frontend engineers, middle-end. What's the... Laurie Barth: Yeah. So interestingly, my technical title is UI engineer at Netflix. I don't think anyone really cares what it is. It's just that's what I technically applied for. And they ended up hiring two people when they were interviewing for one. So they hired me and they hired my colleague. And they hired us because we have very complimentary skill sets. So technically they were looking for a frontend engineer. And what they ended up with was me, who's the back end of the front end and a little bit of the backend itself, and all of this tooling stuff; and her who's a CSS design system expert, who's not a designer, but a developer. Laurie Barth: Every team is about piecing together different individuals. And I think most people would consider middle-end developers to fall into the frontend spectrum more than the back end spectrum. I don't know that I agree with that, but what you'll find is on any team, even if you had full stack developers, even if you had backend developers, even if you have front end developers, all of those are way too big as terms for people to be experts in all of them. And so some people might consider me a tooling developer and they would say a team was looking for a tooling developer, but at the same time, there's an expectation and my expectation of myself is, I fit the needs of the project. I've done weird, random things over the course of my career. So this week I'm coding Java backends, which I haven't done in six years, but that's what's needed. Brian: Yeah. That sounds fun. Laurie Barth: It worked. I had a very exciting tweet where I was like, "I coded Java and it works." Brian: Interesting. So the other thing I hear is, okay. If we assume that JavaScript is essential to being a frontend developer today, which I assume it is... Laurie Barth: There are Python front ends. Brian: See? I knew that if I paused, I was like, "I bet that there's probably something." Laurie Barth: There are other types of frontend for sure. There's WebAssembly and other things, which honestly, I haven't dove into it, but I think it's slightly different though. There's JavaScript component. Knowing JavaScript is helpful. It is not the only option if you're going to write front ends. Brian: Yeah. And are there circumstances where you, not you personally, but where one could be considered just, and I'm using air quotes, a "designer"? I don't mean that like you'd just be like a designer and that's your title, but I guess it would be if you wanted to be a developer and someone considered you a designer, that would be maybe not so great. Laurie Barth: I think it entirely depends. So the first job I ever had, we had explicit designers, and I blame this on why I'm not very good at CSS. We had explicit designers and I wrote all of the backend code and I wrote all of the Angular JavaScript code, and I created the DOM elements, and then someone else took my code and added styles to it. I'm not even kidding. These are the designers. They created the mock-ups and then they did all of the CSS implementation. And so that's not a designer, that's a developer. That's very impressive. I didn't know how to do any of that. Laurie Barth: And so I think that's a unique situation. I haven't heard of a lot of companies since that have that model. I think more common is that you have a designer who's playing around in Figma files and making SVGs and illustrations and all of those things. It is very rare that I have found a designer in my career who can't also play in the code space. They just don't enjoy it, but they can implement stuff if there's a crunch and something needs to happen. They can tweak something if it doesn't match the mock and they don't think it looks particularly good. Laurie Barth: That being said, there are plenty of people who want to be designers and they're getting pigeonholed as developers, who want to be developers and are getting pigeonholed as designers. There's a whole conversation about how you break into design because as entry level, they're like, "You need to have a portfolio of 10 different projects," and all of those things. So I think everyone is individual. And part of the reason I use the middle-end terminology to be honest, is I don't think we have a lot of nuanced specialties. I don't think we have a very good vocabulary for talking about the different skill sets that people have, because let me tell you, one frontend developer almost never has the same skillset as another front end developer. Brian: How could they? There's so much stuff to know. Laurie Barth: There's so much. And the same is true of backend. There are backend people who are SREs. There are backend people who are purely DevOps pipeline. There's backend people who are security people. These buckets just don't really make a lot of sense anymore, and we've done a lot to improve them, but the backend and frontend labels have persisted and we need to get more granular, especially when we're trying to figure out what our teams need and what we're hiring for. Brian: So that makes me think more about what the future of engineering teams looks like. And I understand that maybe not everyone cares all that much about titles, but it feels like we're either all moving... I say we like I'm a developer. I'm not... like if we're moving to one, just homogenous title, even though it's impossible to be that way, or is everyone hyper specialized? Laurie Barth: We have generalists and we have specialists, they both exist. The title thing is complicated because even if we got into a universe in which all of the specialists were properly titled, across companies they wouldn't be the same. It's the same way that leveling is different across companies. So people don't know this, but Netflix only has one title, senior software engineer. There's nothing above that. There's no nuanced title above that. So I came from being a staff level-two engineer at Gatsby, and I am now a senior software engineer, which is very confusing to people who work at Microsoft or Google or Facebook or Stripe, or any of those companies, because they're like, "Senior means four years of experience and it's above software engineer level-two. And then there's staff one, and then there's staff two, and then there's senior staff and then there's principal." And I was like, "No, not here. Staff principal is senior." And it's confusing. Laurie Barth: And so I suspect the same would be true, where if you said, "I'm a tooling engineer," at one company that would mean you work exclusively on the CLI experience. At another company that would mean you work exclusively on the frontend CI experience. And at the last company, that would mean that you're making developer facing API component libraries and it would just never make sense because we're terrible at naming things appropriately. Everything gets overloaded. And then what you think is a one-to-one mapping is not. Brian: I don't want to get you in trouble, but do you know why? Why is there just the one title? Laurie Barth: Why is there the one title at Netflix? Brian: Yeah. Laurie Barth: So there's this really public culture doc that you can read, but there's an assumption... There is a software engineer title, there just aren't a lot of them. And granted, not everyone is a software engineer. I'm a UI engineer, there's people who are DevOps engineers and SREs and other things. But there's the no level, which means you don't have a modifier. And there are some of those, but most of the people I found are just senior. Laurie Barth: There's an assumption at Netflix that everyone is pretty advanced in their career and an expert and that you can trust them to make decisions and be accountable and doing things in the best interest of the company. And all of that is based on the idea that everyone you're talking to has pretty deep knowledge in the area they've been hired to work in. And so at that point, it's a matter of degrees, and compensation is not tied to promotions or titling. So I think it's just not necessary distinguishing between different people. Laurie Barth: Honestly, the more distinguishing factor is tenure, and that has little to do with how expert someone is, and it's more, how much context do you have about the five other teams this might touch, which depending on the size of your company is probably a very helpful piece of the puzzle compared to, "Oh, hi, you were a distinguished engineer at Microsoft for 10 years. And now you work at Netflix. I'm sure you're super experienced, but you just got put in the deep end and you're not going to be any more knowledgeable on this than I am." Brian: Yeah. I don't want to go too far into organizational dynamics, although I am interested, not specifically at Netflix, but pick another company of roughly equal size and talented developers. They have a name for that, but I'm not going to use it. I wonder how those compare other than how they organize, how many teams are there, are they organized differently? That would be helpful if you were considering moving around or just wanted to map out your career, but I feel like I just opened the door to a huge conversation that there's no possible way we could [crosstalk 00:15:29]. Laurie Barth: Yeah, there's a lot. I would say if you're interested in about... I can't speak for other organizations because I honestly haven't worked at larger organizations since I worked for the federal government back in the day, but the culture page, which is available to everyone is really interesting and gives you a general idea, but I think the main thing to know is in other organizations, promotions or how you get raises, they're how you get more responsibility, they're how you get a bunch of career progression stuff. And at Netflix, all of those decisions and all of those conversations are pushed down to teams. So the expectation that everyone is senior is that everyone can contribute to those conversations and make decisions, not in a hierarchical manner. Laurie Barth: And so moving up, you're not going to increase your responsibility by getting a different title. You're just going to change your job. And so it's not going to be like, "I have more ownership." No, you have just as much ownership as you want at any level. And again, the compensation piece is completely separate. So the typical reasons for titles don't really apply. Now, if you're going to go interview for a principal role at Google and you're coming from a senior Netflix title, you're lucky because everyone knows what Netflix's titling looks like, so no one's going to knock you for it, but in a less known organization, that's absolutely problematic. Brian: Yeah. It's funny, the smaller your company is, and I'm thinking about LogRocket, when I started there were less than 10 of us and Matt, the CEO was like, "Well, what do you want your title to be?" And I was like, "I don't care. We're at a conference table in a room. So we call me whatever you want." And then there were more of us and then we got more title standardization, and I assume that'll stick around for a while. And then is the final stage once you get really big and successful that you go back to, well, titles are just- Laurie Barth: No, I think Netflix is an anomaly there. I think in most cases, titling ends up mattering a fair bit. I will say I was a software engineer, and then I was a software engineer, and then I was a software engineer. I never my title because I was at small organizations and it didn't matter, and it was very flat, and promotions didn't work that way. And so I was just always a software engineer. And then I wasn't. Then I was a staff level-two engineer. And seeing my LinkedIn is really confusing because there's no senior title anywhere in there. So when people ask me, they're like, "How did you become a senior engineer?" And I was like, "I worked in a flat company. I just was one." But we never acknowledged it. And then when I went to interview for the next company, I was like, "Yeah, no, I'm not getting under leveled. This is what I should be in your spectrum of job titles." Laurie Barth: But it's complicated and a lot of it has to do with knowing the market and understanding what those titles correspond to and what they mean. And I was lucky, and I had a lot of people I could talk to, and there was a spreadsheet that explained what each level was, but all of these things, it's not easy. I'm rambling, but it's complicated, it's nuanced, it affects different people differently. Obviously, if I walk into a room and say I'm a senior software engineer at Netflix, hopefully I'm going to get some, "Okay, she probably knows what she's talking about," and that's helpful as a woman in technology, but I'm also a white cis woman in technology, so I need some help there, but not nearly as much as other people do, where titles are super important because everyone's going to assume they're the secretary. It's just different people rely on titles for very different reasons. Brian: Yeah, that's a great point. You need a certain title for progression so that you are fairly compensated either at your current job when you're up for a promotion or when you move on. So that part escaped me as I was thinking about the final stage of organizations as they get big, in a very abstract and weird way. Laurie Barth: Hey, there you go. You should go be a CEO. They do that all the time. Brian: Me as a CEO would be a horrible idea. The board would like talking to me occasionally. So I do feel like we owe it to the people we asked on Twitter about middle-end, to answer their questions. So for everyone listening, we weren't really sure if we were going to have enough really to talk about that we hadn't already covered for what is a middle-end developer? So we solicited the public. I feel like if this were a late night show, this would be a segment or ask the audience or whatever. Laurie Barth: No, we got to go to the street with the microphone. Brian: Yeah. I would love to do that. I wish- Laurie Barth: It would be really fun, I'm not going to lie. Brian: I don't know where I would find... Well, you know what, you do it at a conference. Laurie Barth: Oh yeah. Brian: Okay. So I'll just read the questions and then you can respond or not, if you feel like these questions are not that exciting. Laurie Barth: Okay. Brian: Okay. So first one. Honest question, what is a middle-end dev? Doesn't being in the middle exclude it from being an end, which I think you just answered. Laurie Barth: We joked about that earlier. Yeah, no, that's why it's tongue-in-cheek, but I think we did cover what it is, and I think if you consider frontend and backend, where do they meet? And if you were to create a little circle in the middle, what part of the stack would that encompass? That's basically what we're talking about. Brian: Yeah. Okay. That's how you know we're doing this live is that I just read the thing in front of me. And then when I was done, I was like, "Oh, we just talked about that." Okay. Next one. So I don't know what this term means, but I think I might be one of these, which I... middle-end developer. What exactly is a middle-end developer? How would you define it? Am I middle-end developer? Are they cool and artsy like frontend or science-y like backend? I don't know. That feels weird to pigeonhole them all. Laurie Barth: Oh, that makes me sad that people think of frontend is cool and artsy and backend is science-y. I think one of the takeaways that everyone should have about programming is it's much more creative than people like to think of it, regardless of what area you're in, because you can solve the same problem 20 different ways. And it's about being creative with your solutions and thinking through what is the most elegant way of doing this in a way that's readable, in a way that conforms to best practices, all of these things? How can I make this more robust and less hacky? And yeah, of course, there's science to it. There's math to it. But math is much closer to music than it is to biology. And I say this as a math major. So it's much closer to languages. It's closer to all of these things. Laurie Barth: So if you think of programming as a language, everything is creative and everything is fluid. And whether or not you are a middle-end developer, that's entirely up to you, but maybe you can use the definition I've talked about to make the determination for yourself. Brian: Yeah. Even at LogRocket, which again, there are... I forget how many there are, there may be 100 of us now. When I think of our backend devs, the problems that they have to solve, in order for them to do it, they have to be really creative. They're some of the most creative people we have. So I don't know that I would agree with that question that's calling them science- Laurie Barth: Yeah. And I would also say that there are front end developers who don't do anything related to design and use very little CSS, and they are still incredibly creative, because figuring out how to trick the browser into being performance, even when you're loading it with 5 million things, that's an exercise in creativity every day. Brian: Yeah, for sure. So then we have a couple of other ones. We talked about how to see... Now I'm ahead. How does middle-end change based on company size and structure? I think we covered that. Oh, this one we didn't cover. How does testing work in the middle-end? Laurie Barth: Interesting. So testing in the middle-end is very similar to testing APIs in the backend and testing end to end in the frontend. I would say that there's a lot of integration tests that you would do if you're building something like a CLI, but a lot of middle-end work, at least on the tooling side is making sure those tests are running and preventing people from doing things like merging with the main branch, or pushing updates to production where they fail tests. Laurie Barth: So a lot of that is taking things that are best practices, whether that's ESLint rules or tests or pretty or any number of other things and making that part of the workflow automation. So that's a big part of what middle-end devs wire up and get working, or at least in my definition of middle-end. It can be different for everybody. Brian: I don't believe that there is a hard and fast definition of middle-end, so- Laurie Barth: Well, I just created one, didn't I? Brian: Precisely. So yeah, it sounds accurate. Okay. So then we have a bunch of other questions that don't really seem to me like they're middle-end specific. So the first one is what can staff engineers do to make your experience easier? I suppose that means you specifically. Laurie Barth: It's funny. I think this person read middle-end as middle career, because there are a staff level middle-end devs. I was one of them. So it's not about levels. For any title or any given person, you have the level that you are, and that can be early career, that can be senior, that can be principal, whatever. And then you have your area of focus, that can be backend, that can be DevOps, that can be design, whatever. So you can have a principal middle-end engineer. That's more about seniority and depth of knowledge than it is about anything else. Laurie Barth: I will say if you are a staff level engineer and you're a team lead and you have a middle-end developer who isn't at that level of seniority, be super collaborative and communicative about how they can one, make the job easier of the developers on their team, making sure there's appropriate tooling and that sort of thing, but also make sure that they're really well-integrated with anyone who's doing user experience interviews or doing design, so they can have in-depth conversations about, "What should this API look like? What is an intuitive CLI experience for this?" All of those pieces, because there's so much of middle-end development that is about really intelligently building those interfaces. Brian: Sometimes I just nod my head and then I forget that no one can see me. I agree with that. So that's what I just was doing. Okay, last one. What learning resources exist to grow... Oh yeah. You're right. So to grow it and mid-senior level? Laurie Barth: Yeah. So middle-end versus middle level. Very much depends what you're working on and who you're working with. I would say some of your best resources are at your job because that's the area that you could potentially want to grow. I always recommend some of the people who are streaming code because I think it's a great way to see how other people debug, especially because there are so many really senior people doing that. Laurie Barth: We do more blog posts, building more things. It depends entirely on what you want to do. One of my ways of leveling up was to constantly write about what I learned because it made me understand it at a deeper level and it provided me with this really nice resume of, look at all the things I know. But everyone's different. So you just have to find something that you're interested in doing that will help you combine increasing your knowledge with making it repetitive and something that you're going to remember. And if you do it in public as much as you can, that's not a bad thing because it helps give credence to the fact that you've leveled up in this way. Brian: I would also just add the LogRocket blog, just frequent it all the time, just whenever- Laurie Barth: Yeah, exactly. Brian: ... whenever it comes up in a Google, just be like, "Yeah, this is where I want to go." Laurie Barth: Honestly, blogs are really critical. And if you find one where the writing style resonates with you, absolutely. Brian: You and I could, I think, probably talk about creating blog posts for devs for a long time. We don't have that time right now, sadly, but maybe another time. Okay. Not that I wasn't excited about all the stuff that we just talked about, about the middle-end, but I am really excited about this topic. So I saw that you tweeted out, let's see, I'll give a proper date so people can go and find it. On May 11th you sent a tweet that was just like, I don't follow... Oh, I'm sorry. I'll read it verbatim. There are a lot of really big names in JS that I don't follow. It's not an accident. What do you mean? Laurie Barth: Isn't that the point of a sub tweet that it's vague enough that nobody knows? Brian: No, that's why I want to do it. Well, yeah, but what... Laurie Barth: So for April fool's day, I made an entire launch page and a workflow for signing up for the mailing list for the launch of a book, which has a cover and a 3D design and all of that. So I made this whole April fool's joke and the title of the book was The Art of the Subtle Sub Tweet. And I had this whole launch page and you can still find it. It's on my website/booklaunch, I think is the URL. And it was joking about all us. It's like, "I'm going to tell you what the source of my subtweets is for greatest hits," all of these things. Honestly, I didn't do that. Laurie Barth: So there were a few reasons for me posting that, but I think the take away from it and what I think is important is one, you don't owe anyone to follow, myself included. You can create your community on a place like Twitter with as much restriction or openness as you want. You don't have to have your DMs open, you can have your account private, you can do whatever you want and no one should make you feel bad about that. Your boundaries are your boundaries and that's super import. Two, I'm a JS developer. I'm developed in other languages, but I'm very well known for being a JavaScript developer, sometimes for a JavaScript developer who's learning Rust. I blog about JavaScript. I work with TC 39. I make video courses about JavaScript. Laurie Barth: You would think that I would follow the major players in JavaScript and I follow some of them, but I don't follow all of them. And normally if I don't follow them, it's not because I haven't heard of them and I haven't seen their accounts. So that's why I say it's intentional because maybe I've seen them and I'll like, "No, it's not really my jam." And there's normally a couple of reasons for this. One is a lot of the really big names in JavaScript are talking about and tweeting about and building very specific tools. If those are tools that I'm not particularly interested in, or I don't use, it doesn't make much sense to dilute my feed further. So that's one piece of it. Laurie Barth: The other piece is that I have seen, and this is not JavaScript specific. It's just something, there's a lot of JavaScript people on tech Twitter. Some of those people can be super dogmatic, and they can come down and say, "My tool is the best because, or you should never do this because," and anyone who follows me knows that that's really not my thing. I'm super anti-gatekeeping. I was a consultant for seven years. I know that pretty much everything that has ever been invented was invented to solve a specific problem, and it solved that problem well. And just because it doesn't solve your problem well, doesn't really give you license to discriminate against its use, especially when half the time these are bleeding edge tools and people are like, "Oh, don't use X." And I was like, "X is used on 50,000 legacy systems and those legacy systems aren't going away." And so sometimes I just don't want to deal with that. And it normally he finds its way to my feet anyway if it's a particularly bad take. Laurie Barth: Also, I am all for people who create content, I'm all for self promotion. I think, especially when you're making a living out of content, that's super important. But again, if that's all based around a specific tool that I don't use or particularly have interest in at this point, there's not much relevance in adding it to my feed. So that's the main reason. And obviously, as with any area of technology or any industry, there are certain people who are just toxic and sort of assholes, and I don't want to follow them either, but that's less the case. Brian: Yeah. To my great disappointment, that was not really scandalous and fair and well-reasoned. In the interest of fairness, and I've said it on this podcast before to different people, for me, so I curate the LogRocket Twitter account, and then also my own account I follow, just because when I was starting, maybe four years ago I didn't have a ton or really any web dev experience. So I was trying to figure out who the major players are and all that stuff. But what was really difficult for me was trying to disentangle who were the ones that are building things, and who were the ones that are talking? And what I've come to realize later on is that the talking part, that's their job. Brian: And so I used to say that more negatively than I currently do. Now I get it. Oh, okay. Your job is to do just that, is to be a cult of personality, and I get it. And then you also get the wrong idea. We had Swyx on here a few weeks ago and he used to drive me crazy. And then I talked to him, not in person, but I actually talked to him here and I was like, "Oh, turns out I like Shawn, go figure." Laurie Barth: Yeah. I think it's actually really challenging to be someone creating the content and be the person who is walking a very fine line between I'm a talker and I'm a creator. So I have at times felt like I am being a talker and I've been a talker for a month because I haven't had time to create. And I think for people who don't create, there should be a little more sympathy for that. No one wants the label thought leadership, but at the same time, it's a lot easier for me to write a 250 character tweet three times a day based on something that I happened to be working on or thinking about, than it is for me to sit down and create a video course or write a new blog post or all of those things. Laurie Barth: And there are going to be stretches of time where I can't do that. And that doesn't mean I want to withdraw from a community that gives me a lot of joy and provides a lot of value in my daily interaction. But yeah, my profile of what I'm putting out into the world is going to shift. And I struggled with that for a long time, because I was like, "Okay, if I'm not producing content, then I'm just another thought leader, and that sucks." But I think having grace for that and recognizing that it's always going to ebb and flow is a good thing. Not everyone needs to be a creator. There's also people who, the tweets that they make are super valuable in and of themselves, which is a weird concept to me, because I think of a content creator as blog posts and videos and courses and all of those things. Laurie Barth: And a few weeks ago, maybe a month ago, I mentioned, "Hey, I'm starting a new job. I'm onboarding, I'm not going to be creating as much content." And I meant I'm probably not going to have any Egghead videos out. I'm probably not going to be writing any blog posts. That didn't end up happening. I had some stuff I needed to write about, but I'm not going to be doing this for a little while. And everyone was like, "Well, we'll miss you, but Twitter will be here when you come back." And I was like, "Interesting." There is a huge number of people who expect that when I say content, I mean the tweets that I write, which to me is the low stakes thing that is literally just my stream of consciousness throughout the day, type, type, type, send, keep going back to work. Laurie Barth: So I think for a lot of people, Twitter is content. And when you write, "Oh, Hey..." Like yesterday or the other day, I was like, you can do git status--porcelain. Or I think that's what the command was. And like, I just tweeted that out. I was like, "Hey, I just learned this thing." That is content. That wasn't a full blog post of content, but that was a thing. So it's hard. There's a balance. There' no stringent rule, but the line is a lot hazier than I think I ever realized. Just follow who you want to follow, but recognize that at any given time, the profile of what they put out into the world can be drastically different depending on what they have going on. Brian: Also, I don't think it's a challenge, problem, circumstance that's at all unique to either tech Twitter. I think it's just the nature of the beast with Twitter in general, which is why it's perhaps not my favorite platform in the world. Laurie Barth: Tech Twitter has its moments. "Villain of the Day" is one of my least favorite things because people just need to stop putting terrible takes on Twitter and getting everyone up in arms because they deserved it those days. It's not like they didn't really stick their foot in their mouth. I'm just like, "Okay, really?" But tech Twitter has been super important to my career. So in that way, I find it very valuable. Brian: Fair enough. And I think that this conversation was very valuable and I think it's reached its natural end, because I'm not going to ask you any more questions about what you think about Twitter. Let's see, we managed to figure out what exactly a middle-end developer is, was and will be mostly. And we talked about the people that you don't follow on purpose without naming any names. So everything worked out. Laurie Barth: Absolutely. Brian: So thanks so much for coming on. This is where we typically off, what do you want to plug? Anybody, anything? What should people go check out? Laurie Barth: Yeah. So obviously I'm on Twitter @laurieontech. I have a website where I put my blogs and podcast appearances and all of that. I have a bunch of courses on Egghead IO. In terms of plugging other people, I would say look at the people I do follow. There's a lot of hidden gems there. And I highly recommend giving all of them a chance because they were chosen intentionally. And if there's someone you don't like, let me know, maybe I made a mistake. Brian: Or you're wrong, and you should follow them. Laurie Barth: Yeah, exactly. Brian: Well, thanks so much. I really appreciate it. Laurie Barth: Thanks so much, Brian. It was awesome to be here. Brian: Bye. Brian: Hi. Thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah. We'll see you next time. Thanks.