Five Takeaways from #100DaysofCode

For the longest time, I’ve tried to code. From taking an AP Computer Science class in high school to trying to make a command line RPG in C++, I’ve always wanted to expand my knowledge of programming, understanding that it now plays a key role in our world. However, each time I’ve tried, I came out of the experience disappointed; continuing to see people discuss CS concepts that were far out of my league and witnessing people excel in the field ten times faster than I seemingly could have. So, when I found out about #100DaysofCode, I decided to take on the challenge with one simple objective: see what people are talking about, see what people find important today, and see what I want to know – then learn in that direction.

Today was my final day of the challenge. Overall, my experience was… mixed. However, I’ve found that I’ve learned a great amount – not just about coding, but also about learning principles and a few life principles as well. I’ve decided to use my last day of this challenge to write down five key takeaways I got from doing this challenge.

There’s a massive difference between learning to code and solving problems in code

This I think was my biggest mistake from earlier attempts, and I didn’t even realize it until halfway through the challenge. You can go through something like Codecademy or FreeCodeCamp tutorials, but all they really tell you is what you can do with a programming language. It teaches you semantics through a fairly trivial and easy set of problems – which definitely helps when you’re just trying to understand what you’re working with (and I think that’s the goal of these two sites), but they suck at teaching you how to code.

If you want to learn to code, you need to know how to use a programming language. HackerRank, LeetCode, and Project Euler are fantastic resources on this. If I could do it all again, I would say to spend the first one to two days learning about a language on Codecademy/FreeCodeCamp, and then spend the majority of the time practicing your knowledge through intuitive and challenging problems (and believe me, they are challenging).

Choose something and stick to it

I’m terrible at this. I really am. I’m currently reading six different books at once just because I get about 100 pages in to a book before I think “You know what? This book on AI is really fascinating, but tonight I’m feeling something more about design”. This escalates to a point where instead of reading 100 pages a day in one book, I’m reading like 10 pages from 10 different books and it totally stifles my progress.

A similar thing occurred while doing this challenge.

During my prepping for this challenge, I made an entire roadmap of different projects and courses I could do, when I’d start and end them, etc. I threw it out on the second day. From there, I went on to not finish things such as CS50, a Codecademy React course, FreeCodeCamp, and also Quantopian (to be fair, I plan on finishing that last one post-challenge). Now that I reflect on my completion of the challenge, I realize how much more I would have known by this point if I just stuck with my roadmap. My advice for the future: always use roadmaps. Design a path and stick to it. Don’t get distracted by the shiny things across the road; instead, if you must, save them for later.

An hour a day goes a long way

Not going to lie; I didn’t do the recommended one-hour session for #100DaysofCode every day. In fact, I did it very little. But the times that I took on the full hour, I realized just how powerful an hour of time is.

Optimally, you have about 16-17 hours in a day that you can fill up. One hour, in that respect, is a pretty small amount. However, one hour is also 60 minutes, or 3600 seconds; and that’s a surprisingly long amount of time. I try practicing piano for about an hour a day (well… tried). I played until my fingers got sore, and I got tired, so I got out the chair and checked the clock. Only 30 minutes had gone by. This happened a lot when I was doing the coding challenge as well – if you think you’ve “learned enough” within 30 minutes, that means that you’re learning 2x that much in an hour. Also think about how these hours increase over time – optimally, by the end of this challenge, you would have put in just north of 100 hours into coding. I have about 105 hours total in Guild Wars 2, and that’s felt like an eternity. Now imagine if I spent that time learning and practicing Python.

All coding languages can be very much the same (and very much different)

After doing this for 100 days, I feel certain of one thing: that all coding languages are pretty much the same thing. Just like real languages, they’re all an assortment of different ways of communicating the same thing.

However, just as Russian has almost 10x the amount of curse words as English, some languages have certain strengths for certain situations. You use SQL for databases. You use Assembly for low-level stuff. You use C# for software, and JS for web apps. However, the languages themselves typically stay the same; you can print, use for loops, make ints, etc etc. In this case, you only really need to learn one language; and then when you need to switch to another, you retain your knowledge and just uncover the small semantical differences (print vs printf, {} vs end, etc.).

Determination is one thing. Hard work is what counts.

And here I think is the probably my most important takeaway of the challenge – it’s that there’s a big difference between hard work and determination. To be completely honest with you, #100DaysofCode – for me at least – was less a challenge of coding and more a challenge of consistency. I don’t think I’ve ever done anything 100 days straight in my life. And even though I wouldn’t necessarily say I did the challenge for 100 days straight (there was a few hiccups here and there), I still completed the challenge, which is a big deal.

But as you can get from previous takeaways, there is still much to be desired.

Consistency is only half the battle.

I think I made good progress during this challenge, but let’s imagine the optimum path: if I had followed the roadmap, if I had done exact an hour a day, if I spent the majority of the time on solving problems, and if I had gone for 100 days straight rather than skipping a few here and there. I can imagine that, if this happened, my current knowledge of coding would be 10x what it is now.

Now, that’s not to say I think this challenge was a failure. At the end of the day, I’d say my coding experience with this challenge was much more positive than it has been in previous attempts. Focusing on my three views (what people talk about, what people find important, what I like) definitely helped me stay in the right direction. And now I know that I can apply these takeaways to future attempts at similar challenges, with which I know there are many coming… such as my next challenge, #30DayStartup, which I plan on beginning pretty soon (and also plan on documenting much more).

In the meantime, like share this post if you’ve found it relatable, or otherwise especially find it share-able. If you want to follow me on the next challenge, either follow this blog or my Twitter (@astukari) as I’ll be surely posting plenty of updates on both. ‘Til next time.