<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Things Software &#187; Technical Writing</title>
	<atom:link href="http://hakanerdogmus.net/weblog/category/topics/technical-writing/feed" rel="self" type="application/rss+xml" />
	<link>http://hakanerdogmus.net/weblog</link>
	<description>by Hakan Erdogmus, Kalemun Research Inc.</description>
	<lastBuildDate>Fri, 04 May 2012 17:45:43 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Oulu Technical Writing Workshops</title>
		<link>http://hakanerdogmus.net/weblog/2011/oulu-technical-writing-workshops</link>
		<comments>http://hakanerdogmus.net/weblog/2011/oulu-technical-writing-workshops#comments</comments>
		<pubDate>Sun, 13 Nov 2011 13:42:16 +0000</pubDate>
		<dc:creator>Hakan</dc:creator>
				<category><![CDATA[Technical Writing]]></category>
		<category><![CDATA[Upcoming Events]]></category>
		<category><![CDATA[Workshops & Seminars]]></category>

		<guid isPermaLink="false">http://hakanerdogmus.net/weblog/?p=1622</guid>
		<description><![CDATA[[ December 7, 2011 to December 9, 2011. ] 



University of Oulu, Finland



]]></description>
			<content:encoded><![CDATA[<table class="ec3_schedule"><tr><td class="ec3_start">December 7, 2011</td><td class="ec3_to">to</td><td class="ec3_end">December 9, 2011</td></tr></table><div>
<hr />
<p>University of Oulu, Finland</p>
<hr />
</div>
]]></content:encoded>
			<wfw:commentRss>http://hakanerdogmus.net/weblog/2011/oulu-technical-writing-workshops/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CPSC Workshop: Technical Writing for a Broad Audience</title>
		<link>http://hakanerdogmus.net/weblog/2011/cpsc-workshop-technical-writing-for-a-broad-audience</link>
		<comments>http://hakanerdogmus.net/weblog/2011/cpsc-workshop-technical-writing-for-a-broad-audience#comments</comments>
		<pubDate>Thu, 01 Sep 2011 19:00:43 +0000</pubDate>
		<dc:creator>Hakan</dc:creator>
				<category><![CDATA[Courses]]></category>
		<category><![CDATA[Talks & Presentations]]></category>
		<category><![CDATA[Technical Writing]]></category>
		<category><![CDATA[Upcoming Events]]></category>
		<category><![CDATA[Workshops & Seminars]]></category>

		<guid isPermaLink="false">http://hakanerdogmus.net/weblog/?p=1527</guid>
		<description><![CDATA[[ September 22, 2011; 9:00 am to 12:00 pm. ] 

Department of Computer Science, University of Calgary, Alberta


Registration &#124; Description
]]></description>
			<content:encoded><![CDATA[<table class="ec3_schedule"><tr><td colspan="3">September 22, 2011</td></tr><tr><td class="ec3_start">9:00 am</td><td class="ec3_to">to</td><td class="ec3_end">12:00 pm</td></tr></table><div>
<hr />Department of Computer Science, University of Calgary, Alberta</p>
<hr /></div>
<div><a title="Workshop Registration" href="https://docs.google.com/spreadsheet/viewform?formkey=dGFISklac05mZXNVZzJvVnBzRVNlNnc6MQ" target="_self"><em>Registration</em></a> | <a title="Workshop Description" href="https://docs.google.com/document/pub?id=1uictZK9U72RAz4Kh8hDXBwy5_w7Y8Hy1HiUtq68UrSc" target="_self"><em>Description</em></a></div>
<hr />
]]></content:encoded>
			<wfw:commentRss>http://hakanerdogmus.net/weblog/2011/cpsc-workshop-technical-writing-for-a-broad-audience/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Top Ten Ways to Kill a Paper &#8211; Part II</title>
		<link>http://hakanerdogmus.net/weblog/2009/top-ten-ways-to-kill-a-paper-part-ii</link>
		<comments>http://hakanerdogmus.net/weblog/2009/top-ten-ways-to-kill-a-paper-part-ii#comments</comments>
		<pubDate>Sat, 16 May 2009 04:17:20 +0000</pubDate>
		<dc:creator>Hakan</dc:creator>
				<category><![CDATA[IEEE Software]]></category>
		<category><![CDATA[Technical Writing]]></category>

		<guid isPermaLink="false">http://hakanerdogmus.net/weblog/?p=791</guid>
		<description><![CDATA[In a previous blog, I talked about five common mistakes authors make when trying to get an article accepted for publication in peer-reviewed software engineering journals, magazines, or proceedings. The full list includes ten common mistakes, as follows:
Number 10. Ignore reviewer feedback.
Number 9. Stick to clichés.
Number 8. Borrow without giving due credit.
Number 7. Don&#8217;t worry about [...]]]></description>
			<content:encoded><![CDATA[<p>In <a title="Top Ten Ways to Kill a Paper - Part I" href="http://hakanerdogmus.net/weblog/top-ten-ways-to-kill-a-paper" target="_self">a previous blog</a>, I talked about five common mistakes authors make when trying to get an article accepted for publication in peer-reviewed software engineering journals, magazines, or proceedings. The full list includes ten common mistakes, as follows:</p>
<blockquote><p><em>Number 10. Ignore reviewer feedback.</em></p>
<p><em>Number 9. Stick to clichés.</em></p>
<p><em>Number 8. Borrow without giving due credit.</em></p>
<p><em>Number 7. Don&#8217;t worry about the language.</em></p>
<p><em>Number 6. Ignore your work&#8217;s limitations.</em></p>
<p><em>Number 5. Ignore the context and prior art.</em></p>
<p><em>Number 4. Rely on argumentation to push an idea.</em></p>
<p><em>Number 3. Ignore your audience.</em></p>
<p><em>Number 2. Be undeservedly authoritative.</em></p>
<p><em>Number 1. Write in a purely descriptive style.</em></p></blockquote>
<p><span id="more-791"></span>In this post, I&#8217;ll address the top five sins from Number 5 Number 1.  </p>
<p>Sin #5 is the sin of laziness, or the appearance of it. Readers want to know what encompasses an idea, a piece of research, or a narrative about an interesting experience. They want to be able to position it relative to other works that are similar. They want to know about the connections between concepts, the progression of ideas. They want to understand the context. Prior art and context provide the beginning of a story. Without the beginning, the story struggles to survive. Without prior art and context, a paper has little value.</p>
<p>Sin #4 is the sin of defensiveness. Relying on winding questionable arguments to push an idea makes it seem like the author’s premise doesn’t hold water, as if the weakness of the idea needs to be hidden behind a veil of twisted logic. A better alternative to using argumentation is presenting facts and existing evidence. If evidence is not strong, just admit it. No apologies are necessary.</p>
<p>Sin #3 is making no attempt to differentiate among the various types of audiences. If you write up your excellent research in an overly scholarly style for a professional magazine, it will bounce back. If you write up your exceptionally insightful project experience report in an overly colloquial style for a research journal, it will bounce back. Style matters to your target audience. In addition, certain elements need to be in place in different types of publications at varying degrees. A comprehensive, academic-quality literature survey may not be necessary, or even overkill,  for a magazine, but is essential for an archival periodical. Know your audience, and know what each type of publication requires to meet its audience&#8217;s expectations.</p>
<p>Sin #2 often accompanies Sin #4. It comes from the absolute tone that authors often use when expressing what is simply a point a view. Or, it comes from the tendency to pepper an article with unsupportable statements or embellish ideas with virtuous qualifiers and superlatives. This almost always makes reviewers recoil with disgust and fury. Avoid being unnecessarily absolute and self-assured. Humility, without being deliberately fuzzy, will work better than you think. However, it doesn’t imply that you shouldn’t take risks. Your message can still be provocative.</p>
<p>Perhaps the best strategy to use to get a paper rejected is to take a good idea and just write it up. And stop there. This brings us to Sin #1. A purely descriptive style is one in which you just describe something — whether it’s a concept, a process, an idea, a new technology, an experience, a study — in gory detail, definition by definition, step by step. You start from the beginning, explain all the elements in a clear, natural sequence, perhaps give a few small examples, and then you’ve done your job. You can stop. What could be wrong with this straightforward approach? Nothing. It may be perfectly OK for a white paper, a chapter of a text book, an appendix, a manual, a handbook, or a technical report. But it won’t make very interesting reading and it certainly will not buy you any brownie points with the reviewers. Try it!</p>
<p><em> </em></p>
<div><em><img class="alignnone size-full wp-image-796" title="hakan_e" src="http://hakanerdogmus.net/weblog/wp-content/uploads/hakan_e.png" alt="hakan_e" width="92" height="37" /></em></div>
<p><em> </em></p>
<p><em></em> </p>
<p><em>Releated resources:</em></p>
<blockquote>
<ul>
<li><a title="Tips for Software Authors" href="http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2007.149 " target="_blank">Tips for Software Authors</a></li>
<li><a title="How to Write a Good Technical Article" href="http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2002.10006" target="_blank">How to Write a Good Technical Article</a></li>
</ul>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://hakanerdogmus.net/weblog/2009/top-ten-ways-to-kill-a-paper-part-ii/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Top 10 Ways to Kill a Paper Before It&#8217;s Born</title>
		<link>http://hakanerdogmus.net/weblog/2009/top-10-ways-to-kill-a-paper</link>
		<comments>http://hakanerdogmus.net/weblog/2009/top-10-ways-to-kill-a-paper#comments</comments>
		<pubDate>Mon, 13 Apr 2009 18:36:05 +0000</pubDate>
		<dc:creator>Hakan</dc:creator>
				<category><![CDATA[IEEE Software]]></category>
		<category><![CDATA[Technical Writing]]></category>
		<category><![CDATA[Peer review process]]></category>

		<guid isPermaLink="false">http://hakanerdogmus.net/weblog/?p=696</guid>
		<description><![CDATA[Back in March, I gave a presentation to the IEEE Student Chapter at the Université du Québec à Montreal on publishing software engineering articles in peer-reviewed venues.  In that presentation, I talked about the common sins prospective authors commit when trying to get a technical article accepted by a peer-reviewed publication. This post gives a synopsis of those sins.]]></description>
			<content:encoded><![CDATA[<p>Back in March, I gave a <a title="UQAM IEEE Student Chapter March 2009 - Erdogmus" href="http://hakanerdogmus.net/weblog/uploads/presentations/UQAM-IEEE-Mar2009-Erdogmus.pdf" target="_blank">presentation to the IEEE Student Chapter at the Université du Québec à Montreal</a> on publishing software engineering articles in peer-reviewed venues.  In that presentation, I talked about the common sins prospective authors commit when trying to get a technical article accepted by a peer-reviewed publication. This post gives a synopsis of those sins.</p>
<p><span id="more-696"></span></p>
<p>My top-10 list, which applies to both research and practice pieces,  goes like this:</p>
<blockquote><p><em>Number 10. Ignore reviewer feedback.</em></p>
<p><em>Number 9. Stick to clichés.</em></p>
<p><em>Number 8. Borrow without giving due credit.</em></p>
<p><em>Number 7. Don&#8217;t worry about the language.</em></p>
<p><em>Number 6. Ignore your work&#8217;s limitations.</em></p>
<p><em>Number 5. Ignore the context and prior art.</em></p>
<p><em>Number 4. Rely on argumentation to push an idea.</em></p>
<p><em>Number 3. Ignore your audience.</em></p>
<p><em>Number 2. Be undeservedly authoritative.</em></p>
<p><em>Number 1. Write in a purely descriptive style.</em></p></blockquote>
<p>In this post, I&#8217;ll address the bottom five sins from Number 10 Number 6. I will tackle to top five in a subsequent post. So stay tuned.</p>
<p>If you&#8217;ve already gone through the process of submitting a paper to a peer-reviewed publication like <em><a title="IEEE Software" href="http://hakanerdogmus.net/weblog/ieee-software" target="_self">IEEE Software</a></em>,  you know that once the submission has been screened in by the editors, it goes through at least one round of peer reviews followed by author revisions. Often, two such rounds are required. Sin Number 10 applies to a submission that has already survived a round of peer reviews, and the editors are now recommending revisions to address the reviewers&#8217; comments.  And you&#8217;re naturally apprehensive: the pesky reviewers don&#8217;t understand your work. How dare them? You decide to just pay lip service to their objections and perform some cosmetic changes to silence them, thinking that the submission has already been vested and rejection in a subsequent stage is unlikely. But rejection is unlikely only if the reviewers and editors give in, or overlook the superficial nature of the revisions you are comtemplating. Albeit reviewers and editors are quite diligent, and they won&#8217;t let go. Editors, as per editorial policies,  are not at liberty to ignore reviewers&#8217; concerns although they have plenty of discretion. Indeed, it&#8217;s more common than authors think to have a submission rejected following a round of revisions. And sometimes an article gets rejected even after several rounds. The better strategy requires a different author perspective, one that is not defensive. An honest attempt to address and reconcile reviewers&#8217; concerns almost always pays off. Think of the reviewers as a sampling of the readership: some may not be as familiar as the area as you would like them to be, and others may carry biases, just like your readers. Experienced editors who oversee the review process are often aware of these factors: their eyes are trained to detect biases, and they will take them into account in their recommendations.</p>
<p>Sin Number 9 relates to motherhood-and-apple-pie advice and insights. The self-fulfilling kind that is repeated over, and over, and over again elsewhere and in the mainstream IT media. Editors and reviewers tend to have a visceral reaction to this style of writing, and for good reason: an article peppered with clichés sounds vacous to the naked eye despite the gems hidden underneath.</p>
<p>Sin Number 8, when taken for granted will not only secure a stamp of rejection for your article, but may also get you into trouble. Giving credit to to others who have influenced your work will make you look better, not worse. Most submissions describe incremental improvements over previous ideas, and it&#8217;s important to acknowledge all contributions. Sometimes it feels benign to ignore to mention the source of a peripheral idea, because you&#8217;re the one who have pursued the breakthrough bit: resist that temptation. Respectable publications impose sanctions on authors who borrow without bothering to mention the lender, or fail to disclose background sources in derivative work .</p>
<p>Unlike research journals, professional magazines like <em><a title="IEEE Software" href="http://hakanerdogmus.net/weblog/ieee-software" target="_self">IEEE Software</a> </em>have their content professionally copy edited and laid out. While this extra service allows the authors to focus their efforts on the message delivered, it still does not absolve them from paying attention to the language and adhering to common rules of good technical writing. Which brings us to sin Number 7. A poorly written article distracts the reviewers. Sometimes a substandard language kills the message, and the paper with it. Several submissions are rejected if the ideas are not communicated clearly, and reviewers can&#8217;t get passed the numerous editorial mistakes to glean the important messages from the text.</p>
<p>Sin Number 6 stems from a combination of overconfidence, blindness, and ignorance. Every new idea comes with caveats and compromises. Be sure to identify and declare the shortcomings of your work: where it&#8217;s applicable, where the boundaries drawn, and when it&#8217;s unlikely to work. Or suffer the wrath of reviewers who will only be glad to point them out to you and the editors. Self-awareness is your best defence against a rejection case built on the limitations of your work.</p>
<p><em>To be continued&#8230;</em><em> </em></p>
<p><img class="alignnone size-full wp-image-796" title="hakan_e" src="http://hakanerdogmus.net/weblog/wp-content/uploads/hakan_e.png" alt="hakan_e" width="92" height="37" /></p>
<blockquote><p>Releated resources:</p>
<ul>
<li><a title="Tips for Software Authors" href="http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2007.149 " target="_blank">Tips for Software Authors</a></li>
<li><a title="How to Write a Good Technical Article" href="http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2002.10006" target="_blank">How to Write a Good Technical Article</a></li>
</ul>
<p> </p></blockquote>
]]></content:encoded>
			<wfw:commentRss>http://hakanerdogmus.net/weblog/2009/top-10-ways-to-kill-a-paper/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

