A few months ago, I decided that I was going write some new code every day and have at least one GitHub commit per day. There are three reasons I decided to do this. First, I wanted to get exposure to some new web application frameworks. Second, I wanted to practice getting an application from an idea to something people can use. Third, I thought my GitHub page looked wimpy and didn’t reflect how much time I spent programming.
The first project I took on was called Smarter Playlists. I was annoyed with the way iTunes computed the songs you listened to most often, so I decided to write an application that did a better job (by using average plays per day rather than total plays over time). For this project, I used the Java version of the Play framework.
Everyone can look, but nobody is
I was always afraid to put a lot of projects on GitHub because anyone could see my crappy code, but I quickly realized that I was my own biggest critic. I felt like I had an imaginary person doing code reviews when my code was available publicly, but I later realized that that was a good thing. This pushed me to not only add code that worked, but to also try to follow best practices. When I looked at the traffic analytics on my repos I found that very few people were looking at what I had been working on. Projects only seem to get traction when you promote them and people that use your tools are most interested in the project at it’s current state. My takeaway was, write the best code you can, when you think you’ve got something working well, tell people about it.
All work and no play
Commit history doesn’t tell the whole story
Part of the reason I decided to do all this was because I was jealous of people like Ian Bicking, but I later realized that there are a number of things that can affect your commit history. Committing often pushes numbers up, but migrating a mature, functioning, product to GitHub might only have a few commits. Many people spend a lot of time working on private repositories, store code somewhere else (my bitbucket account would make you think I never write code), or just like to keep their work private. These are just some of the reasons why GitHub shouldn’t be your resume. There is also the fact that you can manipulate your history to be whatever you want.
Waiting for inspiration
Coding every day was a strain on me, but what really started to slow me down was that I was running out of ideas. I wanted to turn my ideas into something real, but after everything was working, it was hard to think of improvements. I had an idea to do a small presentation at work on HTML5, so I got the idea to make it a GitHub page so I can do real demos. Working on the HTML5 examples was a much better experience than I expected because I forced myself to read about so many new features, and I got to try them out and see what did, and didn’t, work. I highly recommend trying out GitHub Pages.
I learned so much about new frameworks and got to turn some ideas into reality, but the biggest thing for me was that it felt like I learned a years worth of things in three months. As a developer, I know I can figure out most problems, but this experience forced me to deal with many things that would not normally come up during in my job. The experience also pushed me more towards using best practices. Because my code was changing so often, I could not ignore the problems future me would have to deal with when refactoring code. Working with heroku was also pretty great. It’s really amazing how easy it is to start coding and get the result online, all for free.
Trying to code every day during my free time was incredibly hard. I wanted to only do meaningful commits and I would start and commit a change the same day. This was pretty hard on my social life because I didn’t want to do anything after spending all day writing code. Trying to do one change per day also made me refrain from doing really big changes. The best example is that I didn’t set up database connections for my projects. I know it can take a while to get the schema right and have the connection working in dev and production, so I just kept putting it off.
Trying to do 100 days of coding is kind of insane. I learned, the hard way, that humans need rest. There were many days when I was just a zombie. The whole thing forced me to work though issues and cut out distractions though. If you’re really trying to get work done, the time-boxed approach is very effective. The key is just setting reasonable goals and leaving in some time to unwind. I’m almost embarrassed with my streak because it looks like such an odd outlier compared to the average, but the experience has been amazing.