On Becoming a Tech Lead

Rate this content

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.

25 min
09 Mar, 2023


Sign in or register to post your comment.

AI Generated Video Summary

The role of a Tech Lead involves shaping the roadmap, helping the team be more effective, and working on important projects. Lessons learned include encouraging idea sharing, avoiding taking on all the work, and focusing on delegation. Tech Leads focus on the outcome, involve the team in decision-making, and make plans based on how different pieces will interact. The role of a Tech Lead is to focus on engineering and guide the team in figuring out how the whole system should fit together. Architecting can become problematic when it loses touch with the coding part, resulting in implementation issues.

1. Introduction to Tech Lead Role

Short description:

Hi, I'm Suez and I'm going to talk about some lessons learned after becoming a Tech Lead. The role of a Tech Lead varies between companies, but it is often seen as a stepping stone towards becoming a staff engineer. Tech Leads are responsible for managing the technical direction of a team and force multiplying the team's efforts. They have the opportunity to be involved in decision-making and shape the roadmap of projects.

Hi, I'm Suez and I'm going to talk about some lessons learned after becoming a Tech Lead. Why you would even want to be a Tech Lead and what is it that Tech Leads even do?

So first of all, what is a Tech Lead? The definition or the job description of a Tech Lead kind of varies between different companies. Some companies think of this as one type of a staff engineer. Some people think of it as a stepping stone towards becoming a staff engineer.

And you know, the role is supposed to be one of the first or the most common ways of getting into the technical leadership track, which is sort of a parallel track to the management track where a lot of companies these days have a technical track where you go from junior engineer to mid-level engineer to senior engineer and there might be multiple levels of a senior engineer. And then it kind of stops. You can be a senior engineer basically for the rest of your life. It's usually considered a terminal title, which means that once you're a senior software engineer, we trust you to do work independently, to successfully follow business objectives and to get your stuff done.

And then you can go beyond that either on the technical track, which eventually, which goes to staff principal, distinguished engineers, and all of those people. Or you can go on the management track, which is engineering manager, VP, CTO, and that sort of thing. Like I don't know the exact steps. Usually there's a bunch of them between different companies. And where it really gets tricky is this fork in the road where you go from being just a senior engineer, or being a senior engineer towards something more. What is the next step? Often tech lead is the first next step that people take. And if you look at it as a fork in the road, it's usually, tech lead is usually more on side of the technical leadership track, staff, principal, et cetera, and team lead is the first step towards the management track. Some companies mix those two, but that's how it usually works.

The idea of a technical leadership track is that you are not responsible for managing people, at least not directly. You're more responsible for managing the technical direction of a team, especially as a tech. You're usually focused on a specific team, which means that while you're sort of still an individual contributor, your output is now being judged by what the team does as a whole, except that unlike a team lead or a manager, you're not dealing with the people management responsibilities. You don't have any direct authority. It's more about soft influence and directing people and helping, basically helping the team make good technical decisions to make sure that projects flow smoothly, that you're working with your product owner and kind of force multiplying the team. I would say that force multiplying is probably the main thing that tech leads do. Force multiplying is the main thing that tech leads do.

The question that a lot of people ask is, why would you even become a tech lead? What is it that makes somebody want to become a tech lead? Honestly, it varies between individuals, but for me, the main reason I decided to become a tech lead was that after doing this for many years, coding kind of became the easy part. I started looking for more interesting things to do than just banging out code, and one thing I realized while working on a team in a hyper-growth startup is that there is a lot more you can get done if you're not the person banging your hands against the keyboard. You can have a much higher impact, a much bigger contribution if you're helping the entire team get more stuff done and work on the right projects than if you're just the person taking direction and writing code.

And one way of having more of that impact is that as a tech lead, you get to, quote unquote, be in the room where the bigger decisions are made, where product owners and other technical leadership is deciding what is it that this team is going to work on next, what is it we're going to decide is important, what we're going to focus on. If you're in that room, you can help shape the roadmap and you can help with, you know, simple things like, hey, we have these five ideas. Which of these is actually achievable within a certain amount of time? And if you're in that room, as a tech lead, you can say, hey, that would take, I don't know, like maybe a couple of weeks. That one is really easy. That one is really hard.

2. The Role of a Tech Lead

Short description:

Being a tech lead allows you to shape the roadmap, help the team and company be more effective, and work on important projects. It's a different challenge than just working on sliced-up stories. The best tech leads are engineers who prioritize getting the right work done and making a positive impact. Reluctant leadership and a focus on what benefits the company and project are key traits.

So when you get to shape that roadmap, you get to help the entire team and the whole company as a result be more effective and get more done and make sure that you're working on the important things, which means that, you know, you have a bigger impact and that feels nice. It's an interesting different kind of challenge than just getting a sliced up story that's, you know, if you're doing Agile, you get a sliced up story, it tells you exactly what you need to do and you go and you get it done. If you're a tech lead, you get to be there way before those stories are even sliced. Sometimes before even anyone knows what the stories are going to be, you get to be in the room and help people decide what the stories should be, what the projects should be, and then help your team work on those. And I think the, what I'm trying to say basically is that it doesn't really matter how productive you are or how much code you can write if you are working on the wrong kind of project. And what I would say here is that the, I think the best kind of tech leads are the sort of engineers who will even get into leadership if that means that more of the right work gets done and more, more good stuff happens. So, you know, kind of at least I personally take a reluctant leadership approach. And some of the best managers I've worked with were always people who didn't see leadership and being a tech lead or a manager or those higher positions as, oh yes, that's the next step in my career. I got to do it to grow. The best people I've seen who take on that role are the people who will even do that if it means that everything is going to go better for the company and the project.

3. Lessons Learned as a Tech Lead

Short description:

Lessons learned as a tech lead: 1. Be the clown to encourage idea sharing. 2. Avoid taking on all the work and focus on delegation.

So what are some lessons that I've learned while doing this role? Keep in mind, these are early lessons. I'm a fairly new tech lead. So the nice thing about these lessons is that they still come from a perspective of remembering what it's like not to be a tech lead rather than, you know, 20 years later when it's like, huh, what was it actually that felt new about being a tech lead?

So the first lesson that I learned is that usually the person who becomes a tech lead is the strongest engineer on the team, or at least usually they're a very, very strong engineer. So what you can do as a tech lead to kind of help the rest of the team and empower them is to be the clown. When some, when, you know, the manager or the product owner is asking for ideas. One of my favorite things to say is, well, okay. So we need immutable data, but let's not use the blockchain. You know, funny joke, ha ha. But it's also setting the floor for what a dumb idea looks like. Because you're a tech lead, you have a lot of so-called reputation that you can burn or karma points. So, you know, if you make a stupid suggestion, nobody is going to think that you're stupid, but it frees up everyone else on the team to give their ideas because they know that they can't say anything stupider than what you just said, which then brings out a lot of their ideas, makes it easier to collaborate, and make sure that nobody feels afraid about sharing what they, what they might think is a stupid idea, but is actually a really, really good idea, and a great solution for whatever problem you're solving. So being the clown works really, really well.

Another one is that engineers who get to being a tech lead, they're, you know, strong engineers, they take a lot of ownership, feel a lot of responsibility. I actually remember reading a study that said that feeling responsible and feeling sort of guilt, I've also heard it called tech lead's guilt, is that if you feel a certain kind of guilt towards not getting stuff done, that actually means you are great tech lead potential and staff engineer, etc. potential because you take a lot of pride and a lot of ownership and you try to make sure that you get a lot done. But that is also a trap because once you are a tech lead, you become sort of, quote unquote, responsible for the output of the entire team. So it's very easy to get lulled into the role of trying to be the hero and be like, oh, shit, that didn't get done. I'll just do it. Oh, that other thing didn't get done. I'll do it. Oh, crap. This project is going poorly. I'll do it. Oh, no, that engineer is struggling. I'm going to jump on a Zoom with them and get it and help them get it done. If you try to do the work of an entire team, you will burn out. So and I've seen this with a lot of my friends when they were early managers, they were like, Okay, cool, I'm managing a team of five people. And they were just doing the work of five people instead of delegating. So really important is to focus and think about doing less and letting your team do the work. You know, you're there to help the team be effective, not to do the teams work for them.

4. The Role of a Tech Lead Continued

Short description:

As a tech lead, focus on the outcome, not how the work is done. Show leadership and certainty to the team, even if unsure. Involve the team in planning and decision-making. Commit to a plan, but leave room for autonomy. Make a plan based on how different pieces will interact. Tech leads do more engineering than coding.

So do less, let people struggle, let them fail, let them fall flat on their face. If it's not working, you know, after a day or two days, let them be and then be like, hey, do you need some help and then jump in. But you don't have to, you really, you have to consciously avoid trying to do everyone's work and give away your Legos and let other people shine because I promise you, it's going to be fine even if they don't do it the way that you would do it, it's going to be good. Focus on the outcome, not on how the work is done.

And the next thing that comes out of this, I mentioned earlier, is, you know, working on roadmaps and future looking things. It gets really, really confusing once you are beyond the senior engineer stage. Companies, it turns out, and I think this is true across the board with anyone I've talked to who was in a leadership position, nobody knows what the hell they're doing. It's like, oh my God, we have so many priorities, we have so many big, critical, important projects. If we don't do that thing, the company is going to fail. If we don't do that other thing, the system is going to explode. If we don't make this customer happy, they're going to leave. And there's just so many critical, urgent things that feel like they should be the next thing you work on. But when you are presenting the team, you have to show leadership and yeah.

So basically it's confusing up there, but what you have to do for the team is to have that sense of leadership and kind of almost play act or present a front of certainty. Even though you're not sure if you made the right decision or if you're not sure you're working on the right next thing, once it gets to the rest of the team, once people start working on it, you have to show some level of certainty. You have to, even if deep inside you're not sure you're doing the right thing or you're not sure about the technical decisions that you've made, you kind of just got to go with it and commit to a path. You look at different possibilities, ideally when you're making plans for a specific story, you get everyone involved so the whole team is coming up with ideas and then when you have competing ideas, your job as the tech lead is to say, okay, that one is 60% bad, that other one is only 50% bad, let's go with the 50% option and then reassess if it's not working out in the next couple of hours or in the next couple of days, depending on what your story cycles are like. The idea being that you make a plan and you commit to a plan and then when you make these decisions you just hold them in your head. The rest of your team, it should look like you're mostly certain, you should explain your reasoning, you should explain that there are error bars in your decisions, but once a decision has been made, commit to it, don't try to flip-flop every couple of seconds or every time they come into a meeting and they ask you, hey, how should we do this? Don't change your decision or change your entire approach. But also really important, when you are making a plan with your team, is to leave enough room for the team to have autonomy and for everyone to feel like, not just feel like, for everyone to have space to contribute. Don't say, okay, for that button, you have to go to that file, change it to purple, go there to change it, to change where it shows up. You don't have to give them all of those details. You don't have to, and you shouldn't give all of the details to your team for what they're doing, because then you might as well just do it yourself. It's more like, okay, you take care of the button, make sure it's in the right place. This is the place that we want it to be. You go take care of the API, build the back end API for this. You go work on the middle layer where the button is talking to the API, and then when we get it all together, we're going to figure out how to assemble it. Make a plan more based on how the different moving pieces are going to talk to each other rather than what the actual moving pieces are going to be and then let your team focus on the insides of each individual moving piece and figure out how to build the implementation itself.

Which brings me to my next point, which is that as a tech lead, what you get to do is a lot more engineering and a lot less coding. And this is one of those things that it took me a really long time to realize the difference between coding and engineering.

5. Explaining the Role of a Tech Lead

Short description:

When you're engineering, you can work with a whiteboard or virtual whiteboard to figure out the moving pieces and how they should interact. The tech lead's role is to focus on engineering and let the team handle the coding details. It's important to ask good questions and guide the team in figuring out how the whole system should fit together. Going for a technical leadership position can be fun and allows you to work on interesting challenges and focus on higher-level things.

And the best way I have of explaining the difference is that when you're engineering, you can work with a whiteboard and, or a virtual whiteboard, or even post-it notes, and you can just draw circles, squares, arrows, and stuff like that on a whiteboard of some sort, or on post-it notes, and figure out what the moving pieces are, how they should interact, how you should, you know, a lot of this is domain modeling, how you should break down a problem, what are the steps that it will take us to go from a initial, valuable working solution to the full solution, so like how do you get from a skateboard to a car, which is an analogy for a moving vehicle that, or a people transporter, you start with a skateboard, you end with a car, and what are the steps that get you there? What are even all of the steps in a business process that people are doing, and how can you turn those into code software, and basically into software.

The tech lead's role is to do a lot of that breaking down, and less of the actual final implementation and coding. It's important that you still stay in the code, and that you do the work, and that you're hands on with the team. But what you're focusing on day to day is a lot more engineering, and then letting the rest of your team figure out the idly coding details, where they build the actual implementation.

This is one of those things where it's really hard to explain until you've tried it, but once it clicks, it feels very freeing. Because, at least to me personally, after I've been coding now for 25, 26 years, it's been a really long time. What I realized is that the more of these systems you build, the more you see the philosophy and the structure behind the actual code. And then you can kind of, in your head or on a whiteboard or with your team, just move pieces around and figure out what they should be and how they fit together without even knowing or caring about the final implementation of those because then the senior engineers and the mid-levels and the juniors and everyone else can work on the actual implementation after the overall engineering piece has been done.

And also, you know, it's really fun to code. So I personally still jump into a lot of the moving pieces, but I find that I'm much more effective and I have a much bigger impact and it's much more helpful to my team if I focus on the engineering parts and help them reason through the engineering parts. You know, sometimes it can just be asking good questions when you have really strong senior engineers that are really good that just need some guidance, you can ask them pointed questions to guide them into a certain direction and help them figure out how the whole system should fit together. And, you know, overall, I would totally recommend going for a technical leadership position and going on that track. It's honestly been the most fun I've had with coding and software engineering in a long time. It feels a little abstract sometimes and it feels like you're far removed from the implementation, but on the other hand, you also don't have to do the parts that feel boring anymore. It's really nice to just work on interesting new challenges and focusing more on the higher level things and figuring out what what's coming next, what to do in the future, which parts of the projects can be like swapped. Hey, you know what? This is a lot of work that we don't need to do right now. If we flip the road map around, we're going to get a lot more value ultimately faster, and we're still going to get everything done in the end. And I personally find that a lot more fun than just banging on a keyboard and, you know, and, you know, arguing on the Internet about the best way to write a for loop in JavaScript. So yeah, if you get a chance, try it out. It's definitely interesting. And it opens up a whole new world of possibilities and a new world of software engineering that as a senior engineer, maybe you didn't even realize was there.

6. Poll Results and Engineering vs Architecting

Short description:

The poll results show that beating fuzzy problems into concrete solutions is the most interesting part of software engineering. There is also appreciation for debugging and the curiosity to understand how things work. The difference between engineering and coding lies in solving fuzzy problems and implementing solutions. Architecting can become problematic when it becomes too abstract and loses touch with the coding part, resulting in implementation issues.

Thank you. Well, welcome. How are you today? I'm doing really well. Yes, join our virtual stage. Yeah, it's very comfortable up here. Yes, thank you so much for being here and for that, for sharing your experiences.

I'd love to dig into some questions with you now. First though, I want to discuss the answers to your poll question. So the question, you know, what's your most interesting, fun part of software engineering? 60% said beating fuzzy problems into concrete solutions. 24% were, hmm, that's weird. Why'd it do that? That was my pick, personally. 16% said writing code, and I'm actually, I'm personally surprised that 0% said debating tabs versus spaces, semicolons versus not, VIM versus Emacs, considering how many tweets I see about those topics. But what do you think of these results? Do they surprise you? Yeah, they're a bit surprising. Okay, there we go. We got somebody responding that they like the tabs versus spaces debates. There we go. But yeah, I, I agree, for me, solving fuzzy, fuzzy problems is also the most fun part. So I'm happy that other people agree as well. Nice. And I'm glad that there is also still some love for debugging and No, I was gonna say, if you know that joke that when you press, when a non-engineer presses a button and it electrocutes them, they say, Oh, shit, I'm not going to do that again. When an engineer presses that button, they say, I wonder if it electrocutes me every impression. Exactly. Yeah, we're like taking things apart and seeing how they work and then hopefully being able to put them back together. But if not, you know, that's okay too. So awesome.

So, all right. So, first question here from, from, from the audience is, says, you know, you make an interesting point about engineering versus coding, and then they use the term architecting specifically, what do you consider the differences between engineering and architecting to be? So, I, I think the difference between engineering and coding is primarily that when you're engineering, you're mostly dealing with solving the fuzzy problems and creating their solutions. Coding is like the implementation part of the engineering process. Usually these days we do both of, both of them kind of paralleling simultaneously. And then if you go into architecting, I think a lot of, where a lot of architects run into problem, into trouble, is that if you become too abstract, you lose the coding part and you start, I think we've, we've probably all experienced so-called architecture astronauts that have a really great solution on paper, great diagrams, great schematics. Now just somebody has to go and implement it and you write the first line of code and it all breaks apart because some basic assumption doesn't work.

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 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.
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: https://open.spotify.com/playlist/37i9dQZF1DX6uQnoHESB3u?si=380263b3c853442e
I also love Chillout Daily: https://open.spotify.com/playlist/7ozIozDp260fjNOZy1yzRG?si=66d6c839ec9b458a
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 TestingJavaScript.com 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 egghead.io 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
36 min
Effective Communication for Engineers
Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.
TechLead Conference 2023TechLead Conference 2023
31 min
Imposter Syndrome-Driven Development
“Maybe I’m fooling everyone… I’m not good enough for this, and at this point, it is a question of time until everyone figures it out” these might be the words that cross your mind as your coworker compliments you for doing another fantastic job at delivering a new feature. As you grow in your career, so does your uncertainty. You put in the extra hours, learn all the new technologies, and join all the initiatives you can, but at the end of the day, it never feels enough. At this point, that feeling is leading your actions and decisions. It is the thing that is driving your career. Only one question persists: Are you really an imposter?
React Advanced Conference 2022React Advanced Conference 2022
24 min
A Career As Software Engineer
Typically I talk a lot about deeply technical concepts like TypeScript, type systems, (im)mutability, MobX, Immer etc. But this time it's going to be personal and I'll share lessons, good and bad, about growing as an engineer. I've been leading open source projects, short lived projects as a freelancer and I went through the transition of engineer to tech lead twice. Both at a young startup and at Meta. This talk will be about personal experiences, unpopular opinions and even actions, and anything else that might be counterintuitive. Join for some take-aways for anyone aiming at an engineering focused career. Probably I will be wrong about most things, so don’t miss the opportunity to follow up afterwards!

Workshops on related topic

Node Congress 2022Node Congress 2022
39 min
How To Design A Sustainable Freelance/Contracting Career
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn the tricks of the trade from the industry’s most experienced freelancers.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
React Summit 2022React Summit 2022
75 min
How To Design A Sustainable Freelance/Contracting Career + Speedcoding Challenge
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn from the world’s largest fully distributed workforce in the world.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
At the end of the workshop there will be a Q&A session with a Freelance Developer who can answer your questions and provide insights and tips into their own success.
During the Workshop break, we will be running a speed-coding challenge! At the end of the workshop, we will award a prize for the winner and display the leaderboard.
We will have you login to our portal and complete the challenge as fast as you can to earn points. Points are assigned based on difficulty and the speed at which you solve the tasks. In case you complete all tasks, you get extra points for the remaining time. You’ll see your score, ranking, and the leaderboard once you complete the challenge.
We will be giving away three Amazon Gift Cards ($200, $100, $75) for the top three winners.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Designing A Sustainable Freelance Career
Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work.>> Submit your interest on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist <<

Freelancing is no longer an unstable career choice.

This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Table of contents

Module 1: Dispelling common myths about freelancing
Module 2: What does freelancing look like in 2021 and beyond
Module 3: Freelancing choices and what to look for (and what to avoid)
Module 4: Benefits of freelancing from a freelancer + case study
Module 6: How to get started freelancing (experience, resume, preparation)
Module 7: Common paths to full-time freelancing
Module 8: Essentials: setting your rate and getting work
Module 9: Next steps: networking with peers, upskilling, changing the world
Module 10: Freelancer AMA
React Summit Remote Edition 2021React Summit Remote Edition 2021
121 min
Landing Your Next Developer Job
Renaud Bressant (Head of Product), Nathanael Lamellière (Head of Customer Success and Solution Engineer), Nouha Chhih (Developer Experience Manager) will be looking at the different developer jobs that you can accounter when looking for your next developer role. We'll be explaining the specifics of each role, to help you identify which one could be your next move. We'll also be sharing tips to help you navigate the recruitment process, based on the different roles we interviewed for as recruiters, but also as candidates. This will be more of an Ask Us Anything session, so don't hesitate to share your thoughts and questions during the session.