The First 100 Days

The First 100 Days

Advice on the '100 Days of Code' challenge

After embarking on my own coding journey, it only took a short time for me to come across the 100 Days of Code challenge. A challenge that attracts every type of developer imaginable, from those writing their first ‘hello world’ to developers with years (even decades) of experience under their belt.

For those unfamiliar, 100 Days of Code is a challenge in which developers attempt to code, unsurprisingly, for one hundred consecutive days and share their progress using the hashtag #100DaysofCode.

For some personal context, I began my first round of the challenge on April 4th, 2021. It did not take long for me to realise why so many are drawn to this challenge, it provides a great structure to develop (pardon the pun) new skills, while holding yourself publicly accountable and meeting other likeminded developers.

The benefits didn’t stop there either. Since then, I have started a second round of the challenge, during which I acquired myself a junior developer position.

After reflecting on my experiences, I was curious to know if sharing the lessons I had learned would be beneficial to others. I asked Twitter whether or not they would like to hear my advice and experiences surrounding the challenge, and the answer was a resounding yes.

And that brings us here, to my eight rules (and I use the term ‘rules’ loosely) on how to extract the most value from the 100 Days of Code challenge.

Let’s begin.

Overview:

To get the most from this article, I would advise reading the rules in full. However, I understand this approach isn’t suitable for everyone, so I have included the condensed versions of the rules in this section:

#1: Make a plan: Start with a direction in mind, but keep it simple because it will change.

#2: Everything counts: Any activity that builds your coding skill set should be counted as part of your challenge.

#3: Set time aside: Commit to coding for a set duration daily.

#4: Life gets in the way: Understand and accept that you may not be able to code every day.

#5: Learn to learn: Find a learning method that is most efficient for you.

#6: Take note: Keep a note of anything that piques your interest.

#7: Abandon the plan: Follow your passion, keep coding fun.

#8: Make connections: Connect and share with other devs on Twitter.

Now, let’s take a closer look at the rationale behind each of these rules.

#1: Make a plan:

It seems appropriate to put this rule first, as it’s the first thing I would advise anyone wanting to start the challenge to do.

Admittedly, this can be a daunting task when faced with the whole world of coding. There are hundreds of languages and paths to choose from, which can be overwhelming at the best of times. If I can stress one point here, it would be this:

Keep it simple.

Your plan does not need to include a second-by-second breakdown of every single day. It can be loosely defined to start, because you are still a beginner, without the necessary knowledge to discern what is of importance and what is not.

Before beginning the challenge, I would recommend:

  • Taking stock of your current knowledge: What do you already know about programming?
  • What is the next logical step?: Find the next stepping point in your journey. This step may require some research, but it can be as simple as Googling 'web development for beginners'.
  • Self-study or a structured programme?: If this is your first time participating in the challenge, I would recommend finding a structured programme (on sites such as freeCodeCamp or Udemy). Creating your own curriculum when you are still inexperienced can be frustrating, which in turn creates a barrier that I would imagine turns many people away from coding. If this is not your first challenge, you are likely able to conduct the proper research to create your own curriculum, even if the subject/language is new to you.

Don't be afraid to dedicate the start of the challenge to planning and preparation; planning is a skill that you will use regularly in coding. In my own journey, I spent the first two days creating a plan using the above steps, which looked something like this:

  • I assessed my current knowledge: Coming into the challenge I already had some understanding of HTML and CSS, but it was by no means sufficient.
  • Next steps: To recap and expand my knowledge of HTML and CSS and, following a quick Google search, move on to JavaScript once I had recapped my previous knowledge.
  • I decided to begin by reading Jon Duckett's "HTML and CSS: Design and Build Websites", a book I had started reading previously, but by no means comprehensively. In retrospect, I would recommend starting with online coding courses (as mentioned above) for beginners, as they are more interactive/engaging in nature.

Taking this time to plan, however, should not be used as an excuse for inaction - my rule of thumb is no more than two days of planning.

That leads nicely on to my next point.

#2: Everything counts

As mentioned above, there are many skills that are adjacent to coding that you will need to learn on your journey.

Some of these code-adjacent skills can be very time consuming. Due to this fact, it can sometimes become impossible to fit learning these skills and coding into a daily session. If you find yourself in this situation, don't criticise yourself too harshly; all of these skills contribute to your ability as a programmer.

Toward the end of my first round of the challenge, I decided to spend a few days getting acquainted with Figma. During this time, I did not manage to find any time to code, but learnt a considerable amount about design principles and prototyping. These skills I considered valuable to my overall goal of becoming a front-end developer, so I decided to count them toward the challenge.

My rule of thumb is: as long as what you are doing moves you toward your end goal, then it counts.

Before moving onto the next point, I would like to highlight one of the potential problems with this outlook. If you spent the entirety of the 100 days working on something other than coding, have you completed the 100 Days of Code challenge? There has to be a fine line when deciding how long you are going to leave coding to pursue something new.

As I rule, I would say spend no more than three days on something code-adjacent before dedicating some time to coding. Ultimately, however, you should find how many days you feel comfortable with; if you think you can explore another avenue for a week without losing too much of your coding progress, that may be more beneficial to you. It is all about balance.

#3: Set time aside

The original intention of the challenge was to set aside one hour every day for coding. Since then, the challenge has become more flexible, as one hour may not be tenable for everyone who wishes to participate. However, I think this idea does raise an important point.

You should decide on an amount of time you going to commit to every day, and stick to it.

The amount of time you commit to must be reasonable. If you commit to five hours a day, it will not take long before you burn out, unless you yourself are a machine who has gained enough sentience to try and amend your own code. For us humans, it is better to commit to a short amount of time and persist for the full duration of the challenge than overwork ourselves and drop the challenge, and possibly even coding, altogether within a few days/weeks.

Consider it from an arithmetical point of view. If you code for five hours a day, but only last one week due to burnout, you have coded for thirty-five hours. However, if you code for thirty minutes a day, for one-hundred days, you have coded for fifty hours whilst avoiding the mental fatigue that long days of coding can bring.

Another piece of advice I would give here is to choose a start and end time for your daily coding session. This allows you to quickly establish a routine, which removes some of the cognitive workload of having to actively schedule your session. This way, you know at X time you will be coding, every day.

When starting the first round of my own challenge, I decided that I was going to dedicate ninety minutes daily, between 7:30pm and 9:00pm, with Saturdays off to protect against burnout. I guessed that this would probably be the maximum duration for which I could properly concentrate.

However, on occasion, when working on something that really caught my interest, I would allow myself to go over the set time. This is fine as long as you are cautious and are honest with yourself about feeling fatigued or burned out; if you do start feeling this way, it is time to call it a day.

Whatever you are working on will always be there tomorrow.

#4: Life gets in the way

A hundred days is a long time to commit to. During that time, any number of things can - and will - happen. When life does rear its head and pulls you away from coding, it is easy to feel guilty about not putting the work in that day.

While these feelings of guilt are difficult to brush off, it is important to develop a healthy relationship with coding right from the outset.

Imagine the alternative, where everything is falling down around you; your wife’s water has just broken, but she can’t get to hospital in time because your car burst into flames before falling into a sinkhole – you, however, have missed all of this locked away in some distant room revising JavaScript loops.

That should probably be avoided.

With that being said, there is (once again) a fine line. If you find yourself being constantly pulled away from your work, chances are you have not chosen a realistic schedule for yourself, and it may be time to reconsider.

Here are two questions you can ask yourself if you are constantly getting interrupted during your work:

  • Have I given enough time to the urgent tasks of the day?
  • Are there any other times during the day where I am not as busy?

If your answer to the first question is no, you may want to reconsider how much time you are spending daily to code. If you are coding for ninety minutes, try dropping it down to one hour to see if that is a better fit for you.

As for the second question, the reason I chose 7:30pm to 9:00pm was that by that time, most of the day's events had passed, so I was less likely to be interrupted. The same holds true with early in the morning. A good way to gauge which hours of your day are the least busy is to keep a note, hour-by-hour, of all the tasks you had to do in that hour. It will quickly show you which times of the day are your busiest.

Even with your schedule optimised as much as possible, things will still eventually get in the way. One way in which I avoided feeling guilty about missing days was to try and recount the time I had lost throughout the rest of the week. If I had missed one ninety-minute session, I would try to add on fifteen minutes to the next six sessions. This way, I have made up for the time, while not adding so much to my sessions to overwhelm me.

It is a fine balance, you should try to minimize the amount of days/time missed, while acknowledging that, sometimes, things more important than coding while arise.

#5: Experiment with different learning methods

The 100 Days of Code challenge is a great time to discover which methods of learning work best for you. It is difficult to give prescriptive advice here, because different techniques work for different people. However, I will share some of the methods I toyed with during my first round of the challenge.

I tried:

  • Note-taking
  • Creating flashcards
  • Building projects

Let's take a closer look at each of these in detail.

Note taking:

When beginning my first challenge, I took many notes of the books/articles I was reading or videos I was watching. The feeling of taking these notes, and putting in the hard work, made me feel like I was really progressing. But then came a problem...

A short time later, I could not recall what I had learned, and if I wanted to revise it, I had a massive pile of notes to sift through to find the information I needed. I decided then and there that if I was going to take notes, I needed some form of simple, regular revision to make them worthwhile.

Again, during this time, by pure serendipity, I was introduced to the Cornell note-taking system by Layla. To keep it brief, this system requires you to divide the page up into three separate sections: main notes, summary, and questions. Writing questions about everything I was learning not only made me focus more on the subject, but it also gave me questions to quiz myself on and revise later.

This is where the next method comes in.

Creating flashcards:

Creating question flashcards (with a question on the front and answer(s) on the back), engages your brain in a method called 'active recall'. You are training your brain to retrieve information and reinforce the information in your long-term memory. There are also some other things you can do to maximise the efficacy of flashcards:

  • Use spaced repetition: a system that shows more difficult flashcards more frequently, while spacing out the easier cards.
  • Keep the questions and answers relatively simple: complicated questions and lengthy answers can cause frustration. Try to keep questions to one topic and answers less than three sentences in length.
  • Revise multiple topics simultaneously: This method, known as interleaving, has been shown to help consolidate information in your long term memory.

Anki allows you to combine all of these things, and sync your flashcards between mobile and desktop devices.

To make flashcards, I simply take the questions and answers from my Cornell notes (above) and transfer them to Anki, a flashcard app that combines all of the above practices and allows you to sync your flashcards between mobile and desktop devices. If I ever find myself with some free time, instead of doom-scrolling through Twitter, I will try to revise my flashcards.

The final thing I would like to say on flashcards is that, compared to simply taking notes, it is difficult. Not being able to recall information can be incredibly frustrating, and it requires a lot of cognitive effort. However, if you are serious about making your learning as meaningful as possible, I cannot recommend flashcards enough.

Building projects:

While I have said that there is rarely one method that works for all people, I would like to advise that one practice everyone picks up during the 100 days is project building. This gives you a taste of what being a developer is really like and the challenges they face.

Also, the feeling of completing a project is extremely motivating, and will help you to continue through the challenge. By the time I had completed my first three projects (A 'pass the message' page, a times table checker, and an image slider), I was hooked. This motivation carried my through the hard days later in the challenge.

#6: Take note

As the days start to pile up, and you get further into your coding journey, you will come to realise that there are millions of different paths to choose from. You will start to develop what I call Shiny Things Syndrome (STS) - you'll want to drop everything you are doing and move on to the new exciting thing. How do you overcome this urge?

Keep anything that catches your eye in a list to return to once you've finished with your current study.

When I was about fifteen days into my own 100 days, I was still recapping a lot of the CSS I had forgotten from before. It was at this time that I came across a lot of exciting JavaScript projects for beginners. I wanted so badly to start learning JavaScript and making dynamic web pages. Then STS set in.

I set off learning all about variables, functions and for loops. It was so novel and new, I would spend a lot of time practicing the concepts using sites like CodePen. However, it didn't take me very long to realise that I could not make the pages I visualised because I had not developed by CSS skills enough. I realised then that to get where I wanted, there were shortcuts - I made a note of all the projects I wanted to create (using Notion), and used them as motivation to continue pushing through CSS.

The second lesson came around day fifty-five of the challenge. In this time I had recapped CSS to a level that I was comfortable moving on to other languages, and had completed some small JavaScript projects. When deciding where to go next, I turned to the list of things that had excited me along the way. After looking through the first handful of items on the list, I realised...

Many of them did not excite me anymore.

This is the second lesson, review your list regularly. It is easy to add projects that you think will be fun in the moment to the list, but if you come back and revise the list, you will be able to catch out the ones that you may not have really been interested in.

#7: Abandon the plan

This rule is a continuation of the previous rule, but only to be used in certain cases. I would say the two primary cases for this rule are:

  • You have passed the fifty day mark of the challenge, and have a better understanding of what is and isn't important.
  • You are considering quitting the challenge.

Ultimately, the factor that is most likely to keep you on the coding path is that you remain to find it fun and engaging. You can't always determine what will be engaging to you in the planning stages.

When you come across something that is so enjoyable that you cannot stop thinking about it, that is a good indicator that it is worth pursuing. Don't be afraid to put a pin in your current plan, you can always come back to it later.

This takes us to the final rule...

#8: Make connections

From day one, I would recommend sharing what you are doing, using the 100DaysofCode hashtag on Twitter. I can not express how positive the experience of connecting with other devs has been. I have made a load of new friends, and now have people that I can turn to for advice on anything tech related.

To get started, I would recommend looking up the 100DaysofCode hashtag on Twitter. Here, you will find many other devs who are in the same situation as you, sharing what they have made. Any accounts you come across that look interesting, follow them and reach out to let them know their work is appreciated.

Next, share what you have been working on or learning that day and use the 100DaysofCode hashtag. Sharing what you are learning about not only helps reinforce it in your own memory, but you might even help someone else beginning their coding journey!

After some time, the more popular accounts will become more obvious. I would recommend following these, partly because they often post great content, but you can usually find tons of great devs in the replies to their posts too!

Some accounts I would recommend to start:

Conclusion

And there we have it. If you have made it all the way to the end of this mammoth article, I would like to thank you so much for reading.

If you found any of this helpful, or would like to ask any more questions about the challenge, I can be found here.

Happy coding.