How would your career benefit if you started writing as a developer? Not writing code, but writing about code and writing about the problems that you're solving. That's part of what we're going to be talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Teaon this show. My goal is to coach you through some of the hardest parts of your career and help you level up as a developer. Become the great developer that you want to become. That's why we're here. And in today's episode, I'm going to be talking with someone else who wants to get you to that place as well. And also has created a community, a place for you to go to meet other developers and to talk about developer culture and so many other things. And today's episode is an interview with Ben Halpern. Ben is the founder of Dev.to that's dev.to. We'll talk a little bit more about what Dev2 is. Go and check it out, dev.to. Thank you so much for listening to today's episode. I'm going to get out of the way and we'll get straight into this interview with Ben Halpern. Ben, welcome to the show. Thanks for having me, Jonathan. I'm really excited to have you on. I feel like I say that for all of my guests. And it's true. I actually love all of the people who have been on the show. But I'm excited to have you on because you're a little bit of a different personality than the average developer who comes on here. A lot of times we have developers come on the show because of a platform that they built that was, or maybe an open source project that they built that is a product and they've been really successful. But we're going to talk about the developer culture quite a bit in today's episode. And that's why I'm so excited to have you on because it's so different from our average topic here. Yeah, that's really exciting. As with all the things we're going to talk about, I think it's going to be pretty interesting. Cool. So let's just jump straight in. So I like to ask all of the guests who come on the show a couple of questions because I think they're really insightful into what that person finds interesting and valuable. And one of the questions that I like to ask is what do you wish more people would talk to you about? What do you wish more people would ask you about? Yeah, these days I'd really love to talk about technical writing, technical blogging. That sort of thing. It's become more and more of my life. And I've found every time I've gotten to talk about it, I've been able to help people through it. And I remember talking a lot about, at the New Year's, I asked some people what their New Year's resolution was. A lot of people wanted to write more. And so it's been a topic I've been talking about more and more. And I'm always interested to be asked about it. Yeah, writing and losing weight are like the top two for everyone. So technical blogging, when you say technical blogging, you're talking about actually writing some kind of post, you know, a thousand words or however many words about a technical topic, right? Yeah. And there's, it's not always purely technical. There's so much human and culture element, so many human and cultural elements that always are just pervasive in any topic. But yeah, breaking down a technical topic or a struggle that developers have and just sharing expertise and experiences is just such an important part of our lives. And we like to do it. And we also, we consume a lot of it just in learning and interacting with people. And it's not necessarily a topic that's going to be covered in your education. You sort of pick it up as a professional. Yeah, it's kind of interesting because it's almost transitive stuff, right? We have these posts that are, they live for a couple of years and they're not necessarily going to be timeless. They're going to be valuable maybe in five or six years as a piece of, oh yeah, this is how we used to do things. And now we've changed it in these particular ways. A lot of that stuff actually is still applicable depending on what language and what technology you're actually talking about. But it is, it is quite interesting how different that is from, you know, more formalized theoretical education. Yeah, it's definitely transitive. I think the internet sort of naturally erodes away things that are less timeless. And so, so it's really important to sort of keep even rehashing some of the same ideas because, because new concepts bring new ideas. I mean, it's amazing how different JavaScript development is, for example, post-react really. You know, Angular was sort of an evolution and then React came along and it really sort of changed the way all the discussions happened and then the whole, and node and the language and stuff. And it's really impossible to think of anything on that topic as timeless and it's a good one just for the, for, to make the point, but really every environment has a constant evolution because everything that comes out, every new technology, every political swing, anything can, can affect these things. And you sort of need to maintain a constant, er, er, to the ground. Like, you need to keep your radar strong. Yeah, it's, it is something that, so on the show obviously we don't talk a lot about hard skills, but that's not because they aren't important. You know, obviously, keeping, keeping those skills sharp, it's, you know, once you've used a blade enough times, eventually it will become dull. And the, the strange thing is people are making new stuff all the time, right? And that new stuff is going to affect the old stuff that you're already using and, and you can't just rely on something and act like it's going to be the same reliable tool that you used yesterday or last year or, you know, five years ago, it will change. And the world around that, that technology will change as well, especially with, you know, 99% of us probably are writing software for devices that are switching out, right? So the software you wrote this year, next year, a new device is going to be consuming that software. Yeah, absolutely, and, and it's not as if even the, the writing process is necessarily just observing and documenting, even if you don't intend to, your writing process is going to also affect the world, especially because it all popular. The half of it is developing and half of it is sending these signals out in the world, because there's not a lot, there's not a lot in development that's not just sort of an abstract idea that exists in our collective minds. So, so when we, when we write about it, we really send these signals out to, to let people know what our thoughts are and how we're sort of evolving our mindset. And, you know, for everyone writer, there's a thousand readers or whatever, it's a very, it's a very read intensive operation. But it's a non-going thing and it's, it's very much, it's very much necessary, but it doesn't just kind of happen. It sort of, it takes, it takes an ecosystem to really prop up the best work and to, to really act together to, to do good things in that regard. So if you're listening to this episode and, and that sounded like kind of distant, especially if you're, if you're early in your career, this episode is going to make more and more sense, the longer you're in the development career or a development career, you're going to eventually realize, wait a second, languages are pretty much just a collection of opinions, right? Like, it's actually pretty incredible how opinions shake decisions, right? The opinions of, of a collection of, you know, 100 developers who are writing regularly on, on particular topics, the people designing languages, the people designing frameworks, that stuff isn't growing out of the ground, it's being created by someone and the decisions they make on, you know, what is going to be useful to a developer, what's going to be, you know, and it's not just useful, it's what's going to achieve particular goals, particular values for developers and also for the company, you know, that, that I work for. Maybe I have a company that's commissioned this project, for example, react is a part of Facebook. How does react going to make Facebook more successful or, you know, there's tons of decisions that are being made by humans, not just, you know, this stuff comes from people, it's kind of the long way of saying that, right? Oh, yeah, absolutely. It's a, and at all, it's all these decisions, you know, they live in the margins, it's all new ones, and things evolve sort of, you know, collectively, so you can't really just code in a vacuum, it's really impossible these days, and especially how much, how much greater the expectations for each project have become, you really can't expect to, to simply use the best, the, the available tool, just in the most basic way, I mean, you constantly got to customize everything, and in order to do that, you really got to be plugged into to what's, what's happening in the world without, without getting, without letting it spin your head too much. Right. Yeah, the balance is so important. That's something we talk about all this time on this show as well, is, you know, we, if you're switching out your tools too often, then you never master a tool, right? It's switching out a tool for a better version of the same tool, or, or, you know, something that makes you more productive, under the same, like, general talent set, that's where you can really see some, some significant gains in your productivity as a developer, but also stay up and, and, you know, relevant with the development world around you. It is, it is really difficult because there are so many things happening around you. And people who started three years ago, five years ago, seven years ago, all have completely different ecosystems that they learned in, right? So it, it, very, very important to keep your mindset in the constant change awareness and, and know when the, the right time is to pick something up to adopt it. And you see large shifts in momentum in the industry that you recognize how that affects you at the very least. Oh, yeah, absolutely. And the more you understand how these things are a bit transient and they come and go a little bit, it also lets you be a little more comfortable with your, your steady technology that really, maybe isn't catching any more steam, but really isn't going anywhere either. I read a lot of, I read a lot of rails and honestly, like, new, there's not a lot of new developers coming into the ecosystem. And it's not all this technology, but it's really settled into this nice, this nice steady group. And as far as personal enjoyment goes, it's a, it's a really funny ecosystem for me. And it's, and that's not even specific to the technology, the Ruby, the, the framework itself, but the, the, the dialogue is really steady and nice. And you can't really build some of these sort of quote, modern, most, the most modern applications, which have some different expectations, but as it's, that's sort of, as a, as a, as a really sort of, as an environment that's really steadyed out, that's, it's almost, it's really impossible to, to not sort of enjoy that part of it. Yeah, I also write quite a bit of rails and we're, we're a rails and WordPress and JavaScript shop basically. And those, that's three, you know, kind of three points of a, of a triangle of things that the one missing piece is, is Java for us basically. And everything else is, is basically covered. And we, you know, sometimes they'll have somebody who writes Java for an Android app, contract for us or something like that. But really between those three, kind of pillars, we cover a lot of ground. I would, I totally agree. There's totally different things that each of those, those technologies do. And if we hadn't brought the technology to the table, if we hadn't stayed aware and recognized, okay, you know, JavaScript is going to be better for real time applications, for example, or, or at least it's going to be a little bit lower barrier to entry for real time applications. It's going to do well for, you know, obviously if you're going into React land, then having a JavaScript front in and back in, you may see some benefits that you don't necessarily get in something like rails. So there are, there are definitely, you know, when you add a technology to your stack, you're opening up new opportunities just because you're opening up new offering categories almost. Oh, yeah, absolutely, and, and I just, I want to kind of add that, adding, adding a new technology to your toolkit rarely means you have to let go of the old thing you've been working on. And often you learn some insights and then you bring it back into your expertise like this is, oh, I've been working in Ruby for a while, but this is how, this is how go handle something. Maybe I'm going to start writing more applications and go or maybe I'm just going to take these ideas back into my, my current ecosystem. And it's always really exciting to do it for the right reasons. Yeah, I totally agree. Some of the things that I've learned from, you know, taking a day and looking at, for example, Haskell, I brought that kind of learning back into my Ruby code writing and, and really increase the quality of my code, right? Because I took something, a smart thing from another place and imported the knowledge into Ruby and I wonder, you know, you wonder how, can I apply what I'm learning in this other space? Problems they're solving in the other space, reasons they're solving those problems. Can I identify similar problems that I'm not currently solving well in my Ruby code? Oh, absolutely. So I want to kind of shift gears or maybe rewind a little bit and learn kind of how you got into software development, what was your first, that first step, what tweaked your interest in software? Oh, well, I've been writing code sort of since I was younger. The first application I built was a fantasy sports website when I was about 13 or so, just geo cities, HTML and that sort of carried me along as a hobby until college and I took a little bit of CS, but I actually dropped out of CS and graduated with a marketing degree. I thought I was going to go into that field and I really just didn't really like it as much once I got into the real world. Then I sort of wanted to get into comedy writing, which was fun, but I didn't really see any professional future in it and I fell back into software and really fell in love. I got to be more project oriented as opposed to project or like I got to do my own projects which really was much more fun than anything I did in CS and I've been doing it ever since. So you have a talent that I absolutely do not have. I have almost no funny, no comedy talent at all. I know a lot, anybody that I tell that does have some comedy talent. What is the word for that? Some sense of humor. I think you can have a sense of humor without really being good at doing comedy, right? Yeah. This is why I never try to tell jokes on the show. I can't even think of the right word, but I know how to tell joke in person maybe, but writing it for this kind of atmosphere, I'm really not really not apt to it. So it's interesting to hear that you actually consider going into comedy writing and now you've kind of brought that interest into what you do and I don't want to jump ahead, but into what you do with practical dev and dev.to or dev.to. What is the correct pronunciation? I only see it on my screen. Yeah, so I usually say dev.to if someone's not familiar with it at all because it could be confusing otherwise, but I usually, if I'm talking to someone who is familiar, I say dev.to, just as shorthand for dev.to. There we go. So we'll call it dev.to on this show then. Yeah, please do. Yeah, so I can just start talking, telling you a little bit more about how that came to be if you're interested. Yeah, let's talk about it. So dev.to, you started it after or before the practical dev, which is the Twitter account that's that's grown to be incredibly popular, by the way, how many followers are on the practical dev? About a hundred and eight thousand right now as we record. Yeah, that's like at least 20 times more followers than I have, which is impressive. I didn't even know there's that many developers on Twitter, so the practical dev and then dev.to, can you kind of explain what was the day, tell me about that moment when you decided to start each of those things? Yeah, so there's a few defining moments. I think the absolute start of it is less defining. I really think I just felt like creating a second Twitter account because I didn't want to necessarily annoy my friends on Twitter with too much programming stuff like constantly. I just wanted to write more about programming and thought I should do a second Twitter account, just about it programming and call it the practical dev. It's not the most interesting, exciting name I've ever heard of. I just decided to do that. I can't even really remember what my plans were at the time. But my thoughts were that I would just share interesting things, whatever came interesting to me and other people would find that valuable. And they did and it was a growing grew. I can't say it was a total surprise. I've got a background in marketing. I kind of understood how to sort of grow some of these things. But it really started, I mean, so then, yeah, so then I decided I wanted a website to go with it and I registered the practical dev.com. And then I later decided I really wanted a really much shorter domain name. So I got dev.to and I had, I remember having conversations with people in the space of sort of your space, you know, like content for programmers. And I felt like I had a lot of advice, but I wasn't really taking a lot of it in myself. Sure. Yeah, so I decided I'm going to really sort of take this seriously. It's still just a side project, but I'm going to really build this website as like the platform for talking about programming that I really envisioned. I decided to really put all of my creativity as much as I could into the Twitter account. And that's kind of where I, when I started really making it just my own personality, myself, I started telling jokes and then I realized that people really liked, people really liked the humor. They liked sort of how I was going with it, the tone and I just kept running with it. You know, I had a few inklings here and there to just make it purely humor, not so much a good resource and educational, but that really wasn't in line with what I really wanted to do from the beginning, it was just happened to be what was popular. But I thought the most valuable thing ultimately would be a little bit of both. Really a lot of commentary and humor about the programming culture, but also sort of bring it back to like some real values, some real educational, some real learnings. And all in all, it just kind of, it hit just right. And it's really been a labor of love. So let me ask you this just for the sake of the remainder of the conversation. What would you say is the scale of Dev2? How many people are visiting the site on a regular basis? It's growing regularly. I'd say we get about 30,000 unique visitors a day, but it scales up like the most red articles, about 100,000 reads. The typical article gets several thousand and every tweet gets a few thousand visitors from the tweet itself, which is pretty crazy because I've used Twitter before and there's not always a lot of engagement. It's kind of remarkable how many people rely on the Twitter feed itself to jump onto the site and to as their starting point to get reading. Yeah, a lot of times, the site itself is driving content and that's true for, obviously for Developer Tea, the majority of people find us through iTunes or the finest through another podcast discovery platform. And then they'll seek out a Twitter account or something like that. So really interesting how it seems like that audience almost latched onto Dev2 after they latched onto the Twitter. So I want to gauge kind of the involvement that people have on Dev2. Can you give just an idea of how many developers actually engaging with the content there? Yeah, so I think a good portion of the 100 and something thousand followers engage on a reasonably regular basis. Data-based traffic on the site itself is a little over 30,000 unique visitors a day these days, which 600, 700,000 visitors per month, which is pretty exciting. It's quite a lot. It's really scaling. Yeah, it's incredible. Yeah, and I honestly think it's been growing really quickly and I think it's going to be a lot more than that in a few months. It's really remarkable to think about. But what we work really hard every day to do is just to provide people a reason to come and check back, to delight them, to inform them, to tell them a story, to help them through a struggle, and to give them a reason to come back to the site the next day or two days from now, or maybe check in after a week. It's amazing. We really think we're helping a lot of Developer These days. Yeah, that's such a cool thing to hear from a developer because a lot of the same shared values that I have for the show, for example, and building something that people will return to because they find value in it, not because, okay, well, I found an answer on this thing. And whenever I need that answer, I'll just keep that link in my back pocket, but I have no reason to go back there. I want to create something new for you tomorrow, right? I want to continuously be adding value to your repertoire of content that you can consume on a regular basis. So I think that's every content creator knows this, that as you gain an audience, the most valuable thing you can do for your thing, for your content platform, is create more value for that audience. It's a simple principle, isn't it? Oh, yeah, absolutely. And we try to provide lasting value. We don't just want to get your click, we want to get your interest, and we want to help you. And sometimes I'll be reading a book or a long-form programming book, and I sometimes think to myself, like, I wish we could provide some of this more kind of lasting sort of value you get out of a full-on programming book. And then I sort of think back, well, a lot of people are also doing that really well already, and we're providing another kind of value. So we're not trying to, you know, we can't give you everything you need on a daily basis, but we, I think we really help people just read some interesting content about programming and, you know, randomly solve a problem they didn't even kind of know they could solve. Yeah, that's so interesting. I love this because, you know, I love this space. Let me start there, because I think that what you've done is you've created this interesting, like, shared, for example. Let's do the flip side. A very, very valuable platform for developers, but one that seems to be somewhat void of deep culture, at least, would be Stack Overflow, right? It's certainly is incredibly valuable, so I don't want to downplay the value of the platform. And in fact, you had a Twitter discussion with Stack Overflow today, and we're going to talk about that in just a few minutes. But Dev2 is kind of this, on the opposite end of the spectrum when it comes to cultural engagement, right? And I love that idea because, you know, there's tons of information out there on programming languages. There's tons of tech writing, and there needs to be. There's nothing wrong with that. In fact, it's a good space to fill. If you're wondering what to write about, just write about whatever it is that you're building these days, right? On the flip side, though, this concept of engaging developers as a subculture or as a culture of people, it is really valuable. And I'd love to ask you a few questions about, you know, what you've encountered so far with that because I think understanding our culture is so important to understanding how we can behave better for the culture, how we can create better things in this culture. Yeah, absolutely. Do you have any specific questions? I'd love to talk about this. Yeah, let's talk about it. So one of the questions in something that I've talked about on the show before, I talk about the developer poisons, right, the things that a lot of developers end up falling prey to because of some collective, like hive minds perspective on what we do, that can really be bad for your career, right? So one of them was cynicism. As a lot of developers experience this overwhelming sense or overwhelming pattern of cynicism, because we learn about the inner workings of a platform and then it's easy to start writing off the value of that platform once you know what's behind the curtain sort of, right? So what would you say is one of the more damaging things that you've observed in developer mindset or developer attitudes, for example, that you think could be damaging to a person's career. And is something that you commonly see? Yeah, well, first on the topic of cynicism, I'm always a little worried that my humor is a little too cynical, except that I think I try to keep it light and I try to keep it diverse so sometimes, sometimes, and I try to sort of just acknowledge, acknowledge the pain there. But moving on to kind of what the issues and what the things people face and the, the mindset I feel like we try to help with is the idea that you can feel so lost in this industry. Very, it's not often you can really feel all that grounded in your work because things are so abstract. It's so hard to know if you're right in an opinion and nobody really knows for sure. That's the imposter syndrome we talk about, but it's more than just feeling like you're not a developer, it's just feeling like you're not really sure about the right answer to this problem and you're not really sure about the future of the compatibility of the software you're writing or the future of the whole industry. And often you need to sort of reach out to the void for a little bit of help. And I wouldn't say we go all the way to the opposite end of the spectrum from Stack Overflow because we try to help people fill the void technically as well as some of the career stuff. We really try to hit on everything and try to help people work through the nuance of their technical problems. And some of that is just a straight up tutorial about some programming language or concept or how I made this sort of thing. But it's really consumed as a whole collection. When you scroll through the front page, maybe one day you need a tutorial to help you through something, maybe a tutorial not even in your own programming language. Or maybe you just need to read someone's personal journey if any sort of headline catches your eye. It's something a little different every day, but we so often feel a bit lost and a bit lost in space a little like we're traveling to a destination we don't know yet. And that's where the need for connecting to other developers and really getting validation or just getting help through a problem really comes about. Yeah, I think that's exactly what I've experienced as well, both on a personal level, but also with people who listen to the show. If people who are constantly looking for, I hate to use the word validation because it makes people seem like they aren't strong enough to make a decision. But that's not the case. There's a lot of people who are making decisions and there's nothing on the other side that's saying, yep, you did the right thing. And so success is so relative for most developers. So many pairing sessions, I'll sit down with another developer and we'll write out some code and we'll look at each other and say, what do you think? And the other one says, well, I don't know. What do you think? And we both have like almost a lack of opinion about it because we're just not really sure. And such a broad range of possibility that doing the quote right thing is so ambiguous and it's going to change tomorrow. And so it's difficult to know exactly when we've made a good decision. Oh, yeah, absolutely. And you sort of look for validation and you don't necessarily even need expert validation necessarily. You just need someone to sort of make you feel like you're not crazy for making this technical choice, for going down this path, for even for even for making using a graphical user interface to interact with Git instead of the command line. There's a bit of shaming sometimes I feel and some of them are, you know, you're not a real programmer. If you don't use the command line, you're not a real programmer who don't do this. And sometimes we just need a little bit of validation that the things we think maybe are in fact a good idea or maybe we find out they weren't. But one way or another, we really rely on each other in this industry. And even like the other day, I wrote an article just about this one Git extension I found called Git Stand Up, which helps you remember what you were working on the last few days. It's a very simple, very simple command line utility and it in order to write the post I pretty much just rephrased what the readme told said. But I phrased it from personal experience. The readme was just like do this, do this, do this, do this. But all I did was said honestly this was really helpful and that's practically the whole post. It was about 250 words max or less, maybe 100 words. And but people really liked it. They got shared a bunch. People found it valuable. There were several thank yous in the comments and all I was doing was just giving people a quick tip and a quick sort of validation that you should use this. And I'm sure based on the different from the post, a thousand people might have installed the library. And in writing it I was sort of thinking to myself, am I really providing value here? Should not just be linking to the readme. But I realized just by like providing a bit of narrative, a bit of explanation of how I use it, that was enough to make it a useful piece of content and sure I could have done that in the 119 characters on Twitter. You know, not counting the link space there. So that's sort of the, from a value perspective, that's, I try to let people know that they can, they can give tips like that, little posts like that. Like truly just think how can I take something that's been helpful to me and send the signal out to the world. A blog post is worth a thousand readme. If you're going to, if you're going to take a quote away from today's episode, there you go. That's your tweetable thing. But in all seriousness, you know, there's so many projects out there and tons of open-source stuff. There's stuff that's been left in a band and there's, there's boilerplate code that's sitting around everywhere and, you know, uncovering tools that other people could use and validating, like, hey, this is something I've used and it's been valuable to me. It's not bug-ridden, you know, like I installed it and I've successfully used it quite a few times. Here's what it's done for me. And it's intuitive, it's intuitive too. Like I can genuinely say, it's been six months, I use it about once a day and it's intuitive. Like it fits with my brain and you can't really get that from a readme. Actually the project owners read me, you need, that's, I mean, that's why we have Amazon reviews, you know, that's why that's, that's why that is so valuable. These are, you know, you know, the objective third party just, you know, just enough of a tilt to, you know, maybe, maybe it's a good idea. Like I sort of, I get this. I'm connecting with what you're saying right here. We kind of need a review system for, this is kind of a, here's your weekend project, someone who's, whoever's looking to build something. We kind of need like a review system for this stuff, right? Like we have stars on GitHub, but that can be, you know, a little bit old or out of date. But having, I mean, maybe this is something that Dev2 does decently well. It's just a quick write up. This is a review, like you would review a movie, but now you're reviewing open search project. Um, yeah, so it's hard to cut you off, but I just want to like, I want to just say I absolutely agree. And as a project, I've thought of had, you know, explicitly making review libraries. And those actually do exist. I've seen them out there. But I definitely want to encourage our members. And sometimes I don't do a good enough job of sort of speaking directly to the members about what they can do on the platform. A lot of people don't even realize they're allowed to just publish whatever they want on it. Um, the homepage is, uh, is reviewed and, and editorialized, you know, only, basically only the good stuff gets to the homepage. But everything is discoverable and, uh, and everything is discoverable within the site. You can follow tags. You can follow people. Um, it's, it's going to be pretty full featured and, um, I've just started kind of trying to be better at, uh, providing some guidance into just how you can be helpful without spending all your whole weekend working on a post. The most frustrating thing for me is when I, I, I say, oh, by the way, like you should make this into a post. That's a really good thought. And almost without fail, people say, yes. And they get working on it. But about halfway through the project, they've got like 1200 words written and I just sort of stop hearing from them because they, they couldn't quite get it to finish because they've, they've tried to get everything in there. But I really think little posts like, uh, a quick heads up. I love this library and you should use it because it's been great for me. Um, or little just brief thoughts. I mean, if people can use Twitter effectively with 100 short characters. Um, then you don't need 1400 words in, in a, in a great post. You can, uh, you can get by, you can really get to the, get to the point of it. You can, you can really think as if you're just telling your, your co-work or sitting next to you, hey, by the way, this worked for me. Um, this can work for you too. Um, you know, you should use good grammar and you should spell well and you should give it a good title. But then you've got to package up. It's a, it's a 15 minute process and I'm telling you right now saying I don't think I've done a good job. Uh, it's funny in that yet, but I'm excited that the platform has been fine even though I think people are not quite, uh, people don't quite realize how capable they are of, uh, of sharing their personal experiences and how valuable that is. Yeah. So just a secondary validation of this idea, definitely by far my most valuable post, uh, that I've, that I've posted on my personal stuff, you know, on my personal side, Jonathan Cutrell. Com, you know, back when I was writing on subtle, if you remember that platform, um, and even on medium, all of that stuff, all of that, uh, the highest visited posts were the shortest ones. And on top of that, Developer Tea is typically pretty short as well. So if you think that, you know, uh, a quick tip isn't worth your time to write up, uh, definitely not true. In fact, uh, you'd be surprised. I think that the, the most popular stuff is the stuff that is, um, most digestible quickly. Oh, yeah. Absolutely. Um, and, uh, and there's a few kind of more things I feel like people, um, they, um, some people are, uh, afraid to write technical pieces and they'd rather, um, even if they want to write, they'd rather write about like anything but technical, uh, writing and, um, you know, I see sort of boot camp grads feeling that way. Like they're really excited about sharing their journey, but they're not as excited about sharing their technical ideas. And it's an absolute, uh, symptom of imposter syndrome. Um, but I feel like, uh, these, these small tidbits, it's really hard to, uh, to not get it right when you just have one little tip to share with people. Um, and, uh, and it's sometimes, uh, a high barrier, if you even write that as a blog post, and, uh, I'm really happy. I think our platform, uh, makes it, uh, easy to get some exposure into this. We, um, we really try to, uh, bring things to the light and, uh, and things really do get a lot of traffic when they, um, when they, when they get featured and stuff. Um, the barrier to that is actually a lot lower than people realize. And, um, and the, uh, the whole thing, I think it, uh, it really, um, it works out well once you get into the mindset. Um, you, uh, you really figure out that people actually are interested in, uh, in, in a, in a quick tip here and there. Yeah, absolutely. And, and so this is just a, for homework, for those of you who have a big, long, uh, technical article that you're halfway through, uh, I challenge you to cut it in half or maybe even cut it in thirds and go ahead and post the first, uh, the first part today, like, or tomorrow, um, post, post the first part and then see what people's responses, see what their questions are, you know, post on dev two, post on your personal thing, whatever. Uh, see what people are saying in response to it and then continue the conversation in the second post, like there's, there's absolutely nothing wrong with cutting your, your content in half and people will come back and read the second part. Oh, yeah, absolutely. Thank you so much for listening to today's episode of Developer Tea, the first part of my interview with Ben Halpern. Make sure you go and check out dev two. It's dev.to, the platform for Developer That've been, uh, founded and then went on to create a team around and we're going to talk more about dev two in the next episode as well. Thank you so much for listening. If you don't want to miss out on the future episodes of Developer Tea, including the second part of today's interview, make sure you subscribe and whatever podcasting app you use. And usually there's a subscribe button next to the Developer Teapage. It's not going to be on, you know, an episode page usually it's going to be on the podcast page itself. So the page for Developer Tea and that subscribe button should be in pretty much any app that you use. So thank you again for subscribing. Until next time, enjoy your tea.