How to Write an Article

Who writes articles in Overload? Taking names from the list of Overload authors on the ACCU website gives around 250 authors, without breaking down joint authorship. The top three authors have been Sean Corfield, with 80, Alan Griffiths with 74 and Sergey Ignatchenko with 69 articles. Figure 1 shows a histogram of authors with 10 or more articles to their name.

A consistent pattern emerges of a few people who contribute again and again – most regular Overload readers have never written an article. Some readers may have a blog, or join in a discussion on accu-general, or discuss something technical over a beer with colleagues one evening, but never get as far was writing it up for the ACCU.

The majority of the articles published here are from ACCU members, but from time to time other people submit articles. Indeed, as a peer reviewed journal, we are open to submissions from anyone. One of the benefits of such a journal is the feedback process. The article can be improved before being read by the public at large whereas a blog gets the feedback after it is published. Don’t forget being published in a peer review journal counts as a few extra kudos points.

Idea

How do you decide what to write about? Bear in mind writing is usually a learning process. Even if you think you are the world’s leading expert on a particular field, writing it up clearly will find gaps in your knowledge or spark off new ideas.

It can be worthwhile to simply write a summary style article, with the latest thinking on a subject you are interested in, perhaps delving way back to its beginnings years ago or simply introducing a new language feature. This will get you, and your readers, up to speed with a way of doing something.

Some articles have started life with a question on a discussion group, like accu-general. In fact, my first Overload article, ‘Floating point fun and frolics’ [Buontempo09], started there. It can make life easier to just have a trail of comments and ideas to summarise if you don’t feel you have enough ideas yourself. Alternatively, you can present a new technique, library or even language you have developed yourself. Either way, the audience may expect to see a few references, so it is possible to do further background reading on a subject.

If you’re not sure whether to submit to Overload or CVu, try both and see what happens. The main points to bear in mind are:

• Overload is freely available, so anyone may read it. You may want to just try something in CVu first time, but this is not a requirement.
• Overload tries to take a more academic tone, so might tend towards more technical content, with more references.

Something like ‘My first ‘Hello World’ program in JavaScript’ might be more suited to CVu, while something like ‘Advanced C++17’ might be more suited to Overload.

If you do not have a full blown article, but just a sketch of an idea, it is OK to get in touch for some early feedback. We might be able to give a few pointers of further things to research or other ways of doing things.

If you do want to submit a full-blown article, try to give it some kind of structure. Simply having an introduction, main work and conclusion is far better than sending in a list of bullet points.

Spare a little thought for your target audience. How much background might need fully explaining? What can be covered by a reference and leave them to go read up if required? We are always open to other ideas, including but not limited to letters to the editor, for example if a previous article has set you thinking.

Submission

How do you submit an article to Overload? The best approach is to use email: Overload@ACCU.org. An easy-to-copy format, like Open Office, Word, or just plain text is best, though other formats are acceptable. Any diagrams should be attached as separate scalable graphics, so they can be positioned and sized easily for the final layout.

If you are demonstrating code you have written, it might not need listing in its entirety. Enough listings to get the main point across often work well. It is sensible to add a link to the whole codebase, for example a github repository, if relevant, though.

We also like to have a short biography, with a contact email. Your readers may get in touch and say ‘Thanks’.

Some journals offer a template, expecting submissions in a specific font, with a specific size, number of columns and so on. We don’t mind – the formatting and layout will happen later. We won’t fuss too much about length either. Approximately one thousand words fill a page. Anything from one page upwards is ok. If your article is a 20 page epic, it might make more sense to split in into two or more mini-articles. This will depend on how many other pages have already been taken up, and where we can find a natural place in which to insert a break. More details on the format and structure can be found in ‘Guidelines for contributors’ [Overload07].

Feedback

If your article looks like a plausible candidate, it will get sent round the review team, and you will be emailed back comments. We try to make sure we get a mix of positive encouraging comments, nit-picks over typos and grammar, and suggestions of unclear parts that may need rewording. On top of this basic style feedback, be prepared for the reviewers to point out something you may have missed, for example newer language techniques, more succinct ways of doing things, pre-existing libraries you can use off the shelf. You are allowed to argue back, of course, but this process can make the articles more thorough and you may learn even more during the process. Once in a while, the only feedback simply says, “This is great.” Not often, but it can happen. On very few occasions the potential author decides not to take on board the feedback, and the idea is taken no further.

Once all the articles have been reviewed they are sent to the production editor, and you will then receive a proof first-draft, showing the actual layout. At this stage everyone needs to keep their eye open for omissions, like second author’s names, missing diagrams, copy and paste errors and other typos that have slipped under the net. Not matter how hard we try there always seem to be at least one in the final printed version.

Fame

Shortly after the drafts, the whole magazine will be pieced together. You are likely to see an announcement on accu-general, the accu.org webpage and possibly Twitter.

Obviously, if you are a member and have paid for it you will get a paper copy through your door at some point and can leave it lying around open on your desk to show off to all your friends and colleagues. If you aren’t a member, you can ask for a printed copy – yours to show off and share with others. It might even persuade someone to join.

Almost nothing beats the sight of your name in print – try it.

References

[Buontempo09] Frances Buontempo ‘Floating point fun and frolics’ in Overload 91, available at https://accu.org/journals/overload/17/91/buontempo_1558/

[Overload07] Overload ‘Guidelines for Contributors’ in Overload 80, available at https://accu.org/journals/overload/15/80/overload_1414/

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD using AI and data mining. She’s written a book about machine learning: Genetic Algorithms and Machine Learning for Programmers. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.