developer chats

Dan Abramov, co-author of Redux

Episode Summary

Joel Hooks co-founder of, interviews Dan Abramov, co-author of Redux. They discuss the "Redux phenomenon" and the notion of improving the developer experience.

Episode Notes

Joel Hooks co-founder of, interviews Dan Abramov, co-author of Redux. They discuss the "Redux phenomenon" and the notion of improving the developer experience.

Dan's Redux course has been the most popular course on for years. What caused Redux to blow up as it did? Dan is here today to talk about the problems he faced that inspired him to write this framework, and all the experiences he had that led to it.

Joel and Dan talk about how quickly functional programming concepts pushed their way into the mainstream. When they were younger object oriented was how you programmed, Gang of Four was like their bible. However, Dan talks about the problems he was facing and how they inspired him to create Redux.

Dan's belief that user experience starts with the developer also inspired Redux. The notion that a developer should suffer is silly. Having a tool that is a joy to use and allows a programmer just to create things is invaluable.

The frustration of getting started with React was enormous. You had to deal with Webpack and install packages manually and hope that you didn't mess up. All this was hugely daunting for beginners especially. create-react-app was the solution for that. Allowing an easy way to get React going with a dev server and all, it let you just get in there and start building components.

Finally, Joel and Dan leave us with a note to those seeking to learn to program well. Read GitHub like it's a blog. Read the commits, the issues, the PR's, all of it. You might not understand what is going on now, but you will build fluency and eventually you'll understand well enough that you can start to answer questions and contribute.


"Dan Abramov, co-author of Redux" Transcript


Dan Abramov

Joel Hooks

Episode Transcription

Joel Hooks: So, today, I'm sitting down with Dan Abramov and we're going to talk about the overwhelming success of his Redux library.

Joel Hooks: Hi, Dan.

Dan Abramov: Hi.

Joel Hooks: So, I was going through the end of the year stuff and I was doing some database queries. And you're Getting Started with Redux course on Egghead has, for the last two years, consistently, month over month, been head and shoulders above every other course we have on the site, in terms of popularity.

Joel Hooks: We track usage and people have spent six years, six years, Dan, watching that Redux course.

Dan Abramov: Oh, man.

Joel Hooks: And that's only the people that are logged into our site. That does not include all the free views, which are astronomically high as well. I didn't get into that to calculate it, which is nuts to me.

Joel Hooks: We pay royalties. It's into the six figures over the last two years. To me, it's amazing, this Redux phenomenon. And so, I was kinda thinking about it. And have you thought about why Redux has blown up in the way that it has?

Dan Abramov: Yeah. I'm not sure, really. I think I'm surprised by it, as well. Both by the popularity of the course and my popularity of Redux.

Dan Abramov: I think the Redux phenomenon is weird to me because it relies on some concepts that I don't think have been mainstream. I think they were on the verge of becoming mainstream and, actually, Redux kinda helped to push them to mainstream.

Dan Abramov: Like using immutability in client side, kinda Javascript code. Obviously, there was a lot of prior work. And it's not an innovative project, in terms of it uses ideas from Om and Elm and a bunch of other projects that are a little bit less mainstream than Redux.

Dan Abramov: And I was just chatting, actually. I was just chatting with somebody from a code in boot camp a few months ago. And so, this is a guy who learned web development, basically, during the last year.

Dan Abramov: And so, he told me that all these things like immutability and the kind of approach that Redux uses, this is natural for him. This is like what he learned. And this is so strange for me, because when I was learning, everything was object-oriented.

Dan Abramov: And there was a lot of dogma around it. And functional programming has seen something that's not really accessible to most people. And it seemed more kind of academic. And it's so strange how the tide has turned.

Dan Abramov: So, I think, getting back to your question, I think it's just ... Redux just happened to be at that point in time when functional programming concepts were becoming more mainstream. And it just happened to kind of give a name to some of these patterns, even though he did not really invent those patterns.

Dan Abramov: And I think people find these patterns useful, even if they don't use Redux. So, there was this entry React project, which is inspired by Redux that's popular in the angular community.

Dan Abramov: There is React itself, which is obviously not inspired by Redux. But some of the things we did in Redux are kind of slowly making their way into React itself. So, I think it's like its success is just because it gave a name to something ... To some things that already existed and that people find valuable to these concepts.

Dan Abramov: And people just want to learn these concepts.

Joel Hooks: Yeah. You mentioned object-oriented programming. And I came up the same way, right? It was all ... I remember when I was starting to learn how to program. It was the Gang of Four. I was reading it like it was the Bible and trying to really get in and understand these concepts.

Joel Hooks: Do you think any of that carries over though into Javascript? It's totally different and people have almost stopped using the terminology from that book. But at the same time, if you read it, you see some of these patterns.

Joel Hooks: And even with Redux and this React programming that we do, I see some of those patterns. Have you seen anything? And would you say there's a thread that goes through those?

Dan Abramov: Yeah. I have a history with that book. So, when I was learning development, I really liked making notes. So, I had this book, A Gang of Four book, and I ... It has these examples in Java and small talk.

Dan Abramov: And I didn't know either of them. I only knew virtual basic at the time. So, it was a bit hard to get through it. But I was fascinated by [inaudible 00:05:03] coding and programming at the time.

Dan Abramov: And I would try to create a concept of the book. And I used different colored pens to draw all these diagrams and stuff. That was fun. In terms of how these concepts apply, I think, one way of saying it is like a lot of people say that, I think, that it's ... A lot of these concepts are less necessary.

Dan Abramov: They just disappear, at least their structural form disappears a little bit with functional programming. Because once you have function as a first-class concept, a lot of these things are just like ... It's just functions that you can pass around.

Dan Abramov: And a lot of the complexity in how these patterns are described, I think, disappears if you have function as a first-class value. But I do think that some of these, I don't know, factory come out as just a function that you can poll.

Dan Abramov: But I think that some of these, definitely, are still valuable as ideas. And I think, it's good to know them. And I think that some of them also translate to either functional world. Some of them translate less.

Dan Abramov: There is a good book called Game Programming Patterns, I think it was called.

Joel Hooks: Deje Chanel, I think is his name. Is that the one?

Dan Abramov: I'm not sure. I think he's currently writing another book about creating VM's. So, that's the same author. I don't remember his name. But basically, there's a book that's ... There's a little bit more water in it, compared to design patterns I would say.

Dan Abramov: But I found it enjoyable. And I think it revisits some of these patterns. But from perspective of a game programmer and think in terms of the game loop and how to structure your logic in a game.

Dan Abramov: And I think modern front-end development, especially like React and the React-like libraries and this kind of mindset, I think it has a lot to do with game development, as well.

Dan Abramov: Because you have this complicated state and you have these many actors that, components, that have to talk to each other, but you want to render them efficiently. You want to separate this state from the drawing logic.

Dan Abramov: And that's kind of what React does under the hood. You don't really think about it much. But I found that the patterns described in that book, and it sometimes references the [inaudible 00:08:00] book, as well.

Dan Abramov: But I found it more relatable to what I do today. So, I would recommend anyone to read it.

Joel Hooks: Yeah. We'll get the title of that too, and put it in the show notes. Yeah. And it's interesting to me, too. And if you think about a game and how a game's built, because it's a very visual aspect of it.

Joel Hooks: But then, you also have the world, right? You have the state of the world that has to change at every frame, which is ... That's effectively what Redux has done for us. And that was the thing that blew my mind actually with Redux was that the single, immutable state was just like the sky is open for me, in terms of how I thought about my applications.

Joel Hooks: And it's really, really been a benefit since then. So, you talk a lot ... Or, you have talked a lot in the past about developer experience and what we go through, kind of the experience we have as developers.

Joel Hooks: Which, to me, relates to user experience in some ways. But I was wondering where this idea of developer experience kind of came from and what you've done since you started working on that to kind of push that forward?

Dan Abramov: I don't think I'm doing a great job at it. It's like there's a bunch of projects that I started that I didn't really follow through with. And it makes me feel a bit guilty, but also I feel like I'll fix them eventually.

Dan Abramov: It just takes time. So, where does this come from? I think a part of this is just like I hate keeping things in my head. Like, I'm not a very great learner. Or, it's hard for me to take a complicated application and try to remember everything that happens to it and try to remember what might be causing bugs, these kind of things.

Dan Abramov: So, I need any kind of debugging tools that I can get. And so, I think it ... So, I was working on an application a few years ago, before joining Facebook, before Redux. And it was a really complex, client side application with a lot of state and a lot of interactivity.

Dan Abramov: And we wanted to cash state very aggressively and try to fetch as little as possible and tr to make sure that it's consistent across. As you navigate through the app and you do something, we want to make sure that anything you do is reflected in the widgets you see and so on.

Dan Abramov: And so, we were using Backbone at first. And I found it very limiting, in terms of ... It was hard for me to avoid phrase conditions and avoid the kind of bugs where you do something and some part of the UI gets into an inconsistent state.

Dan Abramov: And you're like, "How do I reproduce this? I'm not sure." Because it happens only once in a while, or you don't really have log-in in place to tell what is mutate. And every object mutates another object.

Dan Abramov: And I found that really difficult to work with, especially in the Async world where you have Async graphs coming in. And you have these promises. And they have objects set in fields on each other.

Dan Abramov: And I think, monkey patched some Backbone matters just to kind of log average when that happens. But that was still frustrating. So that was one of the reasons why I wanted to centralize the mutations.

Dan Abramov: And when I saw Flux pattern, I was like, "Yeah, this is actually the problem that we're trying to solve in our product." So, this is a good answer to how do I avoid all these objects that modify each other?

Dan Abramov: Why don't we just put all modifications in a single place called an influx. Influx, it was achieved with different stores. But still, each store only mutated the parts that are relevant to it.

Dan Abramov: So, I wanted to have a higher visibility into all the mutations that happen and all the changes and to be able to debug them better. But I also had this project called React Hot Loader, which is just ... I came up with it pretty randomly.

Dan Abramov: I think I was inspired by watching Brad Victor's invention on principle talk. And I have a disclaimer that I'm pretty sure Brad Victor hates everything that people do, after watching his talk.

Dan Abramov: Because he shows a big vision. And then, people chase after the five percent that's easy to implement, but forget about the rest of his vision. But yeah, I did what I could. He had this, that won't work.

Dan Abramov: He would change the code and the change would be reflected in real-time and around the application. And that was really inspiring to me, considering that I had to ... Every time I would change a file, I had to wait for Grunt, or whatever I was using at the time, to finish building.

Dan Abramov: And in a deepliness that kind of central application. If you're working on comic books or on some widget that only makes sense in the context of your distant data in your app. And you don't want to build separate fixtures for it.

Dan Abramov: It was really annoying to have to refresh all the time, get the app into the same state and kind of iterate on it. And when I was ... We migrated to Webpack, because they required ... Oh, yeah. We were using required JS, but it was too slow.

Dan Abramov: So, I migrated to Webpack and I noticed there was this page about hot model replacement. Which I had no idea what it is. So, I just asked on the Stack Overflow, what is hot model replacement in Webpack?

Dan Abramov: And Tobias Koppers, the author of Webpack, actually replied to that and he gave an overview. He said, "This is like a system that lets you ...". In a very convoluted way, he explained it like ... I mean, he always goes a bit deeper, in terms of implementation details than people usually expect.

Dan Abramov: But he really explained what it does. And it reminded me, when I was 14, I read a book about Erlang. And it had this sentence that since Erlang is a functional language, it's easy to replace modules at one time.

Dan Abramov: So, it can do deployments of specific modules. If I remember correctly and just kind of replace them on the fly and run an application. And this is how ... If I remember it right, I think this is how some of the networks like telecommunication, like GSN networks, worked at least at the time.

Dan Abramov: So, a lot of them were using Erlang. And it was easy to deploy nowadays, because you can kind of hot swap it.

Joel Hooks: I think they still are.

Dan Abramov: Yeah. This came to my mind and I was like, "Yeah, this is a similar system, but for Javascript." But obviously, Javascript has side effects. So, how do you deal with that? But then, I realized that in the case of React, most of the modules that act with React components don't actually have side effects.

Dan Abramov: So, what if I could kind of replace a React component on the fly, but trigger React into thinking it is the same component so it would not throw away the dominant state. But somehow monkey patch the matters to point to the right version.

Dan Abramov: So, you could add it to file and see the changes reflected in a running application without throwing the component away. And this idea fascinated me. And I kind of just sat down one evening and I just ... I think I finished at six in the morning.

Dan Abramov: My wife was like, "What is going on here?"

Joel Hooks: You're a maniac.

Dan Abramov: Yeah. I mean, it's not very healthy. But at that point, I was really fascinated with this idea. And I couldn't stand the thought of not doing it and then, somebody else would do it. And I would feel very silly.

Dan Abramov: So I was like, "Yeah, I got to do it." So, at seven am, I had a working prototype, which was super hacky. I had to change some coding. React to write to Window variables, stuff like this.

Dan Abramov: But it was enough to make a video. So, I made this video where I'm editing JSX and seeing the changes reflected in the live running application. And Christopher Shadori tweeting that. And so, this is how I got my first followers.

Dan Abramov: I think, before that, I had about 20 followers.

Joel Hooks: I'm almost sure that's when I contacted you and asked you about making videos too. It was probably that retweet that caused that first interaction, I would think.

Dan Abramov: Maybe, yeah. I'm not sure. But I think it was Christopher who kind of introduced me to the React community this way. And yeah, and this tweet was retweeted 50 times. And it seemed like a lot for somebody who doesn't have an audience at all.

Dan Abramov: And I realized this is something people want. And so, I just continued working on it, basically. And it was super hacky. And due to some edges, it's even more hacky now. But, I think, eventually, it will be less hacky.

Dan Abramov: But I just felt like this is something I really enjoyed. On the one hand, I like to work on user experience and on polish. I really liked working polishing things and making them pleasant to use, kind of finding those small things that annoy you and try to eliminate them.

Dan Abramov: So, I try to do that as a developer. But also, I'm really selfish and I kind of want to do things better for myself or for other developers who are like me. So, I think this is why I was moderated to work on this kind of developer experience projects.

Dan Abramov: Because I just like to polish things for people whose workflow I understand. So, I do this for developers.

Joel Hooks: Ultimately, to me, the end user experience, at least in part, developer experience is responsible for that, right? If we, as developers, can have a pleasant experience in why we're writing software.

Joel Hooks: And we should, right? We are users and we're using this software. And we should have a pleasant experience. And we should enjoy our jobs. And we should wake up and be excited about our code, instead of waking up sad that you've got to go, whatever Maven process or some sort of horrible developer experience that you have to suffer through every single day of your life.

Joel Hooks: That is ridiculous to me. And user experience starts at the coders. We're down at the foundation of it. There's a lot of work down there, but I think we're getting-

Dan Abramov: Oh, yeah. I think there's ... I don't understand some people are trying to present this as some kind of ... I think it's a false dichotomy. It's not like you need to subtract from developer experience to get a better user experience.

Dan Abramov: This doesn't make any sense to me. I think, if you improve the developer experience, it's just ... You need to be conscious about how you're improving it and how it's going to have the downstream effects.

Dan Abramov: You want to make it easier for developers to create good products, right? So, you want to make sure that you spend less time on obvious things that are obvious in retrospect, but it's hard to find the issue.

Dan Abramov: They spend less time on typos. They spend less time on raise conditions, on all these hard to debunk things. You want them to see the issues clearly. If they don't see what's happening in the app kind of like its data flow, it's harder to fix issues, right?

Dan Abramov: And you also want to have an opportunity. If the reason is you want to have a way to ensure that it's reproducible, so that's another thing that I really was fascinated by. When I was talking to Jen Chan and she told me that flux architecture allowed us, at Facebook ... At the time, it allowed them to reproduce some back reports.

Dan Abramov: Because they would just realize the actions and the action of those kind of tell a story of what the user was doing before the back happened. And you kind of can get close by replaying the same actions.

Dan Abramov: And this was really ... This felt really powerful to me, this idea of having actions be plain objects that you can serialize. You can pass between clients. You can record and then, replay.

Dan Abramov: And I think, this is another reason why I wanted to work on Redux is I wanted to have this baseline for ... Ensure that there is a baseline for more apps to be able to build tools like this on top of them.

Dan Abramov: And obviously, if you have tools that let you reproduce the issues your users are having, you're going to have better products. It directly impacts the user experience.

Joel Hooks: So, I work with basically two environments. We use React on Rails. And we have a big Rails app. And it's like I refresh and I have to wait. But then, when I'm working on a component, a specific component, I like to fire up Create React app.

Joel Hooks: And more than anything I can think of in the last couple of years, Create React app has positively affected my development workflow. It's really great. And I was just kind of curious, how did that come to be?

Joel Hooks: Was it just kind of a natural progression of this work around developer experience? Or what's the story with that?

Dan Abramov: That's pretty random. I guess, there was a lot of frustration in the ecosystem, because of all ... There were a lot of changes going at the same time. There was the Babel 5 to Babel 6 transition.

Dan Abramov: There was the ... In general, the idea of compiling your Javascript code kind of went mainstream. And together with Babel, it was a big step for a lot of people. And at the same time, you had this ... The ES 6 final specification.

Dan Abramov: And people were just starting to learn ... The first big update in 10 years and it's a lot to learn. And so, people felt like they were kind of behind. And when they were trying to follow tutorials and examples, a lot of these would be broken because they specified different version of Webpack than the one that is current, or a different version of Babel.

Dan Abramov: And it felt like a train wreck. Where there is so much potential in these people who are trying to learn all these technologies, but we just screwed up. We didn't provide them with an environment that they can learn in.

Dan Abramov: And we didn't provide them with a way to get started that's working. So, it was really frustrating to me personally, I guess. And I was seeing a lot of these bullet point projects which tried to mitigate the problem.

Dan Abramov: But I think some of them actually made it worse, because now, you had ... Every time a clone a bullet point, you end up with all these conflicts in your project, whether you want them or not.

Dan Abramov: And even if you're a complete beginner and you don't care about customizing anything, now you're left to maintain all of these kind of infrastructure that you have no idea how it works and all these dependencies.

Dan Abramov: And if you're trying to update any one of them, the rest of them break because they're not compatible. And it takes a lot of effort to learn how to update them. So, I think this was a big anti-barrier to the React ecosystem.

Dan Abramov: And this was one of the reasons why it got such a ... I wouldn't say bad reputation. But yeah, it partly was a bad reputation for complexity. But I don't think that throw in the build tools of the Windows is the solution.

Dan Abramov: So, I was just chatting about this with Christopher Shadori again. This person's responsible for many of my projects, it seems.

Joel Hooks: He's awesome.

Dan Abramov: Yeah. And so, he was just ... They had a hackathon there in the [inaudible 00:25:11] Park Office. Which I don't usually participate in hackathons, because I'm like ... I don't know. I just hate context switching.

Dan Abramov: I prefer to work on one thing at a time. That's just the thing that I'm working on. But he was like, "We should do something. Let's do something for a while, for a week." And he was talking about this idea of doing that, like a generator for React projects.

Dan Abramov: And I said that, "I don't want it to be a generator, because it's just directing the problem back to the user." Okay, you're going to create a project. But then, you have all these the banners that you have to maintain and all these tools and configuration that I have to do.

Dan Abramov: And so, I suggested that, "What if it was a separate kind of ... A single dependency that you just ... You use this dependency and it builds the project for you, tests the project. It runs the line chart. It consolidates all these different tools under a single package."

Dan Abramov: And if there is a new integration of some of the underlying tools, we can update the package ourselves and make sure that all of them work correctly together. And if you are not happy with the tools that we've chosen, you can run a check. And then, it will copy the build configuration and the dependencies into your project.

Dan Abramov: And this point is the same as a bowl, a plate. So, there is like this escape hatch. And I got this idea from another project called Enclave created by Ian Pletter. And so, we thought that maybe this will fly.

Dan Abramov: I don't know. I felt like this is either going to be a disaster, or it's going to be really helpful. I wasn't sure, because there were like four or five projects that attempted to do this before and they failed.

Dan Abramov: So, there was React CLI, React CLI, WRB. There was an internal phase of projects that did that. So, there were a bunch of projects that tried to create an entry point to React and like a curated project generator, or something like this.

Dan Abramov: But they were all too opinionated about the project structure or about specific tools, and so on. And they didn't really catch on. And yeah, we just kind of tried to release it and see what happens.

Dan Abramov: And it has its share of issues. I won't deny it. A lot of people wanted to customize some things. Some of the things are awkward. People are coming up with workarounds that are weirder than the problem that we were solving in the first place with like-

Joel Hooks: It's so weird. I've seen some of them.

Dan Abramov: Yeah. But then, on the other hand, I like that there is a way to create a project and it will work. And it will be optimized for production correctly. You will not shape the development version of React by mistake.

Dan Abramov: And I've seen people type the command. It works. They have a thing that they can learn React with. And later, if they feel like, oh, I want to do things differently. Like, if you want decorators, you probably know enough to go on your own.

Dan Abramov: And I don't know. I can discuss specific decisions we made there. But overall, I think, it's been healthy for the ecosystem to kind of ... It pushes hard into the opposite direction from other tools.

Dan Abramov: So, it's not moderate. It's a little bit on the extreme side of not allowing you anything at all. And I think that's healthy to shift the overall balance to the middle. And I see us moving closer towards the middle in the future.

Dan Abramov: But I think it's been a helpful kind of purge for the ecosystem.

Joel Hooks: It's opinionated. You all did this and made certain decisions for specific reasons, which gave it an opinion. I don't know that it's too opinionated. And for us, we try to use Create React app up 'til the point where we just can't anymore.

Joel Hooks: And then, we eject and we have a really nice boiler plate that is sanctioned, right? You and your team have sanctioned this for us and we can use it. And it's been really great in our day-to-day development.

Joel Hooks: Aside from people constantly asking you to add SAS support, have you noticed a positive change in terms of the support you have to give for React and kind of in that general space in the community?

Dan Abramov: I don't have to ... I don't see a lot of questions like how do I create an app anymore. So, I think that's a really positive change, considering that we had a lot of those questions in the past.

Dan Abramov: And it felt like people were just kind of blindly trying to make different tools work together and they didn't. And they spent a lot of time with that. So, I think that, alone, is valuable. And I think it also helps to kind of standardize on the language features that we think are solid enough to be enabled by default.

Dan Abramov: And I know we're kind of taking liberties there. And we say, "Yeah, class properties are fine. But decorators are not." But in practice, it's just some things are going to involve more churn in the future.

Dan Abramov: So, if class properties proposal changes, we're going to write a code mod for it. Because we are the ones who depend on it. Like, on Facebook, co-bases are using the class properties. There is a guaranteed liberation path, in case something happens.

Dan Abramov: But the decorator's proposal has already changed. Like, Babel implements the old version. And maybe the new version six and Babel seven, I'm not sure. But in any case, there will be breaking changes there.

Dan Abramov: And people who depend on decorator's proposal, or on the legacy one, are going to have to figure out how to update their code. And in some case, they might not even be able to because some pattern may not be supported anymore.

Dan Abramov: Or, it may have ... Somebody may have to update the libraries to be compatible with a new syntax. So, it's like is it worth the community churn in this case, considering that Facebook is not going to provide a code mod for this.

Dan Abramov: Because we're not using this, or we're not even sure how to write this code mod. I think it's not worth it for the ecosystem. And I found, I think, the positive change here is that if some code doesn't work in the Create React app, in the Stack Overflow answer, people are going to rewrite it.

Dan Abramov: And people are going to use the subset of features that we support. And this kind of ensures that everybody speaks the same language, despite everybody using Babel. And so, I think that's a good thing.

Dan Abramov: And it also helped, I think, less libraries force people to change Webpack configs now. There are some cases where we made the situation worse. With modules that are written in for more recent versions of Node, than ... So, we don't compile Node modules.

Dan Abramov: And obviously, if somebody publishes something that uses CSS syntax, there's going to be a problem. So, we'll be looking at that. But, I think, what's been helpful for the ecosystem is that less libraries now say, "Oh, you need to use me. You also need to go into your Webpack config and change this.

Dan Abramov: Because this was not really sustainable. It's very easy to break something if you change the Webpack config. It's hard to do this. It can depend on the version of Webpack. Not everybody uses Webpack.

Dan Abramov: So, I'm happy that more libraries now work without configuration. I think that's a good thing.

Joel Hooks: Yeah, definitely. So, I had one last question. I'm a self-taught coder also. I think you are, too. And one of the pieces of advice I always give people that are trying to learn to code is read GitHub like it's a blog.

Joel Hooks: Reading source code and reading issues, going in there and just really digging in. And that's been wonderful to me. And I think it's a real opportunity for people to learn. And I was wondering if you had any kind of top tips or advice for people that are out there and they're struggling ... Learning to code is kind of a hard uphill climb.

Joel Hooks: And I was wondering if you had any advice that I might be able to pass along to people that are trying to just get started and learn how to be a web developer.

Dan Abramov: I don't know if I had any good advice, because it took me a really long time to learn development. Even not web development, but general. I think people are learning much faster than I did in my days.

Dan Abramov: It took me maybe two years to really understand what code blocks are and what Async ... Before Async/Await existed, which is like how to write asynchronous code and what it really means. So, I could pass functions around and this kind of stuff.

Dan Abramov: It took me a few years to really get it and I'm a very slow learner, really. But I think what's been helpful to me is just trying to build things, I guess. I learned everything on the job really.

Dan Abramov: I was hired to write an iPad app. And the middle, it was like, "Hey, we're going to write a web app now." And so, I had to throw what I knew, just kind of throw it away and learn it on the go.

Dan Abramov: And so, I was just kind of forced to ... I have these requirements. I have these screens that need to work this way. I need to figure out the way to make them work this way. And it was stressful, but that's basically how I learned.

Dan Abramov: I just kind of kept trying to do it. And obviously, I had this background of the things that I read before. It's helpful to read blogs and it's helpful to learn about design patterns, and all this kind of stuff.

Dan Abramov: But it's also just by building things, like real things, that you learn how to do it. I would suggest to focus less on best practices, because a lot of these are not really valuable. And I think people are way more dogmatic than they need to be.

Dan Abramov: So, don't focus too much on that. But just try to focus on kind of making your code easy to change, I guess, but not too flexible. Yeah, that's not really helpful. I think it's just a lot of ... As you work on some code and you come back to it once in awhile, you learn how things work and what things don't work.

Dan Abramov: And that's really the experience that you need to get to be productive. You want to get a feeling for what you're good at and what you're bad at. And what are your kind of weak spots. And if you need to, write some code and then, see.

Dan Abramov: Oh, I haven't come back to this page in two months, because it just looks fine. So, I guess, this is a good way to write the code. And you may write something smart and think like, wow, I was so smart.

Dan Abramov: But then, you come back to this piece of code every week. And you're like, oh, there is a block here. There is a block here. And you learn from more things about yourself and your workflow and how to structure things by understanding how the code changes all the time.

Dan Abramov: But in terms of the open source, I think your advice is as good as it gets. Just pick a project that you're using that you enjoy using, or that looks fun to you. And just try to ... At least, for me, a lot of knowledge comes ... It doesn't make sense at first.

Dan Abramov: So, you kind of have to build a tolerance for not understanding things and getting through them anyway. I did that by answering questions. So, I think, the way I learned programming had a lot to do with just answering people's questions, even when I didn't know the answer.

Dan Abramov: So, I would just hang it ... Before Stack Overflow existed, I would hang in local programming forums. And somebody would ask, "How do I screenshot the screen in C#?" And I have no idea how to do that, but I can Google it.

Dan Abramov: So, I'm like, "How do I screenshot?" So then, I found some solution and I tried locally. It doesn't work and figure out what's wrong. I read about these API's and this kind of stuff. And that's how I get something working.

Dan Abramov: And I post it as an answer. And I did the same, after Stack Overflow existed, so I would try to answer Javascript questions I don't really know the answer to. Like, questions about ... I think I answered some questions about angular, just by Googling things and trying to figure them out.

Dan Abramov: It makes it uncomfortable, but it also ... Eventually, you realize that the people who have liked this code pages. And I don't know. Like, 100 case of reputation, and this kind of stuff. They're not really much better than you.

Dan Abramov: They're just really good at finding things. And then, trying to form a theory based on incomplete data. And then, explaining what they learned to other people in a way that is more digestible.

Joel Hooks: It's like programming in a nutshell though, right? Like-

Dan Abramov: Yeah.

Joel Hooks: That's what you do everyday. I don't know the answer. I have no idea. We're going to figure it out though. And by the end of the day, hopefully we'll have this thing working and maybe not.

Dan Abramov: Yeah. I think, I get a lot more productive after I realized that. That, yeah, you just need to start doing it and try to figure it out. If it seems ... It's not effortless. Right now, I'm rewriting some parts of React's build system, just refactoring them because I don't really understand them.

Dan Abramov: I'm just trying to understand them. And in the beginning of the day, I was like, "Oh, this feels so daunting. I don't know where I should start." And I just deleted all my code and I just started from scratch and kind of copy and pasting the things that kind of make sense to me.

Dan Abramov: And I get to the point where it actually works now. And so, it always feels daunting. This feeling, it never goes away. You always feel like, "Oh, well, I don't know what's going on." The only thing that changes is you kind of learn to get through it, I think.

Joel Hooks: Yeah. And you get those endorphin hits where you feel like a super genius once you've beat the computer for the day. And then, the next minute, you're back to your normal kind of dumb self.

Dan Abramov: Yeah. And that's what keeps a lot of people going, I think, is just this kind of random reinforcements.

Joel Hooks: Yeah, stubborn tenacity, right? That's one of the core elements. At least, for me, that's kept me going.

Dan Abramov: Yeah. It's the same in open source. You just read through the issues, try to help the people who ... Even if you don't know how this project works, try to reproduce the issue they're having.

Dan Abramov: Try to help them, try to form theories about what can go wrong. It's just code, right? You can trace every line and you can see what's really going on if you want to. And eventually, you'll gain enough context into a specific library so you're able to contribute with, maybe, tests or code or documentation or easier triage, which is underappreciated.

Dan Abramov: But this is the thing we want you to help us with. It's like you don't need to go, I don't know, write a new feature. That's valuable, but it's five percent of what we're doing. But I think it's way more valuable to go ahead and help the people who are struggling who have less experience than you.

Dan Abramov: And help, because as you help them, you contribute to this ecosystem of people who can explain things to each other and help each other. And maybe, they'll create projects that people use eventually.

Dan Abramov: So, it's also selfish in a way. But, yeah, and as you do the easy triage and go through the source code and try to read it, even if you don't understand what's going on, still you can read the changes.

Dan Abramov: You can read the commands. And eventually, it will start making some sense to you. Especially, if you use the project and you know the bugs and the issues that are currently here.

Dan Abramov: And I started open source this way. I just tried to find the fixes for the problems that I was dealing with. And some of these fixes were not reviewed for a year and nobody cared about my PR's.

Dan Abramov: But some of these were and it's just a matter of volume, I think, before people really kind of notice you.

Joel Hooks: Yeah. The instinct is probably, "Oh, I'm going to go do that with React." React may not be the best place to start. And the React project, itself, is-

Dan Abramov: Yes, it's too-

Joel Hooks: And there's a lot of work there. Don't get me wrong. But in terms of projects, there is a lot of work there. And it's kind of more maybe on the advanced side, just in general. I think there's a lot of small projects in the ecosystem that are related to React and we might use on a day-to-day basis that-

Dan Abramov: Yeah, I think it's easier. I think I started contributed to React cloud or actually, that was one of the first open sourced projects that I really tried to contribute to, because I was using it. And it was not working the way I wanted it to work, so I tried to fix things there.

Dan Abramov: But also, so when we're doing the React is we tact ... We have this tact called Good for Us This Year. So, if you want to help with the development of React, which might evolve react itself, might evolve our build system, all kinds of infrastructure we built around it for ourselves.

Dan Abramov: There's always something that we need help with. You can go to our GitHub repo at Go to interest app, filter them by label called Good For Us This Year.

Dan Abramov: And they're not all beginner friendly, because some of them are complicated. But they all have the difficult label. So, there is like difficulty starter, difficulty medium, difficulty advanced, difficulty maybe impossible, something like this.

Dan Abramov: And regardless of your experience level, you can look at those different issues and just keep track of the label and when we add it, or something. You can take a look and if you are interested, you can comment, saying, "Hey, I'm interested."

Dan Abramov: And we're going to assign that issue to you. And you can always contact us on that issue by commenting and say, "Oh, is this the right approach? Is it a good way of doing it? How do I do this or that?"

Dan Abramov: We're happy to answer those questions. And also, you can always reach out to me directly in Twitter or direct messages. I don't always reply, because it's a bit overloading. But I try to, especially if you start by saying that you're trying to contributory add.

Dan Abramov: I'll try to prioritize that. But it's easier to start with smaller projects. I think you're right.

Joel Hooks: And I will say, it never gets old, having your PR's merged into an open source project. It's one of the best feelings. I always love it. I had like two lines of code and the angular JS code base, and I was always patting myself on the back.

Joel Hooks: It's just nice, right, when you get to feel like you're giving back to this community that gives so much to you.

Dan Abramov: Yeah, yeah.

Joel Hooks: Alright, Dan. Well, I really appreciate it. Thanks for talking to us.

Dan Abramov: Thanks for having me.

Joel Hooks: Yeah, cheers.