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
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.
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.
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.
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.
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.
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…