100 Days of Code - #100DayOfCode - again?

For those not acquainted with this 100 days of code thingy, basically, it's a challenge where you code for 100 days straight, for at least one hour a day, you can take one day pause every 14 days and you need to share your progress publicly, for example by tweeting about it with the #100DaysOfCode hashtag. The rules are available here. I started it about two and a half, maybe three years ago.

Thus far I've finished five rounds of this challenge, which translated into five hundred days of coding for an hour daily on average. The digits might seem impressive, and one might think that after five hounded, or more, hours of coding that one would become a coding ninja. I've made a lot of mistakes while undertaking this challenge such as jumping from one technology to the next hot thing. I also kept a log of my progress on GitHub and had git commits for most of the days.

As for the sixth round of the challenge, I've re-started it twice so far and due to my own laziness and external circumstances, I botched it both times... I've been pondering of giving it another try but I'm still not sure if I should. At the times I haven't been coding I was still learning other technical stuff, mostly related to testing, like passing the ISTQB, taking a few 30-day testing challenges from the Ministry of Testing and getting more familiar with test theory and automation. 

One of the main reasons why I wanted to become a web developer in the first place was the fact that my job at the time, working as a manual tester was too easy and I wanted to challenge my self a bit. I worked with some really awesome people, but the role itself was not very demanding, there was a lack of process, no implementation of best practices and standards and no real software development methodology in place. When I change jobs, my new responsibilities made me look at testing from a different perspective, previously I believed, as many others do, that testers are just people who don't want to code, or weren't good it enough at it - I underestimated the role. Working in a place where a clearly defined process was in place (Scrum) and testing was done at all levels of SDLC, where there was a defined hierarchy and seeing testers who are highly knowledgeable in various aspects of IT, really opened my eyes and sort of made me fall in love with testing. 

The most important takeaway from this would be that if you are trying to learn something, chose a single topic to focus on, without jumping around. For instated, chose one programming language and stick to it almost until the point when you start hating it, don't spend time trying to check out every new hot technology that comes out (like fron-end frameworks) but focus on those fundamentals, when you got that under your belt, learning a specific implementation of that fundamental skill (ie, new framework or a tool) will be significantly easier.