And today's episode we're going to be talking about things like books versus audio books. And that's relevant to you as a developer and you're going to find out how in this interview with Ben Halpern, my name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to coach you through some of the hard parts of your career. Give you advice, give you ideas and inspiration and hopefully answer your questions. And to that point, if you have any questions for me, you can always email me at developert.gmail.com. We try to uncover tools and processes and ideas that are going to help you in your career. Hope you level up and become a great developer to adopt the great developer mindset. So thank you so much for listening. I'm going to get out of the way and we're going to get straight into the second part of the interview with Ben Halpern. If you missed out on the first part, you may want to go listen to that first. Thank you again for listening. Let's get to the interview with Ben Halpern. Like there's absolutely nothing wrong with cutting your content in half and people will come back and read the second part. Oh yeah. And to the point of posting it on your own blog on dev.to, we actually tried to, it's not always clear, like we sort of need to get better at describing all the features, but we try to make it really easy for you to cross post from your own blog. In terms of, we use Jekyll Compatible Markdown as our basic editor. We provide the opportunity to add a canonical URL to the post so Google knows to send all the link juice back to your own post. And my mindset with that, I think, is that really we want you to sort of own your ideas and you should have a canonical source for your writing. But the way the internet has evolved and some of the just kind of fundamentals of CSS work honestly, it's really nice when everything is packaged up in a consumable reading environment where every blog post sort of looks the same and you don't have to move your eyes to find the text and everything. So that's a lot of the value we provide. But we actually encourage people to cross post, it doesn't have to be original work. They can find an old post they've written and sort of give it some new life on our platform. For a while, I was concerned whether things needed to be original and then we just decided we can go the 100% 180 and let people go crazy with cross posting old posts or anything that's obviously still relevant. A lot of ideas are kind of fundamental and if you even think it's still relevant, it probably is. And you know, this is honestly, I don't get a lot of chance to just talk about the platform and give people ideas about how to use it. I think sometimes I'm a little shy about being self-promote but it's, yeah, honestly, we have a thousand Twitter followers I talk to every day and I never even say this stuff because I don't want to enjoy them. But I like interviews because I don't think people are annoyed to find out about these things once you really get to open up and talk about it. So obviously, thanks a lot for giving me that opportunity but I really think when I hear from people who don't want to post or who want to get better at this stuff and they don't know how, I'm always just really excited to talk to them and I'm sometimes not as good at expressing to the masses what's possible. One on one, I usually have a pretty good idea of how to get this across. But honestly, I just know myself, I need to take my own advice and I need to write some good, quick blog posts about this subject. But just today, someone reached out to me on Twitter just with the question, how can I be a better technical writer? And I DMed her and I kind of told her what I'm telling you which is good kind of preparation for this discussion. And she was all about it and I'm kind of excited to talk with her a little bit more and getting her up and running on the platform. Yeah, it will be interesting to see how people respond to this episode as well and people who go and sign up for an account at Dev.to. I signed up and went through the onboarding, really cool onboarding process for anybody who wants to create a community platform. This is a really good blueprint. Like Cohen, look at the ideas on Dev.to because it's actually really, really interesting. I love the tone of the whole thing just feels very, you know, I hate to say it's a social network because it's not, but it feels inviting as a developer, which I think is really unique. Yeah, well, I don't really use the phrase social network because it's kind of a buzzword, but so, but we provide, we like, we hope and when I talk about this, like half of this stuff is just like what we hope the platform can grow to. Like I don't even think of it as like, it's just kind of getting started. Like we really, for 99% of work that's gone in, it was me solo, I mean, you know, but this summer, I brought in some more help and I'll talk about that in a sec, but we really are like taking the sort of the approach that developers kind of need to be grounded and need support and we sort of provide that support by giving sort of a place for to discuss the technical parts, you know, we don't, the groundedness you need sometimes is not strictly, is we don't necessarily address some of the underlying things that make you feel this way, although I'm sure we do do that, of course, as well, but we sort of, we just kind of try to provide that value and we, and we sort of have an abstract platform. So, so whatever that thing that you need is, we hope will ultimately kind of surface itself for you because, because we try to do a good job with our sort of ranking algorithms in combination with our editorial oversight for the whole thing to really kind of help people fill in the gaps and get to the nuance. And if I can for a minute, I feel like I haven't really talked about anyone else involved in this venture, which is kind of a just not sort of a good thing for them. But yeah, so it's, it started myself and it very, very much was a solo project. So I'm not being dishonest to talk about the origin story that way, but the summer I brought in my friend Jess and I was introduced to her because she wanted, she just graduated from boot camp and she really wanted a, some help with some stuff and just she just wanted to get rolling with her career. And I met her through a friend and we got working together on some stuff, different stuff altogether, different project. And ultimately we just wound up being really great partners and I brought her in and we were doing it part time and I work, I'm the co-founder of this startup Argo and I've been doing that for most of my day and then practical dev and dev.co on the side. But we've just recently sort of combined all these things because it was getting to be too much. The platform was taking off too much. I didn't have enough hours in my day. So I wouldn't say like we know exactly what our organization structure is right now, but now we have, we have the rest of our small team at Argo and involved in the project and my co-founder Peter at Argo is now sort of a co-founder of the whole venture along with Jess and I and Jess's involvement coming into our little organization has been awesome. She really brings a lot to the table from an organization and just personality perspective. And we've really been firing in all cylinders ever since the five of us and we are just having a lot of fun with it and doing just really fun things every day. We often go home pretty tired because we've really been working hard but it's been a lot of fun. So you're living what a lot of developers would like to be doing. Like you're doing what a lot of developers would like to be doing, engaging yourself on a product and doing it with a couple of people who are really involved. The team isn't so big that it's limiting or that you have a lot of strut. Like you said, you're not even certain what the structure is at the moment but that's kind of where a lot of developers want to end up. Another thing that is marking what you guys are doing today for example and we mentioned this earlier but you had this Twitter conversation or what would you call that? It was a Twitter chat that's the word we will use for. It's not like an official thing that Twitter does but it's a hashtag that you could follow. It was called, I believe, a stack chat. Is that right? Where was it? A stack service. A stack service. There you go. A stack service. Of course, we can link that in the show. But I'm certain actually that a lot of developers here listening to the show probably saw that on Twitter if you are on Twitter today and by the time that this releases it will have been a couple of weeks ago. But first of all, having a chance to do something in tandem with the people that stack overflow, that's a pretty big moment for we all know about stack overflow. It seems like that's a distant big entity and I feel like that's a huge moment to experience. Can you talk about how you actually went about garnering that opportunity first of all? But also, I'd love to know some of maybe two or three really interesting findings from that conversation today. Yeah. So every Tuesday at 9 p.m. Eastern time, we do one of these Twitter chats called Dev Discuss. We have just a bunch of our followers to show up every week to discuss a new topic. And our European and Asian and Australian followers are kind of annoyed that we don't have one that's more better for their hours. And we will by the time this airs, I hope we have a second one every week that's better for their time zones. Anyway. So we do this and it's not even the biggest thing we do. It's just kind of one of our weekly things. But stack overflow sort of recognized that we sort of understood the nuance a little bit and we had a fun community and a really welcoming, loving community. And they, Caitlin from Stack Overflow reached out and she, I forget exactly how it came about. She asked about, she let us know that they were going to release their annual survey. And my ears parked up like I know all about that. It's an incredible, it's an incredible yearly thing. There's 60,000 people who took the survey. It's remarkable. And I was so excited to help partner with them on the release of this thing. So what we did today was, we just hosted the same sort of chat. We did it during the day this time in my time zone. And that was a little nicer for the rest of the world. Except, I think it's a little less nice for America because everybody's at work and it's not really a great time to just be hanging out on Twitter all day. But ultimately, we had a really great time. We sent about. We just started a lot of conversations and the team at Stack Overflow was really excited to just be kind of having this live conversation a little bit. They have such a huge community, but they just don't kind of have the same kind of community. And they don't have the same kind of established practices and stuff. And they were really excited to work with us about the things we do well. And that was just, and we were so excited to get to work with them. And we didn't even need to go to the office, but we did anyway. And we went to their office and we just hung out with a bunch of members from their team. And we had a fun, fun time after two hours. I'm pretty burnt out from preparing for the whole thing and getting it done now. But I'm glad it's over, but we had a blast. And I think they really enjoyed the partnership. And it's really surreal because that we, that Stack Overflow reschedule us, it's kind of, there's a lot of lore around Stack Overflow at least in my mind. And I think there is a lot of genuine things that we do differently. And there's a lot of Stack Overflow can't be everything to everyone. And there's a community and there's a lot of reasons we, we provide value to people. And it's, it's, it's pretty clear to them that they, that they saw a lot of that same community and attempts to sort of just foster a great culture that we've worked so hard to do as well. That's really cool. And so these questions that that were asked were, you know, basically asking Developer To explain, you know, what they are doing in their careers, right? So different, different methodologies, different languages, you know, how, how they learn that kind of stuff, right? Yeah. And there's a lot of, of different types of questions. So there's a lot of interesting opportunities to compare the two. Like Ruby developers feel this way about their, the future programming of salary and closure developers feel this way. And, and it's, it's a lot of fascinating data. And we're only really getting started to unpack it. We on dev, on, on dev two, we're going to be trying to write as much about this, this data as we can. And we're encouraging our members to also write about the data because it's just so fascinating. And like, as with the sort of libraries and as with these things, the data itself is only, that is only so interesting as the stories it tells. And, and we intend to tell some interesting stories. And of course, stackable for themselves, they have a whole team trying to, trying to tell interesting stories. But the data is going to be 100% public. And I really hope people dive into it and, and find out some things about our, our industry and our community that people didn't quite realize. Yeah, yeah. So if you don't mind sharing maybe one or two things, I wanted to insights that you came across today that were either surprising or, you know, maybe they're, they're verifying some of the things that we've talked about already. Yeah, so one thing I, I, that really stuck with me was that programmers on average consider themselves un, underpaid. Pretty much like that's pretty definitive, you know, it was, it was a spectrum. So it wasn't exclusively that way. But a lot of programmers, sensitive themselves, either somewhat are quite underpaid, which is interesting because in general, at least from my experience, we get paid pretty well. Like programming is a pretty lucrative field. Not everyone makes Silicon Valley money, but there's a lot of money in the industry. And yet people still genuinely sort of consider themselves underpaid. And I thought I really want to sort of investigate that a little bit more once the data comes out. Interestingly, my mind went to the idea that there are sort of, this is a global survey and it's not the same American experiences, not the same everywhere in the world. But early indications were that it wasn't all that strong in the differences across countries and somewhere, there were some differences, but it wasn't like a direct correlation between earnings. It's really interesting. It's very psychological, you know, considering itself underpaid. Yeah. It's a fascinating idea. And that one really stuck with me. And yeah, a lot of this was about career stuff. So a lot of it tied into people's earning potential and stuff. And another one, it was interesting to see closure is the most highly paid programming language you can be in. But that doesn't mean going out and learning closure is your best bet, because it sort of so happens that people choose closure for problems that are sort of fundamentally more difficult. Like if you choose closure to make a simple application, you're going to be wasting a lot of time. But closure is fundamentally very, very powerful. But if you look at the data, you say, like, if I learn closure, I'll make more money. Well, that's probably not the case. It's probably more of a correlation. The second highest paying language interestingly with small talk, which is kind of funny. And it's not really a living language in a lot of senses. It's probably got, there's probably just existing applications that need to be up kept. But the people who program in small talk are likely, and the data indicated their extremely experienced. And it's just interesting to see the hottest, most upward trending sort of language slash implementation of a language is Node.js, which is super surprising. You definitely see that rising quickly. From my anecdotal experience, I find that any environment or language that's gaining a lot of popularity and it's also kind of more Lucy Goosey and it's typing and it's environment sort of like JavaScript or Ruby. When Ruby was a little more a newer, less mature, it gets a lot of sort of a lot of flack, but it's also gaining popularity. So there's a lot of, it always creates a lot of divide or flame wars that people are really being jerks to each other. But just fundamentally Node.js is just skyrocketing popularity these days. Yeah, it's pretty amazing. I think a lot of it, we can postulate why a particular language ends up being super popular. You have Java, which is still an incredibly popular language. Tons of jobs in Java still a lot of big companies relying on Java as their underlying thing. And you could say, at least globally, that Java is also the dominant language for mobile application programming as well. On the flip side, you have the rate of growth of something like JavaScript or a little while back, the rate of growth of something like Ruby, which was certainly highly influenced by Rails and the growth of that community and web development in general. But really trying to predict what the next language is going to be, it's kind of difficult to say, okay, well, these features are exactly what would make the next killer language. Because all of the features that you can imagine probably already exist in a language that nobody's ever heard of. Oh, yeah, absolutely. And it's sort of a popularity contest. But it also kind of needs to be because it's not strictly a language. It's an ecosystem. There's nothing about the English language that made it take off to the extent that all our programming languages are also the English language. It just kind of happened to be that it caught on with the right crowd. And it's programming languages are as much about the ecosystem as they are about the fundamentals of the language. Yeah. And I mean, they need to be good, but they also need to be popular. So it's a really, it's a study in anthropology and communities as much as it is about computer science and semantics. Absolutely. I mean, it's a marketing, right? So you have large, huge companies behind popular languages, Java and Oracle. And you have Mozilla, which I wouldn't say is nearly as big as a company like Oracle, but Mozilla and Facebook are behind JavaScript pretty heavily. Obviously, Apple being behind Objective C, well, when they moved to Swift, Objective C took a pretty big hit at that moment. And so it's easy to think about these languages in terms of their, in terms of them kind of living on their own. But really, they do rely very heavily on business energy to keep them moving forward. Oh, yeah, absolutely. And I think, I think, I think languages, programming languages you choose. I think as you advance in your career, it doesn't matter as much the languages. So much as understanding the context of a type of apps and the important things that go into the sort of the nuance of the protocols and stuff, I think it's easy to get caught up on which languages and frameworks become popular. Because in the moment, that can be very either frustrating or, or it really depends. I mean, for new programmers, if you feel like you're learning the wrong thing, it can be really demotivating. But there's never a loss in value of learning something. I don't feel like, I really use jQuery anymore as a library, but I feel like that context in my mind of having worked with it and having been able to compare it to how modern browsers have made some of jQuery's features less important or how the frameworks have sort of taken on. The abstractions that jQuery provides and built them into a more structured environment. None of that makes me feel like I wasted time learning jQuery. Sure. Yeah, no, not at all. Yeah. And if anything, if any frustration you have learning jQuery, it's that maybe you learned it instead of learning some of the more basic primitives in web development or something like that. But it's a long journey and every experience is valuable. And I feel like in college, I coded mostly in Java and sort of the, there's a lot of Java sort of pain points, which some people are totally fine with, but some of the verbosity and the boilerplate that went into it just never really kind of worked with me. And when I got to start coding in Ruby, it was really a pleasant experience. But I am so thankful that I have this very different experience with a type system and with like what else is out there. And as long as you're open to learning new things, I don't think there's ever a situation where there's a worry that you're learning the wrong thing. If you get into that situation, I think it's because you weren't open-minded from the beginning. I've certainly talked to people who will sort of be just so set in their ways that I just hope their environment never goes away. Or anything else. No matter how much they like the environment, they'll, I think as long as they realize that just coding is coding. And you can pick up new things and you can always keep learning. And you'll never lose the ability to learn if you really think you can. And that's really been, that's sort of allowed me to keep coding in Ruby when I sort of don't see it being around as the most popular thing forever. I really think it's just super nice and convenient these days. But I genuinely don't think Ruby is going to be like, it's declining popularity, but that's fine with me because at some point in my distant future, I have no idea when. And it might be sooner rather than later, I'll probably start doing more of my coding in another language. And that's like totally fine. I think there's no reason to hang on to sort of something in when things are progressing. But there's also no reason to think you have to jump off of something. You just kind of allow yourself to be open-minded. And I think it takes a lot of weight off your shoulders. I couldn't agree more with that. I think it's so important that we realize that learning, it's not like whenever you learn something, you're changing the structure of your brain. And I think the way that we consider learning is more like a collection with limited space, right? So it's like we think just intuitively for some reason that we're going to collect our stuff and we're going to invest in this learning process. And that eventually we're going to run out of the ability to learn. And we're going to run out of space to shove things into our brain. And so we better pick the right things and organize them in the right way and do it in the right time or else something's going to blow up. Something's going to break. And the reality of that is so different. And I think it's because we don't really think about learning from the perspective of what it, from a physiological level. And what it's actually doing, and it's actually changing our previously gathered knowledge. Right? This is what we were talking about earlier with, you know, taking this information that you have in Java and then applying Ruby on top of that. Well, that's very different than learning Ruby from scratch, right? You can compare things. You can use the information you already have to contextualize the information that you're getting. And we do this automatically. And this is something our brain is actually really good at. We learn to compare things with our existing schema, with the thing that's already in our brain. And we say, oh, that's kind of like that. This is why, you know, music tends to change and slow, you know, large cultural changes tend to happen in a way that is connected to the thing that happened before them, right? It's one thing progresses after the other. The way that you learn Ruby is largely going to be informed by whatever you learned before. And so if we treat these things as if they were discreet from each other, then that's missing a lot of the potential value in combining learning. You're really expanding your potential for knowledge every time you add something new to the plate. Oh, yeah, absolutely. And you're constantly learning about yourself. And I think we should be examining sort of what's working and what's not working and develop strategies to cope and to advance our abilities and to be okay with ourselves when we're not learning something as quickly as possible. I'm personally sort of a slow learner. I'm not the quickest to sort of engage in a topic. And eventually I sort of get it pretty deep understanding. But I'm sort of amazed sometimes when people can jump right in and really figure something out right away. And I just have to try to put myself in situations where I'm given a little bit of time to think about things. And I also sort of, you know, you're constantly learning things about yourself. I've come to realize lately and I want to sort of examine this more about myself, but I've never been a big reader. That probably is part of my bias towards shorter, more digestible content, but I've never really read a lot in my life. And I've been learning more about sort of attention issues I have. And I discovered that audio books have been my sort of, it's been, and I actually got into audio books after getting into podcasts and stuff and podcasts like yours. And I sort of took the next step and I've now been in two books at a rate like 50 times, you know, more than I would have normally read before. I've actually, I've read like 75 books this year and like in audio form. And I've actually started reading more physical books as well because it kind of like, I don't know, it gave me a little confidence too. Yeah, tweaked your brain a little bit and a value of books, maybe. Yeah, and this is like this year sort of thing. It's a brand new thing for me. And not that I like never read, it was just always kind of a struggle more. So then something I could really, truly enjoy unless I really, really got into something. But I think we're constantly learning about these things and making discoveries. And these are sort of general human things. I think everybody has to learn these sort of things. But programmers especially have a very interesting relationship with learning. There's not a lot of industries where constant learning really is the skill you need forever. And there's a lot of pressure on it. It's a, you're paid well usually to keep learning. And there's a lot of pressure and there's a lot of stress. And there's a lot of production code you're sort of responsible for. If you're advancing in your career and it can be stressful and it can be a tough environment to just sort of get over the mental hump sometimes. But we've got to somehow do it. And so we do it. And so we try to ground ourselves, we try to cope and we try to just keep learning forever. Yeah, absolutely. This is fantastic. Fantastic inspiration for developers. And I'm really very thankful that you came on the show today. I have a few questions for you before we wrap up today if that's all right. The first one actually is kind of a good segue from your discussion on reading and having read so many books as of late. I'd love to know and this can be a book or it can be something else or it can be multiple things if you want to share them. But what is something that you have invested in and by invested I just mean bought a service or a product or a book, something that you feel has been incredibly valuable to you and you think other developers could find value from as well. Damn, that's a good question. All right, I'll just give you a few books. Yeah, so a few books I've read this year that come to mind right away, the Rosie Project is a fictional book about a sort of a scientific person. I think it's ever really made clear in the book, but it's a man with just sort of a real analytical mindset. He probably has Asperger syndrome, but it's told first person and it's just kind of a fascinating book. And if you're at all of that kind of mindset, the sort of analytical type, the sort of people that use, find doing this career a lot of the time, it's really well written. I'd also, I'd recommend the book Hitmakers. Maybe that's just more interesting to me because I really found it sort of valuable just recently to sort of think through some interesting concepts of how things become popular in the world. And I think open source projects and a lot of these concepts with computer programming languages are described really well in this book. And the science is really, really wonderful. The book originals. And I don't really remember the author for any of these books. But the originals is a really book I really liked. Well, actually, I like to thank the first of the order. It's kind of felt like I got kind of boring, but it was still worth reading. There were some really interesting ideas there about how people come up with ideas, how people think through problems, and how people sort of take, sometimes, they take a long time to follow through with ideas. And I felt like it gave me a lot of permission to really take my time with some things. Whereas previously, I underpassed them, and became discouraged if they didn't immediately take off. And I read the book Disrupted, which was an interesting kind of one person's take in Silicon Valley. And if you're at all, if you're anything like me, where you kind of think you sort of roll your eyes at some of the Silicon Valley buzzwords, this book will bring you a lot of delight, because it was one person who really didn't enjoy his experience in the industry very much. And whether or not you do kind of enjoy yours, and I love what I do, but this was a very wonderful for sort of getting at some of the ridiculous parts. So three books I would absolutely recommend. And I've been meaning to put together a longer list of books I like, but I don't know how I'm really getting around to that yet. Well, there's a platform that you can do it on that I heard about recently. It's called Dev.to. Yeah, absolutely. I actually wrote about the Rosie Project on Dev.to. And I hope I'm remembering the name of that book correctly. It might be the Rosie something else. But anyway, you'll find it a few Google. It is the Rosie Project. I've been looking these up as you've been listening them off. Yeah. I wrote a little article on the site about that. And there's a bunch more. I liked the book about the Jon Carmack and Jon, and I'll see what the Jon. And the two Jons behind the game Doom, and their whole history, I can't imagine what Doom is the name of the book. I love that one. I really liked lots of books, but this one for you. Or five. That's pretty incredible that you've read as many books as you have recently. And inspiring, I'm sure, for people like me, I have a bad habit of reading. I wonder if this is something that's common amongst developers. Because I've noticed that a lot of the people that I meet that are in business that are not developers seem to read exponentially more than me for some reason. So it's definitely on my list of things that I want to do better at up there with lose weight and write more. Well, I have a bad habit of sitting down to read and starting to code or starting to do something else that's also productive, but just not reading. So the audio books are great because I get it at a house and I go for a walk. And that's my number one activity on weekends. And I take time from the other people in my life. Sometimes it's hard depending on your current situation. But the people in my life know that part of my weekends needs to be walking around listening to a book. Yeah, yeah, absolutely. Well, fantastic. So really good stuff there with the book. I feel like books are such a great and rich resource to share. And I'm really thankful that you've gone through those and that you can share those with the readers as well. So I appreciate that. Oh, yeah. Anything else I can do for you, Jonathan? Sure. Final question for you today. If you had 30 seconds to give every developer a little bit of advice, what would you tell them? OK, so one quick piece of advice is to really think about things as going to take longer than you think. In general, side projects, your businesses, your learning, I think people really rush to get things done. And they give up on things too quickly. So expect to be in activities for the long haul. And go out of your way to think that something might last longer than it will. And you'll probably set yourself up for more success that way. That's a fantastic piece of advice. I do think that we, as a general statement on not just developer culture, but really culture and large, being rushed is an endemic issue. Like it's widespread that we want everything immediate. And so another book on this topic, I've mentioned it on the show before, but it's called Essentialism. And it talks about one of the things that talks about is the effect of this immediacy and the desire for immediacy. And how it actually changes our perspective of not understanding progression. Like we don't understand how we've gotten to where we are today. And we don't really have a perspective on how we're progressing through time because so much of what we do is right now at our fingertips, we don't really have the space or the, I'm not sure what the correct word is here, but we don't really have the perspective of time that we need to be able to understand history, right? And where we came from, where we're headed, we only understand this kind of hyperversion of now. Yes, absolutely. Well, great. This has been fantastic and I really appreciate your time. And people can find you, if they aren't already following you, I imagine that most of them are at this point. But if people are not following you on Twitter, it's the practical dev, correct? Yeah. And you can follow my personal account, Ben Halpern as well, it's not as popular, but we, but, you know, I certainly, if you're, that's sort of another way to keep in touch with me personally. Fantastic. And sign up for an account at dev.dev.to, that's dev.to, and just a disclaimer, by the way, Ben and dev.to have not sponsored the show in any way. I reached out to Ben because I think what he's doing is really cool. I think that other developers can gain a lot of inspiration and value from the stuff that he's doing. So if it sounded that way, then it's not that way. So totally transparent on the show about the people who are sponsoring this. So, again, thank you again to Ben for both creating a really fantastic platform that's engaging a bunch of people and teaching people that things are okay, things are more okay than you may feel like they are in the moment. And supporting developers, thank you so much for that. Oh, yeah. Well, thanks so much for having me. To all the listeners, if you want to do something that would make me smile, write a little technical piece on dev.to and do it as a favor to me. And I'll be forever grateful, or at least as long as I kind of remember that I'm supposed to be grateful. That's a good piece of homework for developers who are listening to the show. Yeah, I mean, it's just a lot of fun. Awesome, thank you so much. Thanks a lot. Thanks again for listening to Developer Tea today. Thank you again to Ben Halpern for joining me on the show. Go sign up at dev.to, that's dev.to. And of course, you can find Ben on Twitter. You're probably already following them. But if you're not, go and check out the practical dev. You can probably Google that and find it pretty quickly. It's a popular account. Thank you again for listening to today's episode of Developer Tea. The only thing that you need to do at the end of today's episode is go and subscribe so you don't miss out on future episodes if you haven't already done that. Thank you so much for listening. And until next time, enjoy your tea. Bye.