ElixirTapas, ElmTapas, HaskellTapas, CrystalTapas…

…are not what I’m announcing in this blog post. Sorry.

Here’s a suggestion I receive periodically, and I thought I’d address it in a public post:

Avdi! I love RubyTapas, but I’m not doing much work in Ruby anymore! And/or I feel like I’ve learned all I need to know about Ruby!

I know you’ve been working to grow the show. Here’s an idea: why don’t you expand to cover technology X in addition? I would totally pay for that!

I’ll be honest, I’ve given this idea a lot of thought over the years. I’m not wedded to doing Ruby training for the rest of my career. I’ve never thought of myself as a “Ruby Programmer”; I’m just a programmer who happens to know a lot about Ruby.

In fact, I’ll let you in on a little secret: I bought the domain CodeTapas.com the same day I bought RubyTapas.com! I like to plan ahead.

So yeah: I’d be lying if I said I’d never thought about doing RubyTapas-but-for-technology-X. In fact, for a while I was kinda planning on it.

But I’ve been doing a lot of soul-searching lately, and I’ve realized that this isn’t quite the direction I want to go.

First off, these days there are a lot of wonderful how-to screencasts out there, at least one for just about any language you can name. Some of them cite RubyTapas as an inspiration, which makes me happy. I’ve always tried to encourage and help budding screencasters, especially in the “short, frequent videos” genre.

Sure, I know there are already screencasts about technology X. But your screencasts are better!

This is something that a few people have actually said to me when suggesting I switch focus, and I want to address it.

For those who have said this to me: Thank you. It means a lot to me that you value the thought and production values I try to put into the show.

But I’m already at the limits of my personal capacity to generate content, even with a fair amount of delegation in place. And to make such a move financially viable, it would definitely have to be in addition, not instead-of.

(Also, I chat with other screencasters, authors, and educators, and I suspect that a lot of enthusiast programmers over-estimate how much of the buzz around shiny new languages translates into actual training dollars. It’s like the DJ who said to her friend “I don’t understand why this band isn’t charting, everyone I know has their album!” and the friend replied “no, you know everyone who owns their album”).

Beyond all that though, here’s the core of the matter: Covering “how to code in $LANG” is not where my heart is. Nor is it what I think I’m best at.

The episodes people remember and recommend to their friends are the ones about naming things, and patterns, and domain modeling, and choosing the right tests, and refactoring. Episodes like the one where I explain why I no longer create User models. By far, the highest praise I receive is for episodes that are about design, and problem solving, and tools for thinking about code.

These are the difficult episodes. They are the ones that take weeks of research and planning and thought. They are often longer, and involve more diagrams, metaphors, and visual aids. Often, they feel risky, because I’m afraid that people watch them and respond “that’s crazy, I’m not going to write my code like that!”. And they are literally risky in the sense that occasionally I’ll sink a few precious days of research into a topic, then decide I don’t like where it’s going, and find myself with half a week gone and nothing to show for it.

These are also some of the most rewarding and personally satisfying shows to make. And judging by the feedback I get, they are the episodes that people get the most value from.

In fact, I’ve heard from a number of people who don’t even work in Ruby, but still subscribe because they find these kinds of lessons to be universally applicable.

This is a big deal. My subscribers make an investment in money and time when they sign up for RubyTapas. I take that seriously, and I want to provide as much value as I can. I want to be in the business of handing developers the biggest levers I can find.

As much as the computer language hobbyist in me wants to have a business excuse to master interesting new languages, I don’t think that “RubyTapas-but-for-Blub” is the best practical value I can offer to working programmers.

I’m not a big fan of sharing future plans before they come to fruition. But to speak in general terms: Yes, eventually you might start to see some content in this space that goes beyond Ruby. But the focus is always going to be on design insights, and making pragmatic development choices. The specific technologies will play supporting roles.

I hope that this is an appetizing prospect to current and future subscribers alike.

Happy hacking!

— Avdi