✍️ Want to support the podcast? Subscribe in your favourite podcast app and leave a leave a 5 star review here.
🎙 About the episode
Meet Mark! Mark maintains Redux and is a seasoned developer with more than a decade of professional experience coding and working with Juniors. In this episode, Alex and Mark explore if beginners need to know Redux before delving into Mark's best coding career advice around searching and evaluating online information efficiently and how to find meaningful information on even the most obscure programming errors!
🔗 Connect with Mark
- Introduction (0:00)
- Working at the same company for a decade (01:47)
- What is Redux and should newer developers bother learning it? (02:38)
- Where does Redux shine? (06:24)
- Quick introduction to TodoMVC (09:58)
- Redux vs Context API (12:12)
- Does Mark with more than a decade experience need Google anymore? Yes! (17:40)
- How to search information efficiently (20:10)
- How do you search hairy error messages to find meaningful results? (20:44)
- Why TypeScript errors trip a lot of people up (23:53)
- Mark's best advice to folks new in their career (25:07)
🧰 Resources mentioned
- Redux documentation
- Fundamentals of Redux Course from Dan Abramov
- Mark's coding career advice series of posts
⭐️ Leave a Review
If you enjoy this episode please leave a 5 star review here and let us know who you want to see on the next podcast.
You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so they can thank you personally for tuning in 🙏
Hello and welcome to the Scrimba podcast. My name's Alex, and on this weekly show I speak with successful developers about their advice on learning to code and getting your first junior developer job. Today, I'm joined by Mark Erikson, who is a core maintainer of Redux. You might have heard of Redux. It's a popular data management library, often using growing React applications. We explore and learn about Redux a little bit and then see how it compares to React Context. But spoiler, there is some overlap, but Mark shows us they are fundamentally quite different. Eventually we wrap things up by talking about how to google things effectively, how to understand error messages, even if they look intimidating at first and why you should consider journaling every day. All that to come, and more on this episode of the Scrimba podcast, let's get into it.
Mark Erikson (00:54):
Hi, I'm Mark Erikson. I'm probably best known for being a Redux maintainer, but I'm also a software engineer with a fairly standard day job. I suppose you could argue that I got into tech when I was eight years old and my family got our first computer and I promptly started using it to play games. This was back in the DOS days. So I'm dating myself a little bit, had to learn how to mess with config files to get games running sometimes. But I didn't get into programming until college. I had a standard computer science degree and I actually did not try to program at all until my freshman year. So the CS degree actually taught me how to program to begin with. Graduated college and went off and did a couple other things for a while and was lucky enough to get my first real programming job back in about 2008, I think. And I've had a kind of fairly stable, consistent job ever since then.
You've been at your company for over a decade. I think that's remarkable.
Mark Erikson (01:50):
I've been very lucky in my career in a lot of ways. Really about a year in, I was lucky enough to get transferred to a project with a more senior developer who was A, really, really smart. B, perpetually involved in multiple interesting projects at once and C, a very good mentor. I can remember sitting in his office as we were getting ready to work on various assignments and he'd be going off and sketching things on whiteboards and explaining how we were going to build this thing. I would just be absolutely enthralled. It's like, wow, I am learning so much from this guy. As the years went on, we kind of went off in slightly different career directions and we're much more peers now, but we're still friends. And he's been one of the absolute biggest things that shaped my career.
Mark, you mentioned that you are probably best known for Redux and maintaining Redux nowadays. For anybody who doesn't really know what Redux is, but might have heard about it since it's often associated with React, what can you tell them about the project?
Mark Erikson (02:51):
Mark Erikson (04:13):
Do you think Redux is something that a new programmer should be looking to add to their arsenal of technologies when they're looking for their first developer job?
Mark Erikson (04:59):
Yes and no and yes.
Mark Erikson (05:03):
It's a very wishy-washy answer, but I have reasons for this. Like I said, Redux is heavily associated with React, probably about 90% of the people using Redux are using React. And my estimates are that around half of all React apps are using Redux in some way. Certainly there's an argument that if you are using React, you ought to learn Redux at some point just based on the job market. But at the same time, we actually recommend that most people should not try to learn Redux until they're already familiar and comfortable with React in the first place.
Mark Erikson (05:39):
And there's a few reasons for that. One is that there's just a lot of concepts to learn in both libraries. And if you try to jump into both of them at the same time, there's going to be too much to learn. So it's easier to learn them if you focus on one at a time first. But also, once you understand what React is, you're going to understand state and props and components and re rendering. And once you have a good grasp on that, it's a little easier to understand where some of the pain points are with React and how Redux fits into a React application and what kind of problems Redux can help solve. So it kind of makes sense to do it in a little more of a sequence.
You know that saying, when you have a hammer, everything looks like a nail. I feel like in the early days of Redux, and I think in part thanks to Dan Abramov's popularity, and just the general idea that Redux was something you should always used for state management, sounds awfully like I'm blaming him or something, but that's not the intention. I just remember there was an egghead module teaching Redux in which Dan Abramov builds a sort of counter application primarily. And that maybe gave the impression that this is something you should use in the most simple of applications. When one thing I've learned over the years, or at least I think I've learned, is that Redux tends to lend itself better to projects as they become a bit more data heavy and complicated. And perhaps there are exceptions to this rule, right? But for the most part, that's my impression. What do you think?
Mark Erikson (07:11):
Oh, I have so many different thoughts here. We could spend multiple episodes on this. There's a bunch of different factors. So number one, Dan never really tried to heavily promote Redux. In some ways it was almost like a conference demo example that took off far beyond what he ever imagined. He actually did legitimately build it. And he did try to build it in a way that people could use it. But Dan was not out there like telling people that they had to use Redux or that if you're using React, you must use Redux or that you have to put everything in Redux. The community did that. There was a whole series of libraries based on this Flux architecture concept that came out in 2014 and 2015, and Redux really was the best version of that idea. And so it killed off other Flux libraries at the time.
Mark Erikson (08:01):
And then it sort of took on a life of its own where you had senior developers coming in and telling everyone else on their team, oh, we're going to use Redux. You have to be using Redux if you're using React. And then you've got all these new programmers coming in and being told they have to use this thing. And they didn't understand the background for, what is this thing? What problems does it solve? Why does it exist and why should I even care about it in the first place? Kind of the flip side of that. You mentioned that Dan's egghead videos show a small counter app. Those of us who have been around for a while are very tired of seeing demo apps that are a counter or a to-do list. But there's good reasons why we use those as demos.
Mark Erikson (08:46):
You want something that can show the basic mechanics and the data flow of the tool that you're trying to explain without getting bogged down in a bunch of unnecessary details. And a counter is going to show the most basic process of, I have a little bit of state, here's my process for updating it. Here's how I know when it's changed. Here's how I get the value and display it. And a to-do list. What do we do on the web and in application development? We get arrays of data and we show lists on the screen.
Mark Erikson (09:23):
We do basic crud. We add items, delete items, show items, select items. And a to-do list is the most basic thing you can show that illustrates that process. And you can flesh out a to-do list example in a lot of ways. You can fetch them from the server. You can persist them in local storage. It's overused as a concept, but there's a good reason why we do it so that we can show the process and compare different tools back and forth without getting bogged down in, oh, I'm going to add three different levels of styling the application and all this other stuff.
Well, there's a good project, isn't there, called TodoMVC? I think where it's the same to do app fundamentally, but in the GitHub repo there's a different folder implementing it with different frameworks and different data management tools. I'm pretty sure there's one for Redux, there probably are for other libraries too. But just to sort of summarize here, I think yes, there are some great reasons to teach with these type of apps and then maybe for anybody listening, it's important to take it with a pinch of salt essentially, and realize it's very much for demonstration purposes. But also you can make your own judgment when you have the problem. It's kind of up to you to reach for the right tool. And that's a scale much like anything else.
Mark Erikson (10:33):
I will say that the downside of using these smaller kinds of example apps is that, like you said earlier, Redux is a little more useful when you have a slightly larger app with more complicated data flow. And a counter app or a to-do app using Redux is probably going to look over engineered because it really is over engineered. Last year, I rewrote the Redux documentation tutorials from scratch. There's now two different tutorials. There's one called the fundamentals tutorial, which starts from the first principles. Here's how all the pieces work from the ground up.
Mark Erikson (11:10):
And that one does actually build a to-do app. It's a little more complex one, but it is a to-do app. And it's because I'm trying to focus on the moving pieces, what they are and how they fit together. But I also wrote one called the essentials tutorial, which dives right into using our newer Redux toolkit package, which is now the standard way to write Redux code because it simplifies a lot of the common tasks. And I wanted to have an example there that was more real world style than just another to do app. So I ended up designing an example that's sort of like a little Facebook, Twitter style, social media clone. Partly because that's something we're all familiar with today, but also because it gave me reasons to write code that fetches data from a server, tracks a few different types of items in state. And so that allowed me to show off the reasons and the use cases and the APIs in a more realistic kind of way.
I think there are a couple of other use cases for Redux. Like some people use it to manage a piece of data globally, like a theme setting or a language setting or something like that, that every component deep down in the hierarchy needs to access. And you would otherwise have to drill many layers deep. I've also learned that Context API is something we can use to achieve this as well. And so I was wondering your thoughts about the Context API versus Redux, and if it's even a fair comparison at all, for that matter?
Mark Erikson (12:45):
This is a very, very common question. And I think there's a number of things that need to be unpacked here. I am a very big proponent of the idea that you should try to understand what kind of problems is a tool meant to solve? And when does it make sense to use or not use a given tool? And in a lot of cases, it helps to understand when and why was this created in the first place? So Redux itself is a tool for managing state. Now it's a very generic, low level tool. You can put literally any kind of data in Redux. You could put the current user, you could put a theme color, you could put a list of items fetched from the server. You could put, is the dropdown open? Although that tends to be a little too small or granular.
Mark Erikson (13:34):
So you can use it for almost literally anything. And there's many reasons why you might want to use Redux. You might want to use it so you can track data outside of the React application componentry. You might want to use it so that you can share logic across different applications or so that you can access that data in any component in the app. What I've tried to encourage more recently is that the best reason to use it is to understand, like I said earlier, when, where, why, how state is getting updated and the fact that you can access data globally is almost just kind of like an extra little side benefit. React has two main ways to pass down data. One is props, when a parent component renders a child, it says I'm passing in items, A, B, C, just like you would arguments to a function.
Mark Erikson (14:25):
But many times we need to access the same data in several deeply nested components. We could pass that data down from grandparent to parent, to child, to grandchild as props all the way through, but that can get a little tiring to do so, because you have to do it each step of the way. So Reacts Context API lets us take one specific value, put it into a component called a context provider, higher up in the tree. And now any component that's nested deep down inside of that can say, I want to have access to that context value and React kind of like magically wormholes the value from where it's provided up top to where a component wants to grab that down below. If you've ever heard the term dependency injection, Context is kind of a form of dependency injection. I want this value, give it to me.
Mark Erikson (15:22):
I don't care exactly where it came from as long as it's there when I need it, that's all I care about. And there is a little bit of a parallel between what Context can do and what Redux can be used for. Both of them let a component deep in the tree say, I want to grab this value, give it to me. But the real difference is that the only thing Context can do is passing down one value so that other components can grab it. And then if you pass in a new value to that provider component, the components that are reading the value will be re rendered and updated. Redux does a lot more than that. Redux is a store that contains some current data, the logic for updating that data, the ability to run additional side effects, the ability to inspect the history of changes to that data over time.
Mark Erikson (16:19):
So there's a little bit of overlap in what these tools can do, but they're really very, very different tools with different purposes. And I think that's the biggest problem is that people see that they can do this one similar thing and they assume that they're replacements for each other. And it's more what they can do is two circles that have a little bit of overlap, but they're actually very, very different. And so I've written a number of articles trying to help explain the differences in what are these tools meant for, why would I want to use it and how are they different? There was one in particular I wrote earlier this year called Why React Context is not a State Management Tool and Why it Doesn't Replace Redux. And that's usually where I point people to try to help explain the differences between these tools.
If you're enjoying this episode of the Scrimba podcast, please remember to share it with your community, followers or even a friend. Word of mouth is the single best way to support a podcast that you like. So thanks in advance. Also, remember to subscribe in your podcast app, it could be Spotify, Google podcasts, Apple podcasts, or any other well known podcast app. We've uploaded every Tuesday since June, 2021 and you never know which episode might inspire you on a slow day or spark an idea that changes it all. So Mark, you're a maintainer of Redux. You have a very established tech career. Is it fair to assume that you basically never have to google anything?
Mark Erikson (17:53):
Oh man, I literally could not do any of my job in or outside of work without Google. I have dozens of Google tabs open at any moment. There was one task I worked on a few years ago where I wanted to rewrite the history of our git repository to strip out a bunch of files that shouldn't have been added to the repo over time. I knew the basic idea of what I wanted to do. I knew it was possible, but I didn't know the exact mechanics of how I wanted to do it. And I also didn't know how to make this tool that I was writing do it fast. I googled up dozens of articles and ended up kind of picking out pieces from several of them to assemble my own solution. Another one I can think of, I was trying to solve a particular bug in the React Redux library a couple years ago.
Mark Erikson (18:41):
And the problem was, it was breaking when it was used with React Native. And I think a similar question had popped up on Twitter earlier in the day. It's like how much do different engineers actually google in real life? And so just for kicks, I ended up recording every single thing I googled that night while working on that task. And it was like 25 different things. I think I actually wrote that in a GIST somewhere and I could probably pull it up later. So no, you are not, as a programmer, even a senior programmer, you will not know everything. The programming field is simply too big.
Mark Erikson (19:19):
To me, one of the best possible skills you can have as a developer is being able to search for information efficiently. You have to have some idea what want to look for in the first place. You need to be able to look at the results, narrow them down, identify what things might have useful information, read through them in more detail, pick out the pieces that do matter and then use those and your own brain to assemble the solution for whatever actual problem you're dealing with. Whether it's looking at some stack overflow questions, searching through five year old GitHub issues, or literally just googling things. Searching for information and learning as you need it is one of the most valuable skills for any developer of any skill level.
Yeah. And it's not something thing that you can watch a course about and be immediately better at. It's something you kind of often learn as you're doing it. Maybe it's hard then to teach as well because if you learned it just by virtue of doing it, it's not always the easiest thing to then go back and explain.
Mark Erikson (20:26):
I actually wrote a blog post, I think earlier this year, about how to search for information efficiently. I actually actually made the observation, look, I first got on the internet in the mid nineties as a teenager, I've been doing this for a while. It's natural to me, but here's kind of like what I've learned about how to search for stuff.
Let's link that in the show notes, definitely. Another approach to googling is like, when you have an error, you get a stack trace or something in your inspect elements and now you have to google it. And so you copy and paste the stack trace and you paste that into the Google search. But at that point you don't really find anything sort of meaningful. Do you have any advice as to how to break that error message down and find the result that you might benefit from?
Mark Erikson (21:07):
So Shawn Swyx Wong actually wrote a post over on the dev.to site about two years ago. It was either like how to google your errors or don't panic or something along those lines. And he actually gave some advice for how to handle that. So I definitely recommend that we link that one as well. The first thing to understand is that when something breaks, there's a reason for it. Now it may not be a very easy to understand reason, but there is a reason. You are a person with a brain. You can figure this out. A lot of it is when you look at the actual stack trace, the first thing to try to do is look, is try to identify what part of this actually matters. A lot of times we're using like a third party library, whether it be React or a Java web framework on the backend, or even like a type script error or something.
Mark Erikson (21:59):
It may be 95% of the information is irrelevant. So you kind of need to look through it line by line and start by just trying to identify what piece of this actually matters. So if I have an error in my own code, I probably want to look for like a file name that is something that I wrote, or at least is in our own application versus something that looks like it's from another library. Because I want to know where in my code is this happening. But also literally look at the error. If something says, cannot call prop function map of undefined, that tells me, okay, I probably have some code that thinks this thing is an array.
Mark Erikson (22:41):
It's probably trying to loop over that array. But the thing that it thinks is an array doesn't actually exist in the first place. So now the question becomes, where is that data coming from and why is it not actually a real array? So narrow down what piece of information is relevant. Identify where in your code there's a problem. But then also, actually look at the error. There's there's been so many times I've been answering questions where someone just pasted the error and said, help. It's like, did you actually read the error message? I don't expect you to understand every bit of it, but there's a very clear error in that message.
It's kind of like the, it made me chuckle a bit when you were quoting Swyx, who's been on the podcast by the way. So we'll also link that episode in the show notes. Yeah, great guy. It's just that when you said, when you read don't panic, that made me chuckle because that's it, you see this huge red error, you're like, oh, I can't possibly understand this. What are all these lines? But then your advice and also parts of Shawn's is to just calm down, read it carefully. There's definitely something you can understand within there. Even if it's just identifying the line in your code for triggered the issue.
Mark Erikson (23:53):
Another tip I've learned is that like type script errors are notoriously hard to read. It helps if you read them bottom up. Type script tries to kind of narrow down, like here's the entire reason this type is wrong, because this reason, because this reason, because this reason, and it eventually gets down to well, you said field A should be a string, but you're actually passing in field A as a number. And it goes through like 15 steps to get down to that point. So if you actually kind of read it starting at the bottom, you might actually have a better chance of understanding the exact reason why something went wrong.
Mark, I think that's all we really have time for today, but I genuinely really appreciate you coming on the podcast. I think it's been a great sort of teaser about some of the other information that's out there. I mean, we unsurfaced a few interesting resources that we'll link in the show notes. But I also know that you have a blog, which is a treasure trove of both content on Redux, as well as your coding career. For example, I know you have a post about journaling as part of being a developer and how that can help you sort of maybe answer your own questions in the future and certainly be something to rely on during performance review season. I won't reveal too much about it, but we'll also link that as well as the series, since there's going to be a lot to learn. Again Mark, thank you so much for your time.
Mark Erikson (25:07):
Thanks. I really appreciate it. And honestly, my biggest advice to folks out there who are earlier in your career, there's a lot of information. You are not expected to know everything, but the more that you can do to take some initiative and learn how to search for things and try to tackle problems on your own, that will help you grow so fast. I have a computer science degree. I learned a lot of useful things in college. But basically everything I do today is stuff that I learned on the job or in my free time as I was trying to solve real problems. So go out there, try to build something, stub your toe, run into a wall, search for info, work around it, and it will definitely help you grow in your career.
Mark Erikson, thanks again.
Mark Erikson (25:57):
That was Mark Erikson, a seasoned developer, writer and maintainer of the ever popular Redux library. We hope you enjoyed. This episode was edited by Jan Osinovic and I am your host, Alex Booker from Scrimba. You can follow me on Twitter @bookercodes where I shall highlight some of the podcast and other news by Scrimba. Subscribe and I'll see you next week.