About a year ago I made a promise to myself: spend an hour every day learning new stuff. In the weekends I would watch a course or read some articles but the time devoted on 'learning' was really inconsistent. That's when a couple of months later I started my 100 days of code challenge.
What is 100 Days of Code?
You've probably seen this hashtag a couple of times but here's a quick primer.
Code for at least an hour every day for the next 100 days. Make this a public commitment and track your progress.
Some personal extra rules:
- Aside from the code I will create a
log
and update it each day. - The
code examples
andlog
are pushed to GitHub. - I code at work but that time doesn't count towards this challenge.
Goals
The 100 days were focused on improving my core JavaScript knowledge. My first thought was: I don't have the discipline to keep it up for a 100 days and why should I even bother? After finishing the Minor web Development at AUAS I started noticing that I was still struggling with even basic JS concepts. From not knowing enough to not knowing at all.
It was this moment that I realized that these 100 days might be useful to force me to actually learn these concepts and start taking action.
That coding for an hour evolved around three main pillars:
- Refresh my basic JavaScript knowledge (e.g FreeCodeCamp)
- Learning new syntax (e.g ES6 for Everyone)
- Solving real world problems (e.g JavaScript 30
Takeaways
After coding for about 100+ hours I wanted to share some takeaways and the upsides this challenge can have.
You form a habit
This one is a bit obvious but I really felt it. You just have this solid goal at the end of each day that you have to complete this. I used Trello for daily tasks and just made a reminder task everyday.
You can do more than you think
When I first started I put some resources in the readme and thought that those kept me busy for at least 100 days. In the end I worked my way trough far more resources than originally thought. After almost 30 days I did all the resources I wanted to do when I started.
The form of the resourcedoes matter
I couldn't just read for a whole hour in a book I had to switch from time to time. Use different types of resources: read a book one week and watch a video course the other week. Switch it up.
Split up time
The first week or two I just sat down for an hour straight but after I started noticing that I was more focussed by splitting up the time throughout the day. Maybe two sessions of 30 minutes or even three of 20 minutes. Mornings were pretty good for reading while the evening was more suited for video's.
Track your time
Look at your tracked time to get a grasp of how you're progressing. Maybe the mornings you finish more resources than in the afternoon. It also gives you credibility, you can make the logged time public if you want to.
Repetition isn't bad
Covering the same topic or same concept multiple times isn't bad. It's a nice refresher and most of the time the person handling the topic has a different way of explaining so you get multiple views on one specific topic.
It was worth it. You feel more confident while writing JavaScript, you become better at explaining concepts to other people and the code you write becomes more explicit because you make thoughtful decisions based on the knowledge you gained.
Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!
Top comments (5)
Nice write-up Danny. #100DaysOfCode is a fantastic way to build consistency in programming and learning new concepts. I have also used #100DaysOfX to apply this concept to other things outside of coding.
Thanks Kyle! On what other topics did you use the 100 days concept? I'm thinking about applying it to writing.
I applied to writing to finish my Learn AWS By Using It course. You can read my experience here on dev.to.
you have NaNoWriMo coming up which is writing up a novel in November
Oh wow never heard of that, I'll check it out! Seems really interesting.