I’ve pulled the plug on Code Quarterly. To read about why, please see this blog post. Thanks for your interest. —Peter Seibel
If you are interested in writing for Code Quarterly you can either send us a completed article or a proposal for an article that you’ve not yet written.
Whichever you send, one of three things will happen. If we like it, we’ll offer you our standard contract and you can start work. If you started with a complete article, that will mean working with us to whip it into its final shape; if you started with a proposal it will mean actually writing the article. Another possibility is that we won’t be quite ready to accept your submission but will think it has potential. In that case we’ll suggest ways you can revise it before resubmitting. Finally, it’s possible that we may simply let you know that your article or proposal is not right for us.
If you submit a proposal, rather than a complete article, your job is to convince us that you would write a fascinating article. Hook us from the beginning and we’ll be confident that you’ll be able to hook our readers too. Beyond that, your proposal should give us a sense of your writing style and should explain what material you intend to cover and how you plan to organize it.
The more detail you can provide, the better. For instance, “I want to write about NoSQL databases,” is too vague. “I will compare current NoSQL databases to RDBMes,” is moving in the right direction, and “I will compare current NoSQL databases to RDMSes by showing how a small applications – a simple blog server – would be implemented using a document database like CouchDB, a graph database like Neo4j, a key/value store like Memcachedb, and a traditional a RDBMS such as MySQL,” gives us plenty of detail to chew on.
Speaking of details, here are some about what we are looking for.
Our mission is to provide well-written, in-depth articles. If you write for us, we are going to constantly push you to place your topic in context. There are plenty of places readers can go to learn how to use the latest programming language, framework, or development methodology. We want to show how those things fit into the history of our craft and how the ideas they embody are related to other ideas.
A large part of the reason we want to publish in-depth articles is because we assume that many of our readers know a lot already. Whatever your topic, you’ll need to find something to say that will be interesting to people who already know about it. On the other hand, nobody knows everything, so your article will also have to bring people up to speed who don’t know about your topic when they start reading.
We want in-depth articles; therefore we plan to publish long articles. There’s no upper limit on length other than how long you can maintain the reader’s interest. Probably things in the 8,000–20,000 word range are ideal but we’ll be happy to look at things shorter or longer than that. (Heck, we’d be happy to publish a complete book though we’d want to publish it serially in the Quarterly first.)
This may all sound a bit daunting: long, in-depth, and aimed at a highly knowledgeable readership. And we want it to be well written. But you won’t be alone. We know well-written prose doesn’t just happen. Luckily there’s a simple, old-fashioned solution: you will be edited. We’re not going to try to force your article into a particular style or tone but we will work closely with you to help you organize your material, to find the places that need to be filled in or filed down, and to make sure you’re saying what you really mean to say in a clear and comprehensible way.
Well, we’ll pay you. At the moment we’re not sure exactly how this is going to work, but the basic idea is this: We hope to make money by selling PDFs, print-on-demand books, and ebook versions of our pieces as well as from subscriptions to the print quarterly. That’s revenue. It will cost a certain amount of money to produce the Quarterly and run the web site, etc. That’s expenses. What’s left over is profit and we will split that with you in some equitable way. We know that good writing takes time and – from personal experience – that it’s harder to make the time when it’s purely a labor of love.
We will, of course, sort out the details by the time we draw up our publication contracts.
While anything could end up in the Quarterly that someone convinces us will interest hackers, there are a few basic categories of articles that we imagine we’ll be publishing most often.
Technical explanations – Explain a technical concept. But first convince our readers that they should care about it. Perhaps they’ll care because it’s of immediate practical use. Or maybe it’s just intellectually fascinating. But you have to make the case. Examine your own interest in the topic and figure out how to convey that to the reader. Mere novelty is unlikely to be a sufficient reason to care – the computer world is littered with novelty. But if you can take the new hotness and put it into a broader context, that could be a winning article.
Code reads – Explore an interesting piece of code. Though many of the elders of our craft say we should read code, few of us do so regularly. In part that’s because it’s hard to sit down cold with a piece of code and wrap your head around it. These pieces will try to help by giving the reader a guided tour of a piece of code, either to demonstrate some interesting techniques that it uses or to show how a particularly well written piece of code is put together. If the code you want to write about is your own, you can explain why it is structured the way it is and what other approaches you tried.
Q&A interviews – Sit down with a programmer and talk about programming. See Coders at Work for fifteen examples of how it might be done. Note that this form of article may turn out to be harder than you think: after you’ve had your conversation and get it transcribed, you’ll have to do some serious editing to turn it into something anyone will want to read. We’ll show you some of the tricks of the trade.
Think pieces – Talk about a not-strictly-technical issue that hackers would care about. For example, should the code behind scientific research be released and if so, why isn’t it? Or, how can computers be best used in kids’ education.
Computer history – Take a look back at where we came from. Tell the story of the people who made our field what it is or explore the origins of a technical idea.
Book reviews – Read a book. Write about it. You know the drill.
At the moment we’re pretty flexible about how you submit your work. (For proposals, we prefer plain text.) Use whatever tools and formats you want and we’ll see if we can work with it.
Ultimately, we’re going to want to store articles as some kind of plain text in version control. If your chosen format isn’t plain text we’ll need to be able to round-trip it between your format and something else. Once we get a bit more experience under our belts, we may settle on a few formats that work well for us.
Feel free to email me even if you’re not quite ready to submit a proposal and just want some quick feedback on your ideas. Or if you’re on irc.freenode.net, I’m often there as ‘gigamonkey’; feel free to message me there. –Peter Seibel, Editor.