I’ve pulled the plug on Code Quarterly. To read about why, please see this blog post. Thanks for your interest. —Peter Seibel
One of our goals for Code Quarterly is to find ways to encourage and facilitate code reading. Virtually all of the interviewees from Editor Peter Seibel’s book Coders at Work mentioned reading code as a key to becoming a good programmer. And most of them bemoaned how infrequently programmers actually do read code.
Often we don’t read code because it’s hard to find good code to read.1 And many of us find it easier to write our own code than to read other people’s. So we’re going to try to leverage the latter fact to help out with the former by including as a regular feature of Code Quarterly a coding challenge wherein we present the specification of a medium-sized bit of functionality, along with some test cases, and ask our readers to send us code that implements the specification.2
We will then publish all the submitted code on our website and will write an article giving a detailed analysis and critique of some of the best programs.
By participating you will get to:
Hone your craft working on problems that are designed to challenge your software design skills, not your mathematical insight (c.f. Project Euler) or your raw coding speed (c.f. Top Coder).
Have a chance to compare your efforts to those of others tackling the same problem.
Perhaps be recognized in our pages as the author of some particularly well-written code.
For participants and non-participants alike, the collection of programs written for each challenge will serve, we hope, as a good set of programs to read—each long enough to be interesting but short enough to dive into and easier to understand together since they all implement the same specification.
The programs should also provide an interesting chance to compare different programming languages and different ways of approaching the same problem as we will accept submissions in any language and in whatever style each programmer thinks is best suited to the problem.
Because the purpose of the challenge is to encourage code reading, we are more interested in readable code than in excessively clever, obfuscated line noise that somehow magically implements a specification. When choosing which submissions to discuss in the article we will be primarily looking for code with good qualities we can point out. But beyond correctness and readability—which should get top priority—we are excited to see how different coders make different trade-offs between code length, speed, memory usage, maintainability, debuggability, robustness, and other qualities.
If this sounds interesting, check out our inaugural challenge.
1 Which is, by no means meant to say that there isn’t good code to read—just that it can be hard to find. We also intend for Code Quarterly to regularly run articles looking at and critiquing good bits of code found “in the wild.”
2 By “medium-sized” we mean something that will probably take more than a hundred lines but fewer than a thousand in a high-level language. Though we fully expect that some submitters will show ways the challenge can be met in far fewer lines than most of us would think possible.