What Is Developer Experience? - Adam Wathan (Tailwind CSS) and Lee Robinson (Vercel)

In this first episode, we dive deeper into what is developer experience with Adam Wathan from Tailwind Labs and Lee Robinson from Vercel. Why did developer experience become so important? Concretely, what does it mean and how do you achieve it? Sarah Dayan chats with our 2 guests to uncover what makes awesome DX, what are the best examples out there, and how they imagine the future.

• Adam Wathan is the creator of Tailwind CSS, one of the most popular and the fastest growing CSS framework, which popularized utility-first CSS. He has since then founded his own company, Tailwind Labs, where he builds the best tools for CSS developers.
• Lee Robinson is the Head of Developer Relations at Vercel, the company behind Next.js, which is rapidly becoming the most popular React-based framework out there. He’s built tons of learning material, including blog posts and courses, and you can always count on his video tutorials to learn how to build anything with Next.

Transcript

Adam Wathan: 0:00

Developer experience really is just about making it possible for people to achieve the things they're trying to do in the fastest, most joy inspiring way possible.

Sarah Dayan: 0:12

Hi everyone. And welcome to developer experience a new podcast brought to you by Algolia. We chat with guests us to build products for developers about their developer experience strategy, what it means for them, why it's important. And so on today's episode is our very first, so we will be diving deeper into what developer experience or DX really means I AMS. And today I have two fantastic guests with me to answer this question. Adam Wathan is the creator of tailwind CSS, one of the most popular and the fastest growing CSS framework, which popularized utility for CSS he has since then found in his own company tailwind labs, where he builds the best tools for CSS developers. Hello Adam.

Adam Wathan: 1:05

Hey, thanks so much for having me on

Sarah Dayan: 1:07

Our second guest is Lee Robinson, who is the head of developer relations. Verel the company behind next JS, which is rapidly becoming the most popular react based framework out there. He has built tons of learning material, including blog posts courses, and you can always count on his video tutorials to learn how to build anything was next highly.

Lee Robinson: 1:32

Hey, thanks for having me really excited to be here.

Sarah Dayan: 1:35

So let's dive in. You know, when I look at the, at your websites, like the tailwind tells CSS page, I can read stuff like rapidly build modern websites without ever leaving your HTML. Then I go to Versace. I'm like Versace combines the best developer experience with an obsessive focus on front end user performance. And then again, I go on next and it's like, next JS gives you the best developer experience again, with all the features you need for production. So how comes that developer experience has become so important that now it is a top selling argument on lending page for up and source, but also commercial products. One, why do we care so much?

Adam Wathan: 2:25

Yeah, I mean, I can take a, a stab at it. I think there's probably a lot of different elements to it, but I think like the one that stands out to me is being a developer is a, is a bit of a unique job in a lot of ways where most of us that do it for a living, I think also do it because we just like really enjoy it and find a lot of fun in doing it. And we love to use tools that make that fun experience even more fun. You know what I mean? I think a lot of jobs out there, people don't expect to have fun or don't, or don't look to have any fun with it, but when you already kind of enjoy the work that you do and you get to kind of, of be creative, it can be made even more enjoyable when it feels like the tools that you're using are really like, you know, helping you move faster and be more productive and like stay in the flow versus feeling like you're fighting with them. And then I think on, on top of that, you know, of course there's just like a lot of demand for developers. You know, software is eating the world. People want to keep their developers happy. You know what I mean? So if, if, if you can give people tools that, uh, help them have more fun and help them feel more productive and keep up morale and keep them motivated. I think that's, that's kind of good for everybody.

Lee Robinson: 3:35

Yeah. And I, I think also increasingly we're seeing people in executive or like higher level positions at companies start to understand empowering their developers and increasing their productivity is having a good return on investment. And they're seeing those gains of if our developers are happy, our business is doing better, which is then allowing developers to influence decisions around ending whether that's tools you use or SAS you use, or frameworks that you choose or all those different decisions. I think that's, we're finally starting to realize a lot of that.

Sarah Dayan: 4:08

Yes. And it makes a lot of sense, especially when, considering for example, tailwind or next, or Algolia, we're making products for developers. So in that way you build software for developers. DX is really just UX in a way you are making it great for your audience. And in those cases, the audience is developers,

Adam Wathan: 4:31

Especially when you're a company building tools for developers, of course developers are your customer. So you want to attract those customers by basically promising them the best possible experience. For sure.

Sarah Dayan: 4:45

One thing I'm noticing is that the ecosystem is growing and we're getting all better at building software. So there is more and more quality products and so competing quality products available. So it's not just like great software. Where is the unique differentiator? You need something more when you look at next, it's not the first react framework. Tell when CSS is not the first utility first, but also CSS framework. So it's not just about, Hey, we're making it easier. Or our tech is better. It's also, you are gonna have, have fun is gonna be easy to use it. You are gonna have a steady learning curve. Like you're gonna be able to be productive faster, or it's gonna be a better investment of your time than this and this. Yeah.

Lee Robinson: 5:37

I, I think one interesting point here is developers get really excited about perform and not only like end user performance, but also increased performance while they're developing locally or what that experience is like. And something that's interesting is because of the growing community and more developers at large, you see people experimenting and trying out new solutions to maybe problems that existed in the past with something completely new. A great example is like ES build ES build is awesome and it's really paving the way for a new future of dev tooling. And the great thing about being at the forefront of developer experience is looking at ideas like ES build and looking at fundamental new approaches to technology and seeing how that changes the developer experience. Like when you start your application, it's just immediate and then taking that inspiration and trying to work even harder on your own tooling, trying to make Webpac faster in next JS.

Adam Wathan: 6:31

Yeah. I think performance is a great thing to talk about when it comes to developer experience, because it's the one thing that's like, if you can't think of anything else to improve, you know, improve the performance. Like it's like, I think there's like a quote, something. I think I heard about like Amazon back in the day, which was like focus on the needs that people have that are never going to change. Like no one is ever gonna want their packages to be delivered slower. So let's just figure out how to get them to them faster and faster, faster. And it's a same with developer tooling, no one wants transpiring, their JavaScript to get slower. And you know, the feeling that people have when they use something like ES build for the first time or some of the tools that are kind of powered by it, like VT is kind of like a, a popular new, like development environment that just like, because it's using ES build under the hood and like native ES module and taking advantage of all these new technologies, it just boots up like instantly. And as a developer that just like brings this huge smile to your face, you know, like you're so used to waiting for everything. And when it just feels like things are instant, I don't know. It's a, it's a bit of a magical feeling. So it's a, a fun one to chase for sure.

Sarah Dayan: 7:35

Yeah. And it's interesting, you you're speaking of ears build which, which is, is extremely fast, but then VT is built on top of it. But what V also brings on top of yeah. We're fast and we're using under the hood, the tooling to make it fast is that we are also bringing all that together because VT is not only just like a server, it's also bundling up with, with roll up. And when you are looking at the progress on JavaScript tooling, like Rome, there is a lot of excitement around that because it's not only fast best in class, but it also consolidates a lot of similar concerns.

Adam Wathan: 8:15

Yeah.

Sarah Dayan: 8:16

I'd love to know what's your opinion on what can greatly makes great DX because when you ask people, they will tell you, okay, it's when you have great documentation or when the software feels intuitive, but is it only a matter of like checking the right boxes or is there more more to it?

Adam Wathan: 8:37

That's a hard question. I think, because I think it it's different for each product. You know, I think all the examples you gave are, are great ones for me. Like a great anchor way to think about it in general is just that the goal of like building these tools, if you really want people to have great experiences with them is you want to be focused the whole time on like, making people feel like they have superpowers when they use like your tool. I think I've read this, this kind of like first put into words that way. And Kathy Sierra's badass book like a few years ago where she talks about like basically how to make a great camera, not to just is not to think about all the features that you can add to the camera, but it's like, what do we have to do to make sure that when someone takes a photo with this camera, they're like so proud of the photo that they took and that it feels like they did it, it doesn't feel like the tool really even gets the credit. It feels like they achieved this outcome and it helped them get there. You know? So how can you, what decisions can you make when you think something that, that are going to make someone feel like they are kick at the problem that they're trying to solve? And sometimes not even really noticing that the tool is a thing that's like letting them do it, you know, like you're, you're not looking to get credit for it in a way, you know what I mean? It's, it's really just about focusing on like, how can you make someone super successful? And I think like the, the open source example that like stands out to me the most just cuz of my own experience and like my own journey to get to where I was, was when I first started using like, laal back when I was like still in college, in like 2012, compared to what I was used to doing with like vanilla PHP and like writing SQL statements myself. And so stuff like that, it was so crazy to me how I could just like get some stuff showing on the screen from a database and click around and stuff with like so little work. I just felt like I can build anything now because of like these tools that are here. So for me, a lot of it just comes to them to like trying to create that, that feeling by any means necessary. And it think, I think it does depend on each project. I think with tailwind, for example, some of the elements to that are like agonizing over the class names to try and make them like as guessable as possible. And it's never always guessable for everyone, but I do hear that feedback a lot where people, a lot of people feel like they don't even need to read the docs. They just like guess and they're right. You know, and then even just like designing the tool to accommodate the whole, you know, utility first workflow that like we believe in, in so much, like that's not really a feature of tailwind itself as a technical library. You know, it's not like code that we wrote that creates that experience. It it's really just like creating something that enables a specific flow and letting people experience kind of like the benefits of that workflow. And then documentation, I think is a huge one. I think I heard Taylor Atwell say this years ago that he kind of believes that basically given a set of open source tools, like the one with the best documentation is like almost always the one that wins because that's the one where people are gonna be able to do the things that they, they need to do. So paying attention to what people are struggling with and, and finding ways to get people over those hurdles, either through documentation or by introducing a feature that fixes that you just wanna just like make sure nothing ever slows people down.

Lee Robinson: 11:57

I, I love the first point you made because something that I have a lot of respect for the tailwind team for is that a underrated benefit of creating a great developer experience is that you notice that design is really rooted in every decision that you make. And that's something that I think the tailwind team does really well. And that I have a lot of respect for my peers ATL for thinking about really deeply, because what is design in the developer space is a lot more than just how the documentation looks it's like you said, with making sure the class names are guessable, it's down to how you design even APIs for frameworks. It's how the user interaction on your site makes it so that it just gets out of the way. It makes it really easy to just jump in and get started. And from my personal experience, I feel like when I have a really great developer experience, it's always rooted in teams that think very deeply about design and they care deeply and they stress over the little details that other people might not spend the extra time on.

Adam Wathan: 12:58

Yeah. Developer experience is a design problem, for sure. Like not all developers are the sorts of people who create things that, you know, have great developer experiences. Not because like just, just cause it's a different skill. You know what I mean? It's, it's, it's like magical when you can find people who like have the technical ability to build the thing and also have like the sort of design mind sort of brain to sort of bridge that gap. And you get lots of amazing things, you know, coming from that, when you see that, I think like another concrete example of like when I had an experience that made me feel like what, wow, I can't believe like how easily I was able to do that was when I first was playing with incremental static regeneration in next. So I had to build like a website for my podcast, full stack radio. Cause I didn't like, like the default website that came with podcast host I was using and I was trying to think, okay, well, how am I gonna do this? You know, I have to like consume this RSS feed and I have to figure out how to like get all that working. Am I gonna have to like run a build script every single time that like I publish a new episode or, um, have something make like an API request and like cash things. And then I just started building it out with next expecting like, not really fully think through like the power of that feature at the time, but just like started building it and just see where I ended up. And then when I added that first, like I think it's just like get static props, right? That's like the API for like the, that stuff added, like get static props. All it does is make an Fe request to the RSS feed and then pass it in. It's literally like three lines of code. And now I have this like fully static podcast site that automatically update it's anytime I publish a new episode, as long as someone visits the page once. And I, I just like, I couldn't believe that I was able to do it with like such little code without thinking about anything that had to run on the server. And, and in hindsight it's like, well, of course that should be possible. Like when you see that it can be done, but it was this magical experience of being able to do something so easily, but also like understanding why it was easy. And also like not feeling like there was some magic happening that like was well beyond like my ability to comprehend it. You know, it it's, it's straightforward enough that you feel like, again, like you feel like you can take credit for building the website, you know what I mean? And it makes you feel like an awesome developer. It doesn't make you feel like you just have this like overpowered tool that elevates even someone who doesn't know what they're doing. Like you, you know, it's, it's an empowering feeling. It's not, it doesn't feel like a crutch, you know, and trying to find out how to design things that way is, is hard. But that's what I think you need to think about.

Lee Robinson: 15:33

Yeah. The behind the scenes story there is really interesting to me because you know, huge shout out and, and credit to the next JS core team for designing these APIs and, and coming up with this approach. But what you don't see is that, you know, that was in the works for years, they had been thinking deeply about, do we build this abstraction on next JS to make it easy, to build static sites? So if I roll it back a little bit, like when next JS started, it was focused on server rendering react applications. And you know, there were other solutions that existed that would allow you to build everything

Adam Wathan: 16:08

Was server render, right? Like you had to write like isomorphic JavaScript for everything that was kind of like the big pitch. Yeah.

Lee Robinson: 16:13

100%. And you know, there were other solutions out there not even react related, but just allow you to create static sites. And we kind of just stepped back. I say, we, I wasn't at Verel when this happened, but the team stepped back and just looked at the ecosystem. And at this point I was just a happy user of yes. And they looked at the ecosystem and they, they understood what worked well and what maybe didn't work as well, or what could be improved a little bit and really deeply thought about how do we condense the API for making a static site into just two methods and how can we make it so that adding new functionality, like allowing your pages to regenerate in the background is just a couple lines of code, extra, such that when we release it, we're not gonna have to completely rewrite this thing in a few years. Like making it have an extensible API design from the start,

Sarah Dayan: 17:06

People always say, oh, it's about great documentation, like writing great docs and building great DX are all root it in the same need for empathy. You need to empathize with the people who are gonna use your product. And like, yeah. When I, when I think of Algolia, there are many examples, but when you index your data, you might have a lot of data. So we are going to batch it for you. We're gonna chunk it and batch it for you because otherwise you would need to do it. And when you index for the first time, because we know you're gonna be excited about searching it right away, we make all your attributes searchable. And then we tell you, you might want to pick which ones are, are searchable, because we know it can be a performance drain, but we don't want to make you go that extra step to do it and to see it work and to be amazed by, by the magic of it. So there's really, uh, this sense of empathy of how are people going to, to react when they see what? And so that's kind of the continuity of the work that you do when you're a software engineer, when you're a software engineer and you are working with a team, you want to write code that your coworker is not gonna hate you because you wrote it. So you're gonna do that, that job of, okay, I'm going to name my variables properly or, or split in my, uh, my PR in a, in a certain way. But then you are handing a piece of software to other developers who are not your coworkers who are not supposed to like you, they are using something that you made, but there is no, yeah, there is no tide. Like you don't have to be nice to each other. And so, yeah, there's really that continuity of you, your work, as I'm, I'm trying to exercise empathy and to make sure that people enjoy what, uh, that they enjoy the experience of working with that.

Adam Wathan: 19:02

I was gonna say, like, I think a thing too, that came to mind that I think is, is one of the things that makes trying to create great developer experiences, hard, that it's easy to just like jump on this idea of, we just wanna make things as easy as possible. We wanna make things as automatic as possible, but that never comes like for, for free. Even when you see people solve those problems, it's easy to assume or to, to kind of not recognize how much effort went into achieving it. But it's easy to try and build things that make some things easy while sort of making some things impossible, you know, and what's really hard is to figure out how to make things easy without like enforcing constraints. Some people that are just gonna frustrate them in like different ways. Cuz we've all seen like libraries that try to solve a specific problem and you work with it, but there's just like one tiny like deal breaking element of it. That's just like, ah, I just need to do this one thing. And it's like fundamentally impossible because of like this other decision that was made and now I can't use this tool. So I think that's one of like the most challenging elements is, is trying to find these kind of perfect solutions that make things easier without introducing limitations that are significant enough to kind of like ruin that, that magical experience. I think like the hardest thing in general about all this stuff is there really, isn't like a way to make a checklist of like, okay, here's like the things that you need to make like easy for people. It's it's really just has to be like noticing what could make people's lives better and figuring out how to solve it. Like one example that comes to mind for me is the command palette and sublime text. I might be wrong, but I feel like that was the first app where I ever saw that concept. The idea of a super quickly searchable thing where you could pull it up with one keystroke and you could access basically every function that you could perform in the whole app by searching and just like hitting enter to, to perform it. I'd never seen anyone else do that before, before it was always like memorize the key keyboard shortcuts, memorize the keyboard shortcuts, memorize the keyboard shortcuts and the people who took the time to do that, to memorize the keyboard shortcuts were always like, they always looked like wizards to the people who that wasn't natural for. Right? Like for me, I would always, anytime I wanted to perform any action, any tool, I'd like go up to the menu bar, open it up, find the action, see what the keyboard shortcut and then do it with the keyboard. Like I wouldn't let myself click the action in the menu bar. You know, otherwise you're not building that muscle memory, but not everyone is kind of has that like built into their DNA. You know what I mean? So you notice that problem as like a maker of these tools and you think, well, how can I help people not have to move their hand in the mouse? Cuz I know that that's like slowing the, these people down and you have to invent a solution for it. You know what I mean? Like there's no, it's not obvious. You know, you have to like work really hard and figure out like what sort of improvements you can make. I, I think like sublime in a lot of ways doesn't get enough credit for like completely changing the productivity expectations from tech editors with like the multi cursor stuff. And I, I was we reading some old, old hacker news comments about like when sublime first came out and someone said that something else had multiple curses before sublime, but then the creator sublime replied listing all the things that like that even that didn't have. And he had never even seen that either. So we take some of these things for granted. Now, like every modern editor we use has like multiple cursors has a command palette, like Chrome dev tools has a command palette at this point, you know? But these things had to be like in invented by someone who like noticed a situation where someone could do something faster and had to just like grind it, coming up with a solution. But I guess like if I did have to generalize, like what developer experience is, it really is just about new making it possible for people to achieve the things they're trying to do in the fastest, most joy inspiring way possible. You know, like when you do like a big, um, have you ever done like a, a project wide like Redex replace with like unfortunately, um, like placeholders and stuff, you know, where it's like a caps sure. This capture group and like replace it with this and like preserve the case or like change the case when you pull something like that off like the feeling that you get from that it's just like, I'm awesome. You

Speaker 4: 23:20

Know, you know what I mean?

Adam Wathan: 23:22

And like that that's possible because like someone created regular expressions, you know what I mean? Like regular expressions, like we all like to like kind of poke fun at them or whatever, but in, in some ways they're like one of the most powerful DX tools that exist, you know? Cause they do give you that super power that you wouldn't have otherwise. So, well,

Lee Robinson: 23:41

It what's interesting to me building off the, like the last part that you said, I think there's a word for this and it's rooted in other creative fields, but like let's say you're a musician like great musicians have great taste. They listen and they consume a lot of music, great artists, you know, they go to art galleries and they go view a lot of art. And I think with devs too, like great developers have have great taste and they try a lot of tools. They experiment with things. They, they understand what they like and what they don't like. And then all of that knowledge and shared experience helps then funnel back into creating an amazing developer experience in their product too. And I think that's where a lot of the inspiration comes too. Like I'll try out something like, you know, linear, which is an incredible, and I'm, I'm not building project management stuff, but I see their command K keyboard and I'm like, wow, this is amazing. Like I, I need to have this on my site or I need to put this in bursell.com.

Adam Wathan: 24:36

Yeah. I, I think it's a really important if you're trying to create great developer experience to really have like a very low pain tolerance. I think a lot of people are willing to put up with experiences that could be a lot better. So if you want to find opportunities to make things better, I think it's really important to, even though it sounds kind of negative it's to just like convince like be annoyed easily by your tools. No, I agree what I mean,

Lee Robinson: 25:02

A, a good example of this is like, it also ties back to empathy to too next JS is definitely not the first framework or tool to do this, but for certain errors, when you run into errors in the command line, it spits out, it says, Hey, here's what you did wrong. And then there's a URL to go learn more about it. That shows you specifically what went wrong, potentially some code to fix it. I I'm guessing that

Adam Wathan: 25:23

Was we're we're in the process of stealing that idea from you. I,

Lee Robinson: 25:26

I guess this was probably popularized by like ES lint, because they usually have links to docs for like why this lint or exists. Yeah. But it helps a lot. And it shows empathy for people. Not only thinking about the, like the happy path, but the sad path too. Yeah.

Adam Wathan: 25:41

You can do so much more with that than you can in just the console, right? Like if you limit yourself to just trying to figure out how can I explain this error in two sentences? So if it's in the console, like you can't really do much to help people, but if you can link to a page where you can have like embedded code examples and like you might be trying to do this, like here's how, what you should do instead, I'm really looking forward to creating like full blown, like scrollable docs pages for like certain common errors where, you know, we can really help people. And it helps us too, because like then we have less GitHub issues. Yes. Whatever, you know,

Lee Robinson: 26:13

A side benefit of that too, is that if you're going to a website and you have analytics on it, you get this nice ranked list of like, what are the errors that people are running into. And interestingly, we've, we're gonna talk about this at next year conference next week, but we've been working on integr ES lent directly into next JS. So the intention here is like, rather than even having to go through that process of like clicking out, ideally you get in editor feedback, like, Hey, you shouldn't do this specific thing. It's gonna break your

Adam Wathan: 26:41

App. That's actually a whole interesting topic in general, I think is ideas for improving kind of error situations that people run into as like a whole class. Like that's a whole subcategory of like developer experience, I think where there's lots of room to, to do stuff. And I'm interested in figuring out ways to improve there because the only idea I have right now is to do what you guys do with the, the, the links in, in the console. And, and we have stuff like in our like intelligence plugin, it'll like warn you, if you have applied like two conflicting classes, you know, if you have like flex and block, it'll be like, uh, don't do this. Like only one of these can work and we can't guarantee you, which one is working, stuff like that. So there

Sarah Dayan: 27:23

Is one thing that I, that to me is extremely important when we talk about DX, is that again, not to forget that it's UX. And so there are many existing patterns that apply from existing UX research. And one of the things that I really value is look how people use your product, look at what frustrates them, look at the feedback that you get. And yes, granted sometimes you can get lost in feedback and it's important to be able to pick the right things. But an example is that when we rebuilt the, the search on the Algolia documentation, we decided, okay, it's not just gonna be a new, pretty search. We're gonna build a search that caters to developers who are looking in our docs. So it's our specific docs, the way it works, the ecosystem we have and all that. And so we made a lot of decisions based on that, because we are the prime users of that, that document, but we can also know what people search and what doesn't yield, any results. And so, for example, that's how we decided, Hey, in the documentation, you're going to have a preview. So if you go on the documentation of Algolia you type something and when you navigate a results, instead of having to go there and see, oh yeah, that's actually what I'm looking for. You're gonna see a preview. And that is rooted in seeing people go and try. And because yeah, you show a result that is one line because you want it to be compact and people go, and then it's not the right page. So they come back and they do the search again. So they have to reopen it, et cetera. So there's that you also have the pattern of, uh, let's say you wanna say, you want to find how to index in PHP. So it's gonna be nice if you are able to filter on PHP, but if we're like, okay, let's provide you a dropdown and you're gonna select your language. Then you have to use your mouse and you have to leave the focus like the, the input. And when you actually look at people using the search and you say, okay, search for indexing in PHP, they will type indexing in PHP. So why not put that here? Like let's put patterns and put the developer experience or the user experience in the places that people expect them to be in. This is definitely something, for example, in tailwind that I use a lot that I can see is that it's not only gonna be about one place. It's not just the documentation or the product, but it's also the entire ecosystem that you build around it. Like tailwind intelligence in vs code is one of my favorite extension. It does so much for me. And I'm so happy about it because it makes me a lot faster having the, the errors in the console, like there is an error and having the link to the documentation in reacting next, in view, in it removes so much friction. But also I know that there is someone like me who probably went through that and decided, Hey, it's a good pattern. I know that someone is going to have a lot of pain in that place. So we're gonna put it here because that's where they're going to look.

Adam Wathan: 30:39

Yeah.

Lee Robinson: 30:39

It's obvious that you've really thought out about the entire ecosystem. Not only from I'm, I'm working with the library, but then, okay. I need some icons. Okay, well, we have this, you know, all these icons, you can pull off the shelf. Okay. But now I need to create a model and now I need to create some kind of JavaScript interactive thing. Okay. Well, now we have this headless UI package. That's gonna work with your favorite framework or tool of tool and going even further than with like tail one UI. It's like, well, okay. But I wanna see this in like a real world application, show me some real code. And it's like, here you go. Here's some free code.

Adam Wathan: 31:11

Yeah. Thanks on the note of what you were saying, Sarah, with like some of the documentation stuff. And, and even like the, the previous stuff that Algolia does with the search that makes me think of like something even sublime does that still, I think vs code doesn't do where if you hit like command P and start typing a file sublime previews it immediately. Whereas like vs code, you have to commit, you know, you have to say, uh, that's the file I want enter. Okay. Now I can see it. Just like little details like that make a big difference. I, I think like something we do in the docs that is painful as hell for me, but is, uh, I think worth it is there's so much redundancy in our documentation. Like so many things are explained seven different times on seven different pages, because I've tried really hard to think about like, what are all the ways someone might look for this information? So if you wanna learn how to like customize the different opacity values that are available, but there's a whole section of the documentation on C tailwind, but then on the opacity page, right at the bottom, there's an example of like how to customize it right there. You know? And we, we do that in a lot of places to try and just like, make sure that no matter what door someone comes in, like they still find it. Even if it means we have to duplicate it, which means it's harder for us to maintain and it's more work, but at the end of the day, everyone always figures out how to do what they want to do.

Sarah Dayan: 32:25

Yeah. I can definitely empathize on, on that. Especially docs because like the Algolia docs is, is huge because the Algolia ecosystem is huge. Like Algolia is the company. And when you say Algolia you think the search engine, but it's actually so big, you have the engine and then you have the open source, like the UI libraries, the, the API clients, et cetera. And it's easy to think, very like objectively, okay, I'm going to create one page or one section per project because it makes sense to document them that way, but that's not actually how people use it. And unless you're really, uh, a huge company that has a lot of different products and it they're all very contained, usually you're creating an ecosystem. And so, yeah, you might have one small page on the tailwind in intelligence plugin, but you're probably going to talk about it in many other place is because that's where people expect it. And that's, that's kind of the way that we, we tried building the documentation is thinking, what is the path that people are gonna take to achieve something? People don't really care about your products, the product itself. It does not matter to them. What matters is, what tools do you, if people so they can achieve what they have to achieve. And one very important thing to remember, especially when we we're all in the, like the tech business and we we're selling software building software is that search is one small concern that, that someone has when they're building something CSS, same thing like styling is concern, JavaScript. And even like how to build a website is one concern in the whole strategy of a company that is building something entirely different. So they will never be as invested as we are in our product and thinking that, oh yeah, everything is about search or a style or whatever, you know? So it, you needs to be stressed that people don't care about the product itself. They care about what they can achieve when you feel smarter, when you feel empowered and it's the same with docs. And it goes back to the, the guidelines of the UJS documentation are my favorite ever. And there is this one thing where, where it says like, yeah, people have a certain amount of energy and it de it depletes a lot slower when you make them feel smart. When you make them feel dumb, like you can have the smartest tech ever, if people feel dumb or behind or less done, because they can't understand it, it's going to Dee lead that their energy a lot faster than if every time you teach them some something, they feel empowered and that's ultimately what they care about. It's not about the product, but it's about what's you and luck. Yeah.

Lee Robinson: 35:17

Yeah. People will always remember that feeling for sure. Like the lasting impression is not necessarily the outcome of what they built, but the feeling that was left over, did I love this tool? Did I hate this tool? Would I use it again?

Sarah Dayan: 35:28

Definitely. I'd love to know maybe. And I'm gonna put you on the spotlight. Is there any recent example of incredible DX and you're not allowed to say either tailwind or Versace because, or next JS, because it's too easy, but that blew you away, but not, not only in an anecdotal way, but maybe in a way that you are thinking it's gonna hint what we can expect to see in developer experience in the upcoming years.

Adam Wathan: 35:57

Yeah. ES build has really impressed me and the tooling that's been built around it. And it's given me like a renewed appreciation for performance. I think, I don't know, maybe it's cyclical or something, but it feels like things are fast. And then we kind of just get used to them being fast. And then we just make things better and add more features and do cooler things. And then things kind of get slow again, but it happens gradually and you don't really notice. And then someone figures out how to make it fast again. And you're like, whoa, I forgot how awesome things being fastest. So playing with, um, with some of that stuff has, has really just, uh, gotten me more excited about pro performance than ever and making performance improvements to our own stuff and, and, and really kind of embedding it as like a core value into, into the work that we do. So, yeah, that, that's kind of the one that stands out the most for me is like ES build then by extension, uh, V when it came out and playing around with that,

Lee Robinson: 36:50

I, I definitely agree with both of those for me. I have two, one of'em is linear that I briefly mentioned earlier, but they have, it must be like a core company, ethos, or just a product ethos, but they really stress, like everything should happen. I think like in a hun under a hundred milliseconds. And when you use their product, you can really tell that they have performance benchmarks and that they make sure that these interactions complet as fast as possible. So it just feels fast when you use it. Another one too, for me, just like context and history, I guess, is that I started as a front end developer. And then eventually I stumbled into figuring out how to use a database slowly, very slowly. And I, I still wouldn't call myself like an expert in the distributed world of backends. Like there's really a lot there. And I've recently been trying out planet scale, which is like a new, a new solution for your backend. And it's built on my SQL and the test, which is like this open source software that they used at YouTube and like a bunch of other big companies. But the interesting thing about it is it's a bunch of, well, there's a lot of ex get hub people. And the, the UX flow when I used it is like the mental model of GitHub branches. And like the thing that I already understood and conceptually knew how to work with like the GI model and then copy pasted onto databases. So when I started to use it, I was like, oh yeah, you just make a new branch and you like, apply your schema change. And then you commit that schema change back to your main branch. And it just works. And I was like, oh my gosh, like this reimagining of that, how that workflow should act for helping front end developers like understand the back end actually really wowed me.

Adam Wathan: 38:32

That's awesome.

Sarah Dayan: 38:33

So, yeah, I wanted to mention vs, but Adam, you took it. So I'm gonna shamelessly plug, uh, Algolia here. One really cool thing. And, and I worked on it, so it's totally subjective, but, uh, the auto complete library, we just pushed the V one of the auto complete library of Algolia recently. And what's really cool in it for developers is that there is so much knowledge that has been accumulated over the years. Uh, Al GOIA regarding auto complete that I cannot think of anything that you could not do with this library. If what you have to build is an auto complete and I've, and I've really pushed it myself. Like I've, I, I worked on it, but also, uh, played with it. And one of the recent things that I've tried building with it is replicating the Omni surge that you have in, in Firefox the quantum bar, which is actually filled with awesome, delightful UX patterns that are very specific. And that can be very, very hard to reproduce and, and building that, building that experience that is so complex with autocomplete is a delight because all those patterns and all those abstractions and it, and I think it goes back to, yeah, one of the things that I love about N JS, all those abstractions have been so well thought out that it works and you feel like that's the right level and lower would be too hard because I would have to pluck too many things myself, but higher would remove the control that I want.

Adam Wathan: 40:06

Awesome. Great example,

Sarah Dayan: 40:09

Lee, Adam, where can people go to find you online?

Lee Robinson: 40:12

You can find me at Le Rob do IO or on Twitter at Lero with three E's because somebody else already took the other one.

Adam Wathan: 40:21

Uh, mostly I'm just on Twitter at Adam wain

Sarah Dayan: 40:24

And I'm on Twitter at front stuff, underscore IO, and then you can find anything and everything about algolia@algolia.com. Lee, Adam thinks a lot for doing this. It was super interesting. I wish we could stay two extra hours.

Adam Wathan: 40:40

Yeah. Thanks so much for having us. Yeah.

Lee Robinson: 40:41

Thank you.

Sarah Dayan: 40:44

This was developer experience, a podcast brought to you by Algolia. You can find this podcast on your favorite podcast platform. If you want to know more about Algolia check us out@algolia.com and we are at Alia on Twitter.