Burnout driven development. When more is less.
Being a beginner developer can be hard at times. With the amount of languages to learn, paths to choose and frameworks/libraries to master it even become intimidating. The typical solution to this is practice in enormous amounts. You get a lot of code challenges to solve, side projects to build and suddenly you don't look at the things you learn like on scary monsters from the horror shows but consider them tools.
But wait, there is caveat that could make everything not go as initially planned.
With this pushy mentality that many people promote (I admit that I've done it) - it feels like when you are starting out your journey into development, the only thing you should care about is development. This is principally wrong approach.
Let's take a typical example of a good cause that is misused to the worse. #100daysofcode is an amazing initiative that is aimed at continuous commitment to programming for 100 days and posting the progress on twitter or other social media. Sounds good, and there is a tremendous amount of cases where people who were doing 100daysofcode succeeded, but there is another side of the medal. What I see in beginner developers on twitter and in my own mentees who participate in this challenge - they get radically upset, when missing a day or two from the challenge.
Same is reflected in the commit history wall on GitHub and other similar services. Isn't that rewarding to see a green wall of commits spanning across months. Isn't that depressing to see gaps for the days when nothing has been done?
What I can tell you is that pushing yourself is fine, unless you start doing it in an unhealthy way. The key point in the training is the rest time. Like muscle training in the gym tires your muscles, any mental activity, programming in our case, is tiresome for our brain. There is plethora of research in this field, read this article if you want to learn more!
You might think that not giving yourself wholeheartedly to the cause lowers your chances of getting desired first job, or secure a first contract as a freelancer, or even build that nice cool product that you've been thinking about. It is not true! Taking the time to rest is important for the learned things to settle down in your memory.
When learning new skill, whether it be a musical instrument, new programming language or taking up a new sport aways stick to the gradual progress and not an explosive one week sprint that will get you there. More to that it has been even confirmed that interrupted learning actually works better! To learn more about this - take a look at the Zeigarnik Effect. Although not fully proved it states that people recall unfinished tasks or not fully learned concepts easier than the ones which were accomplished. You can use that to your own advantage and see if it works like that for yourself!
To put it nice and short the generalised rule to follow is to take breaks deliberately even when you don't feel like you are tired or your productivity levels go down. Moreover, when you feel tired and feel like you would rather do something else than code - refrain from it for a couple of days. Burnout is tricky, as it has the interesting characteristic to progress exponentially when not handled.
I hope these pieces of advice would be helpful to you and bring about more enjoyable development-rest-development cycles that will increase your happiness all together. Happy developer - productive developer!