Communications of the ACM
Lessons Learned Writing For BLOG@CACM
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.
Contact BLOG@CACM
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
Outline
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.
Submit To BLOG@CACM
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.
References
Jerry Seinfeld - Comedian: https://www.imdb.com/title/tt0328962/
BLOG@CACM
- A Tale Of A Non-Traditional Software Engineer
- Challenges in breaking into the software engineering field.
- Career Care For Engineers
- A non-technical but important article on principles for managing one's career that are too often overlooked.
- Why Are There So Many Programming Languages?
- An example of the benefits of tracking ideas, sometimes for fairly long periods of time.
- Software Stories: Legal Trouble
- An example of a non-technical topic that is too frequently ignored until it's too late
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 https://www.linkedin.com/pulse/publications-doug-meil
No entries found