Inspired by this blog post, I have decided to start this commit challenge with my friend Jeffrey Zhouheng Sun. The description for the commit challenge can read from the that post in the first few paragraghs under the title The 30-day GitHub challenge.

Like the author of the aforementioned blog post, I wanted to start with a simpler task. I intended the streak to be as long as a month, but within a few days into the challenge, Jeffrey dropped the challenge. So by now, after 2 weeks into the challenge, it's only myself committing after all. I will not set a far-fetched goal for myself on how many days I will maintain the streak, but so far, it has been a rewarding experience.

At first, I just thought having someone doing the same task with me would keep me on track. But 1 week into this challenge, I realized that my momentum comes from myself. Once I have been fixated on the idea of daily commit, I couldn't live without not coding anything for the day. But of course, the challenge is demanding. Consistency in any sense is hard and cherishable.

Since I can't post my in-class projects online, all the commits come from my personal projects, which means I have to do more than what's required. Luckily, I have a lot of spare projects to do. I keep a repo of my configuration files, namely dotfiles, under version control. These files, catered to my own taste, are are frequently updated, so that I could commit on the very day when I go out of any ideas. Especially, I would put in an extra word for my emacs config, from which I learn something new about emacs or lisp every time I make edits to .emacs. One can never claim to be a master of Emacs as there is simply so much to learn about this (OS in disguise of) text editor. Also, blog posts like this count as commits, so words can go in the place of code. Moreover, I have found my drive to solve more project euler problems, as they prove to be crucial when I run out of commits.

Most of my commits are less than 100 lines of code, sometimes with minor stylistic changes that doesn't change the functionality of the code. But anyway, I was still able to maintain the streak.

Finally, apologies to the readers, if there are any, I probably wouldn't make any more long blog posts like I previously did (even though they were not long by most standards). Maybe a busy engineer has more important things to do than writing a blog, but more likely the reason is laziness or reluctance to express myself.