Providing Amazing DX Regardless of the Technical Stack - Ben Hong (Netlify)

In this episode, we chat with Ben Hong from Netlify about the challenges of providing amazing developer experience for a wide variety of technical stacks. How do you consistently provide incredible DX to everyone when what you build isn't tied to a single platform? How do you properly think of such systems? Ben gives us insights on how the DX team works at Netlify, and how a culture of curiosity and experimentation allows them to stay in touch with the JAMstack community.

Ben Hong is a Staff Developer Experience Engineer at Netlify, one of the most popular serverless platform to build and deploy web apps. He's also very present in the Vue.js community, as a member of the core team and as a Vue Mastery instructor.

• Ben Hong: @bencodezen / bencodezen.io
• Sarah Dayan: @frontstuff_io / sarahdayan.dev
• Algolia: @algolia / algolia.com
• Netlify: @netlify / netlify.com

Transcript

Ben Hong: 0:00

We all know that at the end of the day, their webpages that are like, that's all the customer cares about. They get their HML, their CSS and their JavaScript. However, it gets there doesn't matter. So the more we can make that easier for people to do better, it is.

Sarah Dayan: 0:13

Hi everyone. And welcome to developer experience a podcast by Algolia. We chat with guests who built products for developers about their developer experience, strategy, what it means for them, why it's important. And so on, on today's episode, we are going to talk about the challenges of providing amazing developer experience for a wide variety of technical stacks. How do you consistently provide incredible DX to everyone? When what you're building is not specific to a single platform, how do you properly think of such systems to answer those questions today? I have Ben Hong with me. Ben is a staff developer experience engineer at Netlify one of the most popular serverless platforms to build and deploy web apps. He's also very present in the UJS community as a member of the core team and as a view mastery instructor. Hello, Ben.

Ben Hong: 1:15

Hello.

Sarah Dayan: 1:16

All right. So let's dive in. I'm a big fan of Netlify. I really use it a lot. And as a frontend engineer myself, when I hear Netlify to me, it's like, Nety JAMstack same thing goes hand in hand. When you look at the gems stack ecosystem in and of itself, it's already pretty wide, you know, you have many different libraries like JavaScript, but not only Hugo and Jackal, many different languages. And then on top of that, you have the frameworks Gadsby next, et cetera. But even then when I go on the Netlify website, I see that you support solutions like DRAL or WordPress, which traditionally are dynamically rendered. Like you give a JAMstack spin to that. So I'm interested. How do you decide what to support and how do you make sure that you can actually sustain it?

Ben Hong: 2:08

So, as you mentioned at LFI, one of our goals is really to make it as easy as possible for developers to build and ship modern web applications as possible. And I think one of the things about like the origin of jam SAK is that cuz it was originally defined as like JavaScript, right. An API and markup. And so it was like, well, if there's no JavaScript, it can be jams stack. And really, if we think about it, like the reason jams tech even came up was because we had this whole era of single page applications, right. We were deploying these like, um, you know, single index that HTML, we were using JavaScript to rendering everything. And so in really, if we think about a lot of technological concept, this is, was kind of a throwback to the way things kind of were originally done. Right? You ship as little HTML are like just enough for the client to, to get started. And so when it came to like support, really it's about figuring out how to generate the most impact. Right? Certainly popularity is a consideration when a lot of people use it because if you know that, for example, like WordPress powers, a large percentage of sites on the web, then certainly we wanna make sure that we have support for it. Even though WordPress is traditionally more PHP and there's really not as much JavaScript on it, we still wanna make it as easy as possible for you to ship, call it a headless WordPress cm mess with the things that you might wanna build otherwise. And so, yeah, I mean, that's kind of like what goes into it as far as support since like, to your point, it is tricky when you have so many different libraries. And so I think the team is constantly looking at how can we make sure that we help improve the web and get developers to ship quicker with their solutions?

Sarah Dayan: 3:37

Yeah, that makes a lot of sense. Uh, I love what you said about, uh, like it's, it doesn't have to be specifically JavaScript and that's like when it comes to gems stack, while I believe if you take a step back, it's not about JavaScript. It's really more about building and using tools and using specific technologies where they're good at. And what I love is that when you think of gems stack, for example, it's not that you have to ditch WordPress. Like you can still use it. It's a pretty darn good piece of software for editing. It makes a lot of sense. A lot of people are already trained on it, but should it be the part that renders your UI that renders your website? Maybe not. Do you need to have your own server that you build like that run and you keep an eye on it, et cetera, maybe not because what you have may not be as dynamic as you think, or maybe only have a few parts that are dynamic. It's kind of the same idea that you have with Algolia should you own your own search engine? Should it be hosted on your own server? Do you need it to be done on the backend? Like you really need it when you realize what every piece of the pipe, whether it's the server, the client like that, this and that language, you realize that all have really interesting strength and weaknesses. And to me, that's really this idea of building SaaS products like that and build building those kinds of platforms. Is that really focusing on where you can bring the most value and piecing that together. To me, that really goes back to the initial concept of developer experience. Maybe some people like it, but when you are a frontend engineer, you're especially in many companies, when you're a frontend engineer, you're probably going to be the one who's responsible of the website. Like the entire website. You may not have a team, a fully dedicated team of people working on the website, but are you comfortable operating a server? Are you comfortable making sure that this build step happens in the right way or that you use the right CI or whatever may not. And so that's what I find really interesting about services like Netlify is that it really integrates with what you have, but it takes away the common parts that you don't want to care about.

Ben Hong: 5:53

Yeah. And I think to your point again, JAMstack evolved out of its time as far as like its timing of the ecosystem with a single page applications, but it really is like a architectural concept regarding trying to simplify this idea that when you're deploying things that you keep them in an anatomic way, that you abstract the way these problems that we all had to deal with. Right of us who used to actually directly F TPR files onto the server, dealing with cashing and all that stuff. You were wanna focus on solving your problems, not these common problems that everyone keeps solving over and over again. So to your point like services like neti and Algolia like helping you to abstract those problems away. So you can focus on, you know, solving your customer needs rather than these solutions that, you know, Algolia has done a wonderful job. Like we have such a great time using it on the view doc side, just to know that, like we don't have to come up with our own our solution for all our docs and we can focus on writing great docs. So we're really grateful to tools like Algolia.

Sarah Dayan: 6:43

So how do you actually decide what to support? Because Netlify is a universal platform. It's not tied to specific technology. How do you keep an eye on what's going on in the JAMstack ecosystem? More like I would even say like in the realm of website making, how do you keep an eye on that? What's your strategy around deciding, oh, that's actually interesting. It's getting traction. This may be not so much like what's the strategy around that.

Ben Hong: 7:10

So I think it's you bring up an excellent point, right? Think a running theme we'll see in this episode is that it's not about whether it's a jam stack, a specific technology, but it's a at how does it impact the web, right? Cause we're about shipping web applications. And so when it comes to deciding these technologies, so the NFI, we have an entire team devoted to developer experience. And so each of us does cover like specific areas. So we have Jason who came from like the Gasby community Cassidy who focuses on like the, sort of the reaction generic overall I cover view. And we have to, who does angular fill sort of more generic like JavaScript frameworks, like 11. And we have Kenny here also providing support because everyone's tapped into different ecosystems. We have the ability to kind of listen with our ear to the ground as far as what's going on. And like what kind of conversations are happening around the web? Because we were talking about it. Doesn't have to be JavaScript. Let's rust is making quite a bit noise right within the community as far as potential improvements. And so should one day there's like a really major rust framework that really helps to let people ship things faster. That's something we want to invest in because again, our goal is to get people to ship faster, right? As we know in software development, the more you can iterate on something at a, at an inexpensive way, the faster we are to make changes in improve to it. It's when you have the really long build times the TES that take 20 hours to run, those are the times where like people start being afraid to make change because the feedback loop is so long. And so I think these are some of the things we constantly look at, because again, if we're about shipping and iterating faster, then we gotta figure out, make sure we keep our ears to the ground. As far as those tools to invest in,

Sarah Dayan: 8:40

You actually brought up a really interesting point is that you have a developer experience team, like a fully dedicated to developer experience. And within that team. And I remember reading what your former VP, Sarah ner wrote. She wrote an interesting article on that, on the amplify blog, how this team is composed and you have within that, you have even people focused like you are on DX specifically in community aspects. And it looks like you have specialists on many facets, uh, of the JAMstack. And that to me is really fascinating. I'm wondering like, is this by design? Is this on purpose? Is this like part of a strategy or did it really just happen? Like it happened to that Nety had someone interested in react, had someone interested in view, had someone interested in angular, is it something like you make sure to keep to preserve so that you can have an ear and a, like a voice in every community on top of that? Like how does that help keeping the bar high across the board with everything you build at Alii?

Ben Hong: 9:42

I can't speak for, you know, Sarah's hiring practices at the time. But to me though, as far as like my impressions, it does seem keeping specialists in the different communities is something that was entirely intentional. Because if we think about it, like one of the things that's trickiest about think development is that when we get kind of used to a stack that we're comfortable working in that sometimes we forget to look outside the box and what other people are doing. Right. Because, you know, we talked about react, angular and view, for example, but felt obviously is making a lot of noise. And there's a lot of people who really love things about felt. And I think it would be a travesty for teams ignore that these up and coming frameworks because when people create new solutions, there obviously is a problem missing there, right. Or new ideas to play with recently, like ES build is starting to really become a thing, right. With tools like vs snow pack. If we were to just say that, oh, it's not that popular yet, but we ignore it. Like this is how I think companies or teams would miss the opportunity to like really innovate on their technology from that regard, I'd say it is good to have that to of diversity of opinions. So you can have people's perspectives to reflect on things. When you go like this is the perfect solution and that I've seen, but it's oftentimes they're catered to a certain customer with a certain kind of tech stack because a lot of us we talked about, right, we're just talking about JavaScript framework, but what about people in the WordPress ecosystem and other headless CMSs databases? And that's why part, part of our job too. It's also diversified the things that we learn about so that we can keep a broad perspective on tolling in the community.

Sarah Dayan: 11:04

That's actually, uh, an interesting point because you have a lot of people in your team who are really knowledgeable about the JavaScript ecosystem, like your part of the view core team. So obviously your team can rely on you on any thing, new or upcoming in view that should not be missed. Same for the Rya Gadsby, uh, next like Cassidy and Jason will be on top of that. Now, WordPress, like whatever anybody said, WordPress is still extremely present. Not only extremely present, powering a huge chunk of the web. They're really cool, interesting features that come out. Like it has a rest API for a while, but like the Gutenberg API keeps on improving et cetera, but you don't necessarily have someone who's a specialist on WordPress on the team. And so how do you manage to preserve great developer experience on stocks that you are not familiar with, that you don't have anybody who's specialized on that and who will have a natural appeal at keeping up with that community?

Ben Hong: 12:04

One of the things I really love about my team is that everyone here has a, a real appetite for learning and trying new things. And so while we've all become special list in our respective domains, for example, Jason has his learn with Jason show where he brings on new guests every week to talk about new tooling and that kind of thing. Um, we are encouraged by net LFI to go out and explore those things. And so, for example, whether it's working with the Shopify CMS and building things with new tools, a lot of us on the team use what we have as a base to then go out and just keep expand, ending on that knowledge. Because once again, I find that innovation often comes from the most unexpected places. And so I'm always eager to just see how are other people doing it, right? How are they thinking of these problems? And so whether it's building demos using, for example, like view with the headless WordPress, those are the kind of things we're given the freedom to explore because our team is trusted to figure out like what we think might be the most impactful within our given communities, as well as how it might also add up to on a larger scale as far as like impact for the web as a whole.

Sarah Dayan: 12:59

I can definitely recognize that at Algolia it's been definitely quite challenging, especially because we have many integrations. Like we have integrations with many different languages, frameworks, et cetera. And the more I think about it, the more I'm like DX should a shared responsibility. It's not like everything will be on the integration. Like there's common stuff. There's common logic, there's com common aspect that probably always need to be handled at a lower level. The more things you can shove into the part that you, anybody and everybody can share the better. Because when you think of about, let's say, okay, let's take gets beef. For example, what's important when you think about gets beef in the context of a service net, like Algolia Nety is that it should be the most Gadsby ask experience. That's the role of this aspect, like gets be this strategy, this part of the product, it should be about being the, the more, or gets BX experience for the person that's using it. Anything else should probably be at lower level. And so that, you know, that layering aspect to me is really core to the problem thinking in layers and making sure that every part is really responsible for what it is strong about, what matters about it. And that's not really just an engineering issue. It's really a, a product problem. It's how you design things. So every part solves the exact problem that it is going to be good

Ben Hong: 14:27

At. I think that's really important to highlight here is the DX team at LFI in particular is just one aspect of how we manage DX across the entire right. So my team specifically with Jason Casy, Tara, Phil, and Kenny, we represent a very specific team within Netlife I, as far as like community outreach. So, you know, obviously coming on and being able to talk with you, writing blog posts, creating content, as well as exploring and interacting with the communities, but we're not also solely responsible for DX across the company. We have integration teams who are responsible for like the engineering aspect of taking what the things we've learned about and bringing it back into the core product and figuring out how they can improve that. It's really important to highlight that there's a lot of teamwork going on and a lot of different teams involve in making net what it is

Sarah Dayan: 15:10

As a view Corps member. How have you witnessed that being a part of this community as whole so helped inject better DX at Nety and maybe vice versa. How maybe did you witness that your involvement at Netlify and being in that space? Like it's probably the most popular platform did help or did you witness it help when it comes to how you think of new features on view, on view, press on V press

Ben Hong: 15:39

My involvement with the view community, I think has been a mutually beneficial one. One of the things I really love about the view community is that it's always willing to learn from others, right? It doesn't try to reinvent the wheel. And it says when the framework does something, well, it tries to explore with that concept and figure out it does this solve the problem. Well, and so, for example, Evan's been playing lately with like a sugar ref, um, RFC right. Request for change, where it actually kind of mimics the felt syntax, which a lot of people find really weird, right? Cuz it's not traditional JavaScript. These are the kind of things that are great to think about because for technology to move forward, we have to be willing to try new things that might feel foreign because I think a lot of people, especially in tech now forget that like a lot of things you're familiar with with vanilla JavaScript, you know, quote unquote is actually things that came from the jQuery days. Like it was an external library that like they did such a good job with it. They made it part of the core. And so when libraries are trying new things, I think we have an inherent like, oh no, that's not the view way or the react way. Like to me, it's like if it solves a problem that helps to move the web forward, that is the more important thing rather than sort of being comfortable with like the one way of doing things. And so similarly, you know, in the Netlife I ecosystem, I, I am always really happy to learn how other people are doing things because one of the challenges that we have with deployment of websites is what happens when you are, when you wanna have long build times, how do we solve that problem? And so, you know, learning from the different architectures and thinking about how we can make a solution that works well across the web was one of those things where yeah, it's super exciting to see all the different solutions and try to piece together. What makes the most sense? I think that's what view I think I learned a lot from view it's like at extract away certain things, right? So example we have the template block, which is basically HTML, but there are a lot of people that are like, oh, well sometimes I really need programmatic HTML. I need, JSX great. We have a render function for you. But like in the 90% of use cases where you don't need a render function, just use HTML that I know that guy's a lot of the ethos, as far as my creation of tooling and solutions,

Sarah Dayan: 17:34

That's actually a really good segue to, to something that I wanted to ask you. Like, you briefly mentioned the way you build, you know, when you think about static side generation, especially when that's something that you are really familiar with, it may look like, oh, it's a solve problem, you know? Yeah. Okay. You're going to compile a website you're going push to get, and then you're going to specify what your bill command is. And then the directory in which the files are gonna be, and then that's it. But what I find really interesting is that it also means new problems. You know, like new patterns are starting to emerge. When you think of next JS, for example, they created what they call incremental static regeneration ISR. And the goal is to basically avoid long builds when you have large websites. So instead of recompiling everything, you are going to compile on demand, but such a feature. It is not just one new thing. It's also, it has implication. It has consequences on the infrastructure. And so I'm wondering because that might be an easy problem when all you focus on is next, it like it has its challenges. But on top of that, when you are Nefi, you are a universal platform, you need to cater to everybody including next JS, but not only when you have so a responsibility of catering to many communities, but you need to stay abstract enough. How do you keep up with those kinds of problems that need probably more tech than you initially intended for that problem?

Ben Hong: 19:04

You know, we're talking about long tail bills, right? So, you know, for the audience who might be new to this problem, imagine you have an e-commerce site, right? Like I say, it has thousands of items, but the truth is, is that maybe only like a hundred of your items are the ones that are kind of most frequently visited. And so with the traditional static site generation model, every time you build the site, you need to generate all thousand pages along with anything else that results. But at the same time, part of you probably also wonders, like, is that really necessary, right? Cause that result in long build times, which then as we talked about earlier, like that increased the amount of time it takes to get feedback, the concept being talked about here, um, which we're sort of terming like distributed persistent rendering is this idea that what if you could only build the files that you needed up front. So you, you marked these specific pages as like, these are the main ones that need to go immediately. And the, then in the future, if anyone requests anything that's like outside of that realm and we have the data for it, we will then generate those pages for you dynamically and then cash them according to that build. And so this is sort of another solution, like we're turning it on demand builders and net Lai. And so this is part of the challenge part, right? When we create solutions, we want them to be in a way that like solves everyone's problems, it's sort of a generic solution that applies to your framework regardless. And the reason that's important is because as we know, frameworks do come and go, we happen to be in kind of like a nice period where frameworks seem to be stabilizing, but we know that it doesn't take much in technology to have all of that disrupted and have the kind of the ecosystem switch. And so similarly to how we try to auto make deployment in a way that's like not specific to a specific framework, we wanna make sure that similarly, when you're trying to create these sort of architectural patterns that allow you to define core pages and then the ones that will be returned later, we wanted to think, how can we make it easier for framework authors and whatever framework come up in the future to also leverage these architectural models so that they can then take advantage of it without feeling like, oh, well this is the view way of rendering things versus like the react way of rendering things, right? We all know that at the end of the day, their webpages that are like, that's all the customer cares about. They get their HTML, their CSS and their Java as script. However, it gets there doesn't matter. So the more we can make that easier for people to do better. It is

Sarah Dayan: 21:13

You mentioned it, we're probably in a sweet spot right now because there, a lot of things are stable and there's more and more qualified people working on it. The experimentation is usually a bit more fruitful than it was back in the days where we're transitioning between the old way of doing, uh, making website or building JavaScript or anything in relationship to, to what we have today. Now, one thing to, to stress is that it is okay to take the time, to really find the right angle. Because when you think about ISR or DPR, like it's not just a new hot feature, it's one solution to a symptom of a bigger topic in gems stack four, for that matter, that's okay to take the time to really think about it from a higher level. We see it in Angolia every day. Like we have customers who are very specific requests and that's actually awesome, you know, because it gives us concrete application examples, but it doesn't mean that we have to jump on it and make it, or as is we can take the time, you know, to reflect and, you know, take a step back and think about it more holistically. And to me that makes sense. Like, that's really the role that you have when you built such platforms in a way like that was the initial idea, always network based APIs, right? We need access to a functionality. And regardless of what it is, in what language it's written, we just want to have access to that thing in a way that works for everything. And so then this abstraction came in and it powers a huge part of the web. Like you have web hooks, et cetera, all built on top of that. And that also what Algolia evolved to, uh, I don't know if you know the story, but we used to be a mobile, offline search engine. That was Algolia at the very beginning, it was running on your phone and now we are a rest API base. So we are able to actually power any kind of stack, anything that runs in a client can power Algolia I think when good takeaways that those problems that you see and those patterns, it can feel like, oh, that's the new thing I need to hop. Like, jump on that horse. It's actually really much more interesting to take a step back and to think broader, what is the actual problem? What are we trying to solve? And how can we build something that's sustainable? And that's probably, even if we don't know the future, that's probably going to span some future cases.

Ben Hong: 23:39

Yeah. I really love that this focus on the problem you're solving is something. I think that a lot of engineers often forget, right? When you have the latest hottest trend, why are you implementing this? Right? Why are you using static site generation? Right. Everyone says to do it, but like maybe it makes more sense for yours to be like just a single single page application. Right. I think people forget, right? Every engineering decision you make comes with trade offs. There's no perfect solution. Maybe it solves a problem in a perfect way, but it won't solve the same, like another problem in the same way. The other thing I think that's worth mentioning is you mentioned like, as these concepts come up, right, like we were talking about like DPR ISR, this stuff, it's kind of interesting because I think for engineers who have been in the space for a while, it feels like a lot of the stuff coming back is the way that it was used to be done, which is kind of interesting. Like a lot of front end theories are originating in backend. Like they're like, oh, backend did this years ago. And I think it's funny in the development culture of this need to like assign, oh, well this came from this, this came from this. But really if you ask me at the end of the day, are we solving problems? Are we moving forward? I think it's, that's much a much more fruitful discussion over of the whole like, well, the, you know, that this is actually just basically server side rendering. We've been doing this for 30 years. I prefer not to get into those sort of arguments with, with this kind of stuff.

Sarah Dayan: 24:55

That's a very human thing, you know, to try and draw connections between things that you think are the same, like, oh, there's the new thing. How does it relate to something that I already know? Like that's kind of re reassuring for you to be able to put it in the same box because that, that means that you probably don't have to learn it, but at the same time, what can be, as you said, more fruitful in the conversation is what kind of new problems are we solving? I say that it's, it's pretty, you reassuring that we are reusing work that has been developed a while ago would be probably sad to see that we are throwing everything and that all that work, that, all that research or that all that knowledge, all that technology is really gone. Like there is nothing left from it. There's a lot to learn from how things used to be done. Even before static side generation was a hot word, like before the Jack days, basically people used to statically generate some of their sites for security reasons. And back then, like most people thought they were crazy to do that because it was like, yeah, your website is not dynamic. Like, you know, to me, that's quite reassuring to go back to developers experience. That's the point of the, the conversation today is that you part of, to me, of the developer experience and having a good developer experience is to be able to reuse things that you already know is to be able to leverage the knowledge that you have. Not everybody comes in that space with the same baggage. Some people started react, developers. Some people started as WordPress developers, whatever, even not even developers. But what's interesting is that we can reuse prior arts to solve new problems. There are things that exist today that were not even a conversation back in the days, things like, and now of course like this is not a new problem, but when you think of stuff like responsive design, like I clearly remember that shift. There was a time where we didn't care at all about responsive web design. Nobody cared about it because nobody had a smartphone to where they wanted to look at a site. But today that's something like that's important. There are ways to think about that. But then the, I would say the more, the faster your computer is, you're probably less and less tolerant to performance lags. You know, you don't want anything to be slow when everything on your machine is, is really fast. And at the same time, you have people who can ha now I access the internet who couldn't before, but they're not doing it on the same devices that you and I are using. So those are new problems. Those, and they are not technical problems. They are human problems. Then they are around individuals, around people, existing information. That's what technology is here to bridge.

Ben Hong: 27:41

A lot of actually I think DX as well, all is about that incremental improvement. Right? I think we oftentimes forget that technology, when we evolve, we took older concepts, right? Like you said, static site, for those who like built, who used to ship via FDP, that was technically all static, right. If we were using the, the hot term, but really what we've done is like over time, we made it easier to do things that would've he to do. Right. Because those of us know that like when you deploy the same style that CSS filed multiple times, you have a weird caching thing, right? People don't get the same one. So what do we do? We started appending custom hashes to it. And so then this is why the build process started getting appended because we wanted it to make sure that we were deploying unique assets, that people could actually get the newest thing faster. Uh, and so a lot of times like your, I think to your point, Sarah, like when we take ideas that have existed and we can increment them by just like, you know, 1%, but we consistently make that 1% increase. I think we forget that that has a compounding effect over time. And that's one of the reasons why we are in a little bit of a stickier situation now with like build tools and stuff. Right. Cause people are like that. So complicated from where the way it used to be, but there are reasons why we needed this because the problems have advanced and they've gotten more trickier as we deal with your point new devices and all these things. It's a fun space to be in.

Sarah Dayan: 28:56

Definitely. Yes. On the last episode, uh, we had Adam more than with us from tailwind and I really liked the way that he summarized the X E. He said, basically that it is providing superpowers without getting in the way. I really love this definition. And again, when you are a generic service, like you, you amplify your Algolia, you care about many people, not a specific usage. You're not tied to specific technology. How do you achieve that? How do you provide superpowers without getting in the way? And especially it's easy, you know, to care about the hot things and to have some that are left behind. So how do you, for example, ensure that N users feel as catered for as Gadsby users and similarly that JCO users don't feel left behind

Ben Hong: 29:48

One of the nice things I think about, even though you're managing different frameworks, right? If you're running a tool that has like you're servicing different customers, is that typically the users aren't necessarily like they're not using Gatsby and nuts at the same time in those cases. Right. But at the same time, I think when people feel like you've created a good developer experience for them, it's about kind of like to Adam's point, right? You are giving them you're supercharging their past so that you can let them do something and then let them do it in a way that's not like as few configurations as possible. I think that's one of the key things to a lot of good developer experience for getting started. Right. Because if you knew that, like when you started the card, you had to like, press all these buttons before putting in your key and then turning it on, right? Like that's a lot of work. And so the more we can reduce the barrier of entry into tooling and then allow to incrementally grow on it. Right. This is one of the reason why, for example, the view community also starts you with templates because we wanna leverage what you already know with HTML. And then certainly when you have additional problems you wanna solve, then we can then give you the render functions. We can give you other things to make it better. And so with Netlify as well, like a lot of people, I think with their entry point, when Nety is like deploying their sites, right. Making it easy so that each and every time you push a commit or you add a new branch that it creates those deploy previews for you and makes it so easy to integrate. Like, all you do is hook up your GitHub, repo, like you said, to like define the customizations. And so, for example, like you were talking about framework experience, right? And so this is why when you hook up a repo with Alii, we try to detect in advance, which framework you're using. So we can automatically populate. Right? It's one less thing that you have to go into your package, that out JSON to figure out what's your build command. And then like, we automatically populate for that for you, so that you can then ship it and then see how that goes. And then once you're there, then you can start being like, okay, now that everything's deploying really smoothly, I can start thinking about things like, how do I want my red RXs to be, or maybe we start integrating serverless functions into our application to make things easier and like on unlock a whole world of possibilities. That's really, the key is making people feel comfortable in the space that you're in so that they can then feel basically confident enough to then take that next step.

Sarah Dayan: 31:53

All right. And so for our question would be, how does that scale? So many different platforms, so many different solutions, you can create a JAMstack website with different languages, different frameworks. How does that scale, how do you make sure that you can keep up with a wide variety, uh, of

Ben Hong: 32:11

Tools? Nice thing about, especially the way that nullify has architected, it is that, you know, with technology, it becomes, luckily our build tools, aren't changing that quickly, that we need things to be every day. And so, as a result, we basically have a manifest and we figure out what the highest impact is as far as the sites that we see people trying to deploy with. And this is also why it's really important to be in touch with their community, right? Because you might have a lens as far as like your analytics and your metrics, but if you're actually listening to what the community is talking about, a lot of times, that'll let you get ahead of things. As far as like, this is a new framework that's coming up, that people are trying out. And so that might be a job, for example, my team, to go and build some test deployments and figure out how do those demos work in relation to our current workflow. And are there things we can learn and improve as far as that goes?

Sarah Dayan: 32:51

Yeah, that that's really interesting. And I think it's also, it's, uh, highlights kind of a hybrid role that is starting to grow and we call it developer advocate. But that term is really loaded. And in the mind of, of different people, it means different things. But I think there's something really interesting in having actual ICS, like people really building the tooling, building the production software, also being in the community and being involved and being around people and discussing with people. To me, the, the developer advocacy realm is really much bigger than what we have in mind for, for, from maybe five years ago. But that really outlines the necessity for engineers to be much more product oriented, which is actually really exciting, especially when you're building for developers, which is what we both do. We're building tooling for other developers. You are kind of your own customer. Like you're supposed to be interested in those problems because they are the problems that you want to solve for yourself. And it is much more interesting to be in touch with the community in touch with the actual concerns that that people have, because it's going to make you a better developer. You have, it's so much more interesting that when you can have an impact on the roadmap, when you are able to say, Hey, you know, that thing is really what we should be looking at right now, because when you are on the field, that's something you can see, people are into that. And if we don't do that, we're gonna use the train

Ben Hong: 34:24

To build on what you were saying. I think this is what I think is what I really love about what Sarah did with the team and what I'd love to see more companies do is like with developer experience to allow them the opportunity to be basically hybrid engineers, as well as advocates, cuz I know that's so I think that's a lot of the topic of discussion around this right now is that to your point, if you're not helping to build the product that you're helping to advocate for, it's kind of a weird separation, right? It, it actually synergizes really well when your advocates are also involved in product discussions. And Sarah did a really great job as far as helping to ensure that the net DX team has that like has a voice in the engineering department as well as is in product. And just sort of having that all around.

Sarah Dayan: 35:04

I can confirm even from the outside that Netflix, I is really the, probably the model for that. Like there is such a really great grasp at community in this company and we can see it from the outside. That's really amazing. Like the, the work you've done with the, the DX team is really incredible. I have one question for you, specif is I'm going to put you on the spot with that. How do you specifically as a person, how do you define great DX? What is your level of expectation?

Ben Hong: 35:33

All right. So to me, great developer experience is striking that balance between abstracting away a problem that people have consistently while leveraging models that they already have up to a point where it's the Preto principle of where for 20% of effort you get 80% of impact, right? I think this is where people feel really excited to keep continuing with a tool. How ever, I think there comes a point where it becomes overly opinionated and when people need to break out of it, if you've locked themselves in too much, then this is where I think people do have the bad experience of like, you know, it was great at first. And then by the time I got in, and then I had a problem that I needed to customize, it was like a nightmare to get out of it. To me, that's not good to DX. It just means that you've solved one particular path. And then you are like, good luck after that. Right? Like, you know, if you did it my way, then you're great, but the moment you wanna do it a different way. Like to me, that's not necessarily good DX. That's, that's a really strong opinion. And then, so this is why I think the other half of DX comes with the allowing people a way to then customize how they do things from there. So I, I like to call'em escape hatches. The more you can allow people to do that, I think the, the better you get to a point where you really do allow people to kind of customize the solution to really their own. For example, most of us don't wanna be solving cashing problems, right? Like that's a problem. Most we just wanna build, develop. And we, as long as the customer gets what we like the latest and greatest, we are happy. We don't need to know, you know, which caching methodology is being used, like security protocols. How many of us wanna be dealing with authentication managing those are things you do kind of wanna abstract away. And those, I would say are great examples of where it might not necessarily make sense for you to allow someone to customize security credentials, because that has a big foot gun. Right? And so for those who are, aren't familiar with the term, just like ways for people, for developers to make MIS stakes, that they can't come back from. So it really is a delicate balance of like providing enough opinion so that they feel empower to get started escape hatchers to customize it. But then also like considering the foot guns of where, well, if we give developers this much power to customize, they might end up breaking things or they might end up like doing things that harm their customers, leaking sensitive data, that kind of stuff in that case, let's shield them. Right. And so, and as we mentioned before, earlier in this show, there are always trade offs, right? Like to some extent you can always abstract things. To some extent you can allow customization, but Maning those trade offs for your customers and listening to your community, I think will be the key in striking that solid DX for your audience.

Sarah Dayan: 37:58

The, I, I really, you love with everything that you just said, and I think that's, uh, that's really a perfect point, uh, to wrap onto Ben, where can people go to find you online?

Ben Hong: 38:08

Yeah. You can find me under the moniker, Ben code Zen. And so whether it's Twitter, YouTube, Twitch, I think I've got a handle on, I think I've got most of the platforms luckily. And so if you're looking for me on whatever reply from them on you just find me at www dot Ben code, zen.io, and you'll find all my stuff there.

Sarah Dayan: 38:26

All right. And so you can find me at front stuff underscore IO on Twitter. If you're looking for Algolia stuff, it would be on@algoaontwitterandyoucanfindusonalgolia.com. Ben, thank you so much for coming. Thanks so much. It's been great. 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 out@agoya.com and we are at Algolia on Twitter.