End of the line for Code Quarterly

A bit over a year and a half ago I announced that I was starting a magazine for programmers, Code Quarterly. Today I’m pulling the plug.

So what went wrong? There were three parts to the theory that led me to start Code Quarterly:

1. There’s a market for high-quality, in-depth articles for programmers.
2. By working with other writers and providing extensive editorial support, I could produce more high-quality content than I’d be able to write on my own.
3. New ways of publishing (Kindle, iPad, print-on-demand, etc.) have opened up opportunities to publish (and sell) different kinds and different lengths of writing than had been feasible in the past.

As far as I can tell, I was right about point number one. Over two thousand people filled out the form on our web site to express interest in subscribing to Code Quarterly and the comment and emails I’ve received have been very enthusiastic and encourging.

Point number two, however, turned out to be the sticky wicket. I couldn’t find enough people to write the kind of stuff I wanted to publish, even with me doing a lot of editing. There was interest: almost four hundred people indicated that they might like to write for the Quarterly. But I wasn’t able to turn that interest into actual pieces: from that pool of four hundred I got thirteen writers to the point where I actually sent them a contract. Eight of those finished a first draft, three persevered to a second draft, and only one got all the way to a published article.

For a while I thought, “Okay, I’ll just do most of the writing myself.” Unfortunately there turned out to be two problems with that theory: one is that I couldn’t write enough, quickly enough to make the Quarterly a viable publication. The other, even more serious problem, was that I found myself losing interest in writing on the topics Code Quarterly was supposed to be covering. I have, for some time, described myself as a writer turned programmer and a programmer turned writer. These days I’m feeling more and more like just a writer and one who wants to write about things other than just programming and computer science.

As a result, I never got Code Quarterly to the point where I could find out whether the third part of my theory was right. I’d like to think it was: two out of three wouldn’t be bad, even if not good enough for success.

I’m sorry that I wasn’t able to pull this off. It’s certainly possible that there’s something I could have done differently over the past year and a half that would have led to a more successful outcome but to continue now would be to fall prey to the sunk cost fallacy—the time and money I’ve spent are gone and spending more when my heart is no longer in it is just a recipe for ending up with less of both with no more to show for it.

My thanks to everybody who encouraged me along the way and my apologies to those who are still waiting, hoping to see something come of it. I especially want to thank Adam Solove, who did some beautiful design work, both print and web, which now, sadly, will never see the light of day and Michael Fogus, my one writer to complete an article, his interview with Rich Hickey.

Up next, I try to figure out a new career as a writer and editor. I hope to write more books but I’ve discovered, working on Code Quarterly, that I also enjoy editing other people’s writing. So if you know anyone who’s looking for a freelance or part-time development editor send them my way.

Advertisement

Code Quarterly (née Gigamonkeys Quarterly)

So this is an actual announcement. The idea I floated the other day about a quarterly journal for hackers is now a real going concern, renamed Code Quarterly. I got a ton of email from people interested in the idea and have put together some writer’s guidelines for folks interested in contributing. If you just want to be told when we have made some progress toward actual content, go to the website and fill out our form. Or follow us on Twitter.

Gigamonkeys Quarterly

I’m not sure if this is an announcement, a pre-announcement, or simply a trial ballon, but here’s an idea that’s been getting me excited lately: Gigamonkeys Quarterly, a web site / journal / publishing house that will publish well-written articles and books of interest to hackers.

My basic theory is that there’s a niche waiting to be filled by someone publishing well-written pieces longer than blog articles but shorter than books and making them available in a variety of formats.

So my plan is to create a web site where I can publish in-depth articles about computers and software written by me and by other writers who are interested in working with a hands-on editor. (Me, that is.) We will then publish individual pieces in other formats: DRM-free PDFs, ebooks for devices such as Kindle and iPad, and print-on-demand paper books. And then, if all goes well, we’ll also publish a nicely typeset paper magazine quarterly. Finally, we may publish book-length treatments of various subjects in serial and then publish them as books when they’re complete. Or all these plans might change drastically when they come into first contact with the enemy.

I plan to pay contributors for their work but at the moment all I can say about that is that I expect to pay them fairly for their contribution, based on how much money, if any, the Quarterly makes.

The basic categories of articles I’m interested in are:

1. Explanations of deep technical ideas aimed at competent programmers.
2. Annotations and critques of interesting code.
3. Profiles of and Q&A interviews with interesting programmers.
4. “Think pieces” about larger issues of interest to hackers. e.g. Should the code behind scientific research be released and if so, why isn’t it?
5. Book reviews.
6. Cool hacks – interesting code explained by its author.
7. Computer history – articles that explore how we got where we are today.

If you have any interest in writing for the Quarterly or being involved in any other capacity, feel free to email me. Or if you just have words of encouragement, or even discouragement, I’d love to hear those too.

Life on the hedonic treadmill

There’s a theory in psychology called the “hedonic treadmill” which says that most people have a happiness “set point” that they return to pretty much regardless of what happens to them. Things that you might expect to make someone very happy (winning the lottery) or very sad (losing a limb) actually tend to not have a dramatic long term effect on a person’s happiness. In other words, people are pretty resilient. Or, put another way, we’re forgetful. We think how how happy we would be if we got a big raise and how much easier our lives would be with a bit more money in our pocket. And we get the raise and some things do get easier. But pretty quickly we forget how life was before and how happy we are supposed to be now. The new becomes the status quo, we find a new set of things to worry about, and we end up about as happy as we were before.

However most of us don’t get raises or experience any other big life changes often enough to get a real sense of the power of the hedonic treadmill. To get a dramatic demonstration of this phenomenon in action, all you need to do is spend two years of your life working on a book, have it published, and then obsess over the hourly updates to its Amazon Sales Rank. (The Sales Rank is the number Amazon attaches to every book it sells. Better Sales Ranks mean more sales and—more important—a book’s Sales Rank is the only readily accessible, frequently updated data an author has about how a book is selling.)

You finish your book and start paying some attention to its Sales Rank. It’s still in the high 100,000s, or even the millions. Whatever. No one but your parents has even heard of your book yet, let alone bought it. Then you get some word of mouth going on the web which gets you a few pre-orders and your Sales Rank spikes up a bit, maybe into the 2,000s. Woohoo! Party!

Then it starts drifting back down. Oh well, the book’s not even out yet, no big deal. But you dream of maybe one day breaking into the top-1000. That sounds pretty cool. Imagine, one of the top-1000 books on Amazon! They sell essentially every book in print; what’s that ten million books or so? Top-1000 would put you in the top 0.1% of all books. That’d be awesome.

Then some early reviews hit the web. Maybe they get some play on the social networking sites. Wow! Sales Rank goes shooting up—past 1,000, into the 500s. Yippee! And the book isn’t even out yet! Who knows how it’ll do once it’s actually released. Then, once again, the rank starts drifting back down. You feel a bit sad when it starts dropping but pretty soon the days of a 500s-level rank feel like a bit of a dream; anything better than 10,000 is still quite respectable. The decline continues and pretty soon it’s closer to 100,000 than 10,000, but no matter. Hitting the 500s is pretty darn good and the book still isn’t even out yet.

Then a review on a very prominent web site sends the rank rocketing back up. In a few hours it goes from greater than 100,000 to the 500s. And keeps going! Smashes the old high-water mark! Holy cannoli, it’s in the top-200! #178! Wow, that feels awesome. You never thought this could happen. And surely the book won’t have its best rank ever before it’s even out. Maybe it’s not crazy to dream of getting into the top-100, even if just for an hour.

Then the downward drift starts again. But not too fast. It’s hanging out safely in the top-2,000 for a while before dipping down into the 3,000s. And it rallies occasionally into the 1,500 to 2,000 range. Really, if it keeps on like this, this is great. An average sustained Sales Rank better than 10,000 is pretty darn respectable. And that #178 is something you can tell your grand-kids about.

Then the book is released. Whether because of a burst of word of mouth or the publisher’s PR actually working or because there are just a lot of people who wait for the book to come out before ordering, boom! the rank is moving up again. Quick jump back into the top-1,000. 800s. 200s again! Whoa! #173. Beat the old mark! And back down. That may be it. But really, nice that that first foray into the top-200 wasn’t a once-in-a-lifetime event. That’s pretty good. Now, let’s see how long it hangs out in the top-1000.

A few days, it turns out. Life in the top-1000 is pretty nice. Feels like this book might actually be a bit of a success. It would have been nice to crack the top-100 but this is good. Whoops, out of the top-1,000. Oh well. Still a long way to go before it falls out of the top-10,000. And look, it’s rallying again. 600s, 500s, 300s, 200s. Nice! Ah, #239 and then dropping again. Anyway, at least you’re back in the top-1,000 for a while. A dip out of the top-1000 then another rally back to #551.

Then much like before. Drifts down. It takes a couple days to fall out of the top-1,000 and then bounces around a bit between 1,000 and 1,500. Maybe the glory days of #173 and #178 are past but if the book just keeps steadily selling, that’s what’s important.

Then, one night before you go to bed, you see the book has been mentioned on another prominent web site. You wonder if that could possibly pop it back up into the top-200 again. That’d be nice. Maybe, just maybe, you still have a chance to crack the top-100. Something to dream about as you go to sleep.

Get up in the morning. Coffee. Check the ranks your computer has collected overnight. Holy smokes. It cracked the top-100 right after you went to bed! And it’s still there! At #22! In fact it’s been at #22 for three hours. Holy shit! Quick, email your folks! Wait, wait, new rank coming in: #16! Okay, this day is clearly going to be a total loss—you’re not going to be able to do anything until it starts going back down and you can relax. Sales Ranks are supposed to be updated every hour but that doesn’t mean they necessarily change every hour. So, a couple hours at #16. Wow—it’s holding its ground. Then, wait, wait, wait—#9. And #9 again the next hour! #8! #7! You have the #7 ranked book on all of Amazon! Only five books between you and Dan Brown’s new novel.

Finally it drops back down to #8 and hangs out there for a few hours. Then #9. Then #10. Hey, at least you’re still in the top-10. Finally you drop out of that. But you’re still in the top-25 which puts you on the first page of Amazon best sellers. So that’s cool. Anyway, you spent a day and a half in the top-10. A couple days later you drop out of the top-25 and the next day out of the top-50. But what the heck, you made it into the top-10. Who ever figured on that? At the moment you’re still in the top 100, hanging on in the 90s. You know it’ll drift back down. Will it hang out in the top-1000 for a while. Probably. Will you be sad when, inevitably, it falls out of top-1000. Probably not. Life on the hedonic treadmill.

Election 2008—some fun

I’ve been following the U.S. Presidential election on the excellent site www.fivethirtyeight.com which features sophisticated statistical aggregation of all the published polls done in the U.S and also at the prediction market Intrade.com. But as it comes down to the election I know I’ll need a frequently updated dashboard for watching the results. So I came up with this. (N.B. Requires Firefox 3 and at least as much screen realestate as a 15″ Powerbook.)

Inspired by a page put together by Randall Munroe of xkcd fame, my dashboard periodically fetches the market price of Intrade’s state-by-state election markets, which represent the probability, as assessed by the Intrade traders, that a given candidate will win a given state. From those probabilities I compute the overall probability of various scenarios and color the map appropriate shades of blue and red. I also provide some dials and knobs (sliders) actually, to allow you to play some real-time “what if” games with the results.

There are some flaws some flaws with my statistical methodology (most notably the almost certainly erroneous assumption that the state probabilities are all independent) but it should nonetheless be a good way of tracking the results as the come in: Assuming the Intrade traders, who’ve got real money on the line, stay on the job the Intrade values will head toward certainty as exit polls and actual results become available and my dashboard will reflect that.

Software delivery on the web?

The other day I was talking to my friend Marc about software development. Marc is founder and Chief Product Officer of Wesabe a startup that, “makes it easy to better understand how you spend your money and links you to a community of people dedicated to helping each other make better financial decisions.” Wesabe is one of these new-fangled companies whose whole product is their web site, which they update, according to Marc, every day. The frequency of their updates came up when I was using version control as an example of something that developers need to understand in order to work well in groups — not just the mechanics of a particular version control system, but the how and why of things like release branches. Marc suggested that my thinking was way out of date — that because everyone is delivering their software on the web these days, release branches were an anachronism. He’s certainly right that if you release your software by updating your own web site then there’s no reason to make release branches — the point of release branches is to allow you to go back and fix bugs in old releases and if you’re delivering your software as a service there’s only one release and no direction to go but forward.

My question is: what percentage of software startups these days are planning to deliver their software as a service vs “traditional” delivery of software to be run by customers? Is Marc really right that the software-as-service model is so prevalent now that a book aimed at developers who want to learn the things they need to know to be productive members of a programming team can ignore older styles of delivering software?

Another question is, even if Marc is right that everyone is delivering their software as a service, to what extent they will be able to avoid having to support older versions of their software? It’s one thing for small companies, still in early days of fleshing out their feature sets, to continually upgrade and force their users to come along for the ride. But as they get more users and a more mature feature set, I suspect they will discover that not all their users will be willing to accept upgrades willy nilly. Presumably this will be less of an issue for companies whose real value is the social network of the users as opposed to the value being in the raw functionality of the software itself. In the former case the whole point is to have exactly one instance of the software, shared by all users while in the latter case, if the users are depending on particular functionality, they may not want it to change, even if the change is ostensibly an “upgrade”.

Have an opinion? Let me know.

Update: My former boss Bob Pasker, now a Venture Advisor and CTO-in-Residence at Azure Capital Partners, gives me this breakdown of the software delivery mechanism of companies he’s seen recently in his work at Azure:

• 50% delivered over the web, either as HTML or flash
• 25% require an install, either on server or on desktop
• 25% other (mobile, email, hardware, or both)

Hello

Hello. Welcome to my blog. If you know who I am you’re probably either my mother or have read my book Practical Common Lisp. Or possibly you’ve either seen the video of a talk I gave at Google’s New York office last May or heard the IT Conversations interview I did with Phil Windley of Technometria. Any of which — except in the case where you’re my mother — might lead you to expect that this blog is going to be about Lisp. Which, though I’ll probably have occasional things to say about Lisp, it mostly won’t. But I’m hoping you might stick around anyway. (Yeah, Mom, I know you will.)

So what can you expect if you do? You’ll get to see me exploring ideas that I hope will eventually turn into another book. Since Practical Common Lisp came out in April 2005, I’ve been consulting — mostly Lisp work, some not. I wound all that down last September in anticipation of the arrival of a baby, my daughter Amelia. Now, much as my wife’s memories of the pain of childbirth are fading, my own memories of the pain of writing a book have faded from visceral to merely intellectual. I remember saying, “I’m never ever going to do this again,” but I can no longer summon up the feeling that led me to say it. Which must mean it’s time to write another one.

At a recent get together of the Bay Area Lispniks I asked the folks at my table what computer-related book they felt was missing. One fellow suggested a book on the programming language D. Hmmmm, I think I’ve already done my bit trying to promote a deserving but unappreciated language to a wider audience. (And I don’t really know enough about D to say whether it’s really deserving. Though any language that starts from the premise that C++ needs to replaced is at least starting out on the right foot.) Another guy suggested a book on “programming for the data center” — i.e. how to write programs that are going to run on a Google-style room full of computers. That sounded a bit more promising but not something that I have any particular expertise in; someone at Google should write it. Then, speaking of Google, Peter Norvig suggested a book about how to program in groups. By which he meant a book that explains all the stuff that a programmer needs to know to be an effective member of a team; the stuff that a lone-hacker, either self-taught or fresh out of a comp sci program, typically has to learn on the job. Norvig claimed — and I tend to agree, based on my own bookshelf — that there isn’t really a good book on that topic. There are books about how to be a better programmer, as an individual. And there are books about project management from which an enterprising developer could back out some lessons about how to be an effective contributor to a team. But nothing that I’ve seen aimed at helping an individual developer develop the skills that are specific to working in the context of a development team.

This suggestion immediately pricked my interest: I’ve always been interested in the question of “what is the best way to develop software?” One way to look at my interest in Lisp is that it is part of an answer to this bigger question. But as much as I love Lisp, I recognize it’s not a complete answer — most software shops would probably get more bang for their buck from adopting techniques that allow groups of people to work together most effectively than they would from switching to a better programming language, even Lisp. So now I’m excited to start writing about that.

My basic plan is to talk to everyone I know who’s involved in developing software and anyone they’ll introduce me to and to read or reread anything and everything relevant I can get my hands on. Then I’ll be ready to apply the Gigamonkey Four-Step Algorithm for Writing a Book that I developed while writing Practical Common Lisp. If you have suggestions of people I should talk to or things I should read please drop me a note. Since all that talking and reading will take a while, it’ll probably be a while before I can get down to the writing phase proper. In the meantime I plan to use this blog as a place to think out loud and to try to keep up my writing chops. And if the stuff I write here helps either to drum up advance interest in the book or to attract folks interested in hiring me as a consultant, that’d be fine too. (Unlike when I wrote Practical Common Lisp, when I spent two years without working other than on the book, this time around I plan to try to combine writing with consulting, both because I’ve got a new mouth to feed and because the right kind of consulting gigs will actually give me more material for the book. See the section “Gigamonkeys Consulting” in the sidebar if you’re interested in hiring me.)