Reports of the death of Ruby Code & Style have been greatly exaggerated.
I’ve been the Editor-in-Chief of Artima’s Ruby Code & Style for somewhat over a year now. For various reasons, I am stepping down.
Just to be clear, I’ve had nothing but good experiences helping get the ‘zine up and out the door, and have endless appreciation for all those who pitched in and made things happen. It’s mainly a matter of time; I cannot give it the attention it deserves.
I expect a formal announcement on this to appear on the RC&S site before long, so I’ll the details to that. But I want to at least assure people that that the ‘zine has not simply up and died. It continues.
So there is at least one Ruby magazine (albeit online-only) that is around. But people should appreciate that organizing and maintaining a good publication is non-trivial.
Getting and preparing a steady flow of high-quality material is not easy. It’s a job. The goal for RC&S was to publish content a cut above what one typically finds in, say, Linux Journal or on most blogs.
That’s not meant as knock on those sources, just that there is zero reason to publish one more “How To Write a Blog in Rails” article.
But there is competition for material. There are varying fees being offered by different publishing outlets, and while money is not always the main reason people write, it can be a factor. If, as an editor, you are aiming for prestige, then you have the extra task of ensuring that only high-quality material is published. You have to stay on top of finding good reviewers, ensuring that all code samples are correct, and insisting that the content illustrate something reasonably new and technically astute.
It can be fun, but there is also a good amount of administrative work in seeing to it that corrections are made, code tested (and re-tested if there have been changes), copy is grammatically correct and properly formated, reviewers actually review, and so on.
The are any number of outlets for writers. There is very little stopping anyone from getting their words out to the public. There is, of course, considerable competition for attention; most people will find a larger audience publishing through RC&S than on their personal blog.
The Web being what is is, though, you never know if that toss-away article on your Blogger account isn’t going to end up on the hot list at Reddit. You don’t need a large audience; you just need the right audience. But not aiming for, or expecting, a killer crowd, can be liberating. There’s less pressure when you write for yourself, even when you know that nothing on the Web is ever “just for yourself”.
For example, I’ve meaning to write something for the O’Reilly Ruby group blog, but keep putting it off because I kept thinking it needs to be a little better, a little more substantial, a little more polished, than what I’d put on my home page. Rather than driving the creation of higher-quality content, it ends up stifling it. Crossing that line of perceived attention has a peculiar effect. What started as fun can start feeling like a chore.
Many people are happy to write a breezy article describing their latest project, but may be less enthusiastic when asked to provide additional detail about the choices made and the design implications. Writers may also feel that, past a certain amount of time and effort, it doesn’t makes sense to produce “just” an article; why not go a bit further and write a small, down-loadable book to sell? After all, if it’s not fun, then might as well make it pay.
Some years back I started on a Ruby book, Beginning Ruby, for a previous incarnation of Wrox. Halfway through, they ended up going bankrupt. Quite the letdown.
I considered different ways to make use of that material, including parceling it out as magazine articles, but I finally decided to just put it on the Web. Sort of. Beginning Ruby lives, but seeing now how people acquire and use technical information moved me to chuck a good deal of the original content and re-do the presentation.
My writing and release schedule is, let’s say, casual, and I spend as much or more time hacking on the comment system code as I do writing or editing, and that suits me just fine. Were I trying to re-assemble this as a “proper” book for formal publication I suspect that the content would get dated quickly, and it would likely contain much redundant information. (For example, the original text has various sections with detailed descriptions of the core Ruby classes. Given the existence of ruby-doc.org and Dave Thomas’ Programming Ruby, I’m skeptical the world needs Yet Another Ruby Library Reference. (What it *does* need is a complete and current library reference as part of the standard distribution. I’m more inclined to see just how much of the reference material I wrote could be added to the Ruby docs directly, rather than ploink them into one more Web page or have it find a home in dead trees. ) )
Most important, that sort of prolonged, large-scale writing can get painful. Go read Dave Thomas’ series of articles on writing for a good exploration the task of creating a good technical book. So, for now at least, I’d rather follow fun and see where it leads.
This need for passion carries over to magazine writing, and that may be the real reason you see so few good, stable Ruby publications. There’s no shortage of people writing helpful blog posts or “Build a FizzBuzz App” articles; the passion and commitment requirements are fairly low. The longer articles, the more technical articles, take more. They’re hard, at least to do well, and require more of that special combination of passion and know-how. There are fewer people really good at that, too few perhaps than can sustain a full-blown single-topic magazine.
Of course, I’d like think I’m wrong. I know that if I spent more time trying to determine the real reasons then I’d never have written what you’ve just read. I promised myself I’d not get hung up on trifles such as rigorous detail or air-tight logic. Yes, I’m sort of kidding; of course those things matter, but at the moment they would be a killer.
Because here’s the weird part: The passion that motivates writing can also lead to a smothering obsession with detail. Too much, and the writing dies. So, if things get sloppy in the name of passion, that’s OK. That may not work for a technical journal, but maybe that’s not the best metric.