Sixteen years ago to the day, I started RailsCasts, a screencast series teaching web development using Ruby on Rails. It began with free weekly episodes and eventually grew to make over $1M a year, but it wasn't sustainable. This is the first of a three-part series where I share what happened to RailsCasts.
An Aging App
In 2005 the PHP app I was developing started to show its age. Any change to the backend logic threatened to break multiple pages. It was the website for Artbeats, a stock footage company my dad started in 1989.
While hunting for a solution, I came across Ruby on the C2 Wiki where many developers sang its praise. I attempted to build a templating system in Ruby without much success when a new web framework caught my eye: Ruby on Rails.
A New Framework
I ran the
rails command to create a new app and was immediately put off. "What are all of these files it generated?" At the time I wanted a flexible framework that allowed me to structure the code my way. I spent the first week fighting Rails to make it fit my style of development.
A tradeshow was approaching, and I needed to develop a minimal version of the Artbeats site for kiosk stations around the booth. I decided to give Rails another shot, but this time follow the Rails way of development.
Everything clicked. In two months the kiosk app was done, and I had a better understanding of how Rails was intended to be used. Convention over configuration is the "secret sauce" of Rails. The framework will do a lot for you if you stick to its defaults and principles.
The Ruby community was kind and welcoming to the influx of web developers coming to learn this new framework. This sentiment stems from Matz, the creator of the language. A common expression in the community is MINASWAN: Matz is nice and so we are nice. This was the type of group I wanted to be a part of.
I found a home on the Rails Forum, initially to ask for help understanding Rails, and later to help others do the same. Every morning I spent an hour or two researching solutions to other's problems. The best way for me to learn was to teach, and I learned a lot.
I also enjoyed learning through screencasts. PeepCode by Geoffrey Grosenbach offered high-quality screencasts that were over an hour long. They were filled with useful information, but I found it difficult to sit through and grasp the concepts in the longer format.
Another screencast series that inspired me was Photoshop Killer Tips by Matt Kloskowski. These were free, bite-sized 2-5 minute episodes that were released frequently.
I wished someone would make screencasts that were developer-focused like PeepCode in the shorter format of Photoshop Killer Tips. So I did.
I started by applying principles I learned from agile software development: do the simplest thing that could possibly work, get feedback, and iterate on that.
I bought a $10 microphone and recorded a few rough screencasts to share on the Rails Forum. This helped me gauge interest to see what others thought without too much investment. There I also asked for ideas on what to call the series. "Railscasts" someone suggested.
I reached out to Geoffrey Grosenbach who was kind enough to sponsor the show through PeepCode. I then built a simple Rails app to host the screencasts, and within a month, on March 5, 2007, the first episode was released.
Fueled by what I had learned helping others on the Rails Forum, and my own experience as a developer, I had seemingly endless ideas to record. But I wasn't sure if what I had released so far was hitting the mark. I was missing the feedback cycle mentioned earlier. Was anyone even watching?
At the end of one episode I requested the audience review RailsCasts on iTunes. To my surprise, the next morning I woke up to dozens of positive reviews. This sparked me to pursue screencasting further and turn it into more than just a hobby.
I invested in a better microphone and set up a small recording "studio" in a closet because it was the quietest place in the house.
(I don't recommend working in a closet)
An Episode Every Week
Sticking to the format of Photoshop Killer Tips, my original intention was to produce 3 episodes per week at 2-5 minutes each. However, programming is not as visual, and it can be difficult to explain complex topics in only a few minutes. As the episodes grew longer, I decided to reduce the frequency to one episode per week with the sweet spot being around 10 minutes long.
This is when I hit my stride. I released an episode every week like clockwork. My goal was to make a series that one could anticipate and depend on. I kept this up for years to come without missing a single Monday.
Priming the Pump
While I didn't realize it at the time, an important part of the initial success was mentioning RailsCasts in my signature on the Rails Forum. This simple act turned all of my previous posts into mini promotions. Many of the first viewers found their way by googling a Rails issue, stumbling across my post, and then clicking the link in the signature.
Once word got out, it spread quickly throughout the community. It turns out I wasn't the only one wanting short, frequent screencasts covering Ruby on Rails. The series was a hit, but I wasn't prepared for how far it would go.
Continue reading Part 2: The Fire.