Full-stack Developer Tips from the Creator of the Redux Form Library
JavaScript and Redux expert Erik Rasmussen discusses the challenges of open-source software development, the fluctuating world of JavaScript, how he deals with imposter syndrome and burnout as an in-demand developer, and his top podcast recommendations.
JavaScript and Redux expert Erik Rasmussen discusses the challenges of open-source software development, the fluctuating world of JavaScript, how he deals with imposter syndrome and burnout as an in-demand developer, and his top podcast recommendations.
Toptal Research
In February 2019, Toptal’s community team launched a brand-new initiative: a monthly opportunity to interact with Toptal’s network experts in real time. Ask Me Anything (AMA) sessions are open to all members of Toptal’s core team and talent network—anyone can ask a question. In this piece, we’ve curated selected questions and answers from an AMA with JavaScript and Redux expert Erik Rasmussen. Erik discusses the challenges of open-source software development, developer tips, and the fluctuating world of JavaScript, how he deals with imposter syndrome and burnout as an in-demand developer, and his top podcast recommendations.
Erik is a full-stack JavaScript expert with over 25 years of development experience, specializing in React, Redux, forms in React, and GraphQL. On GitHub—a web-based hosting service for version control with over 28 million users—he’s obtained a spot in the top 100 with over 20,000 stars. He’s also the author of the first and third most popular form libraries in React: Redux-Form and React-Final-Form.
Redux Form and the State of Open-source Software
Why did you decide to create another form library after the tremendous success behind Redux Form?
I learned many lessons along the way with Redux Form and gained insights into the needs of React Form developers throughout the world. Some of the problems with React Form just couldn’t be addressed without taking a fresh look at the problem. (More detail here.)
A lot of developers dream of creating a massively popular open-source project. What are some of the unexpected consequences (good and bad) of having a project as successful as Redux Form?
It’s extremely rewarding when you can fix a bug that has been holding up a developer or an entire team from completing a project. It’s also really awesome when people find and fix bugs themselves. So far, people have been very nice and gracious when they ask for help; I’ve not yet had an interaction with a righteous user that thinks I owe them a fix.
On the challenging side, burnout is a real thing, and we have not yet discovered a way to compensate OSS devs for giving their time and energy to OSS projects. Redux Form is used by billion-dollar corporations all around the world to transact business, and its existence has saved thousands of development hours for teams that have installed it, but there is no good solution to giving even a sliver of that money to the authors.
Are there any promising solutions in the works for compensating open-source developers like yourself?
A friend of mine started this company called CodeFund. He had this idea of, “What if we could put ads on code library documentation?” As developers, we spend all day looking at documentation and figuring out how to implement whatever thing it is that we’re doing. Plus, developers make a lot more money than your average web surfer does, so we’re a luxury product potential.
CodeFund came up with the idea that documentation is a really great place to advertise. I was one of the original pilots. It worked pretty well but they ran into a problem with GitHub. Originally, we were putting ads on the GitHub repository itself, but GitHub and the lawyers swooped in and said no. Which is a shame. CodeFund negotiated with them for a while, but in the end they said no.
With well-trafficked library documentation, you can get maybe $150 dollars a month, which is not paying for what it’s worth. There are some rare libraries—like Babble or Webpack—where there’s enough money given to them that they can actually support two or three full-time developers working to make that thing better. Babble and Webpack—billions and billions of dollars’ worth of companies are sitting upon their infrastructure and for sure, Redux Form supports them.
In almost any website you go to, you can look in the source and you can see some code that was written by one particular person who isn’t getting properly compensated. Awareness needs to be raised to make people more appreciative of what open source is and the hours that some of us put in.
Why create something that’s open-source and free? What’s the incentive to developers like yourself?
The reason that you create it is because you need it for whatever it is you’re working on at the moment. When you release it, others come and make it better. The open-source dream is you say, “I built a little wheelbarrow that helps me take my rocks from here over to there,” and then someone comes along and they make it better. On your next project, you go back and you use the same library and you’re like, “Whoa, this thing moves a lot faster. It’s better now.”
It’s also very rewarding. I get a dopamine hit when people say, “This has been holding us up for three weeks and this little fix that took you three hours to do has saved us three weeks of time.” There’s a little bit of an addiction cycle with that, where you get positive reinforcement and it just feels good.
With my second form library, it wasn’t so much that people were saying, “Hey, we want another form library,” it was just that I thought of a way to make it better.
That’s sort of the dream of why you do it. But it’s certainly not for the money.
In an ideal world, how much compensation would you receive for creating open-source software? Just some icing on the cake?
I wouldn’t mind if someone paid me six figures to just work on open source all day long. If you look at the value generated versus cost, the ratio for open-source is so high. You get down to little tiny libraries that do one thing, and one thing really, really well.
If every company in the world had to assign their own developer team to do that, the results would vary very widely. The fact that we have open source and we can have one solution to that—one algorithm bubble at the top that is best—means that everyone in the world has that efficiency built in.
Another value from open source is that if you’re using something that you wrote and only your company is using it . . . compare that to something that 1,000 companies are using. They’ve found every single little nook and cranny of the bug space that could potentially be a problem, and you take that and you plug that into your thing—you’re golden. You’ll have so much more confidence in that.
The Dynamic World of JavaScript
Having been in the JavaScript space for so long, you must have seen so many hot new frameworks [for building JavaScript applications] come and go. How do you keep a pulse on the industry so you can decide what frameworks to commit to?
You have to get a feel for the winds of the dev community. The current battle between TypeScript and Flow is a great example. I chose the wrong horse in that race initially, assuming that Facebook would be a better steward of a typing framework. But I think TS has pretty much won that battle, and now I’m slowly migrating things in that direction.
There’s a corner of Twitter that is the “developer Twitter.” If you follow enough people—maybe you need a sample size of a hundred or so—you can get a feel for where the winds are blowing and what’s becoming popular. You’ll get a lot of posts like, “I used to use library A, but I just learned about library B and everything is so much easier.” You get enough of those and you’re like, “Well, maybe I should check out this other library.”
Trends come and go in the JavaScript space. Will it always be in motion?
I think (and hope) it will continue to evolve. Stagnation is death in tech. Even Java is innovating significantly right now: The stuff you can do in Java 10 is nothing like your grandmother’s Java 6.
It can be exhausting to finally get your app built with Tech X only to see that all the cool kids are now using Tech Y. But that’s the industry we’re in.
In your opinion, what JavaScript concepts are especially important to really understand to gain mastery of the language?
I’d say functional programming and the idea of passing functions around is pretty important. Especially if you’re coming from a language like Java or C++.
Do you think that React should be used for building SPAs [single-page applications] or only for components in a regular page?
That’s the beauty of React: It’s so versatile. I have slowly been introducing React for all new features in an old Java/jQuery app at my day job. React works just fine given a DOM node to act upon. It doesn’t need to be in control of the entire app.
When starting a new React app, what are the tools and libraries you regularly use from scratch?
I think create-react-app
is the clear winner in this now. Four years ago, when there was nothing like that, it was a lot harder.
How do you handle app state in your react apps?
When Redux came out it was clearly the answer. However, I’ve found that much of my Redux “state” was stuff like loading
and listOfObjects
, and I’ve most recently been using Apollo GraphQL for that stuff. Other things like isSideNavOpen
can be managed with context-based components pretty easily. That said, there are still some legitimate use cases for Redux, but none that I’ve run into in my simple React apps.
What’s your favorite editor/IDE?
Ah, that question!
I come from Java, and have been very happy with JetBrains IntelliJ for many years, but it is a little slow for JS. First I went to Atom, but finally settled on VS Code. Its integrations for Jest and Flow and TypeScript are unbeatable.
What is your opinion about isomorphic development like opal
which translates ruby
to JS
and then opens the path for Rubysts to write React/Flux-structured apps in Pure Ruby (without writing any JS)?
The fact that JavaScript has made the jump to the server, I think, is a big deal. Being able to render with the same code on both the client and the server is huge, and more likely the way of the future.
What do you think is the biggest issue of our current most popular JS frameworks?
I’m not entirely sure, but I really like the direction of css-in-js, serverless, and SSR that companies like Zeit are pursuing with Next.js.
It’s really funny to me, as someone that was building websites in the late 90s, that we’re going back to static websites. We’re going back to generating everything at build time, and then you’ve got your static stuff on the server and then you can add dynamic stuff by what they call re-hydrating. After you have the whole page rendered, then you can get the extra JavaScript to actually make things animated and move components around.
Zeit, with their Now framework, also supports static building to your website, because nothing is faster than downloading a static HTML file. It’s just a text file and then boom, you got it. Whereas if you’re hitting a server, it has to hit a database maybe four or a hundred times just to build up whatever it is the page that you need to display. That’s super slow.
The static idea is gaining popularity.
Do you feel that JavaScript can take on “mature” languages (such as Java and C++) and become the language of choice for enterprise?
Definitely. The stuff people are doing now with “serverless” node is extremely scalable and I think enterprise APIs [application programming interfaces] can and will be rewritten in JavaScript, at least by the more agile and forward-thinking corporations.
What should a developer look for in a client?
You want a level of trust and autonomy given to you, assuming you’re senior enough to deserve it. I wouldn’t want to take a job where someone was looking over my shoulder all the time. A lot of time, with development work, you can have something that takes five minutes to fix, but you spend four hours working on some little problem with the build that makes it so you can’t actually test it. There’s a lot of times where I will spend eight or ten hours on a problem—where I’m really working, really focused the whole time—and the actual solution is like two lines of code. You want an employer that has that level of understanding of what your work is like.
On Imposter Syndrome, Burnout, and De-stressing
Imposter syndrome seems to be a not uncommon phenomenon amongst developers. Do you experience it, and if so, how do you deal with it?
Absolutely. Especially when speaking at a conference. (Or doing an AMA?)
When it comes to teaching/mentoring, you need to realize that you know more about what you do than Last Month You did. Ergo, there are always people that are back where you used to be that could benefit from your knowledge.
It’s also important to be able to say, “I don’t know, let’s investigate it together” (also a good parenting tip).
What’s a day in your life like? How do you schedule everything out so that you’re not working 100 hours a week and burning out?
When I have been really deep into open source, that takes a lot more of my time; sometimes, I have to pull back for a month or so at a time. I take my kids to school and then I spend time looking at what sort of problems people are having. If they’re really serious, then I spend some effort trying to remedy them or respond in a helpful way.
I’ve got a day job that is not related at all to open source, which takes a lot of my time. Throughout the day, I’ve got notifications set up so I can see if there’s a serious problem with anything. If a new feature has been released or something, then there’s more likely to be bugs around that time.
I’ve learned that whoever’s writing the requirements for a project is certain that, “This should have been done yesterday, so why isn’t it done yet?” I’ve had so many times where whatever team is receiving my work takes like three weeks to actually put it into production. And you’re like, “Well, what was all that stress about?”
If a task needs to be done by Friday, and that ends up getting done by the following Friday, almost never does the business shut down because you failed. When you’re young and don’t know any better, it feels like, “Oh my god, we have to get this out the door.” But after you’ve done that enough times, and you see, “Wait a minute, what they were telling us wasn’t really true,” you can be like, “Okay, yeah. Whatever. It’ll get done when it gets done.”
I was a little burned out last October when React announced this thing called React Hooks. If I had been there, ready to take up whatever new thing and run with it, I could have gotten a lot of mileage out of being one of the first people to get into React Hooks. I’m sort of keeping my eye out for what could be the next big thing.
What do you do in your free time to lessen the stress?
I take walks and listen to podcasts that aren’t about development.
Any you could recommend?
The only real tech podcasts I listen to are The Undefined Podcast, which is only tangentially about tech and developer tips. I also listen to React Podcast—on which I’ll appear soon (hopefully making some sense, depending on the quality of their editor).
Looking at my pod-catcher of choice, Overcast, my top-prioritized podcasts include:
- Roderick on the Line
- Making Sense
- Accidental Tech Podcast
- Road Work
- Exponent
- Hello Internet
- Radiolab
- Reply All
Recently, I actually started two podcasts myself:
The first is called Seek Justice, in which I, a moderately intelligent person who knows almost nothing about the criminal justice system, interview a friend of mine who has spent his entire career examining and working to reform it. He’s working directly with governors of several US states to reduce prison populations and recidivism post-release. It’s not a topic I’ve ever been really interested in, but my co-host captivates me every episode.
The second is a show of pure silliness, called Happy Hour with Dennis and Erik, in which the same friend and I partake of a few evening beverages, talk about our lives, and make each other laugh. Seek Justice is for your bright eyed commute to work, and Happy Hour is for your unwinding drive home.
To bring it back to dev, my podcast endeavors have helped me solve a problem I couldn’t find a solution for in the industry: an easy MP3 player, with album art, that also worked as a Twitter card. So I wrote AudioCard.