Episode 33
· 34:19
Every person in tech needs to understand this very, very basic concept, which is, there is a technology adoption cycle.
Jack Bridger:Hi, everyone. You're listening to Scaling DevTools, the show that investigates how DevTools go from 0 to 1. I am really excited about today's episode because I'm joined by Sean Wang, who is known on the Internet as SWIX, and has been someone that I've looked up to for a long time and read pretty much everything that he's put out on the Internet. Sean is a writer, a speaker, head of developer experience at Airbyte, chief editor of DX. Tips, which is one of the best resources out there for developer experience and developer growth.
Jack Bridger:Sean, thanks so much for joining today.
swyx:Thanks for having me, Jack. Excited to, chat about, today's topic, which, I actually have in my bio, and you're the first person to ask me about it.
Jack Bridger:Amazing. And so the topic in your bio is crossing the chasm. Could you tell us a little bit about crossing the chasm?
swyx:Maybe I'll I'll bounce this off of you. Did you hear about crossing the chasm before in in in the context of tech?
Jack Bridger:I had a vague kind of feeling that I've heard of it, but it's also now hard to disentangle, like, what I knew before reading about your stuff.
swyx:Yeah. But I'd say no. It's interesting because I feel like it every person in tech needs to understand this very, very basic concept, which is, there is a technology adoption cycle. Things get invented, and then they filter out into the broader population. Some technologies fail to get mass adoption.
swyx:Some technologies get mass adoption very quickly. And, essentially, understanding what, succeeds and what doesn't is the primary goal that you should have as a technologist, whether or not it is choosing where to work, whether or not it is choosing what tools to adopt, or whether or not it is, starting your own if you have those ambitions someday. This is a very general purpose skill set that you should develop, basically for throughout your entire tech career, because it it's extremely valuable. Choose understanding what to work on and how to pick and how to encourage things that that eventually cross the chasm. The chasm describes, a a gap in the adoption cycle.
swyx:The intellectual history of this goes back to the the Rogers curve, which is basically a bell chart, conception of how people adopt technologies. It was created in 1957, and it basically divides the entire population from 0 to 100% of population into innovators, early adopters, early majority, late majority, and laggards. People who are innovators start this technology to people who are early adopters, you know, fast follow, and then the majority, population comes along and then the laggards bring up the tail. And you sort of describe all technology like this. But the primary innovation that Geoffrey Moore had, in his book on Crossing the Chasm, it's it's literally titled Crossing the Chasm.
swyx:Very, very influential book. He basically observed that the transition between stages is not all created equal. There's one particular stage where a lot of products fail, which is the chasm between early adopters and early majority. And why is that? My framing of it is that early adopters are tend to be very forgiving and imaginative, and early majority need a lot of documentation and use cases before they would jump aboard.
swyx:Right? So in other words, you can get very far with a minimal viable product and make a bunch of early adopters happy. Well, then you hit this ceiling in, in adoption unless you break through into the, the early majority and then the rest, come along. So it is in your interest to understand how to break through those. It is my job to help companies break through those.
swyx:And, I think, you know, the world will hopefully be a better place if you can understand, what drives this and and and how to make it happen consciously rather than accidentally.
Jack Bridger:That's an amazing, explanation. And you said kind of documentation and use cases. Could you talk a bit about, like, why this is so hard for companies to do?
swyx:Well, because it's not core to the product. A lot of technologists want to believe, oh, we just build the best product, and then the rest will come. The Americans would say, this is a very fill field of dreams idea, like build it and they will come. Most people find out that that is not the case. Sometimes it is actually the case that you build something that the world just needs overwhelmingly and you never have to think about anything else.
swyx:That is the privileged few that they luck into something that the world just wants so desperately that they get to skip that path, apart. But most people, they build the thing and then they have to market the thing. And it's always this back and forth between products and distribution that, people always find. And in fact, this plays out not just over the the course of 1 company, it plays out over a course of multiple companies. One very famous observation from Paul Graham, is that, 1st time founder is obsessed about products and 2nd time founders obsessed about distribution.
swyx:Because the 2nd time founder knows they can build products, but they failed because they forgot distribution, or they couldn't get it, couldn't couldn't unlock it. Being able to write documentation and demonstrate use cases that, help the less imaginative and less creative or more risk averse people to see the benefit of your technology, whatever the tool you're you're working on, and dedicate some time into it. Every single dev tool adoption is a choice. Is someone choosing to forego something that is probably more tried and tested in favor of something that is newer, because of some story you sold them or some need that they have that isn't being fulfilled. Whatever that is, helping them understand that what you do to help them, is your it should be your primary job.
swyx:And it essentially is my distillation of what an ideal developer relations person does. So they kind of
Jack Bridger:is it like they help meet those needs, or is it that they sort of make everything else so good that it doesn't matter that there aren't, like, strong use cases, say, for comparable organizations?
swyx:Yeah. I I think it's a mix of both. Sometimes they have people have needs and, they don't realize your products fulfills those needs. So so, basically, you're just kind of unearthing, existing latent demand. But other, other times, yeah, you are you are, you know, crossing the gap and and bringing that feedback about use cases back into the product so that they can, work on products as well.
swyx:What I just described, Geoffrey Moore's chasm, is about 30 years old. If you want to be a professional at this, you should probably develop a finer tuned, philosophy on that. And that's where I start to develop my own type of taxonomy on on how people, cross the chasm. Right? Because, in my mind, if I told you about the innovators, early adopters, early majority, late majority, do you know the difference between them?
swyx:It's very hard to describe apart from I don't know. Like, some of these are more demanding than others, and some of these are later than others. So that's so that's pretty much it. And it's, it's it's very it's very hard to sort of distinguish, like, what stage you should be focusing on. So, one framing or reframing, that I've been working on is essentially this sort of renaming for more intuitive treatments.
swyx:So, let's say we have enthusiasts, we have pioneers, we have pragmatists pragmatists, we have conservatives, and we have skeptics and newbies. So the enthusiast will do it because we can. They'll spend their nights and weekends, and they'll do it for free. The pioneers will see a pressing need. They'll buy the vision of the tool.
swyx:They're they're willing to build what's missing. Like, the tool tools that are new are typically incomplete, and require a lot of extra loving support and care, to to fill in the blanks. But the pioneers in exchange, they want to be part of the founding story. They wanna say I was I was early in that technology, and, you know, I will associate myself with that career that career. Right?
swyx:They'll they'll they'll call theirs themselves, x engineer, and and the engineers sort of, associate with your tool. Right? So, like, I'm a Figma developer. I'm a Kubernetes, you know, DevOps person. You know, they they like, it's literally in their job title and in their identity.
swyx:That that's that's how, closely they they tie it, to to themselves. Then the pragmatist, how do you say pragmatist? They're they're they're much more about, things as they are today. They're not so willing to give you credit for things that don't exist yet, the things that are on the road map. They just want what's what makes sense today.
swyx:The it's very much about cost and benefit. They want, well document well documented, technology, then well tested, well supported, all the licensing figured out, everything that needs to be done for, adoption network, because if you don't have any of that figured out, you're literally no value to them, because they they just don't have time to to help you figure out anything else. The conservatives are the 4th one. Conservatives, you know, are even more conservative. They need certifications.
swyx:They need social proof. They they need you to win popularity surveys. They need to see adoption at big companies that are bigger than them to go, oh, yeah. You know, it's good enough for them. It's good enough for me.
swyx:They need to see a healthy job market where a lot of, you know, other people is easy to hire in that technology. And they need to see, good third party ecosystems that that that plug into that. Right? They so they just need to see a lot more work done by other people before they put in their work. So, you know, it's they're they're not willing to go first, and that's fine.
swyx:That's in fact, that that should be the the default position for a lot of people, on a lot of technologies. Otherwise, you waste your time getting, cutting yourself on cutting edge stuff. And then finally, it's the skeptics and the newbies who understand everything that conservatives understand. They see all the cost and benefit, and there's they still don't like the technology. And the only reason they adopt it is because they don't have a choice, Or they don't want to do research.
swyx:They're just like, just tell me, like, what everyone uses. I'll use that. I I I have no time to do any research whatsoever. So so that's that's kind of, like, my interpretation of the Rogers curve, which is 5 stages that are probably named a bit better and more focused on dev tools. Because once you've understood these these grouping of people, then your strategy evolves accordingly.
swyx:So, for example, if you're earlier stage, the tech is the story. All these people who are who are saying, like, oh, we built x with Rust. Like, why does it matter that something is built with Rust? It actually doesn't really. Like but because you're early stage, people love to understand how you work and what you do.
swyx:Open the hood up for for me. The tech is the story. The cost doesn't matter. And in the later stage, the tech is no longer a story. The result is the story.
swyx:And costs, you want to optimize and and get down. So the the marketing changes, the, the way you, you know, the way you tell your story and the the way the the words that you choose, the the use cases and the demos and the documentation even, all that changes based on where you are in the adoption curve.
Jack Bridger:That's so interesting. So it's like kind of the, you know, the Hacker News phase where you're trying to get those early adopters and and things like what language and text stack you use is is important. And then, yeah, as you progress, it becomes more about, yeah, budget and use cases and Gartner reports.
swyx:Yeah. So so that's my explanation. You know, I think every every, dev tools person needs to have a mental model of, what the what what where they are in the journey. And, you know, these journeys progress through different phases as well. So, I think so I think another thing to to understand as well is sometimes the product itself has to change dramatically.
swyx:Like, it doesn't survive, stage change within in the same format. Like, sometimes the product has has itself has to change dramatically to reach the next level. And understanding and studying how other products do that helps you to work on your product. And I I think that is something that I'm I'm very interested in. I I wouldn't I would never say I'm an expert at it.
swyx:But I think recognizing that there is something to be learned here, is step 1.
Jack Bridger:Yeah. And so let's say, like, you're just, like, airdropped into a company, a dev tool. Like, how are you gonna go about figuring out, like, what stage, they're at on the adoption cycle?
swyx:Yeah. I I think that's super interesting. Quite to a quite close approximation, you can just go by number of users, and, that will be a very, very good metric already. Because by definition, the the the the number of, enthusiasts will be small, and the number of conservatives will be very large. So if you have, in the tens to hundreds of users, they're all enthusiasts.
swyx:If you have if you have the 1,000 to tens of thousands, you're probably pioneers. If you're in the hundreds of thousands, you're pragmatists. And if you're the millions, you're in the conservative and skeptic space. Also having some Fermi estimates of, like, numbers of, like, number of users for each different platform, gives you a really good idea. I have I have a longer post on, like, pop population developers in, on DX tips if people wanna read that.
swyx:But so a rough estimate of number of people in Hacker News will be 6,000,000 developers. A rough estimate, GitHub says in the state of Octoverse that they have 95,000,000, developers. That's complete nonsense because, that is just the number of GitHub accounts and not everyone who has a GitHub account is a developer and not every not every, and some people have multiple GitHub accounts for work and personal. So, and then, you know, within that, you should know the rough populations of the relevant ecosystems that you're at. So there's something like 30 to 40,000,000 JavaScript users, versus, you know, Python and versus C Sharp.
swyx:And you should just like understand the the rough population space because that is actually your total addressable markets. If you're a developer tool that that that is it. Like you're not you're not going to hit into the tens and hundreds of millions probably because, nothing ever gets there. So so that's, I think that's that's realistic. And, and and then you sort of phrase your story, the the way that you like.
swyx:Well so sometimes as well, your your audience is also a little bit smaller depending on the type of tool you are. So let's say you're not just about languages, you're also about the role within a company. Right? So, if you are, in in a infrastructure tool or like a DevOps tool, you know, a large company like Twitter maybe would have, like, 200, DevOps, then then, yes, like, that is basically your your total addressable market as well. So, just kinda scaling your expectations by, like, the the the rough population size, I think, is is super useful.
swyx:And then understanding, that that is also a moving target. Sometimes, the populations do increase, and you want to have, some amount of, built in expectation of, like, how different parts of the the the, like, the enterprise are growing. So, for example, one thing I'm focused on at Airbyte is is the data engineer, which did not used to be a job title, 5 years ago and now is a pretty thriving community of, let's say, a 100000 people. And so that's not big, you know, but, itself is growing, and it's probably doubling every year, and, it didn't take that long to be big.
Jack Bridger:Yeah. That's interesting. And could you talk a bit about Airbyte and, like, kind of the phase that you're at, and, like, kind of how that's impacting the decisions that you're making?
swyx:I would say probably, Airbyte is in the pioneers phase. Right? That's the second phase where, people adopt it because they have a pressing need for, for your stuff because, no one else does it. So Airbyte is a open source, data pipelines tool. It has the largest community of open source, integrations with, all sorts of data, data sources into your data warehouse.
swyx:And that's a very fundamental need that you have to perform ELT into your data warehouse, so that you can do analysis and sometimes to drive business impacts as well. Whatever it is, if your data warehouse is growing, you know, Amazon Redshift is the fastest growing Amazon service for the past, like, 10 years now. And you need to fill your data warehouse with stuff. And either you write your own scripts or you take a you take an open source tool, like Airbyte. Oh, well, you can also go for a paid tool, but, the the point is open source.
swyx:It's still not v one point o. Right? That's also another, good metric to tell that you're in the pioneer phase. Like, you see, you haven't you haven't released your the the v one of your products yet to people so people are already using you. But people buy the vision.
swyx:They're willing to build what's missing. We have people building on JavaScript SDK for us because we only focus on Python. And people wanna be part of the story. So, like, giving out, you know, labels, like, earlier by contributor, like, you're part of the story for, like, offers 1,000 stars. Like, that kind of stuff is is all part of building the community around, the open source product.
swyx:And so yeah. I mean, at some point, we will cross over into the pragmatism stage where, cost benefit also does make sense. So we we are trying to appeal on the cost benefit side, but that is not as important as the the pressing need that we do things that other other companies don't do. And so that that puts you squarely in the pioneers, cap. So I'll I'll give you I'll give you a couple of other things to think about.
swyx:So we already talked about how the product itself might need to change in order to reach a broader audience. So sometimes you may need to write wrappers around it. You might need to write a low code version of your tool versus a a higher code. Like, basically, like, to offer, multiple levels of offerings, for different levels of technicality and and customizable needs. So, one one very one experience that you and I, talked about before this recording, you know, previously, I worked at Netlify where I was helping to maintain, the auth library.
swyx:And people who open up the auth library might be surprised to find that we have 4 packages for our for Netlify auth, depending on your needs. 1 is an insertable widget that you can just kinda copy and paste with no no configuration. The second one is a sort of JavaScript, library that is just plain JS and no frameworks. The third would be, a React, hooks, library that doesn't come with any styles. And the 4th would be a React library that is that ships a component that you can use that does come with styles.
swyx:And so do you want styles or not? Do you use React or not? Do you, you know, do you code or not? And and so you have all these offerings to try to reach the multiple people, and the product does, take on different forms in order to serve different, needs and different audiences. Explaining that, does take, takes some time.
swyx:So there is something to be said about refusing to do that until you absolutely have to. So I I do think that I was a little bit too eager in giving all these offerings because that, conflate confused the story and people, came away with a negative impression that it was too complex, when really I was just trying to make multiple people happy.
Jack Bridger:So maybe at the beginning, it's like you just focus in on that one.
swyx:The one offering. Right? Because that so that that that people don't have this extended conversation about the different offerings that you have. Because I think a lot of people when they they need work in dev tools, they they try to say, like, oh, yeah. We can do everything.
swyx:Like, you know, we're we're so flexible. We're so capable. That's because they have lack of conviction on who their target audience is. And we definitely had that. We still have that.
swyx:But, the, you know, the other thing is that the company that wins the, enthusiastic pioneer phase may not be the company that wins the rest. So the company may not capture the value of the technology that it creates. So the the canonical example used to be Docker. Docker Inc, used to be, you know, a company itself and and then, underperformed expectations. It was recently revised and I I hear actually they they seem to be doing well under new management.
swyx:But Docker Inc itself definitely failed to achieve its potential despite revolutionizing, everyone's virtual machines. You know, and, and and and so sometimes a lot of times, especially if you create a successful standard, the work still has to be done to build a platform around it such that you capture the value, or you or you let go of it. So another example in the back end world is, OpenTelemetry, which is, come to come from nowhere in, like, basically a very, very short time, like, about the past 3 years to become the industry standard for, telemetry for tracing. And the company that that was the biggest, large largest champion, biggest contributor, LightStep, didn't, fail to monetize and and eventually, got acquired and sold out, and all the all the all the core people have left. And, so it's it's it's an awkward conversation in in the industry because everyone loves the technology, but the the people that were most responsible for it, didn't get the credit.
swyx:And and and you see occasion occasionally, this happens here and there. And I think, for people who are choosing to work in dev tools and choosing to work really hard and pushing things along the curve, you need to be thinking about, how you're not going to essentially have all your work thrown away by some strategic misstep. I don't know what like, I don't have the complete answer. But all I know is, like, there there are these examples there. Everyone in the industry wonders about them.
swyx:It's one of those things where, like, you just kinda have to try to learn from as many examples as possible because it's kinda really hard to to know the truth because you also have to basically work there to understand the full picture. And all we have are snippets of, like, comments from people, you know, sometimes whispered in, hallway conversations rather than the in the official press. We're all interested in, working hard in technology, but also benefiting, hopefully, from our success. And Yeah. And when when when people work really hard and fail to succeed, that is interesting.
swyx:That is that needs to be discussed. And, I no one in in no in most cases, no one's saying they could have done any better. All we're just trying to do is that we're we're fellow travelers, and we're trying to learn. And, you know, any port in the storm, and you try you try to learn from what's, what's available out there. One more thing I'll offer you.
swyx:So, what I've documented here, the the whole Rogers curve, enthusiasts, pioneers, pragmatists, conservatives, skeptics, and newbies, these are this this is, elements of demands, like the people who are who are users of the technology. Another dimension that you should should think about, in terms of development of it of any technology, is the development of the supply of that technology. So there's another concept called the Wardley map. Have you heard of it?
Jack Bridger:No. I haven't.
swyx:It's it's by Simon Wardley, who's a who's a Brit. He tends to document these very complicated charts of entire industries. So I'll just kind of visually I'll just kind of, like, verbally describe it, but I highly recommend people check it out. So on the left, you have value chain, going from invisible on the bottom to visible at the top, which is basically, at the top, it's closer to humans, closer to customers. At the bottom is closer to machines.
swyx:And then, that's the vertical axis. And then the the horizontal axis on the left is Genesis, the the the original inception of this the the technology. And on the right is commodity, which is, the the more the more commoditized version of that technology. Right? So from invention, so his stages on the horizontal axis are Genesis, custom built, product, and commodity.
swyx:So in in basically, in in increasing orders of commoditization from invention towards, every every company custom building in house towards buying off the shelf as a service from other companies. And then finally, commodity service where you don't even care what brand of of a thing you're you're buying. You just to me, like, you know, I have a mouse. I don't care what what brand it is. I just need a mouse.
swyx:So so that's that's the that's the chart of, like, from of any technology. And and basically, the the main observation, the main takeaway I have from this is that the tendency of technology is to start from invention, going into custom building, going to, product productization and going to commodity. And there's a there's a lot of money to be made from every single stage change there. It does parallel a little bit, the Rogers curve that we talked about. But instead of a single company getting adoption, this is more about entire industries getting getting distribution.
swyx:And finally, understanding, like, what hap what's moving in relation to others. Right? So if other parts of your your stack, whatever your stack is in delivering technology to end users, if other parts of your stack are moving towards a more commoditized direction, that's actually good news for you because your, your part of the stack becomes more valuable. So the choosing where to be in the stack, is is very valuable. And then choosing to understand what process stack you can commoditize while also making sure that other parts commoditize faster than you, is the entire name of capitalism.
Jack Bridger:And is the facts that other parts become more commoditized that makes your part more valuable because that's where people differentiate themselves, is it? Or
swyx:Yep. So, I there's there's there's another, canonical essay in this topic. It's called strategy letter 5.
Jack Bridger:It's a fantastic name.
swyx:Letters 1 through 4, not as useful, but strategy letter 5 was the good one. It's on Joel Spolsky, the founder of Stack Overflow. Joel Spolsky. And hey. There you go.
swyx:And, you know, it is basically the rule of commoditize your compliments. Every if you you've you've seen this, diagram in a 100 different landing pages, which is your tool at the center of the universe and every other tool on the left and on the right, you know, we can we plug into everything and we we deliver to everything. Right? Like, that is essentially Airbyte, but also like a a 1,000,000,000 other tools. Matt Slopnik, who, who I think attracts the data ecosystem, calls this the hardest working graphic in software because every single every single, company says we're special.
swyx:You know, we're not like the other tools. Everyone else is commoditized, but we're the only ones that do, x y z. To the extent, like, you know, that's obviously not true in some in some cases, but you want to find where, the the pockets where it is more true than others, and that's where you make money. But so so here's the here's the main, you know, insight that I, you know, wanna offer people. Like, try to develop a 2 dimension 2 dimensional map of where your industry is.
swyx:Use whatever adoption curve you want, use whatever value metric that you want, understand where your dev tool is is in relation to all the others, and you will have a better insight on how to market and, and develop your tool, than most because most people have never thought about tech in this way.
Jack Bridger:I'm gonna take that on myself. Where where can people learn more about this, Sean?
swyx:So I haven't written about it yet. I I I've
Jack Bridger:done people need a blog.
swyx:I know. Exactly. So I did a, so this has been cooking in my in my drafts for, like, 2 years. I did a talk about this at the the recent Svelte Summit. So Svelte Summit is one example that I've been taking on is essentially a project to understand how to get a dev tool over the chasm.
swyx:So, you know, I, and so the talk that I gave at Svelte Summit was 10xing Svelte. Essentially, when I joined, Svelte in 2019 all the way to 2022, just kind of recapping what we did and how we got how we went from, you know, very, very small project, towards, like, you know, top of the rankings in most JavaScript, ecosystem surveys and then, the usage itself, 10x. And, then the talk was like, okay. We we have 10x over the past 3 years. How do we 10x from here, to the next thing, and and do we want to?
swyx:Because that that's an that's an interesting, part of of open source communities and networks that doesn't get talked about enough, which is sometimes, bigger isn't always better. Sometimes there is an optimal size for for a thing. The only reason bigger is always better is because of VCs. They always want you to grow like a cancer. But and sometimes there's a natural size to things, and, trying to push it beyond its size actually ruins the core technology.
swyx:And and so I think that that was a that was a very honest discussion that we had, at the summit. And, I I basically presented, like, 5 different models of growth there. That is essentially the talk version of the blog post that I would be eventually putting out, on the x tips.
Jack Bridger:I'll put a I'll put a link up in the description as well. K. I'm gonna watch that right now, I think.
swyx:It's a it's a very fast talk. I have decided to optimize for YouTube and to go extremely fast, but then leave breadcrumbs for people if they want to, if they want to learn more because then I get to cover a lot more things.
Jack Bridger:I mean, that's a good approach. I found that in general, like, a lot of your articles, like, I read it, but I'm like, woah. This feels like a whole section of knowledge I had I know nothing about that I need to just Yeah. Dig into.
swyx:Yeah. So it is it is arguably not a good principle of communication. There are other people who are have broader reach than me that dumb things down essentially for clear communication. And I and I'm and I'm probably, missing out on doing that just because I have this, like, inherent pride or narcissistic tendency, whatever you call it, of, like, trying to leave everything on the table. I I just put down everything that I know so that you can get into my head, or you can correct me if I'm wrong.
swyx:Whereas, you know, a lot of people when they write, they're they tend to, be very concerned with being a fully formed version of themselves with, with no flaws. And I kind of dislike that, so I I tried to reflect that in my work.
Jack Bridger:Yeah. I think it it comes across really well. Like, I I mean, your background was like hedge funds, right, before? Like, you So you're switching to kind of you it feels like you're kinda bringing that approach and thinking very analytically and strategically about the whole space.
swyx:Yeah. I don't know if it's annoying, but, like, yeah, I I, I can't help it, so I'm not gonna change it. But, yeah. But so I I do think that most people haven't seen the the depth of analysis that is typical in financial, investment reporting. And then most people haven't taken that philosophy and tried to apply it to all forms of decision making, including technology decisions.
swyx:Yeah. What we're talking about is, like, going telescoping from the micro, which is individual company, development phases and the philosophies around, like, the how to getting your word out there and, like, you know, this is this is what sort of dev DevRel is on a on a very sort of quotidian basis. But, really, when you think about it on a, like, a strategic level, it's about entire industries. And if you want to make an impact, you have to do that. And so there, the formal term for this is, in in is industrial organization.
swyx:There are entire branches of economics that study this. And so I I encourage you to like, I'm I'm only basically a amateur at this. You know, I I pick and choose from, the theories that I that I happen to like. Another thing that you should think about is vertical versus horizontal, splits in industry and, how these develop over time. I have a fuller treatment in my book.
swyx:I think you can read it for free, the the chapter that's relevant to, business and tech. So you just go to learn in public dot org, and look at the free chapters. It's it's the 4th one.
Jack Bridger:That's all we've got time for. Sean, thanks so much for joining. I've wanted to have you on this podcast for a really long time, so it's a big, milestone for me. So thank you so much. And, where can people learn more, if they wanna hear more from you?
swyx:So I've been making a conscious effort to not say Twitter because I think, there's a decent chance that Twitter may not be around or I may not be around on Twitter forever. So the permanent site would be swyx.i0, which is my my main blog. I have 2 other blogs because I have a problem. So one is DX tips. It's literally DX dot tips, and that is my focused dev relevant dev experience, dev tools writing.
swyx:And then 2 is, my AI blog, which is L space. Just go on my site, and you'll see all the links.
Jack Bridger:Amazing. And thanks everyone for listening, and we'll see you again next week.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
