Burnout is something most people experience at some time or another when they're learning to code. It's a common problem, and the common advice is to pace yourself, be consistent, and take breaks when you need them. But you may find that you've done all these and you're still feeling unmotivated. If that's the case, your burnout may not be caused by pushing yourself too hard.
Here are five reasons you might find yourself burning out that have nothing to do with your pace:
This one will plague you throughout your journey. Every time you get stuck on a problem, every time you feel like a project didn't turn out the way you want, every time you try to master a new concept and it just feels so hard, you'll probably hear that little voice telling you that you're not cut out to be a developer.
The more you learn, the more you will come to realize how much you don't know, and it will be overwhelming. And you might start to wonder why anyone would want to hire you when there are so many people out there who know so much more than you. These feelings will sap your motivation and make you feel like giving up.
It's important to remember that junior developers are hired more for their potential than their specific skills. Employers won't expect you to be an expert. Many companies will hire juniors who have never used their stack before, and simply train them on the job.
And remind yourself how far you've already come; think of all the things you've accomplished that you thought you couldn't do. Finally, try to keep a narrow focus -- instead of worrying about all the things you don't know, focus on what you are going to learn today.
2. You're Getting Off Track
As a new dev, there are so many things to learn, and all of them feel vital for getting a job.
"Hmm a lot of these jobs need React, so I'd better learn that... but then a lot of other jobs want Angular, if I only learn React I'll be missing out on those, maybe I should learn Angular too... PHP... Java... Python... Do I need to learn Kubernetes? That seems popular..."
So what do you do?
You need to have a very clear path to follow, and you need to stick to it. For almost everyone, the end goal is "get a job". But there are so many decisions to be made along the way, and so many skills you could learn.
As a junior, your problem-solving skills are more important than the specific stack you've worked with, but you should always check the market where you intend to apply for jobs. Look at which skills are being mentioned over and over again; ignore the 'nice to haves'.
Once you've decided on the technologies you're going to learn, stick to them. You have limited time available and you need to spend it effectively. Every new technology you add to the list has a cost in time and mindshare.
This doesn't mean you can't make adjustments to your plan. Maybe you intended to learn MongoDB but decided PostgreSQL was a better choice. That's fine if you've never worked with either one. But if you've already been working with Mongo for a while, seriously consider whether switching to Postgres is necessary. And avoid tech stack creep: if you decided at the outset that you didn't need to learn cloud technologies to get a job, then check yourself if you start watching AWS tutorials.
I have found a learning roadmap to be a useful tool. I make a list of all the tech I want to learn, how I'll learn it, and what projects I'll build for practice. And most importantly, I prioritize it into phases: I can't progress to a new phase and the tech it contains until I have completed the previous phase. I check it a couple of times a week to make sure I'm staying on track, and review it about once a month to make sure the plan is still appropriate.
3. You're Not Understanding a New Concept
Even if you're staying on track, learning something new is hard. Really hard. And getting stuck can kill your motivation faster than almost anything else, which is why it's important to get unstuck as quickly as possible. But how exactly do you do that?
First, understand why you're stuck. This is a critical first step. You'll be banging your head against a wall if you're trying to fix the wrong problem. Spend a little time considering what exactly it is that's causing you trouble.
"It's just too hard"
"I get the idea but I don't understand how to use it"
First, make sure you really do get the idea. Sometimes you'll understand the broad strokes but be fuzzy on some of the important details. In this case, you may need to take the time to understand the concept fully before you try to use it.
Then, start writing code, however you think it should work. You might be wrong, but you'll have errors to help you figure out why you're wrong. You might not follow best practices, but you'll have built something, and it will be easier to learn about best practices after you're comfortable with the basics.
Finally, read other people's code. Are you learning object-oriented programming but you feel like you don't get how to design your classes? Read other people's OO code and see how they've done it. The more code you read, the more you'll start to understand the patterns and techniques that are commonly used.
"I don't understand the explanation"
Not every teacher is right for every student. Maybe they're not explaining it in a way that makes sense to you. Maybe they're targeting an audience with more or less experience than you. Or maybe you just can't stand the way they pronounce "database". That's fine. Just because a lot of people love a teacher doesn't mean you have to. If you feel like the material isn't working for you, try a different instructor.
But be careful not to end up in...
4. Tutorial Hell
Tutorials have their place, but that place is not to get you job-ready. It's fine to watch a tutorial to understand the basics of a new framework or tool, but you're never going to truly understand it until you use it.
Well, that's simple: the fact that it will waste your time and keep you from your goal of becoming a developer. At some point, you're going to realize that something's not right, that you don't seem to be making progress, that you don't feel like you understand any of it.
So how do you deal with burnout if you're in tutorial hell? Get out as fast as you can. Build something, anything, with the skills you currently have. Screw up, don't understand what's wrong, Google it and copy/paste from Stack Overflow. Write the worst code the world has ever seen, but write it yourself.
5. You're Having Trouble Choosing Projects
Well ok, you say, but what do I build?
As you're climbing out of tutorial hell, you'll probably hear a lot of people tell you that tutorial projects won't help you stand out when you're applying for a job, and they're right. Almost every upcoming developer has made a to-do list at some point, it's just not special, and recruiters may even assume you didn't actually code it yourself.
But now you might be paralyzed for another reason: every idea you have has been done to death, and you can't think of anything else, so you just don't build anything at all. You spend all day Googling "good web dev projects" only to have everyone give you the same suggestions: to-do list, weather app, calculator, social media clone... so you keep looking and looking, and you just keep getting the same answers.
The first step to getting back on track is understanding the important distinction between projects for learning and projects for your portfolio. Projects for learning are just for you, they don't need to be unique. In fact, doing a few of those boring projects is a great way to learn because there's plenty of discussion about how they should be designed, and there's so much help available if you get stuck.
As for projects for your portfolio, your best source of inspiration is your own life and experiences. If you're a career switcher, try to come up with projects that draw on your previous experience. Have a hobby? Build an app related to it. Is there an annoying problem you or someone you know has been having? Solve it.
As a junior developer, your projects don't need to look impressive as much as they need to prove that they are truly the result of your own efforts. That doesn't mean your projects can be overly simple, just that a unique project of reasonable complexity will probably get more recruiter interest than the world's best Twitter clone. (You may be wondering what reasonable complexity actually means. A good rule of thumb is to build your projects as if you expect people to use them. This means taking into consideration things like edge cases, security, performance, UI/UX, and future maintainability.)
Burnout is real, but it's not inevitable
Next time you start to feel burnt out, take the time to think about its cause. You may find it's not what you thought, and it may be easier to solve than you expected.