How to Avoid a Meltdown During #100DaysOfCode
I failed my first round of #100DaysOfCode in less than 10 days.
My second attempt was less calamitous, and I failed at the 50 day mark.
Alexander Kallaway designed #100DaysOfCode to break down the mental barriers to habit formation. There are plenty of success stories out there — one camper landed a job as a React developer. Why was I finding it so difficult?
I decided to perform a postmortem. As a product manager, it is my job to understand the root cause of team performance, for better or for worse. This was no different. I needed to identify and get rid of my blockers.
With a degree of experimentation, I have discovered three steps that will push you to conquer #100DaysOfCode.
Track your motivation to identify your optimal coding environment
When I started this challenge, my enthusiasm was sky high. I would drive to work an hour early, and use the extra time to code. I was smashing challenges, and having a blast sharing my progress on Twitter.
Unfortunately, the tidal wave of enthusiasm ebbed away. This moment is pivotal when forming a habit. How do you maintain momentum without the excitement?
Tracking your motivation level can help you to maintain focus and clarity. The goal is to identify your triggers to low motivation. You can then design your working environment to avoid them.
The easiest way to track motivation is to draw a grid of 100 squares. At the end of each day, color the numbered square according to your mood. If your motivation is particularly high or low, note down why that might be.
Following this method, I found that:
- My motivation to code is highest between 7:00–8:00 am
- My motivation to code is lowest when I do not have a clear goal
- Fluctuations are common when I am focused solely on tutorials
This simple exercise allowed me to adapt my habits and form a routine that suits my way of working. In this way, tracking your mood will help you to identify your optimal coding environment
Set project goals before you start the challenge
The first time a new coder has the confidence to say “I can build that” is both liberating, and overwhelming.
In that moment, project ideas shift away from the dream space and move toward reality. The floodgates are open, and the possibilities seem endless.
Without a clear goal in mind, the sudden realization that you can ship working code is dangerous. In my experience, it leads to unfocused learning and constant project hopping.
This scatter-gun approach is detrimental to motivation. Although you are working toward many exciting projects, you fail to make progress in any one area. At this point, you begin to feel defeated.
Set realistic goals before starting #100DaysOfCode, and use them as an anchor.
These goals can be technology based, or project based:
- What projects do I want to build in the next 100 days?
- What technologies do I need to understand?
- What learning resources will help me to achieve my goals?
When you have mastered a new technology, make note of any new ideas. Acknowledge them as future projects, and continue to deliver on your original goals.
Whether you fail or succeed, perform a project retrospective
The retrospective is a key ceremony in agile software development. It is an opportunity for the team to come together and reflect on their working practice. The aim is to observe what went well in this work period, and identify what must improve for the next.
At the end of your challenge, ask yourself the following questions:
- What did I do particularly well during this round?
- What did I learn during the challenge session?
- What am I most proud of?
- What could impede my progress during future rounds?
Spend some time reviewing your answers, and create a list of actions that you will take forward.
I wish you the best of luck.
What’s next?
My next round of #100DaysOfCode will begin as soon as I publish this article. You can follow my progress on Twitter.
If these tips helped you to avoid a meltdown, please show your appreciation with a round of applause. Happy coding!
