100 Days Of Code Learning JavaScript

100 Days Of Code is about more than just code

First things first, there’s a very good reason to commit to doing something every single day for a period of time. According to science, it takes 66 days to form a habit, and forming good habits is an essential part of being a programmer. If you’re serious about doing just that, then the 100 Days Of Code challenge is most definitely for you.

You’re doing it wrong

My very first attempt at learning JavaScript was a bit of a waste of time, but it provided me with a valid lesson. My learning approach was all wrong. I’d crack on with a selection of tutorials, those concepts made perfect sense.

Incrementing a variable? No sweat.

Array methods? Nailed it.

Logical operators? Completed it.

I’d go away and come back to it a few days later, having not so much as typed a single line of code in between, and be back to square one.

Me lying on my bed, doing some code on 100 Days Of Code challenge

In short, this was an ineffective way of learning to code, which itself made me think that I didn’t really have what it takes. Making the commitment to code every single day is an investment in yourself and your journey to become a programmer. Each day, I took my time with each programming concept and this time, it sunk in.

The theory behind how JavaScript works is simple. But theory doesn’t get anyone very far in coding, you have to do it, over and over (and over) again to understand HOW. The syntax structure can only be learned by doing.

Just do it

I had been reluctant to start the challenge because 100 days is a few months. I always had so much going on. I’m not just a coder, I have a family and lots of responsibilities and the thought of just.one.more.thing made me feel a bit overwhelmed. 

I decided to stop making excuses for myself, I could do this. I found that my biggest excuse, not having enough time, was actually a load of BS. Time wins hands down as the most-used excuse for everything ever. So some evenings I’d have to sacrifice a bit of Netflix and Chill, some weekends I’d have to stay home while my husband and daughter went out. It was definitely worth it.

I learned a lot about when I do my best work from doing this challenge. Some days I’d have to wait until my daughter was in bed. That was when I’d struggle and make the most syntax errors. You need a sharp brain for coding. After you’ve spent the day answering question after question from a 3 year-old, starting from the second you opened your eyes, your brain is less of razor and more of a marshmallow.

My coding breakthroughs mostly happened in the morning before lunch or between 3-5pm. It wasn’t always possible to code at these exact times but I soon learned to save my most challenging concepts for these times. The rest of the day just didn’t yield the results. During these hours was when I’d refresh what I’d previously learned, go back over certain things, do some associated reading.

My Desk Set Up - Laptop, cup of tea and fresh cut flowers

Know your limits

Knowing when to walk away is a very valuable tool to have in your developer self-awareness kit. The trouble is, I’ve seen too many movies where programmers/scientists/whatever spend hours and hours poring over their work. They don’t see daylight, they eat junk food and stay up late until they’ve cracked the code. I thought I needed to do this to be a good coder too, when in fact you need to do the exact opposite.

Need a break? Have one.

Go and get some vitamin D. Do a mundane task like laundry. Go to bed at a reasonable time and sleep on it.

For some ridiculous reason, I thought this was the weak coder’s approach. Knowing that this kind of thinking is totally unhelpful is freeing and extremely productive.

Just ask

But walking away doesn’t solve every problem, and this where the developer community comes in. Basically, you can get technical help from anywhere in the world via Twitter. Someone out there has had the exact same problem as you and they will be more than happy to share how they solved it.

There’s also Stack Overflow, freeCodeCamp and endless online resources to help you on your way. That’s one of coding great’s paradoxes. It’s largely a solitary activity but when you need to reach out, there are thousands of people listening. They’ll raise you up when you’re questioning your abilities and celebrate your successes with you.

And this is a great time to mention and very, very important lesson. Do not under any circumstances, compare yourself to others. I did this, and it made me want to quit.

Me with my first ever shuffle algoritm, coded in JavaScript

No quitting

I was totally stuck on a freeCodeCamp exercise and desperately looking for some direction. I came across someone else’s code on a forum and it was absolutely NOTHING like my own. I instantly decided that I had done it all wrong.

I was a failure in nobody’s eyes but my own. I deleted all the code I written, feeling deflated. I started again, but this time found another set of code that did what was required, but this code was not dissimilar to my own, that I’d just deleted. The penny finally dropped. There is always more than one way of achieving the desired result. I was so relieved, but also angry that I had second-guessed myself.

In the end…

Everyone’s experience of the coding challenge is going be totally unique. I’ve learned as much about myself as I have about coding with JavaScript and I absolutely recommend this approach to anyone wanting to learning any programming language. I only wish I’d done it sooner.

Leave a Reply

Your email address will not be published. Required fields are marked *