A few months ago, thanks to current times, I found myself with a newfound motivation to continue working on my side projects. However, I was running into a cycle of picking up a project and them putting it down after 2 days to chase another shiny new project. The whiplash was too much.
I took some time off to regroup. I struggled with balancing a full-time workday with recreational coding in the evenings. Eventually, I felt rested and ready to start back up. I read dev.to articles to get back into the swing of things, where I learned of #100DaysOfCode.
My goal with this article is to detail what worked, what didn't, and what to improve for the next 70 days. Let me know in the comments if you relate to any of these experiences and ways you overcame them.
My #100DaysOfCode Goals
The official #100DaysOfCode rules are found at https://www.100daysofcode.com/. I also recommend checking out softwaredotcom's article for more insight:
Most participants of this challenge steer toward learning a new skill, learning a new framework, or starting to code. My challenge differed slightly. I needed to commit to finishing one idea while finding a sustainable work/life balance.
My Rules:
- Code an hour every day for the next 100 days on one project.
- Maintain a daily DEVLOG with time spent and tasks accomplished each day.
These rules deviate from the official rules: the one hour deadline became a time limit (instead of a minimum), and my DEVLOG resided away from social media like Twitter or dev.to.
From a high level, the project consists of:
- An Angular static website
- An API made with PHP
- A Chrome/Firefox extension
- A human-readable, version-controllable database
I had little experience with all 4 components starting out. I knew there would be enough new concepts to learn.
My Past "Attempts"
Writing this post, I realized that what has worked during my #100DaysOfCode challenge contrasted with what hadn't worked in other trend challenges I participated in. In 2016 for #Inktober, an art challenge to create an inked picture every day of October, I lasted 13 days. The art I completed is viewable at https://www.deviantart.com/pepper-wood/gallery/60508827/inktober.
With #Inktober and other similar challenges, a trend of behaviors appears:
- I feel pressured to one-up myself each day. This is apparent with my Inktober 2016 artwork. I start relatively simple and gradually build to more involved works.
- The escalated workload becomes unsustainable. Keeping up with the challenge means losing sleep and focus during the day.
- The load overwhelms me. I take a day off to recuperate from the prior day's long hours.
- The double workload the next day breaks the momentum. My involvement with the challenge ends.
My Takeaways after 30 Days
The #100DaysOfCode rules unknowlingly aided with mitigating my prior struggles. By not limiting the challenge to a calendar month, I was able to take time off and regroup when my tasks got out of hand.
1) "One Hour a Day" is better as a time limit, not a minimum requirement
Knowing I was still recovering from my initial burnout, I established the one hour rule as a timebox. Once the time limit was hit, my work stopped for the day. This helped maintain a routine without pushing too fast at the start. I wasn't consumed by coding for the full day. However, the time limit enforcement eased over time due to increasing familiarity with the outstanding tasks. Maybe I should reintroduce the timebox, taking into account the side effects of its relaxation.
2) I burned out but kept going
Twice, I needed to take a day off between my coding days. In both cases, I made sure to resume my progress the next day to avoid derailment.
I took a day off after Day 9. I was hesitant to start on the browser extension component after prior attempts to build browser extensions failed. I was apprehensive about whether I would be able to keep up the pace while out of my element.
I took another day off after Day 17. The reasoning is way more obvious:
- Day 15: 1.5 hours spent working, on a Friday
- Day 16: 6.5 hours spent working, on a Saturday
- Day 17: 6.5 hours spent working, on a Sunday
- Day off, on a Monday
- Day 18: 8 hours spent working, on a Tuesday
- Day 19: 30 minutes spent working, on a Wednesday
- Day 20: 6 hours spent working, on a Thursday
My hours oscillated wildly and fried my brain in the process. After Day 20, I noticed my shaky work times and recalibrated back to spending 2-3 hours per day.
I'm thankful that the format of #100DaysOfCode meant I could take those 2 days off and reset. In other challenges, the days off hailed the end of my participation.
I unknowingly assumed that the end of the 100 days meant the completion of this project without properly laying out what tasks needed to be accomplished, what a final product would resemble, or whether the timeline fairly aligned with the steps needed. This assumption fueled a worry to constantly move and progress, while the initial timeboxed pace may have been the right speed. Moving forward, I want to continue recognizing when I'm being unfairly hard on myself. This change should result in fewer burnouts in the future.
3) I needed the DEVLOG to be kept away from social media
In the original rules for #100DaysOfCode, the daily developer updates are encouraged to be posted as tweets with the hashtag. I've also seen others post their updates as articles here on dev.to.
I had the foresight to know that a pressure to post on social media would hinder my progress more than help. My logging expectations in the past have trended similarly with escalating code expectations. I get caught up in the finesse and length of written updates. A lack of a rigid logging structure meant a lack of pressure and energy to keep my notes perfect.
4) The DEVLOG was unexpectedly useful for logging my hours and reviewing past attempts
I can't count the number of times where I needed to recall a link or an earlier attempt, only to check the DEVLOG and find exactly what I needed. Looking back, I wish I did the same for my other challenges to better understand my derailments. I recommend using the DEVLOG to log both successful and unsuccessful implementation strategies along with any informative links encountered.
5) Lack of a Project Management framework in the beginning was a good thing
I also had the foresight to know that setting up a project management tool in the beginning would stunt my initial momentum. Frequently in past projects, my good intentions to compile and organize all the required tasks leave me face-to-face with a mountain of tickets. Accomplishing tasks barely makes a dent, discouraging me from continuing.
Instead, I started a broad, bulleted TODO at the end of my DEVLOG as tasks came to me. It wasn't until Day 25, after typing a rough draft of this article, when I formalized a Trello board for task management. I realized I placed an unspoken, unjustified expectation that the end of the 100 days meant the completion of this project. This assumption may have been fueled by not establishing endgoals on Day 1. However, I now had a greater understanding of how to build the necessary components and a better expectation for what a "Phase 1" resulting product would contain.
Conclusion
There you have it. My 5 main takeaways from my #100DaysOfCode challenge so far. I'm proud of the work I've accomplished to this point, and I'm passionate about what the end result will entail. I can't wait to share more about it once the implementation is more concrete.
Top comments (0)