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.

The second project was a small movie comparison tool called Same Movies. This application was going to be my chance to work on a node.js application and a chance to get more practice with using an API. I decided to use the Express framework on the backend and JavaScript using jQuery to keep the application lightweight.

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

When I started trying to code every day, it was when I didn’t have any classes in session. I was used to working full time and going to school part time, so squeezing in some more coding was not too hard. Initially, it was the most fun part of my day. I was working on ideas that I had been thinking about for quite a while, so I knew exactly what I wanted the software to do. I was also learning new things, at my own pace, so it was exciting to work on code. Chicago has also had a pretty brutal winter, so I didn’t mind staying in to code. When a new project came up at work, I suddenly found myself much busier. Not long after that, school started again. There was one point where I would spend my days doing Java for work, JavaScript for personal projects, and Objective C for school. Coding became easier because I was doing it so often, but it was becoming less fun because it felt like all I ever did. I decided to stop after getting a 100 day streak because I knew I needed a break.

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.

The good

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.

The bad

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.

Takeaways

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.