Rock My Quote: The Rails Experiment

Rock My Quote was an abandoned, self-funded startup by yours truly. All that’s left is a pile of Ruby on Rails code. It was originally going to be a PHP site based on CodeIgniter. The power of Ruby and Rails persuaded me over and so I decided to host it on Heroku. Unfortunately, I gave up after a month of working on it. Check out the source code on GitHub at have to admit that I didn’t have adequate knowledge of Ruby myself. Rails seemed so magical. I think that’s the secret of super programmers. They keep bumping their heads against a wall to learn.

Strategy of Being Awesome:

  • Hit your head against the wall for a few days
  • Search google, email friends, read papers / books
  • Prototype a few different solutions, realize they are all flawed
  • Cold email experts in the field (or get introduced by friends), set up coffee/skype meetings
  • Build new prototype with newly gained knowledge
  • Repeat


Rock My Quote was going to offer a different experience from all the other quotation sites. It was going to have  a simple interface to store, search and share all quotes from articles, books and social networks. Unlike other quotation sites, it would be ad-free and easy on the eyes.

Why did it fail? When I started, I had no team or done any marketing towards it. Unfortunately, that’s too much of a broken record. I read about great projects getting cancelled because the only person on that team was a super 10x engineer who felt they didn’t need a team. Marketing was a curse word. The harsh lesson learned is that developers need to do market validation before starting a project, and they need to build a team and do a mix of marketing while coding. Perhaps my next startup will be more successful.


Documentation As Your Legacy

Based on hearsay, developers hate documentation…until they come across a project with no documentation!

As you leave your company, how do you want to be remembered? Let me put it this way, if the next programmer is a serial killer that has to review legacy code that you wrote, would you want him to know where you live? Once I thought following a zero comment policy as good because classes, methods, variables should be human readable and obvious, however, there will always be someone who complains about the lack of comments and that your documentation is overwhelming. So, comment sparingly, but when you comment, complement the existing code and comment specifically business reasons behind your code. It’s also useful to use tools in your IDE that automatically apply comments to properties and classes. This is important, but if you comment every object, please don’t leave the default auto-generated comments in there, as they are just as useless as no comments. Finally, you should always reference your code classes to the user-friendly documentation in some other system (such as Confluence). If you comment your code where appropriate and also provide documentation for all your code, then you will be appreciated long past your stay.