Kent C Dodds (00:00):
Hello friends. My name is Kent C Dodds. And with me is my friend Ian Sutherland say hi.

Ian Sutherland (00:05):
Hi Ian. I got it right this time.

Kent C Dodds (00:10):
Brilliant.
So I'm excited to be joined by Ian again, if you did not hear Ian's first episode, we talked about just getting into things. We talked a lot about open source. It was very good. And that's where Ian introduced himself. So please go listen to that, but we're just going to jump into this one. Ian works on create react app and, and so lots of experience in building tools. And I think a lot of us sometimes see tool building as the responsibility of companies that have developers as customers or open-source projects or something. And, and that definitely is, I mean, that is an example of tool builders, but I think that we can all be tool builders and Ian has a lot of thoughts on that. So anyway, Ian what, what are your thoughts around developer experience and, and tool building just in general? Like why do you think that it's an important thing for developers to keep in mind?

Ian Sutherland (01:11):
Yeah, I think so sort of, as you mentioned, I think people, I guess, first of all, for people that might not know DX stands for developer experience, and I think people tend to think of that a lot in terms of, yeah, a company has like a SAS product for developers. They need to care about DX or, or an SDK or something for developers that's DX. But I think you should also consider DX even just, you know, within your own team or your own company, everything that your developers do every day is DX. You know, how hard is it to pull down all of your, your company's code and get it all built and running locally, that's part of DX, you know, what are, what are some of the tools and processes around submitting PRS and other things like that, that all of that is DX. And I think by putting some thought and effort into those things and finding parts in that process that are maybe, you know, a little bit more difficult than they should be there, there's great opportunity to build tools and automate things and really unlock developer productivity there.

Kent C Dodds (02:23):
You know, that I think about setting up the repo in the first place, and all I can think of is when I first started a company, how painful it is, like every single time, it's always just a huge pain and nobody else thinks that it's a big pain, except for me, who's just getting started because they've all just gotten used to it. And so that kind of leads me to this question of like, when is it a good time to start investing in DX? Or are there bad times, should we just always spend our time investing in DX or, or when is an appropriate time to do that?

Ian Sutherland (02:55):
Yeah. I mean, that's a great question. I don't know. I don't know if there's bad times there are, maybe there may be better times. I think, you know, if it's probably, if it's just yourself, I mean, you probably still care about your own time and not doing tedious, boring tasks. So, you know, spending a little bit of time on it, there maybe makes sense. But I think definitely as a company grows, it becomes more and more important as your team grows. Especially if you're onboarding a lot of new people, like a good DX experience can make the onboarding process much, much smoother. So I think that's somewhere where it's very valuable, but yeah, I would say there's always, there's always things and processes that could be better or more streamlined. So there probably is no bad time to invest on the, in those things. It's kind of like the rule of like automated automating something to, right. If you're, if you find yourself spending a lot of time doing the same repetitive tasks over and over again, it's probably worth automating it and it's going to save you some time and make you happier.

Kent C Dodds (04:02):
Yeah Yeah. I totally agree. So like you, you know, generators were a big thing. Like project generators used to be a lot bigger and then create react app kind of came around and then we're like, oh, I guess I don't need these boiler plate projects for react anyway, anyway, but when generators were a big thing, I had people ask me why I didn't use generators. And my answer, I actually answered this in my three-minute podcast three minutes with Ken, but my answer is basically I don't use a generator that I didn't make myself, but I absolutely recommend using a generator. And I I've had a generator for my open projects. This is why all of my recent open-source projects look almost identical it's because they're all generated from the same thing. And it just saves me enormous amounts of time. And, and not only does it save you time, but it actually enables you to do more. You're, you're more likely to do it if it doesn't take as much time. And so, like, I don't think that I would have open-sourced as much or, or done as much in, in that world, if it meant that I had to spend 20 minutes getting things set up before I could actually start writing the code.

Ian Sutherland (05:10):
Yeah. I totally agree With that. I found myself making a lot of TypeScript CLI tools maybe last year. And so, yeah, I built just like a yeoman generator that does that for me, it's just like a basic project with TypeScript and yards for argument parsing, a couple of other, you know, little yes. Lindt and things like that already set up and yeah, it's, it makes it so much easier to just, you know, I want to build a, I want to build a CLI that does one little thing and you just run the generator and off you go.

Kent C Dodds (05:42):
Yeah absolutely. You know, like there's always that, there's the XKCD about like it's this big chart of how much time you spend automating a task versus how much time you spent saved because of that task automated. And what's in that conversation is the fact that if it's automated, you're more likely to do it. And, and so you end up doing, doing much more. And so it absolutely is worth investing a little time in a yeoman generator. That's what mine is that uses yeoman tried and true. It's been around for like, as long as I've been in node, we've had, well, almost we've had yeoman and yeah. So having these little project generators just to, to get you going, in fact, there was somebody in my discord community who shared this vs code extension that he made that like spins up a really quick project, so he can play around with stuff. And it, you're just more likely to, to do that stuff if it's easy.

Ian Sutherland (06:43):
Yeah, exactly. And also if, if you're working on a team of people as well, you know, not everyone is as into building tools or, or as into understanding all of the little nuances that go into that. So having something that can get them started right away. Yeah. It was a big help.

Kent C Dodds (07:01):
Yeah. You know, and what's also interesting is when, when, when you have this and this applies to any code that you end up sharing, whether it's tools or an abstraction or something, when it's built into what you're doing. So you have all these like little scripts or something, or, or functions or whatever, or maybe it's just a list of steps to go through. You're just going to like, basically do the bare minimum for what you're doing. But when you decide to either automate it or abstract it or make, make it special, you're actually going to put more effort into making that experience better. And so yeah.

Ian Sutherland (07:41):
You start to get the benefit of like incremental improvement and stuff there too. Right. The generator now is a repo in your GitHub org and people can start to, to improve that and add incremental improvements to that. So, yeah, I agree. That's your it's, you're going to end up with a much better result. And likewise, like something that I've done is taken a bunch of those little scripts that are lying around to automate various tasks and roll them up into a CLI it's fairly easy with, with node to make a CLI tool. I'm personally a big fan of, of the command line. I, I like those kinds of tools. I know they're not for everyone, but yeah, if you have something like various like deploy and test scripts and stuff like that, just package them up into a CLI that you can share with your team.

Kent C Dodds (08:30):
Absolutely and I think that when with that incremental improvement, especially like when we're talking about stuff like create react app, or I have my well, the react scripts package, and I have the KCD scripts package, I've been able to make some pretty hefty improvements and I've seen react. Scripts does the same, like upgrades, Webpack. And all everybody else has to do is update like the minor version in their package, json. And all of a sudden everything is like way faster. It's way better. Like it bundles better, whatever it is. And it's just an enormous improvement. When I was at PayPal, I also made PayPal scripts and all of a sudden, anybody who use PayPal scripts, they would get TypeScript support and they'd get auto formatting with prettier, or they like all of this stuff and they don't have to manage the like 30 or maybe 200 dependencies in the past json.

Ian Sutherland (09:26):
Right.

Kent C Dodds (09:26):
Just, just the one. And it just makes management of these, these processes even better as well.

Ian Sutherland (09:34):
Well, I actually remember when you were working at PayPal and you talking about that, and that was one of the things that, that sort of got me thinking along these lines as well. That's another great example. It's really easy to build and publish an NPM package so you can take, yeah. Some common if there's common libraries and stuff like that, that you're using it, all of your services, bundle them up into a custom package like that, and then install that into all of your projects. And then, like you said, it becomes very easy. You just bumped that version number to upgrade everything.

Kent C Dodds (10:04):
Yeah. Just so much, so much easier to manage over time. There are also tools that I I've worked on that are not like CLI tools, but like in browser dev tools. So one or pretty early in my career, I decided it would be really nice if I could see some information about the current build or be able to change what feature switches were on or what language was showing up or various different things. And so I created in browser dev tools that would only render during development. I have a blog post about this, but, and I, at other companies, I I've seen people make like Chrome extensions or stuff like that too. That's an enormous improvement for productivity. And that's the sort of thing that can be shared with the team.

Ian Sutherland (10:54):
That's definitely something I've done in the past as well is yeah. Build a couple of simple Chrome extensions, I think at the time that was around logging into our app with various test sessions. So I just made an, an extension that sort of made that a one-click process. Yeah. Chrome extensions are a great option. Even like even building simple web apps and dashboards. That's something like that I've used create react app for at work is just throwing up like a basic like status, status page or dashboard of some kind there's also, you know, slack bots and all kinds of things like that. These days like various bots get hub actions is another big one. I've built a few custom GitHub actions to automate some tasks there, there's really, really endless possibilities days these days, which is great.

Kent C Dodds (11:46):
Yeah absolutely, and early on in my career as well, I, I remember, so you mentioned having a, an extension where you, you click and to log into different tests, users and stuff. And I've had, I never built an extension like that, but we had one at some of the companies I've worked at super helpful. If you don't have something like that, I recommend it. But one of the companies that I worked for, I also used the Chrome dev tools snippets. And so it's just like little JavaScript files in the dev tools that you can save. And with those snippets, you just write arbitrary JavaScript, and you hit execute and it's like, you wrote it in the console. And so if I had something that I was doing over and over again in my UI, then I would build this little snippet in there and I'd execute it.
And then it could automate doing a whole bunch of stuff in the UI, like click on this button, then open this model, then cook on this and that and whatever. And now you can even use react testing library or, or Dom testing library to query things easier. But yeah. So if you have a repetitive task, even within it doesn't even have to be your app, it can be somebody else's out.

Ian Sutherland (12:52):
Right.

Kent C Dodds (12:54):
But want to say that,

Ian Sutherland (12:56):
oh, sorry, go ahead.

Kent C Dodds (12:57):
Oh, I'm going say finish. The, the one thing that I would do is once I had a snippet, if I found myself doing it a lot, then I would actually save this into the project in a ignored file. And then I would dynamically require that. So I'd say if this file exists, then require it and it'll just execute. And so then I'd have like a event listener on that history. And so when I land on this page, let's execute this script and it would do all this stuff. It was really, really cool. And it saved me a ton of time in developing the software.

Ian Sutherland (13:27):
I haven't actually played around with that functionality. I should, I should check that out. I was going to say that sounds kind of like, I mean, you're basically building like Cypress or playwright or something and early version of that.

Kent C Dodds (13:39):
Yeah. You know, it, it kind of was a little bit and, and actually, I, I've never actually done this actively, but on testing, javascript.com, I show how to use Cypress as a I call it Cypress driven development where you, you have Cypress script your way to the, the part of the UI that you're working on. So there was one company I worked for where you had to click on this button and then click add, and then click this other thing. And then this modal would pop up. You fill out this form with like 40 fields and then hit save. And my bug that I was fixing was what happens after you click save. And so I'd have to do that every single time. And so this is one of the situations where I made that little script that I just hit go, and it gets me into that state because I never trust hot module replacement.
Anyway, I maybe, maybe I should become more trusting.

Ian Sutherland (14:32):
It's definitely not perfect.

Kent C Dodds (14:33):
Yeah. Yeah. So I always refresh and, and so yeah, having just a little script that you can run that says, okay, get me from here to here. But yeah, you could do do the same thing with cypress. And because it's, it really is Chrome. Like you can blow up the dev tools, you have react, dev tools, installed everything. Then you can script your way with Cypress to get into that state. Every single time you hit save Cypress reruns. It, it gets you there in like two seconds and you keep on moving. That's a huge productivity gain when you're working on something like that.

Ian Sutherland (15:03):
That's a really great idea. Yeah.

Kent C Dodds (15:06):
Well, cool. So other ideas of, of tools or, or tips that you have for the sorts of developer experience enhancements that you, that you do at work?

Ian Sutherland (15:18):
Yeah, sure. I mean, so I already mentioned, you know, if you have those little scripts and stuff, lying around, packaging up into a CLI and distribute that to your team, something actually that we're exploring now is, is actually building like an electronic desktop app. That's sort of an enhanced version of that CLI like I mentioned too, like not everyone's as comfortable with the command line I personally am, but that's not necessarily the way everyone likes to work. Plus, you know, the browser is obviously a richer environment for, for displaying and interacting with things. So yeah, that's something that we're exploring is, is building yeah. Custom like electronic desktop app that we can distribute to the team. The great thing about that too, you've probably seen in many electronic apps is the auto update functionality. You push out a new version of these tools. People are automatically going to get a pop-up that says, Hey, there's a new version, click and restart.
So it's a, it's a, it has a great like sort of built-in distribution mechanism.

Kent C Dodds (16:20):
Yeah.

Ian Sutherland (16:20):
So that, that's one that I'm kind of excited to start working on. But yeah, like I said, there really are endless possibilities. Like GitHub actions is another really exciting one. We've like company has, open-sourced a few get hub actions. I personally have open-source if you get hub actions, it's a really great way to automate various like checks and things like that. That happened as part of your process. Yeah. There's so many possibilities. These these days and JavaScript, I think is sort of at the core of a lot of these, even like building a Chrome extension, like you were talking about it's actually, I remember the first time that I went to build a Chrome extension, it is actually quite easy. Like Chrome has like a really nice they've they have good docs and it's, you know, a nice SDK for here's how you build, you know, your preferences page and here's how you interact with the active tab and whatever.
I mean, it's been a while and probably a little out of date there, but, but, and then at the end of the day, it's just all JavaScript, you know, and same with like, I think working on create react app really sort of opened my eyes up to that that, oh, wow. You can really build like a pretty nice CLI tool just with JavaScript. And so I've just been doing more and more of that. I even, I made my own wrapper around yarn a little while ago.

Kent C Dodds (17:43):
Really?

Ian Sutherland (17:43):
Yeah.

Kent C Dodds (17:43):
That's interesting.

Ian Sutherland (17:45):
So yarn two came out and it had this feature where if you install, if you're in a TypeScript project and you and I use TypeScript for pretty much everything these days. So if you're in a TypeScript project and you add a package, it will automatically install the types package that goes along with it, if it exists.

Kent C Dodds (18:07):
That's great.

Ian Sutherland (18:08):
And yeah, so I thought, oh wow. I use yarn one. I really want that. So I made my own CLI it's called blarn. You can find it on get hub. But so I, I basically just made a rapper that adds that functionality to the add command and all other commands and just passes straight through to the underlying yarn. And then since then I've added a couple other, you know, every once in a while I'll find a feature like, oh, I really wish yarn did this. And so I just added in there.

Kent C Dodds (18:38):
That's awesome. Actually, that, that makes me think of like, people might be interested to know how react scripts works and KCD scripts, PayPal scripts. They all actually work the same way. I got inspired by react scripts. Do you want to describe, and, and I'm guessing this is how lots of automation tools work or at least that's, that's how I would do lots of my automation tools this way. Do you want to describe exactly how does react scripts work? Does it re implement just and re implement Webpack and it like, it's just, it's all I'm using is react scripts or how does that work with the underlying tools?

Ian Sutherland (19:16):
Yeah, it actually just has dependencies on the underlying tools. It's kind of another way to think of it as sort of, as like a meta package. It's a package that requires other packages. So if you, if you dig into react scripts, you'll see that it actually just requires a bunch of things like JAST and Webpack and babble and things like that. And then it exposes a few scripts, like start and build and things like that, that your project can sort of trigger to, to trigger a build, run the dev server, things like that.
And then just exposes those via the Ben links, which is a thing that a node package can expose. So that's why in your project, all you see is react scripts start, which kind of triggers react scripts to run the script that's pointed to by start. I don't know. It's not a very good explanation, but it's basically, that's basically how it is. And then, and then also inside there is just a, a folder of our various configs, like our web pack and fig and our Jess config and stuff like that. That's really all that it is. Is those configs and a few scripts.

Kent C Dodds (20:29):
Yeah, it actually, I would encourage people to go and take a look cause it's not that complicated. I remember when I was getting ready, I was thinking, oh man, react scripts. That's so nice. It would be nice if I had something like that at PayPal. Oh wait, I guess I can. And I just went and looked at how react scripts works. I'm like, oh wow. So like, it ends up react scripts doesn't handle, or it doesn't have a link to script or a format script or different things like that. That's not, that's kind of outside of the scope, but I decided I wanted to have that. And, and really you just like take the arguments. You have a couple of defaults and you forward those on you just say spawn process and you just bonded onto this other child process and ends up actually being pretty nice. Like let's say that you're using the CLI and every single time you use it, you are passing this additional parameter.
Well, you just make a little script that encapsulates that and forwards on that default parameter every time. And now you don't have to worry about it anymore.

Ian Sutherland (21:30):
Yeah, exactly. It can be a great way to that kind of like meta package pattern can be a great way of distributing shared configs and things like that. You do have to be careful because it then makes it harder if you need to customize those configs in any of your projects, but you can expose that in certain ways as well to allow for that. But yeah, it's a, it's a great way to distribute those kinds of shared tools. I mean, that's another, another great part of like the JavaScript ecosystem, right. Is NPM and being able to easily publish and consume all of these different modules, whether they're from third parties or whether they're ones you've built internally for your team.

Kent C Dodds (22:07):
Yeah, absolutely. And on the note of config react script, doesn't really allow you to configure too much, but I needed that for PayPal scripts. And what I decided to do was before I tell Babel to use the built-in config that I have, the first thing I do is check if the project has a Babel config. And if it does, then I just say, use the built-in one. But then because there's value in the config that I've created, I make it so that people can extend my config that I created. And so then they can override different things. They can make changes to it, but I'm still just saying, Hey, Babel, you use the, the built-in or, or their config.
And then they can just in their config, they're extending mine. And so you kind of get the best of both worlds. If you don't need to extend it, then you don't even need to bother with a config. But if you decide you want to extend, or if you want to customize it, then you can just extend the, the built-in one. It makes it really quite easy, you know, relatively to, to make all of that shared config actually be valuable.

Ian Sutherland (23:13):
Right.
Right. And yeah. And if you're building, you know, for production setting in a work setting that is probably more appropriate, whereas in create react app. Yeah. We're kind of more focused on hiding that stuff away from people who are new to react or in some cases, even new to software development. So we try not to want to give them too many options.

Kent C Dodds (23:33):
Yeah.
You know, and as, as somebody who's had to work around that decision a lot, I still think it's the right move. I think it's, it's a good decision to just lock down. And I, I only say I've had to work around it a lot because I always do weird things. I'm always the one, like taking the tool in a direction. It wasn't supposed to go, wow.

Ian Sutherland (23:57):
We've at least tried to make that possible by allowing you to specify your own scripts, like your own, instead of react scripts, you can specify your own version. So yeah, we, we at least try and leave that escape hatch there for people like you that want to mess around and break things.

Kent C Dodds (24:13):
Yeah.
Yeah. I really want to stick with react scripts as the package, but maybe, maybe I should just fork it a little bit and make a couple of modifications. So I don't have to work around quite as much as ends up working out. Okay. And like I said, it's just been enormously helpful to me, so. Okay, cool. So I did want to add, or talk about a word of caution on like, maybe we could spend too much, so much time on DX that we forget about UX. So where where's the balance here on like, is there ever a time where it's appropriate to make the user pay a cost because we wanted a better develop it development experience or where's the, where's the line there?

Ian Sutherland (24:57):
Yeah. I mean, that's a good question. I would say probably not. It I'm sure like most things, it depends. It depends on what your product is and what your, who your users and your consumers are. But yeah, I would say in general, no, you probably shouldn't be sacrificing your user experience in exchange for a better developer experience. Usually as developers, we're the ones that have to pay the price sometimes. So that, so that the end users have the better experience and yeah, you can't always automate your way out of that or get away from that. And yeah, I don't think you should, if, if it comes at the expense of the user experience.

Kent C Dodds (25:37):
Yeah.
So I, I kind of see this sort of automation or developer experience thing is like, the reason that we do this is so that we can be more productive to serve the user better. Right.

Ian Sutherland (25:37):
Right.

Kent C Dodds (25:52):
That's the ultimate goal is to, you know, whatever the mission of the company is, as long as it's a good mission, your, the, the purpose of everything that you do is to drive that mission forward and DX is important because it allows you to, to accomplish that mission faster. Most of the time, that's, that's normally what you're going for. Is there any other reason to, other than like improve developer productivity to have these tools?

Ian Sutherland (26:18):
I mean, I really think that's the main reason. I mean, you can also use them for, for kind of fun sometimes too, you know, there's nothing wrong with, you know, making a silly slack bot or a, or one of the things we do is we have a couple of different leader boards.
So our slack bot on Friday, for example, we'll post the leaderboard of who reviewed the most PRS who merged the most PRS. And that's kind of like a fun competition among the developers. Like, you know, we don't take it too seriously. It's not like that doesn't factor into your performance evaluation or anything like that. It's just for fun. Or we, we have a leaderboard of code coverage in various services. So everyone's, you know, always trying to get their service into the top, or we kind of have the inverse of that, which is like the slow query leaderboard. You don't want your, you don't want your team service to appear on that one.

Kent C Dodds (27:14):
That's funny,

Ian Sutherland (27:15):
But yeah, little, little things like that are they, they kind of make it and kind of make it fun, make it a little bit of a challenge. You know, game-ify things a little bit, give people a reason to, to, you know, put in a little extra effort maybe to claim that, you know, first, first place on the, on the leaderboard or whatever, just for bragging rights. Really.

Kent C Dodds (27:34):
Yeah, sure.
Well, and, and it, it is fun. And there's also, I can't remember where the, I think it was Boyd, K Packer said when performance is measured, performance improves when performance is measured and recorded or reported the rate of improvement accelerates something like that.

Ian Sutherland (27:58):
Right.

Kent C Dodds (27:58):
And so when, when you have those sorts of reports or things, it, it makes you think about those things more. So like, if you say, Hey, like we're kind of struggling, making sure that our, we have everybody reviewing the code, that's supposed to be you. I could, you know, sometimes people just go rogue and commit straight to master or something like that. Then having some way to report that recorded, we'll just get it on people's minds more. And they'll, it'll direct their behavior and the, where you want it to go.

Ian Sutherland (28:30):
Right.
And there's also the flip side of that too. Right. You can gain some of those things like, oh, I'm just going to make a hundred tiny PCRs and then I'll win. But I mean, you're really just competing against your peers and probably they're going to notice that you're going to get called out for it. So.

Kent C Dodds (28:47):
Yeah. And,
And I think that you can get that performance improvement, even when it's, when it isn't directly tied to your compensation, which as you said, like, I wouldn't recommend tying something like that to your compensation. Cause then it will be exactly.

Ian Sutherland (29:03):
I think that's where, where those things kind of start to fall apart. So if they're more just kind of fun metrics for bragging rights on the team or whatever, I think that stuff in my experience anyways works really well. Yeah. I would not use it for something beyond that.

Kent C Dodds (29:17):
Hmm. Yeah.
Well, it's very interesting. It's, it's a lot of fun. Thank you for talking with me about improving developer experience. We do have some homework for folks. So what we decided on was identify one thing, you do a lot and automate a tedious part of it. And yeah, I think that would be a good thing for people to do.

Ian Sutherland (29:40):
Yeah. And don't, don't afraid to build your own tools. It's easier than it sounds and you'll learn something.

Kent C Dodds (29:47):
Yeah, absolutely. Cool. Thank you, Ian. We'll have you repeat really quick? How do people get in touch with you?

Ian Sutherland (29:53):
Yeah, probably the best way to find me is on Twitter at Ian SU I A N S U just send me a message.

Kent C Dodds (30:01):
Awesome. And I'm sure that if somebody built some fun tool or, or some productive tool, you'd love to hear about it.

Ian Sutherland (30:08):
Absolutely

Kent C Dodds (30:09):
That'd be fun. Yeah. And mentioned me too. Cool. Well, it's been a pleasure to chat with you, Ian, and thanks to everybody for listening and giving us some of your time and you all take care and we'll see you later.

Ian Sutherland (30:20):
Bye.