Developer Experience

Fostering Developer Collaboration in a Remote World - Ives Van Hoorne (CodeSandbox)

• Algolia • Season 1 • Episode 5

Share episode

On today's episode, we're going to talk about fostering developer collaboration in a remote world. This is a special edition because Sarah Dayan is joined for the first time by her new co-host Bryan Robinson, Senior Developer Advocate at Algolia. 

Working remotely is not something new, especially in the tech industry, but since the beginning of the pandemic in 2019, there has been a wave of tech workers going remote. First it was by necessity, and then by choice. So how do you collaborate when your coworkers are not in the same room, not in the same city, country or even continent? How did it change our processes and our tools?

Our guest today is Ives Van Hoorne, creator of CodeSandbox. CodeSandbox is the most advanced cloud-based sandbox environment that lets developers quickly start and share prototypes, but also collaborate on projects, provide bug reproductions, and all of that in the browser.


Ives van Hoorne:

And we'd never thought about making code development more easy to learn, but that became our most important part. After that, after seeing even we had, uh, some children using code Sams to learn, and that was, that felt pretty crazy. And that was super cool to see.

Sarah Dayan:

Hi everyone, and welcome to developer experience a podcast by Algolia. We chat with guests who build products for developers about their developer experience, strategy, what it means for them, why it's important. And so on I'm Sara Deon today, we are doing a special episode. Not only because we have an I'm guest once more, but because I'm joined by my new co-host Bryan. Hello, Bryan.

Bryan Robinson:

Hey Sarah. How's it going?

Sarah Dayan:

I'm going great. Thank you. Can you briefly introduce you for listeners? Don't know you

Bryan Robinson:

Sure. So I'm Bryan Robinson. I am a senior developer advocate here at Algolia. I've been doing some form of web design development for about 15 years, but lot of that time was specified around user experience. Uh, so when I finally joined the ranks of developer advocates, it was kind of a natural progression to keep thinking about UX, but for my favorite group of users, developers.

Sarah Dayan:

Awesome. And so in today's episode, we are going to talk about fostering developer collaboration in a remote world. So working is not something new, especially in the tech industry, but since the beginning of the pandemic in 2019, there's been a wave of tech workers going remote first. It was by necessity and then by choice. So how do you collaborate when your coworkers are not in the same room? Not at the same city country are even continent. How did it change our processes and our tools? So our guest today to talk about that is Ives van Hoorne creator of code sandbox code sandbox is the most advanced cloud based sandbox environment that lets developers quickly start and share prototypes, but also collaborate on projects, provide bug reproductions. And all of that in the browser code sandbox is used at organizations like Atlasian Shopify strive, Microsoft and ourselves. We are big code sandbox users at Algolia hello, if

Ives van Hoorne:

Hello, good, uh, app new or morning.

Sarah Dayan:

So first off, I want to say congratulations for your involvement in the beta react documentation. So we are recording this on Monday 25th of October, and the new react docs just shipped in beta and so congrats to the, the react team first off. But what I've seen is that they're using those really fabulous embedded interactive send boxes using send pack, and Sendak is the browser bundler, that powers code sandbox. So can you tell us a bit more about this collaboration, how it went, what was your involvement?

Ives van Hoorne:

Yeah, the new react documentation. It looks super, super nice. It's funny because it's been a dream of me and I think of some others since coach SIM started, uh, it was a dream that we could go to the react documentation. And it's funny because when the react documentation was released a couple of years ago, we already were talking about, oh, wouldn't it be cool if we could have code sandbox in that react documentation. So it's been a dream for a long time and it's super nice to now see it come to life. And the, the collaboration started off because the react team was working on, uh, the new documentation, the new project, and they've been working on it for a long time, put a lot of love in it. They have rewritten. Well, I think they've gone through multiple many iterations before they, uh, released this one, but they were also looking at how to use interactive codes in their documentation. Because being able to play with codes is one of the most important ways to learn for a lot of people. If you see something and you can immediate type in it and see it update life, then you immediately get that a powerful feeling. You feel empowered in, uh, in some way. And so they were looking okay, how can we maximally utilize this interactive code? They were, I think the reacting was already using, they are already using codes, inbox, uh, quite a bit. So they went to us and we had been working on a project called send for a while. It's a project that has been released, I think, unofficially a couple years ago. And then we put it on the shelf for a while, but this was for us, the perfect moment, Tove it. So to say, and send back essentially is what code sandbox uses. Uh, so code sandboxes is online code that it, where you have code on the left and a preview on the right. And when you change codes, the preview updates. And the interesting thing is that we execute all codes in the browser. So we have this in browser, JavaScript Butler or compiler and sent back is essentially that we took the existing bundler and put it in a library. And with that, we wrote a, some component that allow you to create your own playgrounds, because that was the real thing that the react team needed. They wanted to have something so specific for their experience, that they should be able to completely customize it. And this is why we started sent back again, because now we have sent back, you can create your own components. You can create your own code editor. You can at your own file, explore. You're gonna create your own tap system, even your own preview, but the library provides you a hook that will allow you to execute the code and give you the results back. And this allows the react team to really create a customized experience using the bundler of codes and books. And well, that was super interesting because with this is just one implement, you know, send back, but you can use it for so many things you can, for example, the be rep could use it to show transpo codes on the rights, or if you're building a website where students can, uh, go through courses, you could use, send back to create these step by step processes. It even has just support. So it can run unit tests. So you can even evaluate, you can give like tests to students, and then you can use sent back to evaluate whether their code was written correctly and all the tests best. So yeah, probably a long description of sent back, but it's been a labor of love. I have only started it. We've had many people, uh, within code and working on sand back. And it's really nice to now see a practical implementation of sand back in the react documentation.

Sarah Dayan:

Yeah. I, I think it's really interesting to see because at the, at the core of it, it's still code sandbox running and in your code is still running in code sandbox. It's not every, everything is shipped in your side, but you control the experience. And I really love that. Now, as you were saying, bubble could use it for the rep or maybe pre or could, could use it for the re and it's removing so much friction. Like there are so many cool ideas that I feel go in the trash because thet is not staffed enough or we don't have time. And now, yeah, you can have great search. You can have great code snippets that actually run because people who are specialized on that task who have dedicated their career to making that better are at least a piece of their career to making that better now provide those awesome tools. And, and I think what's really interesting is that we're at a stage in web where we can do so many things like a webpage can be so dynamic, but still we have blogs and documentations that are basically text images and that's it. And maybe sometimes videos and so sad that we have such a vibrant ecosystem of tools and that we still don't have those pieces of content that could be so much richer when you add something where they can play with it. And so I'm really glad to see all those tools emerge and, and definitely for document. It definitely gave us ideas, Al Goya, just looking at that. And I find it beautiful that you're not restricted to, it's either an eye frame and you don't control anything, or it's gonna be a custom component and it's gonna be six month of your time. And you're gonna even come close to what code send box is.

Ives van Hoorne:

I agree. I think that there are, like you said, there are a lot of ideas probably thrown out the window because the implementation seems too daunting or is too daunting to do. And with a library like this, if someone has an idea to, for example, maybe there, there are even better ways to teach. Maybe something new will come up where there's a different type editorial, maybe even where people can help each other live, where maybe there is a way for universities, for example, to teach in a different way where you have a physical classroom, not a physical, but a virtual classroom. And, uh, the teacher can jump into different code snippets and help students. Well, these are all interesting ideas that are now easier to explore because you can use, send back to execute the codes. And another nice thing is that we even have the option for you to self-host send back. So even if code send books would go down, for example, your examples will still work and well I'm, I'm very much looking forward. It's similar to how code send got started. When we started building code send books, we had one big use case in mind with a sub couple of sub use cases. And people used it for so many other use cases that we didn't expect. And I'm hoping that with sent it will be the same thing that people will use send for that we never have imagined when we started, uh, working on sand spec and will make it easier for other people to get introduced, to coding or get more familiar with certain libraries or frameworks or well, anything.

Sarah Dayan:

Yeah. And, and you said it like code sandbox started from a simple, but powerful idea was like putting the main tool of a developer, which is, is basically their IDE with the terminal in the browser so that they can build and share their ideas easily. And Algolia, especially in my team where we're doing, uh, frontend libraries, we are big code sandbox users. We use it for demos. We use it for bug reproduction. We use it for proof of concepts. And we also use it for direct collaboration. For example, early this year, we shipped a new search experience in the Algolia docs, but the development work of that started six months before in code sandbox. It was like between three people in three different French cities. And we were using zoom and code sandbox live, and that's where it all. And without such a tool, we would've been like screen sharing a local environment where one person would be coding and we would be pushing and pulling a temp repo. And they were just working together alive in the browser. So like, it's not just a small, handy feature. It's like a massive leap in developer experience. And for us, it removes so much friction, especially when we're early in the project, we're ideating you don't want to get anything in the way when you're just like spouting ideas. So I'm really interested. Like how did you see people use code sandbox over the years? Like ways you did not imagine, and how did it shape the product direction?

Ives van Hoorne:

So code sand started with the idea that the JavaScript community in particular is very collaborative. People share a lot of work, but at the time people shared it in through GitHub repositories. And while I was at work, I was at work as a web developer at an auction website. I was on vacation at some point, and I got questions for my coworkers about pieces of codes. And I couldn't really answer those questions because they just sent me snippets on slack. They sent me get the prepository files and I couldn't run the codes. And that's when the idea came up. That would be interesting. So code sandbox was built around that idea. We should make it easier for people to share their codes with the environment, instead of only sharing like the static codes actually make it come to life by also running the codes and giving these intelligence on top of it. And that's the I first idea of codes. And I didn't do much with that idea until I started actually going to university some point, I started feeling unproductive and I thought, okay, this is a nice side project to work on. And Goem at the time has gone through so many iterations. It's first started as this react component editor. Then it became a place where people could write MPM libraries. Then it became a place where people could publish online MPM libraries. And it's really funny because at this point you see none of that back in code sandbox right now, code send is an online code edit there. And it has gone through so many iterations before it really became the code sandbox. It is today. And that was a, and that was a big learning for me. That code SIM started with a very different idea from what it is today. And I see many people with, they have an idea, but then they say, I'm not gonna work on it because the idea doesn't sound right. It doesn't sound like a good idea, but I think the only way to get really to a great idea is to start working on the idea and to refine it, not holds the hold, the idea too close to heart, be able to be flexible. And, uh, that's what happened with coach Sam. It was a very different idea year when it started. And when it finally was released, it had gone through so many transformations that it had a completely different idea behind it. And the funny thing is that when we released code sandbox, people used it for ways that we never imagined. We initially built code sandbox as a way for people to very easily collaborate. But then for example, people started to use it to learn how to code, because makes sense. If you want to learn how to code, you don't want to learn how a terminal works, how test work, how bundling works, how WebEx at the time, uh, worked then, uh, you just want to press a button and have an environment for your set. So code cinema started to be used by people who want to learn, how to code start to be used for workshops. It started to be used for documentation, and we'd never thought about making code development more easy to learn, but that became our most important part. After that, after seeing even we had, uh, some children U using code Sam learn, and that was, that felt pretty crazy. And that was super cool to see. So code SIM started to really make collaboration between cohorts more easy. And then we saw the new use cases that code sandbox enabled. And then we changed our prioritization to make development also more accessible. So we have for code SIM, we have that we want to make more accessible. That's the most important part because development is only becoming more and more important. And the second part is that we want to enable collaboration. So the humbling thing of this is that I think you can never know how people will use what you build. Like it's so hard to predict what people get as value from something. The only way to know is to release it and to essentially release fast, because you can build in so many assumptions. But the only way that you'll know is when actually people start using it. And we've, we've gone into that trap with code sandbox, because we got very demotivated around January, 2017 with code sandbox. It was already kind of finished. Uh, we still wanted to build a lot of features, but we thought, okay, well, most of it is done and we stopped working on it. And then at some point I showed it to friends and they were much more enthusiastic than I was expecting. They said that it looked awesome and that they wanted to use it. And I thought to myself, but this is just the basic version of code sandbox. We can't even publish to MPM yet. We can't even import sandbox in other sandboxes, all features, which, which I thought were essential to code sandbox, but they told me that they found it awesome already. So at that point we decided, okay, we're gonna build code sandbox as much as, as far as we can, but April 1st is the deadline. And if there are any features unfinished on April 1st, we would drop those features. And it's funny because one of those features was MPM publishing that was dropped. And we released in it on April 2nd, actually. And it started growing and it became suddenly it became, it became more popular than we were expecting with the feature set with code at the time. And that was so interesting. And it started to be used for bug reports, never expected that started to be used for hiring, never expected that either prototyping that we did expect actually, but there were plethora of use cases that we didn't think of. So yeah, I think the most important is that you have to release fast. You have to get as much feedback feedback as possible because you can't predict what people can use it for and you have to evolve an idea. Let the idea evolve. If you think of an idea and you think it's not perfect, that's not a problem because you will have enough chance to refine it as you work on the idea.

Bryan Robinson:

I never expected code sandbox to have an origin story that was collaboration focused. It feels very much like this online editor that makes it really easy for newbies and, and like people to kind of get up and running. But you kind of, you kind of mentioned you pivoted to go towards that, that new and educational focus, but then one of the first features that really kind of took off was that MPM package publishing, that's not a newbie friendly thing. So how do you kind of prioritize and know what features are gonna be good for the collaboration set versus the education set and prioritize those accordingly

Ives van Hoorne:

Prioritization? It's really, it's really an art. I don't think I can give a perfect answer. Um, it's the most important thing I think is that, well, you have a lot of different inputs. You have people giving feedback, how much feedback you get. So for example, we had one feature at some point that got by far the most thumbs up, and then, you know, okay, this is probably interesting. And you have, uh, data on how people use product that is also very valuable because you know exactly what feature is never used and what feature is used at done. And if one feature, for example, if the MPM dependency installing feature is used a lot, then we know, okay, that's something that we can very much improve. And then you also have your own hus, just thinking of the stories of how people use code, send books, talking with people and hearing how they, what, what kind of things they use it for. That's also very valuable, but even with all that information, you can reliably reliably predict what's to work on. And that's why it's very important to have a very fast iteration cycle. And it fits very much into the release fast idea that when you have a hunch go immediately for the smallest MVP possible of it, like what is the smallest thing that we can release to be able to test whether it works and release it. And ideally that only takes like one or two weeks to, to build that is why the iteration cycle is by far the most important thing for projects and companies, because then you'll not get information and then you either drop it or you continue working on it. So, yeah, I, I think these three things, the data, the feedback from people on what they, what they are asking for and knowing how people, user stories of how people use your product, those are the most important things to really think about when deciding what to work on first. But even that is not a birth picture. You still have to make sure that you build it super fast so that you can get feedback as soon as possible so that, you know, if it's worth, uh, investing more time in

Sarah Dayan:

One thing I find really interesting is also to, to look at the opportunities that are unlocked by technology arriving at a certain stage, because code send is really like leveraging the fact that we have more powerful, full featured browsers and more powerful machines like coat sandbox would not have been possible 10 years or 15 years ago. And I think that's really interesting if you make a parallel with, uh, cinema, for example, the French new wave was possible because, uh, technologically, we had cameras that were like, you basically, you could film outside. And that's what generated such like a, a stream of, of movies of a certain kind and influenced like overseas. I find it really interesting to see all the tools that now that are really web based and like web heavy, you can like Figma, like Figma is really a, a really great example of that. Or I don't remember his last name, but Sid, uh, Sid a, I think is building UI dev tools. So you can like change your tailwind component, like react, build with tailwind components in the browser with the UI dev tools and all those services that are slowly but surely migrating to the cloud. And you can do everything from your browser. And I find it really interesting how technology will also change people's minds. I started in web in 2005, like, uh, as a kid, I was working in 2005 and it was like, of course you wanted to have some kind of a DUI. It was local and you installed it on your computer, but of course you wanted that because it's more fun. And then there was a wave of, no, you are gonna use your terminal. You're gonna use an editor. You're gonna just edit text because you want be, uh, in troll. And then we threw a lot of tools out of the window. And now we're moving again to tools that feel a lot more user friendly. We don't want to have to install anything. Basically we don't wanna store anything on our computers. We just wanna work in the cloud with things that are already abstracted away where all the complexities abstract. So I find interesting how, like there's change of hearts in the community, like regarding what we want to use and what we like. And what we say is the thing at a given moment also because technologically, we are able to do that.

Ives van Hoorne:

Yeah, I agree. I can very much relate through the, the story of having using UI tools to build things. And then that all being thrown away. That's something, I think that's such a big shape. I got introduced to web development through dream Weaver, and I got introduced to development in general, through visual basic. And what these tools both in common is that they have a UI component to it. They have a UI where you can build your own UI, and then you can sprinkle logic on top of that UI by double click on elements, writing a bit of codes. And I think that made development in general, much more accessible to get started with because you have something that, you know, which is a UI that you can use, then that's your stable ground. And from there on you venture into the unknown ground, which is code, and you can link those two, just so that is super, super, super valuable. And it's such a shame that, that it was removed essentially. Well, not of removed, but it's not the default anymore. So this is also one of the most important things that with codes we're working on by putting the development environment in the browser or in the cloud, you don't need to install a development environment locally anymore. And with that, we want to make it more accessible and more easy for, um, for example, designers to be involved, let's say I'm a developer, I'm working on a UI component. I'm implementing the design. Now with coach ox, I can actually share a link with the designer and designer can see live, what I'm working on. So they don't have to install any development tooling anymore to actually see what I'm working on. So that is step one that is already such a huge step forward because now, uh, development is not this walled garden anymore. Uh, it's not this, it's not this siloed thing away, but other people can be introduced to the, um, the same environment. That's a huge part already. And the later step and the next step of code sandbox, uh, that we're working on at code sandbox is also making it possible for designers, for example, to make changes of marketing. So we introduce a bit of load, uh, low codes, uh, tooling on top of it, a bit, bit of no code tooling on top of it. And, uh, um, that is one of the, that is, that is something that's, uh, future music for code sun, but that is in the end, our goal. Cuz if you, for example, look at, look at Figma. For example, before Figma, you had design tooling and with those design tooling, you had files and you would share those files with other people. You would either use Dropbox, you would use slack, you would use email didn't really matter. It was still file sharing and developers, project managers weren't as involved with the design process because they didn't have sketch or Photoshop installed. So they wouldn't be able to give very easy feedback. They had to ask for a JAK or a P and G or something to actually see what a designer was working on. Now, when you go to Figma, I once heard somewhere. I'm not sure, uh, when or where, but I believe that more than half of Figma user are non designers, just people giving feedback, people being actually introduced into the design process. And because of this, the feedback loop is so much faster. You don't have to wait for the tickets on the cambe board to go to in review to then give feedback and have it move back to in progress. You can actually, throughout the pro process, you can give feedback it. If a designer wants to know something very quickly from an engineer or from a developer, they can just share a link with them. They can open it, they can immediately see what's wor what's working and they can immediately give their feedback. And that is so valuable. I think it allows you to create much faster and it also introduces developers more to design. Maybe I can imagine that there would be developers that have, um, that have gotten interest in design because it's now much easier to get started with it. I think that we can also do something like this with development, if we can make it possible to share the environment with a link and if we can make it possible, uh, to very easily give feedback in that environment. And if we even can make it possible for a designer to, for example, tweak styles through a UI, without having to know how to code, we can even use that opportunity to teach them how to code. We can show to the designer, if you change this little, uh, UI, then this code will change in this way and they can then see based on how the code changes, how code maps to UI. Um, I think there's a lot of opportunity there and that's really what coach sandbox is about. Um, um, I think a big inspiration there is Brett Victor, um, uh, inventing on principle. Um, there is so much where that he, he shows, uh, his talks are so great. All his talks are great, but what he is saying, actually, it's pretty crazy to think that to update styles, we have to write codes because it doesn't map as easily. We have to, as developers, we now had to in our heads find that mapping, create that mapping. And then, okay, now it makes sense. If you write display flex, it will do this. Um, but for many people it's not as obvious. And I think that's for example, uh, I, when you learn, for example, tailwind, tailwind is super nice. It makes it so much easier too, right UI, but you also had this hurdle at the start you had to, you had to memorize the, the different and uh, class names that you could use. Um, and I can imagine that a lot of people first have to learn to use this, but then also have to learn all these tricks to get their visual design well, what they want to have in the visual, uh, way. And it is possible. It is possible to create low code, no code tooling to make it much easier to, um, to change UI. For example, framer is a design tool, but what they have done, for example, they have a component called the stack component and the stack component essentially allows you to put elements in it. And these elements will then be rendered next to each other or, uh, one up and the other, uh, down below. And the funny thing is that a stack component is essentially is just flex box and you can change some, uh, properties of that stack component and you can then change whether it should be next to each other or whether it should align on the Y axis, whether it should be, uh, centered, but under the hoods, they actually just vendor CSS with display flex. So that is one prime example of how you can, for example, make flex, uh, a more accessible thing. Well, I went, went a bit on a tangent. I don't know even how the first, uh, what the question was, but I think that there's so much opportunity in making development more accessible and more collaborative, not even, not only through between developers, but even through marketing design developments. So yeah,

Bryan Robinson:

I love this idea of, of collaboration, not just between developers. Uh, it, once upon a time in a past life, I led a design team. And I remember a time when we sat down, we were gonna teach the design team a little bit about SAS, you know, SCSS and, and the first step that our Beely did was all right, we need to make sure we have node installed on your computer. All right, now we have to have this installed on your computer and, and you could just see the designer's eyes plays over. And so when it came to it doing QA against designs, I would go into dev tools and like, you know, adjust things and get the developers, the exact values that I wanted for everything. But the other designers couldn't do that, but having some sort of visual, or like you said, low code or no code where they can specify some values and see it in real time, we've got things like VBU, you know, for, for browser based stuff, but that's still a step removed from the code base. You still have to like share that and insert it. But if we had something like that in say a code sandbox type environment that can be inserted into a GI repo and, and basically we're off to the races.

Ives van Hoorne:

Uh, yeah, exactly. Exactly. Yeah. That's, that's a, exactly what we want to do, uh, with codes and books. We first want to make it accessible. What we first wanna make both possible for designers to see what you're working on next step is that we can make it possible for designers to change styling. Um, but we update the codes underneath. So instead of having to then copy paste values and send them to developers, uh, they can actually open a pool request. And that's interesting because that means that we also have to make, get more accessible. We need to make it easy for a designer, for example, to open a pool request on top of another pool request or to open request on top of Maine. But I think it's possible because if you look at the core flows of, of, um, of kids, um, it's creating a commit. Well, first of all, creating a branch, creating a commit and opening a politic quest. If we can simplify that flow a lot, then I think we can also even make it possible for, to open port quests as suggestions to, uh, existing port quests. And then it becomes really interesting because especially now that we're working in a remote world where sometimes there is a huge time zone difference between people, every loop, every cycle of communication is very costly. So if a developer asks for feedback from a design, the designer checks eight hours later and says, oh no, this color needs to be blue instead of green. And then eight hours later, the developer implements it and asks the designer again for feedback, eight hours later, you already have so many, so many time spent on just back and forth. But if the designer could immediately come back to the saying, okay, now this button should actually be, uh, blue instead of green. And they can immediately also open a little pull request to it. Then you eliminated, I think, two, two parts of the communication there. And that would save so much time also on the product duration itself.

Sarah Dayan:

Yeah. Like having, having worked in docs, same for technical, right? Like it, there is a lot of value in like content in a single place and, and using systems like GI or using repositories in general. Like it's really helpful, but the whole processes around it is really a nightmare. And I think it's great that we start also, um, that we stop looking at it. Like it's a pride that, oh, I master GI or I understand code like the, the, it's not a medal. There's nothing to be proud of. Like, it's great if you, if you're able to, to deliver great solutions to solve problems, but ultimately, uh, there, there's no pride in understanding a cryptic tool that the rest of humanity does not understand. And, and you know, like listeners, if you don't agree, you can look it up. But the average person learns by example. Uh, maybe it, it's not the case for everybody, but the average person learns by example, it's a lot easier to learn from something that you see, you can touch, like with your own sensitive is done, trying to understand from something very abstract and, and Bryan, you, you outlined it really well when you look at any language or tool and you see that you have to install whatever thing that you've never heard about. Like, I know that if I was not already in love with, with, with the field and tech in general, I'd be like, you know what, I, I don't have time for this and I don't have time. And I don't have the curiosity because the reward, uh, is not there. Like I'm aware of the rewards because I've been in the field, but if you're just start starting out and you don't have that patience and you, and you don't have that curiosity that comes with time, then there's no way that you're gonna invest your time into like jumping through all the hoops. I think that's a really important point that it enables co collaboration with not only like other developers at already the same level as you, and who are already willing to, to jump through those hoops, but other people who might benefit from the underlying systems that are actually really solid.

Ives van Hoorne:

I agree. I think that's, and we've been talking now mostly about designers, but there are so many other roles within the company. So for example, what if you could make it possible to, to write content and maybe underneath it's, uh, in visual way, and maybe underneath it changes, adjacent file or an MDX file or an MD file. But if you can make that process visual, then suddenly you make it also possible for other people to work on top of kits. And I think get itself, you is very powerful. It's a very powerful tool and it allows, and it's also a nice I way because it allows people to really integrate with anything. It allows people to integrate with GitHub, have these hooks on top of it, or it allows people to integrate with any kind of code editor, but GI is very cryptic. It's, it's, it's not, it's not intuitive. So if you can build an intuitive layer on top of GIS, while still retaining the power of GIS keeping making, and having the possibility to tap into the existing ecosystem that already revolves around GIS. I think that is a very interesting challenge, but a very worth it's a very worthwhile challenge too, too, because it's only, it enables other people besides developers who went through the hoops to learn gifts, to also contribute to a code base.

Sarah Dayan:

So that's actually a really good segue to, to my next question. Like another big aspect for me of collaboration. Uh isn't, it's not just with your teammates, it's with users and as a library maintainer, uh, an important part of my day is to help out users to interact with people that I don't work with directly. So you're investigating tickets, you're solving issues, et cetera, and Algolia specifically, but in many other, like I know tailwind uses code sandbox. A lot for that, uh, code sandbox has become really central to, to the process. Like we, we can ask, uh, users to provide issuer productions as code sandbox, you know, and they don't even have to come up with it. We can provide them with starters that we have in GitHub and they can open it directly in code sandbox, but also, and that might be my favorite feature. And you know, it, because I tweeted that at you, if you've set up code sandbox CI in your project and you open a poor request, and in that poor request, you reference an issue that has a reproduction sandbox in it, then code sandbox will act it, and it will rebuild the sandbox with your changes in it. And this removes so much friction for users, for maintainers, for reviewers, anybody participating in, in the CI process. Because, you know, when I see that notification that, oh, there is a new commit or a new thing. If I know beforehand that I will have to clone it locally to try and see if it works and build a thing, maybe I'm gonna think, eh, you know what, I'll check this out in three hours because I'm, I'm focused right now. And I don't want it to take an hour to do that. But if I know for a fact that it's gonna take five minutes and I'm, it's not gonna break my concentration, then it makes the process a lot smoother for everybody. And you don't have people waiting for me, uh, to, to take action. So ultimately it's better for collaboration. It's better for UX in general. So I I'd love to know, like, if you can tell us a bit more about code sandbox, CI what it is and what, what are the, the goals to, to help out library maintainers.

Ives van Hoorne:

Yeah. What you mentioned there is also a very interesting point that if you reduce the feedback loop, and if you reduce the friction to build something, then the, I think that the quality of what you're building goes up as well, because you have more iterations that you can spend on something. But also there are just things that sometimes are super, super, super small. Like someone wants to have the margin, a couple pixels changed, or someone wants you to fix this little bug that happens in 10,000 cases. Sometimes I think that I notice this myself that if it's, uh, if it's trouble to, if I need to do a lot to fix it, then I think, okay, I postpone and postpone it until I didn't, until I forget about it. If you make it very easy, then these changes are until be fixed faster. So I think that's an interesting thing that even improve by improving the speed of the feedback loop and the iteration cycle. You will also be able to create a more high quality product doesn't matter what kind of product you're building well anyway, so to the original, uh, question, uh, of code CI another, uh, for code sandbox, when we released code sandbox, we didn't see the bug report case at all, never expected that bug reports would be a case where code sandbox would be used, um, until the author of react form by the time react, uh, Redux form. I think his name is Eric. He started to use it for bug reports and I was thinking, wow, that is genius. That is such a nice way to use, uh, sandboxes. And since then, it's become a really, really, really big use case. So when code sandbox just kept funding in 2019, um, we were thinking, okay, what is a very quick and nice way that we can give a lot of value to people using code sandbox? And we didn't want to change code sandbox itself because code sandbox was used for a lot of different use cases. And that's something that we really liked about code sandbox. So essentially we wanted to build a new service that you could use alongside code sandbox, but it would make code SIM more powerful for a certain type of use case. And that use case was open source maintaining. Um, we saw that code SIMIX was used a lot already by, uh, maintainers for bug reports. So we were thinking, okay, how can we make that flow more valuable? And we started to look at how maintainers used, uh, codes and books. And the general flow that we saw happening often is that as a library, maintainer, you ask in the issue. If someone can give you a codes and books reproducible, then you check that reproducible on code sand books, you see the bug and then you fix it. And then in the PR you referred your original issue, like fixes this issue. And once you verify that it works, then you merge it. And the issue is closed. That was one flow. The other flow is that someone opened so bug re report and they have a code sandbox in there. And that someone else fixes that issue and refers to the original issue as fixes this, in that case, one of the maintainers will have to get that code sandbox from the original issue in some way, install that new version of, uh, the PR and then verify that it works. So they will have to download the PR locally. And while for GitHub, that's even harder because if it's an outside maintainer, then you have to cl the repository separately. So that was the flows that we looked at. And then one immediate fix that we were thinking of is that every time you open a port request, we should build a new sandbox. We should create a new inbox. And with that MPM version of that port request directly installed, and that was one side to it. We should also make it possible for you to install that MPM version locally. So essentially what we built was a little MPM publishing tool that would, um, that would build your library for every port request. So that, and give you back a sandbox with the pre-install version of the library. And this is funny because at the start of this, uh, podcast, I was talking about the three different inputs. Uh, in this, we kind of only used one input. We, we neglected data, we neglected, uh, we neglected, uh, user request. We immediately just went for the user story. What is the user story? And how can we help that help with that? But this felt like such an valuable user story, such an effective user story that we started working on it. And we asked a react team if they wanted to use this. And the react team was also very excited about this. They gave us a lot of feedback as well. So we did, we did seek out feedback before finally releasing it, but when we released it, we saw more and more people using it. That was the, that was bit of how we built it, but we built it very quickly. I think in total, we were working on it for, uh, three weeks. And with even those little, with that little time, we were able to create a lot of, make it very valuable. So now if you open a port request, then we, and it mentions an existing issue like you mentioned. And, uh, we take that sandbox from the original issue, install the new version of the library from the port request. So that maintainers just have to open a sandbox to see if it's actually its the issue. And the other nice thing is that this is not built inside code sandbox. It's kind of like a thing that you can use next to code sandbox and it uses code sandbox, but uh, doesn't change functionality within code sandbox.

Sarah Dayan:

Yeah. I think you also raised a good point is that, you know, it, it doesn't have to be a religion of oh yeah. Only we only take user feedback and, and everything has to be vetted by users. Or we only do what we think is good. Like sometimes when you have a hunch, sometimes it's nice to follow it, but it doesn't have like to be a hard rule of, we always do it like this or we always do it like that. I like that you bring some like just logical thing king into, Hey, you know, we don't know enough on this use case. So let's ask people, but on this, we've already seen people use it so much that we have a pretty good idea that it's gonna work. So yeah, I think, I think that's really interesting. We are reaching the end of this show. So I will ask you to wrap this up the, a traditional question of the show, which is how do you define great DX and what's your personal level of expectations?

Ives van Hoorne:

One thing that I really like to think about always when building something is that you need to build for two flows, essentially you need to build the accessible flow, which is flow where someone doesn't know about the feature or they are looking for the feature, but they don't know where to find it. So you need to, for example, make it accessible by the mouse. That's, let's say you're building a feature where you can create a new file. You want to make it accessible by the mouse that you can right. Click right, click on a document and you have this new file. That's the accessible way to do it. But I think alongside that, you also need to think about the power user way, um, the way that, um, where you can do it very fast, ideally without using the mouse. So it's either a shortcut, it's something in the commands. For example, something where someone can use it very quickly because they use need to, uh, use it often. So I think you need to, for a certain feature, you need to think about both flows and implement both. And once you've finished that feature, you need to look at ways how you can teach people to go as quickly as possible from the accessible flow to the power user flow. That's the interesting challenge. Like how can you teach someone as quickly as possible what the shortcut is and help them help them get more productive in the tool that you're building. And two examples of companies, uh, that I think are doing this really, really, really, really, really well when it comes to UX is, uh, super human. That's an email client and linear, that's a task management tool. They have both have some very good UX where everything's accessible through the commandlets. If I, if I want to change the status of a, of a task in linear, I can open a commandlet and set, uh, do and type set status and it, I will get the command. But the interesting thing is next to that command in the commandlet, I will also see the keyboard shortcuts and I will have this little visual. I will have very quick. I will see it very shortly, but it will be if I do set status from, from the commandlet 10 times at that point, the com the keyboard shortcut will be in my brain. And then next time I won't use it. And that super interesting if you have that mentality of making, making every feature accessible, but also have them have, have it, have a power user flow, and then getting from that accessible, teaching them as fast as possible, essentially to go to that power user, because it will make your developer tool more powerful because people can do more with it faster. It will also make the person using your tool feel more powerful because they know how to use your tool fast. And it will be a big enjoyment for a lot of people just to feel smart in knowing that, you know, how to quickly use the tool that it's your tool of trade. So to say, so, yeah, that's, uh, that's one of things that I would, uh, look out for

Sarah Dayan:

Bryan, how do you define grade DX? What's your personal level of expectations,

Bryan Robinson:

Kind, what you just touched upon, like the ability to find and learn your user flows, uh, is super important. That's actually like one of the tenets of usability, right. Is, is learn ability. It needs to be something that you can figure out, but then you take a step further and you say, how quick can a user accomplish the task they want to do. Those are two almost equal levels. And so I think that's, that's super important. But for me, tools, I usually look for things that allow me to break things, but not in an unrecoverable way, cuz I'm a breaking things, driven developer. And so I like to break things, fix it, break things, fix it and making sure that is as quick a flow as possible to me is a really big dev tool DX important thing.

Sarah Dayan:

Awesome Eve, thank you so much for chatting with us today. It was a really great conversation, Bryan, thank you for co-hosting with me today. That was a first and I think that went really well.

Bryan Robinson:

Totally a pleasure.

Sarah Dayan:

So for you listening at home, maybe at the office, maybe doing your morning, run your dishes or planning your next OKRs. I hope you had a blast. Thanks a lot for following developer experience and stay tuned for the next episode, which will be led by Bryan. Woo. All right, bye. Bye. This was developer experience a podcast brought to you by Algolia. You can find this podcast on your favorite podcast platform. We are on Spotify, Apple Podcast, Google podcast, Pandora, Overcast, everywhere. If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.

People on this episode

Head Shot

Sarah Dayan

Host