And now here we're going to go into the very first official chapter after the introduction. And this is Developer Experience. Over the last year, people have asked me why I started with developer experience. And not only did I start with it, but most of the chapters in this book are 15 pages long.

Well, Developer Experience is 25 pages long. So not only did I start with it, but it is the longest chapter in the book. And that's because developer experience is foundational. Even if you're doing developer content, when you attract developers to your content and eventually to your product, they're going to discover your developer experience.

And if they have a poor experience, then you're actually putting a lot of effort into attracting people when they're going to just fall out and not, actually do what you want them eventually to do, because the idea of, content yes, is to, attract people but eventually you want them to actually use the product.

That's a little counter maybe, to the message of, education first. But the idea is that you want to be able to educate on topics that connect to actual usage of your product. So the developer experience then becomes a really important piece of it.

Sometimes people will say, okay, so I guess developer experience is important, but is it really marketing and for a dev-focused company, I think it is. It's an important piece of it. In the chapter, there are 13 criteria, for a developer experience. One of them is that you can even find anything that is clearly focused on a developer.

And if that little bit is even missing, imagine what that developer who comes to your site thinks when they see that there's nothing there for them. There is no link in the nav bar that says developers or documentation. They scroll down to the footer and there's nothing there either.

Or maybe they do click on it and it pops over to a completely other site. And then you wonder, do they really care about developers if they're providing this poor experience and that's just on being able to find the documentation, let alone some of the other criteria that you'll find, in the chapter.

Another common question I get asked is what's the most important DX criteria. So I think people see 13 things and they say, oh man, what should I do first? And so I definitely address this in the book with, basically getting started with getting started.

So that's often missing from when we do developer experience reviews for clients, there will be no getting started or it will be a getting started that doesn't actually get you started. It's more kind of an overview or concepts, or there'll be multiple getting started that are different projects entirely. And so choosing that what is that first experience going to be like, and how can I walk a developer through that is I think if you're going to focus on one thing of the 13 in developer experience, that's the one to go for. And I mentioned, some mistakes in the chapter as well, like, making it too long or attempting to cover everything, including some long list of concepts that you feel like they need to know before they actually use your product. And I would say it's okay to keep it really focused and to give just in time context, as someone is getting started. Let them see what comes back. If it's an API, what call is returned? What it looks like when they integrate your developer product with a tiny little sample. Or a hello world app. Let them see that.

And then you can start to layer in the concepts that are going to be important. Those become the next steps. That's your path to the first success. Whereas the getting started is about that first experience. And so you can see that in the 25 pages of Developer Experience in the book, Developer Marketing Does Not Exist.