In today's episode, I talk with Ben Halpern. You may know him from his tweets as @ThePracticalDev. Ben also is the founder of dev.to, a site for developers to share knowledge and culture with one another. Check out dev.to to learn a bit more about what Ben has created!
In today's episode, I talk with Ben Halpern. You may know him from his tweets as @ThePracticalDev. Ben also is the founder of dev.to, a site for developers to share knowledge and culture with one another.
Check out dev.to to learn a bit more about what Ben has created!
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 Cottrell. You're listening to Developer Tea. On 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. In today's episode, I'm going to be talking with someone else who wants to get you to that place as well. 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. Today's episode is an interview with Brian. Ben Halpern. Ben is the founder of Dev2. 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... I love 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. 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 my life. And I 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 the top two for everyone, right? So technical blogging. When you say technical blogging, you're talking about actually writing some kind of post, a thousand words or however many words, about a technical topic, right? Yeah. And it's not always purely technical. There's 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 topic. You 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 quite interesting. How do you do that? And how different that is from 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 it's really important to sort of keep even rehashing some of the same ideas because new concepts bring new ideas. I mean, it's amazing how different JavaScript development is, for example, post React really. Yeah. And 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 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 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 affect these things. And you sort of need to maintain a constant ear to the ground. You need to keep your radar strong. Yeah. It is something that... So on this show, obviously we don't talk a lot about hard skills, but that's not because they aren't important. Obviously, keeping those skills sharp, once you've used a blade enough times, eventually it will become dull. And the strange thing is people are making new stuff all the time. Right? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. around that technology will change as well, especially with 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 it's not as if even 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 if it becomes at all popular. Half of it is developing and then half of it is sending these signals out into the world because there's not a lot in development that's not just sort of an abstract idea that exists in our collective minds. So when we write about it, we really send these signals out to let people know what our thoughts are and how we're sort of evolving our mindset. And for every one writer, there's a thousand readers or whatever. It's a very read-intensive operation, but it's an ongoing thing and it's very much necessary, but it doesn't just kind of happen. It takes an ecosystem to really prop up the best work and to really act together. So if you're listening to this episode and that sounded like kind of distant, especially 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. It's actually pretty incredible how opinions shape decisions, right? The opinions of a collection of, you know, a hundred developers who are writing regularly 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 I work for, maybe I have a company that's commissioned this project. For example, React is a part of Facebook. So how is 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 is kind of the long way of saying that, right? Oh yeah, absolutely. It's a, and it all, it's, all these decisions, you know, they live in the margins. It's all nuance. 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 more, how much greater the expectations for each project have become. You really can't expect to simply use the best, the, the available tool just in the most basic way. I mean, you, you've constantly got to customize everything. And in order to do that, you've 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 the 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? Right. If you're 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 know when the, the right time is to pick something up, to adopt it. When 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 the oldest technology, but it's really settled into this nice, this nice steady groove. And as far as personal enjoyment goes, it's a, it's a really funny. Ecosystem for me. And, 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 really sort of as a environment that's really steadied out. That's, 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 where, where 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 we'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 recognize, 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 end and back end, 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, 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, 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 a new code. I took it to 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 GeoCities 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. I got to do my own projects, which really... 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, that does have some comedy talent. What is the word for that? Some sense of humor, I suppose. I think you can have a sense of... I can make it... I suppose. I can make it. You can have a sense of humor without really being good at being at doing comedy. Right. Yeah. Yeah. This is why I never try to tell jokes on the show. I can't even think of the right word. But, you know, I know how to tell a joke in person, maybe. But, you know, 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 the 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 can be confusing otherwise. But I usually if I'm talking to someone who's not familiar with it at all, I say dev.to. If 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 grown to be incredible. It's incredibly popular, by the way. How many followers are on the practical dev? About 108,000 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 was that many developers on Twitter. So the practical dev and then dev.to, can you kind of explain, you know, what was the day? Tell me about that moment when you decided to start each of those things. Yeah. 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. I just wanted to write more about programming and thought I should do a second Twitter account just devoted to programming and call it the practical dev. It's not the most interesting, exciting name I've ever heard of. I just... I just decided to do that. I can't even really remember how... what my plans were at the time. But I... 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... It grew and grew and 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... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... It... I... So then I decided I wanted a website to go with it, and I registered the practicaldev.com. And then I later decided I really wanted a much shorter domain name. So I got dev.to. And 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. And 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 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 in educational. But that really wasn't in line with what I really wanted to do from the beginning. It was just. It 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 but also sort of bring it back to like some real value, some real educational, some real learnings. And all in all, it just kind of it hit just right. And and it's really it's really been been a labor of love. So let me ask you this just for for the sake of the remainder of the conversation. What is what would you say is the scale of Dev to how many people are visiting the site on a regular basis? It's growing regularly. I'd say we we get about 30,000 unique visitors a day, but it scales up like the the most read articles, about 100,000 reads. The the typical article gets several thousand. And. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Every tweet gets a few thousand visitors from from the tweet itself, which is which is pretty crazy because I've used Twitter before and there's not always a lot of engagement. It's kind of it's kind of remarkable how many people rely on the Twitter feed itself to to jump onto the site and to to as their starting point to get reading. Yeah. A lot of times, you know, the site itself is driving content. And that's true for for, you know. Obviously for Developer Tea, the majority of people find us through iTunes or they'll find us 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 on to Dev2 after they latched on to 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 are actually engaging with the content there? Yeah, so I think a good portion of the hundred and something thousand followers engage on a reasonably regular basis. Day-to-day traffic on the site itself is a little over 30,000 unique visitors a day these days, which is 600,000, 700,000 visitors per month. And which is... Pretty exciting. It's quite a lot. It's 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. And we are really... It's amazing. We really think we're helping a lot of developers these days. Yeah, so that's such a cool thing to hear from a developer. Because that's 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? Like, 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... You know, every content... And 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. 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... Sometimes I'll be reading a book or, like, a long-form programming book. And I sometimes think to myself, like, oh, 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 database. We can't give you everything 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... The flip side. A very valuable platform for developers. But one that seems to be somewhat void of deep culture, at least, would be Stack Overflow. Right? It 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. And 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 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... Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.! Yeah. Yeah. 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? What 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, and I try to, I sort of just acknowledge the pain there. But moving on to kind of what the issues and what the things people face and the mindset I feel like we try to help with is the idea that you can feel so lost in this industry. 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. You don't know if you're right in an opinion and nobody really knows for sure. And 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 maybe 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're on the, 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. Yeah. I think that's something I've experienced as well, both on a personal level, but also with people who listen to the show. 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. It'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. Right? 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 almost a lack of opinion about it because we're just not really sure. And it's such a broad range of possibility that doing the quote, right thing is so ambiguous and it's going to change tomorrow. Right? And so it's difficult to know, you 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 a, even for maybe using a graphical user interface to interact with Git instead of the command line. There's so much, there's a bit of, there's a bit of shaming sometimes I feel in some of the more, you know, you're not a real programmer if you don't use the command line, you're not a real program if you don't do this. And sometimes we just need a little bit of validation that the things we think maybe are, 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 I 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 in the last few days. Just a very simple, a 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. Right, yeah. But all I did was said, honestly, this was really helpful. And that's practically the whole post. It was, it was about, it was about 250 words max and, or less, maybe 100 words. And, but people really liked it. It got shared a bunch. People, people found it valuable. There was 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 engagement 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? Shouldn't I just be linking to the readme? But I realized, just by like, just by providing a bit of narrative, a bit of explanation of how I use it, that was enough to, to make it a useful piece of content. And I'm not sure I could have done that in 119 characters on Twitter, you know, not counting the link space there. So, so that's sort of the, from a, 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 from a library and just, and just, and just, and just, and just, and just, and just, you know, how can I take something that's been helpful to me and, and send the signal out to the world? A blog post is worth a thousand readmes. That's, that's, if you're gonna, if you're gonna take a quote away from today's episode, there you go. That's, 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 and abandoned. There's, there's, there's boilerplate code that's sitting around everywhere. There's, there's, there's, there's a lot of stuff that's been left behind. And, you know, uncovering tools that other people could use, and, and validating, hey, this is something I've used, and, and it's been valuable to me. It's not bug ridden. You know, like, I, I installed it, and I've successfully used it quite a few times. Here's what it's done for me. Yeah. And it's, 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. It's in my brain. And, Sure. You can't really get that from a readme, especially the project owner's readme. 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. Like, these are, you know, Yeah, you can. Basically objective, third party, just, you know, just enough of a tilt to, to let you, you know, maybe, maybe it's a good idea. Like, I sort of, we kind of need a, a review system for, this is kind of a, here, here's your weekend project. Someone who, 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, on GitHub, but that can be, you know, a little bit old or, or out of date. But having, I mean, maybe this is something that Dev2 does decently well. It's just a, a quick write up. This is a review, like you would review a movie, but now you're reviewing a, a open source movie. So, it's a really open source project. Yeah. So, sorry to cut you off, but I just want to like, I want to just say, I absolutely agree. And as a project, I've, I've thought about, 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 know what they can do on the platform. So, I think that's a good way to kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, kind of, discoverable and everything is discoverable within the site. You can follow tags, you can follow people. It's going to be pretty full-featured and I've just started kind of trying to be better at 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 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 1,200 words written and I just sort of stopped hearing from them because they couldn't quite get it to finish because they've tried to get everything in there. But I really think little posts like a quick heads up, I love this library and you should use it because it's been great for me. Or little just brief thoughts. I mean if people can use Twitter effectively with 140 characters then you don't need 1,400 words in a great post. You can get by, you can really get to the point of it. You can really think as if you're just telling your co-workers sitting next to you, hey by the way, this worked for me, this can work for you too. 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 it packaged up. It's a 15-minute process and I'm telling you right now saying I don't think I've done a good job explaining that yet but I'm excited that the platform's been fine even though I think people are not quite, people don't quite realize how capable they are of sharing their personal experiences and how valuable that is. Yeah so just a secondary validation of this idea. Definitely, I think it's important to have a platform that's really good for you. Definitely. I think it's important to have a platform that's really good for you. Definitely. I think it's important to have a platform that's really good for you. Definitely by far my most valuable post that I've that I've posted on my personally stuff you know on my personal site JonathanCattrell.com you know back when I was writing on Subtle if you remember that platform and even on Medium all of that stuff all of that the highest visited posts were the shortest ones and on top of that Developer T is typically pretty short as well so if you think that you know a quick tip isn't worth your time to write a short article on to write up. That's definitely not true. In fact, you'd be surprised, I think that the most popular stuff is the stuff that is most digestible quickly. Oh yeah, absolutely. And there's a few kind of more things I feel like people. Some people are afraid to write technical pieces and they'd rather. Even if they want to write they'd rather write about like anything but technical writing and 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 a, an absolute symptom of imposter syndrome. But I feel like these, these small tidbits it's really hard to, to not get it right when you just have one little tip to share with people. Yeah. And, and it's sometimes a high barrier to even write that as a blog post. And I'm really happy I think our platform makes it easy to get some exposure into this. We, we really try to bring things to the light and things really do get a lot of traffic when they, when they, when they get featured and stuff and the barrier to that is actually a lot lower than people realize. And. And the, the whole thing I think it, it really, it works out well once you get into the mindset. You you really figure out that people actually are interested in, in, in a quick tip here and there. Yeah, absolutely. And so this is just a for homework for those of you who have a big long technical article that you're halfway through. I challenge you to cut it in half or maybe even cut it in thirds and go ahead and post the first the first part today, like, or tomorrow post, post the first part and then see what people's responses, see what their questions are, you know, post on dev to post on your personal thing, whatever. 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 T the first part of my interview with Ben Halpern, make sure you go and check out dev two that's dev.to the platform for developers that Ben 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 T, including the next episode of developer T, you can go to the next episode of developer T and click on the link. And if you want to get a chance to join the team, including the second part of today's interview, make sure you subscribe and whatever podcasting app you use. Usually there's a subscribe button next to the developer T page. It's not going to be on an episode page. Usually it's going to be on the podcast page itself. So the page for developer T and a 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. Bye.