In May of 2012 I started Everyday Rails, a technical blog about pragmatic use of Ruby on Rails for web application development. I began writing after I realized that questions I was answering at work, at users groups, and elsewhere might be worth answering to a larger audience. I started with a bang, writing ten posts in the first month. Now I have a hard time writing once a month (my last post was published on September11), and really since that first summer I’ve been lucky to get a post a month up there. I’ve been thinking about why I’ve struggled to keep going, and have some off-the-cuff thoughts (and some ideas on what I need to start doing).

First and foremost, if I had it to do all over again, I wouldn’t have started the Everyday Rails brand. At the time it seemed best to keep my work-related writing and my personal writing in separate containers. Nobody was going to be interested in reading about how I use Rails and looking at my amateur photography, right? In hindsight, though, this split has hurt my all-important personal brand–while Everyday Rails isn’t held in the same regard as other Rails-specific online products, at least more people are familiar with it than they are Aaron Sumner. And as someone with no interest in speaking at conference, and for whom attending a lot of conferences is problematic, I need to get my name out there any way I can.

My second beef with how I branded Everyday Rails is the whole Rails part. Don’t get me wrong, I still love Rails as much as I can love a web framework; I still live in it more than any part of my technology stack; and I believe it continues to have a long and bright future. That said, it limits what I can write about in a blog called Everyday Rails, both in terms of scope and the sheer fact that we may have reached critical mass of Rails-related blogs and screencasts. Given that my day-to-day (everyday) work often limits how cutting edge I can get–and, honestly, that many of the folks producing Rails tutorials are more advanced than I am–coming up with content that’s new and/or unique is a challenge.

Finally, I have to say that writing to a specific audience’s skill level for a sustained amount of time is more difficult than I would have imagined, had I given it more thought. Everyday Rails was always geared toward the Rails developer who’d completed Agile Rails or Rails Tutorial but didn’t know where to head next. This wasn’t bad when I started. I had lots to share to this audience, and most tutorials aimed for beginner-beginners or more advanced developers. If you consider blogging as a learning exercise (which I do), though, you need to grow while taking as much of your audience with you on the ride. (I think Stack Overflow has cornered the audience I was writing for, anyway.)

With all that in mind it’s all the more impressive that bloggers and screencasters like Ryan Bates keep it going for as long as they have (in Bates’ case, more than five years now), keeping content fresh and relevant on a consistent basis. I’m here to tell you, it’s hard work that they make look easy.

So how do I make things right?

First, I need to be much more realistic about my output. Multiple times a week is completely nuts. These days cranking out new material once a week isn’t realistic, either–so I’m going to work to get to a twice-monthly schedule. I might have to build up to that. Second, I’m going to have to start writing for myself first. Sorry, but there are plenty of resources these days for folks on the front-end of the Rails spectrum. And I’m going to be a little more loose with the Rails part–Rails will still be my base, but I’m giving myself license to write about what I use when Rails isn’t the best fit.