You Do Have Time to Build it Twice

Rate this content

If you don’t have time to build it right, when will you have time to build it twice? In hyper growth startups the old adage breaks down. You get an expanding time horizon – IF you can get it shipped. An imperfect feature next week beats the perfect feature 2 months from now. Your code won’t matter if you’re dead. I didn’t believe this until I saw it myself. A startup on the cusp of hockeystick hired me to rewrite their jQuery app in React. Their tech proved the idea then became a burden. Over the next year we rewrote the whole app from scratch, grew a team of React experts, created a codebase that’s a joy to work with, and got the company to a $100,000,000 Series B. All because the early engineers knew that if the crappy version works out, there’s going to be time and resources to fix it later. This talk is about what I’ve learned while rewriting an app with users banging down the door.

21 min
17 Jun, 2022

AI Generated Video Summary

Today's Talk focuses on software rewrites, specifically the transition from jQuery to React. The speaker shares their experience of rewriting a jQuery app to React, highlighting the benefits of the rewrite in terms of improved user experience and increased conversions. Approaches to software rewrites are discussed, including the page-by-page approach which allows for product innovation. The speaker emphasizes the importance of prioritizing rewrites or refactors for startups. The Talk concludes with insights on testing, server-side functionality, and the overall value of the rewrite.

1. Introduction to Software Rewrites

Short description:

Today, I want to talk about software rewrites. Later is the magical time when everything can happen, with more money, a bigger team, more experience, and a better understanding of the problem. We rewrote a jQuery app to React, which didn't slow down team velocity but actually grew the company. jQuery is still popular, with 84% of production JavaScript using it. React has won the Framework Wars with 8% of production JavaScript. The objection to rewriting from scratch is discussed, using the example of Netscape losing to IE.

Hey, everyone. I'm Suez. I'm a software engineer, author, and you can tell I'm legit because there's a big screen behind me. So today I want to talk to you about software rewrites.

Who has seen this quote before? If you don't have time to build it right, when will you ever have time to build it twice? I couldn't find an attribution for this quote because so many people have said it. What I want to tell you today is that you will have time to build it twice later. Because later is the magical time when everything can happen. Because, at least in a growing company that's doing really well, later also comes with more money, bigger team, more experience, better understanding of your problem, and just, later is this magical, magical time.

The story I want to tell you about is how we rewrote a jQuery app, yes, a jQuery app in like 2020, from jQuery to React, full rewrite, we went from scratch, and while we were doing not only didn't slow down team velocity, we actually grew the company like four or five X and got a $100 million Series B round that was announced on the famous NASDAQ screen, which by the way, doesn't happen just for IPOs. If you know the right people, you can just pay them a hundred bucks and you're on there.

So I know, I know, I know, I said jQuery and who here has used jQuery in the last, who remembers using jQuery. Okay, okay. Who has used jQuery in 2020 right before the pandemic? Okay, we have three hands. Nice. So I know jQuery is bad, but it's actually still super popular. This is what I tweeted right after SWIX, Shawn Wang gave a talk at in San Francisco a couple months ago. It turns out that 84% of production JavaScript is still jQuery. And he has this nice graph which, okay cool, you can see it. If you look at the graph, there's like jQuery, 84%, then you have jQuery, Migrate, and I don't know what even that is. And then React is at like 8% of production JavaScript. However, that still means you're at the right conference because React 1, because none of the other frameworks are on the graph. So, at owning 8% of the web, React has won the Framework Wars, yes, amazing.

The other objection you might have to rewrite and starting from scratch is if you've ever read this blog post that came out in 2020, no, sorry, not in 2020, in the year 2000 back when blogs were still popular, this Jolon software guy who later went on to make stack overflow and a bunch of other things wrote a really cool article called Things You Should Never Do and he essentially explains why we're not all using Netscape right now. Who remembers Netscape? Okay. Who has actually used Netscape? Nice. Okay. So there's a couple of you. He makes the argument that Netscape was winning the browser wars until they decided, you know what, Netscape 4 kind of sucks. We're going to write Netscape 5 from scratch. And then IE came in and ate their lunch.

2. jQuery to React Rewrite

Short description:

When I joined the company, they had a jQuery app with 100,000-200,000 lines of code. It was difficult to work with, using global variables and magic mixins. We decided to rewrite it using React, without server-side rendering. The new app not only looks better but also has more conversions and happier users. The rewrite allowed us to improve the product and leverage what we learned. Writing software is like kicking a can, exploring and solving problems incrementally. Our rewrite involved changing and updating things based on user feedback.

So the story about the jQuery to React Rewrite. When I joined the company was like June 2020, and they had this little app. Will it play? It's playing. Okay. So this is a jQuery app. It's recorded in mobile mode because that was all that there was. If you open this on a full screen, it would still look just as wide as it looks right now. And this was about maybe 100,000, 200,000 lines of jQuery code. Nobody exactly knew where any of the functions were. If you tried to move anything, it would basically blow up in your face. It was doing all of the best jQuery stuff, global variables, magic mixins that just create new code. And a lot of it was working on the frontend. And actually, here's the super funny part. When I came into the company, I was like, okay, we got to rewrite. We're going to make a React-based SPA, no server-side rendering, et cetera. Now server-side rendering is popular and all of this was actually rendered on the server because that's how you use jQuery. You take express, you spit out a bunch of HTML, then you add global jQuery variables and functions and it works, kind of.

This is what we have now. It's a little better designed. I think it looks better. There's some loading spinners. We're actually using React Query, which solved a lot of our problems. That was one of the nice parts. And the other than looking better, it also has more conversions, users are happier, our NPS scores, that's the net promoter score about how much users enjoy your company, your product actually went up. And the point I'm trying to make here is that we didn't just rewrite the app from scratch, we also used everything that we learned to improve the product itself and the rewrite was what gave us the ability to rewrite.

So, and that's because writing software is kind of like kicking a can, you know, when you're walking, it's a nice Sunday, the sun is shining, and you're walking down the street and there's a can, and obviously, you walk over and you kick the can. And then you keep walking and the can bounces around and goes to the other side and you kick it from this side, and you're kind of like going where the can is going, right? And that's kind of how software works as well. Software is all about playful exploration and discovery of your problem space, kind of like kicking a can, you know, okay, I have this little problem and I'm going to solve it, you kick the can a little further down the road, then you go where the software takes you, and you're like, okay, I now know better, I have to try to kick it more into that direction. So, that's kind of what our rewrite was all about. We were changing things, we were updating, getting feedback from users, and that's the important part, because when you have bad code, the level of effort it takes to make a change goes up exponentially.

3. Approaching a Rewrite

Short description:

Building a good version of an app takes time and effort, but it's easier to make improvements once you have a solid foundation. React offers flexibility and ease of code maintenance compared to jQuery. The opportunity space lies in the balance between fast development and quality code. Startups must prioritize completing rewrites or refactors before it's too late. Approaches like the Strangler pattern or the Ship of Tethius rewrite allow gradual code replacement. Two common approaches are top-down, replacing entire pages, and bottom-up, creating a React island within the existing app.

You're usually building the first version of a crappy app is super easy. You can do it overnight, you can do it like a very first prototype, you can do overnight you're like, all of you amazing people. I can't, I'm old. So you make the first version, and it's super fast, and you get it onto the market. But if you took the time to build a good version and you tried to follow all the best practices, all of the textbook advice, it would take you a really long time to build. It would be harder to get started.

So that's the good code curve, it's way hard to get started, but once you have it, it's easier to keep going and to make improvements, because like, especially with React, one of my favorite things about React, comparing the jQuery code to the React code, was that with jQuery, I don't want to touch anything. If you move a function to a different file, you have no idea what's going to break. With React, you can just jump in, grab a function, and because it's all self-contained and just relying on props and all of that, you can just move it somewhere else and VSCode fixes your imports and everything works great. So you get a lot of that flexibility which then once you have a lot of code and more engineers, it makes it easier to work together.

But that space in the graphs, where the bad code is fast to get started and then gets really hard, and the good code is slow to get started and then gets really easy, that is what I would call your opportunity space. If you, crap, how was I going to explain this? So, that is your opportunity space is there. That's where you can get a lot of feedback very quickly and start using it in a rewrite that lets you improve and get better code. And what you're hoping to achieve is that before those, before the two lines intersect, if your rewrite or if your refactor or improvements aren't ready, you die. And that's the fun part of working at startups. It's like, either we get it done or it doesn't actually matter because nobody cares about a startup whose code isn't used anymore. I could use a really punchy example there. But anyway, how do you approach a rewrite, right? I'm sure, actually, who here has advocated to stop working on features and go rewrite the code? Yes. Who has an engineering backlog that you never get to? Exactly. And the reason that happens is because the business people aren't as stupid as you might think. You don't have time to stop the company and just go work on tech debt, because that is how Netscape died. It wasn't because they were rewriting, it's because they said, we're just not going to have a new version of the software for three years while we do this. And that doesn't work. What does work is something called the Strangler pattern, or you can, I've also heard it called the Ship of Tethius rewrite where you slowly replace your code piece by piece until there's nothing of your old code left. I don't actually remember why it's called the Strangler pattern. It's not like about grabbing the old code and choking it until it goes away. It has a much, it has a nicer origin story. I think it's something about vines in the jungle. So, there's kind of two ways that you can approach this. Whenever you're building a new feature or adding functionality to your app, you can either decide you're going to go top-down, where you replace entire pages with new functionality, or you can go bottom-up, where you create something like, in my company, we call it a React island, where you essentially build a GQuery-like plug-in that renders React in a div.

4. Page-by-Page Approach

Short description:

The page-by-page approach to rewriting a whole app is easier and provides a smoother user experience. Users may transition between the old and new versions of the app, but as long as the design continuity is maintained, users don't mind the changes.

That actually works really well. If you're rewriting a whole app, if you have time to rewrite the whole app, the page-by-page approach is, I think, a lot easier. What we did was that for about maybe a year or six months, something like that, we had a kind of janky experience. Users would use the GQuery app, click a random button, and end up in the beautiful, redesigned React app, and then they would click another button and be back in GQuery land, which kind of looks terrible. As a user, it's like, what the hell is going on here? I think the biggest example of this in practice that I've seen was my bank, where the login page was amazing and beautiful, and then you click login, and you're in this janky old app that looks like it was designed 10 years ago. But I feel like, as people, as users, we're kind of used to these redesigns, so as long as the designers do a really good job, and they keep that continuity of design, or whatever you want to call it, the users don't actually care. They understand, yes, you know, a new BMW comes out every year and has bigger and bigger and bigger grilles, but it's still a BMW, you recognize that it's a BMW, you know it's a car, you know how to drive it, and the main things are the same, but the small things keep changing.

5. Benefits of Page-by-Page Approach

Short description:

The page-by-page approach allows for product innovation, not just code fixes. Starting with a skateboard and gradually building up to an amazing product is a rewarding process. Product managers love rewrites because they can focus on new features without dealing with legacy issues. Innovate on the product, not the pricing scheme. Despite the challenges, rewriting the app from jQuery to React was worth it, resulting in increased valuation. I'm writing a book on refactors and rewrites. If interested, scan the QR code for updates.

And the page-by-page approach also gives you an excuse or an opportunity to do product innovation. You're not just fixing the code, you're also fixing how the product works. You're starting with a skateboard, then you build a scooter, you turn it into a bike, then you have a motorcycle, and in the end you have an amazing BMW or Porsche, or just This cool car that everyone is going to love.

And the rewrite actually, in my experience, product managers love it if you do it this way, because they also hate dealing with legacy stuff. They would love to just have new features and they come to you with this great idea and you say, yeah, you know what? That's going to be really easy, we can just build it because we're throwing away all the old code and we're doing it in the new style that's faster to work with, so we don't have to deal with everything else, because let me tell you, at an older company we once had, like, we were dragging along about five years of product, of pricing model iteration and the PM came to me and was like, hey, can we add this new type of charging users? And I was like, yes, we can charge them a different way. It's going to take three months to add that. And we did unfortunately decide to add that and one lesson I learned is don't ever innovate on the prep, on your pricing scheme. People just want to pay by month and they don't care about anything else. It's just, it's not worth it. But do innovate on the product, do innovate on what the users are actually using.

Now, at the end of the day, we spent an entire year rewriting the app from scratch. Right now if you go to our thing, if you click certain buttons, you still go back to the old jQuery world, because we couldn't update the backend. And the question might be, was it worth it? Was all of this effort worth it? Was it worth putting in the effort to rewrite the jQuery app into React? And honestly, it kind of was. When we raised the round, like the hundred million dollar round, it was, our effort was essentially worth half a million dollars per employee, but the valuation went up to about three million. It can be worth it, if your company is on the right trajectory.

And please listen to the last line of my tweet over there. You're worth a lot of money to your employers, go negotiate that shit and get paid. And, actually, I'm right now writing a book based on this experience. It's going to go into a lot more depth on how refactors and rewrites work. And if you want to get notified when it's ready, that's the QR code for you. And that's actually all I had to say. Great job, man. Thank you. Yeah. Oh, there's lines on the floor. So, Swissec, refreshing talk. I was thinking of an experience I had when I was interviewing at a company that was now at the time where they were deciding to build their first prototype. And are we going to JQuery, bootstrap it, or are we going to properly build it? And for me, that was a hard decision, because I didn't want to go to them if they decided to go to bootstrap JQuery world. I'm a bit of a snob, maybe. But what made you decide to actually want to do it? So that's actually a really funny story, because the when the head of engineering pitched me to come rewrite their JQuery app to React, he said, we need to do this because it's impossible to hire engineers to come work on JQuery.


React Experience and Mobile-first App

Short description:

Nobody wants to do this. I get to design the entire React experience, set the future of the company. Joined when the React jQuery bit was already done in production. Good experience. Question from anonymous: Is the app still mobile first? Yes, it's mobile first, works everywhere and automatically adapts. Statistics show a shift from mobile to laptops. Protecting against scope creep: join a fast-growing company with users demanding innovation.

Nobody wants to do this. And yeah, that's why I went. Because it was like, yes, I get to design the entire React experience, the framework, set the future of the company, and I think it's worked out so far.

So you joined when the React the jQuery bit was already done in production? Okay. Yeah. So I joined when that was already ready. It was the best they knew at the time. It was the best that they was the fastest way for them to build it. Yeah. And then they're like, we need a React expert to come in and fix it for us. And you're the guy to do it. Nice. Well, good experience.

So we're going to jump into the questions from the audience. Question from anonymous. Is the app still mobile first? I think you showed it, right? Yeah. Right? So we're using a, like a CSS in components framework. Like I said, CSS and JS framework called Team UI. That's super responsive. So the app is mobile first, but it works everywhere and automatically adapts. And that was like one of the reasons we rewrote was because it would, we could make it easier to do that with modern tooling. But then do you still see in your statistics that like maybe nine out of 10 people still come on mobile because they're used to accessing the product from mobile. And actually that slowly went away. As the app started working better on browsers, people started coming on more on laptops. And probably also new users that didn't know that there was no desktop experience. Yeah. Nice. How do you protect yourself from scope creep when it comes to production, product innovation while rewriting? Right. Scope creep is mostly... Honestly the best solution I found to scope creep is to join a company that's growing really fast and has users banging down the door.

Testing, Server-side Functionality, and Conclusion

Short description:

We didn't have time to make the rewrite perfect, as we were losing users by not being able to ship quickly. Some tests in the old app didn't apply anymore due to the app reimagining and improvement. The server-side functionality was handled by an Express app, using API calls instead of rendering HTML with jQuery. The backend team did a great job. Thank you for your time.

Yeah. Because then everyone is on board with, okay, let's just get this out quickly. We don't have time to make it perfect because we're literally losing users by not being able to ship. That makes it really easy to tell your PMs, yo, we don't have time for this shit. Yeah, gotta get going.

And then in the Legacy app, were there any tests written or you just had to hope that what you rewrote was the same? There were some tests in the old app. The benefit of our rewrite was that the PMs also wanted to improve the product. So all of the old tests just didn't actually apply anymore because the features were different. It wasn't like a rewrite just from a technical perspective, it was also an app reimagining and improvement.

Yeah, okay, it wasn't a one-on-one rewrite. Yeah, it wasn't a one-on-one rewrite. So it's like, you know, you're turning a submarine into a boat, not a lot of tests still apply. Yeah, maybe one or two tests, this backend call is made, but that's it. Yeah, exactly.

Okay. And then, was there any server-side functionality? And if yes, what framework or library did you use? There was a lot of server-side functionality, because this was an Express app that was rendering HTML and then jQuery was taking over. So they had like, they basically had hydration before we knew about hydration. So all of the backend stayed. We turned it into API calls and we're now slowly rewriting the backend as well. It's written in Express, Node.js with plain JavaScript.

Okay, well, it sounds like some solid software engineering. Yep, the backend, they did a great job. Alright, so, that's all the time we have for SwissEx, so I'm going to thank you. Good to have you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.
10 min
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
Featured Article
Software engineer, lecturer, podcast host, author — is there something Emma Bostian hasn't done? She moved from America to Sweden, started working at Spotify, and took up a few challenges along the way. And now she has some career tips to share.

What led you to software engineering? 
I was raised in the ecosphere of tech because my dad is a software engineer at IBM, and my mom was a designer there, too. My dad always encouraged me to join STEM and take a look at computer science — however, I was convinced I wanted to be a medical doctor. In my first year of college, I declared a biology major and quickly realized I was not too fond of it. In my second semester, I switched to an actuarial science major where I took Introduction to Computer Science, and the rest is history. In my second year of college, I declared a computer science major and began my journey from there.
What is the most impactful thing you ever did to boost your career?
Writing blog posts and documenting my learning journey on Twitter has far been the best career boost. I wrote purely for myself to reference the things I learned over time, and I even utilized my design skills in Figma to create custom graphics depicting difficult concepts like CSS specificity. By sharing my blogs on Twitter and engaging with the people reading them, I was able to grow an audience extremely quickly. I began receiving conference speaking opportunities, podcast requests, and course invitations to teach with LinkedIn Learning and Frontend Masters.
Ultimately, I landed my job at Spotify through Twitter, too, when a friend and follower of mine asked if I would be interested in interviewing. Now I live in Stockholm working my dream job. It still blows my mind how tweeting about my blog led me to some of the most amazing career opportunities.
What would be your three tips for engineers to level up their career? 
First, be patient. I often see posts on Twitter or LinkedIn about developers who were promoted to a senior position after a year. And while this is wonderful, I think we forget that each company has a different standard for what constitutes a senior developer, and everyone's journey will be different.
Second, don't be afraid to ask questions. If you try your best to solve a problem or answer a question you have, but you can't figure it out after a reasonable amount of time, ask a team member or mentor for help.
And lastly, invest in the right resources for learning. When I started my journey, I didn't know which platforms worked for me to learn. Now, I have a few trusted platforms such as Frontend Masters, Free Code Camp, or Level Up Tutorials that I go to when I need to learn a new skill.
You're currently working as a software engineer at Spotify. What does a typical day of yours look like there?
I begin my day answering emails. Then we have a team breakfast and a standup remotely as we're all still remote at Spotify. After that, we might have a web tech sync with the other squads in our business unit. The day usually includes some form of pair or mob programming, depending on the work stream. 
My team always has Fika, a traditional Swedish coffee break, scheduled every afternoon. Every couple of Fridays, we have team games planned to release some stress. 
Also, I tend to have a lot of free time to focus, which is nice but makes for a boring answer to this question!
Do you have some rituals or tools that keep you focused and goal-oriented?
I'll admit that I've been struggling with staying motivated in the time of remote work. I've been remote with Spotify since onboarding a year ago, but my team is wonderful, and they help me when I'm down.
Apart from that, I use Todoist to keep track of my tasks, and, naturally, I listen to Spotify while working. But other than that, not really. Maybe I should adopt some new tools to keep me on track!
My current favorite Spotify playlist is Brand New Chill:
I also love Chillout Daily:
You wrote a book called De-coding the Technical Interview. What was the impulse to do it?
I wanted to give the community a manual of the essentials of computer science knowledge to ace the technical interviews. The book covers data structures like stacks, queues, or linked lists, tackles algorithms, and deals with systems design. You'll also learn about the interview process from start to finish, get tips on how to submit an amazing take-home project, or understand how to problem solve. You'll also gain knowledge on the frontend coding skills needed to excel at a frontend interview.

If you could stress one piece of advice on surviving a technical interview, which would it be?
Do not lie your way through an interview. If you don't know the answer to something, just admit it. There's no shame in admitting you don't know the answer to something. There is shame in faking it and pretending like you do know the answer.
What's the single best practice everyone who writes code should follow?
Remember that while you are technically writing code for computers, you're also writing it for humans. Your code should be readable and have as little complexity as possible without sacrificing accessibility or performance.
In addition to the book, you co-host the Ladybug Podcast. What inspired you to enter this field, and what are the podcast's main topics?
We talk about everything tech and career on the podcast, from Java and GraphQL to how to start a business and cross-cultural communication. The podcast is a way for me and my co-hosts to share our experiences in tech, having taken different paths. And I'm really glad for doing it — it has allowed me to meet so many incredible people, learn many new things, and support my dream of teaching.
What pieces of your work are you most proud of?
My technical interview book was a huge feat for me as well as my courses with LinkedIn Learning on building a tech resume. I enjoy creating things that help other people advance their careers, so I'm also proud of my courses with Frontend Masters on design systems and CSS.
Follow Emma on Twitter
14 min
Kent C. Dodds: Consume, build, and teach — and level up your career
Featured Article
Even though his bio offers quite a hefty reading, he only applied for one job in his career. The rest came along as he was building his name as a renowned speaker, teacher, and a prolific figure of the open-source community. How did Kent do it? “Commit to creating high-quality content,” he says.

What led you to programming?
I had a friend when I was a teenager who was really into it, and he tried to teach me. But I just couldn't get it — it didn't make any sense to me. So I never really thought I'd get into programming, but I liked computers a lot, and I ended up going to school for electrical engineering. 
Well, that didn't work because I'm not good at math. But right when I started the program, I got a job at a company uploading videos to YouTube and that sort of thing. The work was tedious, so I decided to write a computer program to automate lots of the work I was doing with the knowledge I had about programming. And that was the first spark of things for me to use programming to solve real-world problems. 
What is the most impactful thing you ever did to boost your career? 
Committing to creating high-quality content. That might sound obvious because I'm a full-time educator now, but I would not have gotten my job at PayPal if I hadn't been so active with my blog. In fact, lots of my jobs came out of me being involved in the community around meetups, conferences, or open-source projects. 
How do you choose topics for the content you create, be it for your blog or podcast?
I don't think too much about the content other people are creating. And I don't often consume it. My ideas come from the things that I'm working on, things that I'm learning myself, or — when I was working with a team of developers — the things that I had to remind people of in code reviews regularly. Anytime that I would have a code review comment that was pretty long to describe my position, that was an excellent opportunity for a blog post. Also, if people ask me about a topic regularly, I'll make a blog post rather than answer that question multiple times.

What would be your three tips for engineers to level up their career? 
The number one thing I tell people is to be a nice person. I know that sounds fluffy or silly, but it cannot be overstated. You will get so much further in your career and just in life in general if you're a nice person. That doesn't mean that you take people being jerks lying down, but how you interact with others is out of kindness. You could be the best engineer in the entire world, but if you're not a nice person, you will not reach your full potential or accomplish your goals, whatever they may be.
Second, it's just as important to decide what you are not going to learn as it is to decide what you are going to learn. You could jump into countless things — and there are successful people who are polyglot programmers, but I can't speak to that a whole lot. All I can tell you is that in my experience, focusing on specific things that I want to be truly good at has worked out great for my career. That doesn't mean that I closed myself off to other things. With my website rewrite, I have been doing a lot of dev ops-related work and a lot of back-end stuff that I've typically not been involved in. You want to keep your head up on what's going on outside of what you're doing so that you know what direction to go in when you come across problems you need to solve. However, finding a focus on what you want to be good at has helped me a lot. That way, you feel a little less stressed.
And the third one? 
Learn how to learn effectively. It's a three-step process: you consume, build, and teach. The consumption of newsletters and Twitter and whatever inspires you, but you don't want to spend too much time doing that — implementing it into actually building something matters. This happens naturally if you work at a company, but maybe you're not making the things you want to learn, so you may want to start a side project. The building phase is where you get experience, but you also want to solidify that experience. How? You start teaching. You don't necessarily have to teach it to people, it could be stuffed animals. The goal of the teaching is to retain in your mind what you've learned through the building process.
What are you working on right now? 
The big thing I'm working on right now is a rewrite of my website. It'll be much more than just a developer portfolio — I'll have user accounts, and there'll be fun things that you can do with it. And because it's more than just a website, I'm using Remix, a new cool framework in the React ecosystem. I'm also working on updating my material on and a TypeScript course as well. 
So, whatever I'm working on, it ends up resulting in lots of opportunities for content.

Do you have some rituals that keep you focused and goal-oriented? 
I have a notepad where I keep all of my notes of what I'm going to do for the day so that when I'm checking things off, I'm not distracted notifications. I've tried apps for that, and that does not work well for me. 
I also am a firm believer in inbox zero. I have my work inbox and my personal inbox, and I keep them both at zero. And I kind of use that as a to-do list. 
And if I'm not feeling excited about working for some reason, I will often hop on my Onewheel, which is an electric skateboard that only has one giant wheel in the middle. It's just a total blast, and I'll hop on that with my backpack and a charger, and I'll go to a Starbucks or a park just to declutter my mind.
What things in the React universe are you excited about right now?
React version 18 is coming out soon. The experimental version is out there, and it's fun to play with. I'm just really thrilled that it's no longer a concurrent mode but concurrent features that you can opt into. Cool things like that will enable React server components in the future. 
But the biggest thing I'm excited about is Remix. That's huge. It eliminates a lot of problems that are solved well other tools, but when I'm using Remix, I don't have those problems, so I don't need those clusters.
You already said that teaching is an integral part of the learning process, and you stand your word since you're also a full-time educator. What inspired you to enter this field?
I have been a teacher for as long as I can remember. I grew up in a church where you talk in front of your peers from a very young age, and my mom was an elementary school teacher, so teaching has just always been a part of me. 
I really just enjoy sharing what I'm learning with others. As far as teaching technical topics, I gave my first workshop when I was still a student at Brigham Young University. With my fellow, we taught how to use AngularJS, and I got Firebase to sponsor pizza so they would show up, and that was pretty fun.
Then I started teaching on the side at right after I'd graduated. That was when I first got a paycheck for teaching. And I realized that teaching could be quite lucrative and support my family and me as a full-time endeavor. So I did it — I quit my job. I'm a very risk-averse person, so I'd done teaching as a side hustle for four years just to verify that I could make this work.
When TestingJavaScript was released, and I got that paycheck, I realized that I didn't need my PayPal salary anymore. I could just focus my daytime on teaching and give my evenings back to my family, which was a nice trait.

Apart from that, how has teaching impacted your career? 
Earlier I mentioned that pretty much all of my jobs came because I was perceived as an expert. After the first job, where I was an intern and then converted into full-time, I never applied to another. I worked for four different companies, and they wouldn't have recruited me if they didn't know who I was and what I was doing. My content is how they knew who I was — I just made it easy for them to find me. Teaching made that impact. It made my career. 
We talked about React and Remix. Are there any other open-source projects that you'd recommend keeping an eye on or contributing to?
I have some myself. React Testing Library is probably the biggest one that people are familiar with. And if React isn't your jam, then other framework versions of the testing library. 
React Query is also really popular. If you're using Remix, you don't need it, but if you're not, I strongly advise using React Query cause it's a stellar, fantastic library, and Tanner Linsley, the creator, is a stellar and fantastic person. 
What pieces of your work are you most proud of? 
Probably the biggest thing I've ever done is EpicReact.Dev. It has helped tens of thousands of people get really good at React, improve their careers and make the world a better place with the skills that they develop. My whole mission is to make the world a better place through quality software, and I feel like I've done that best with Epic React. 
There are things that I've built at other companies that are still in use, and I'm proud of those cause they've stood the test of time, at least these last few years. But of everything, I think Epic React has made the biggest impact.
Follow Kent on Twitter and listen to his favorite Spotify playlist
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)