Kent consumes as much information as he can about the thing that he's interested in, then he builds stuff with the things that he's consumed. The consumption process involves glancing over any related content or diving deep into a tutorial.

But then you actually have to build something, and not just follow a tutorial, but actually build a thing that you made up in your mind. Don't follow a tutorial. Then, go off and teach the things that you learned through blogging, meetups, podcasts, conference talks, etc. 

People learn in different ways. By recording your content in multiple mediums you are enabling a larger portion of your audience to learn more effectively.

But, creating content isn't just for brand-building, it is also an effective way to solidify knowledge for yourself. If you are asking yourself at what skill level should you start creating content then you should remember that creating content is for anyone who wants to learn and not forget stuff.

Kent attributes a lot of his success in becoming independent to building his personal brand. He double dipped with the value he produced while employed by creating content to share publicly. Kent also made sure to interact with people and answer questions on twitter. 

The key is not to try to get as many followers as possible, but instead to try to have an audience who is committed to you and your message. You can't do this by trying to force engagement with viral tweets, you have to produce real value and share it with people.

The only thing that matters in software is the experience of the user. And, even though the user will never see your code, the quality of it actually affects them indirectly.  The reason that the user cares about how you write your code is that it affects how long it takes to get new features out the door. Something that takes three weeks might only take a few days if the code was written in a more maintainable way and optimized for changes.

There are many patterns that we can use to make our code more maintainable, but the key is to know when to use them. If patterns are inappropriately used, it can lead to the code actually becoming harder to make changes to. For example, sometimes it's better to have a small amount of duplication than it is to create a hasty abstraction.

Kent amplified the impact of his work by making stuff he'd do on the job public. Instead of sending an email to engineers he would write a blog post and link them to it. He made a closed-source project open-source so he could work on open-source on the clock. And, he gave his workshops to PayPal employees so he could improve his workshops on the clock. 

There are stages to the impact of value. You have some value in your head. Somebody asks you a question, and you communicate it to them. You've created some value. The impact of that value that was in your head has increased to that one person. But let's say that instead of just communicating that value to one person, you schedule a meeting. Now that impact has been spread across these ten people in the meeting. But, what if you record that meeting? Then that value can be distributed across multiple teams.  Now let's say instead of communicating the value directly, you write up a blog post. That value can now be distributed everywhere.

Automation is another thing you can do to increase the impact of your value. Even if you don't save yourself any time by automating, you are still increasing your productivity since you aren't making as many context switches.

Open-source projects are great. You have complete control of the project, or so you think. It's very easy to find yourself losing control of the amount of time that you spend working on the project. It's also very easy to get caught up in the feature requests people are making. 

Kent had to learn how to only spend just enough time on a project. Now, the only issues that he addresses are issues that he runs into that he is personally experiencing. Sometimes he will also work on stuff that he thinks will be fun. But, the point is is that he only works on things that he personally needs to be done.

One of the biggest myths is that being a 10x Developer is all you need to have a successful career. You can't just be good at coding, put in insane hours to achieve senior status, and be set for life.

If you want to control your career, you have to realize that programming is not just about typing keywords on a keyboard. Programming is much more about communication and being effective at marketing yourself.

Pay attention and listen to those who have a position that you want to have one day, even if their discussions aren't relevant to your current work. You will learn about the problems they face in their day-to-day work and how they work together to solve them.

You also have to put yourself out there and volunteer for work that you're interested in. If you're on the backend but are interested in a front-end task, you should ask, "Can I work on that one?" Nobody knows what you're interested in until you tell them.

But there's a point where you'll want to do things with your career, but your current job can't do it for you. At that point, you have to move on to somewhere that can. When you move-on, the most important thing is going to be to make sure that your company can provide you what you want from your career.

The relationships that you build along the way are critical as well. Genuinely praising your co-workers and also sharing your accomplishments pays big dividends.

When Kent was first looking into React, it was like it was what he was trying to make Angular do with Angular Formly, just without all of the framework getting in the way. React allowed Kent to use JavaScript to build his app rather than work around the framework to make it. He began to see the indication that Angular Two was not going to fix what he didn't like about AngularJS. It was at this point Kent started planning on switching to React at some point.

Kent has been teaching React pretty much since he first learned it. He started by teaching it to co-workers and then at paid venues.  Kent has learned a lot about teaching React and has read a lot of research on making people understand it.

In Epic React, you will learn React's basics to super-advanced topics and even experimental topics like Suspense. You'll then be given a real, practical scenario to apply what you've been taught to an actual application.

Epic React has 25 hours or so worth of content for you. You watch a video, and then you spend the next 20 minutes or 30 minutes fixing or solving a problem. In the video, you aren't taught concepts that you need to learn to solve the problem. Instead, you are given the resources you need to learn those things. It's as if Kent hired you to solve the problem for him, and it is up to you to figure it out.

You must struggle. If you don't struggle, you're not learning. But confusing isn't good. The point isn't for you to be confused, but to work hard and feel a little uncomfortable.

Finally, Epic React presents you with a capstone project where you will apply everything that you've learned to an actual codebase with a real backend. This is where you'll bridge the gap from incrementing a counter to solving real-world problems.