Systems and Networking

Lessons Learned Writing For BLOG@CACM

Doug Meil.

I've written 16 posts for the BLOG@CACM so far, enough to have some successes and to have stubbed my toes a few times along the way. I've also had the opportunity to recruit a few new writers to the blog, and this is the advice I give about the writing process that I found effective.

What To Write About?

It sounds trite, but it's true: write about what you know, with respect to experiences and observations. Everybody has a perspective—I am a career software engineer, so my posts tend to be the on the good, the bad, and the ugly of software engineering and product development practices. But there are many other topics to write about such as computer security, infrastructure management, computer engineering, databases and related frameworks, AI and Machine Learning, NLP, and the research and educational processes for the above, to name a few. There are also a host of non-technical topics such as human resources, career management, and legal topics that are relevant to technical fields. Knowledge sharing is powerful for all parties involved.  It's also easy to forget that it's not just the senior folks that have something to say.  A great example is a post from a mid-career co-worker on the challenges she faced in breaking into the software field "A Tale Of A Non-Traditional Software Engineer."

The Idea List

The 2002 documentary Comedian is a behind-the-scenes look at the development process of stand-up comedy. One thing to note was how thorough Jerry Seinfeld's joke-notes were, as he wrote down everything. This is a lesson that writers in every field can learn from: write it down, write it down, write it down. Keep an Idea List and stack-rank it. Periodically review the ranking, because certain ideas will flow to the top and become more actionable. One of my posts, "Why Are There So Many Programming Languages?",  is an example of the benefits of periodic review. I found the high-level concept intriguing, but I couldn't quite figure out how to approach it and it stayed on the bottom of my Idea List for over a year. I had an eventual breakthrough, but if I had not written the idea down for tracking purposes, it is likely I would have just forgotten about it.

The Idea List is effectively a requirements list and a backlog—something that every developer should recognize—except that the writer is playing the role of product manager, engineer, and QA all in one.


If you have a potential idea, contacting the editor of the BLOG@CACM is a good place to start.  Ask about the concept proposal, and confirm the submission parameters (e.g., length, format).

Also, to become a better writer, it helps to read more—especially BLOG@CACM posts and other ACM publications. See what others are writing about, and how they do it.

Working On An Idea


One approach to writing is linearly, from start to finish. Some people might be able to write like that for large papers, but I cannot. For any sizable topic, I find it much more effective to create an outline first and then figure out what story I am trying to tell. It's also much faster to iterate on an outline than to radically overhaul a 2,000-word wall of text once you realize that things are not quite coming together as initially expected. The time spent in developing a solid outline will reap benefits ten-fold down the line.

As an aside, this is why PowerPoint and other related presentation tools can be such a problematic medium. People have a tendency to start creating slides before thinking through the overall presentation message and get stuck in formats which constrain their thinking.  Such tools can be useful, but slide-creation should generally come last.

Start Sketching In

Slowly turn the bullet-points from the outline into narrative.

Let It Sit, If Necessary

Sometimes ideas need to simmer, and that is okay. This is where having a stack-ranked Idea List comes in handy, as having a #2 or #3 idea in process as a backup can be a helpful diversion.

Overhaul & Update

Eventually, the original outline dissolves into well-structured and flowing prose, but this takes effort and iteration. Keep at it.

Keep in mind the Mark Twain quote about editing: "I didn't have time to write a short letter, so I wrote a long one instead."

Test Readers

Every writer has experienced a situation where a draft has been proofed and perceived to be tight, and then only after clicking the send-button various errors and mis-phrases suddenly reveal themselves, as if by bad magic. The send-button has a way of doing that. This is where test-readers can help. Send the draft to a few friends for review—it's a good way to sanity check the overall message, as well as tricking the send-button.

The Beatles sung about getting by with a little help from one's friends, and this entirely applies to writing. Make sure that test-readers are thanked, and do them a good turn by reviewing their drafts as well.


If accepted, don't forget to promote the link on your own social media!

If the submission is not accepted, dust yourself off and try again. Don't be too discouraged, and don't let the lessons learned go to waste.



Jerry Seinfeld – Comedian:



Doug Meil is a software architect in healthcare data management and analytics. He also founded the Cleveland Big Data Meetup in 2010. More of his BLOG@CACM posts can be found at

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More