How to write a technical paperContents: This document describes several simple, concrete ways to improve your writing, byavoiding some common mistakes. The end of thisdocument contains more resources for improving your writing.

Some people believe that writing papers, givingtalks, and similar “marketing” activities are not part ofresearch, but an adjunct to it or even an undesirable distraction. The purpose of research is to increase the store ofhuman knowledge, and so even the very best work is useless if you cannoteffectively communicate it to the rest of the world.

Additionally, writing papers and givingtalks will clarify your thinking and thereby improve your research The Journal of Technical Writing and Communication (JTWC) is one of several prestigious international Articles most recently published online for this journal..

You may be surprised how difficult it is to clearly communicate your ideasand contributions; doing so will force you to understand them more deeplyand enable you to improve them. Know your message, and stay on message The goal of writing a paper is to change people's behavior: for instance,to change the way they think about a research problem or to convince themto use a new approach.

Determine your goal (also known as your thesis),and focus the paper around that goal. As a general rule, your paper needs to convince the audience of three keypoints: that the problem is interesting, that it is hard,and that you solved it.

If any of these is missing or unclear, thepaper will not be compelling. You'll also need to convince your readers that your contributions are novel.

When expressing this, it may be helpful to explain why no one else thoughtof your approach before, and also to keep in mind how you expect thebehavior of readers to change once they appreciate your contributions. Before you write your paper, you need to understand your audience.

Who will read your paper? What are their backgrounds, motivations,interests, and beliefs? What are the key points you want a reader personto take away from your paper?Once you know the thesis and audience, you can determine what points yourdocument should make to achieve its purpose. For each point in your paper, you need to explain both what and why.

For example, it is not enough to state how an algorithm works; you should explainwhy it works in that way, or why another way of solving the problem wouldbe different.

Similarly, it is not sufficient to present a figure and merely help the readerunderstand what the figure says. You must also ensure that reader understandsthe significance or implications of the figure and what parts of it aremost important.

Which details to include Your purpose is to communicate specific ideas, and everything about yourpaper should contribute to this goal. If any part of the paper does not doso, then delete or change that part.

You must be ruthless in cutting everyirrelevant detail, however true it may be. Everything in your paper thatdoes not support your main point distracts from it.

Write for the readers, rather than writing for yourself. In particular,think about what matters to the intended audience, and focus on that.

It is not necessarily what you personally find most intriguing. A common mistake is to focus on what you spent the most time on.

Do notwrite your paper as a chronological narrative of all the things that youtried, and do not devote space in the paper proportionately to the amountof time you spent on each task. Most work that you do will never show upin any paper; the purpose of infrastructure-building and exploration ofblind alleys is to enable you to do the small amount of work that is worthwriting about.

Another way of stating this is that the purpose of thepaper is not to describe what you have done, but to inform readers of thesuccessful outcome or significant results, and to convince readers of thevalidity of those conclusions. Likewise, do not dwell on details of the implementation or theexperiments except insofar as they contribute to your main point.

This is a particularly important piece of advice for softwaredocumentation, where you need to focus on the software's benefits to theuser, and how to use it, rather than how you implemented it. However, itholds for technical papers as well — and remember that readers expectdifferent things from the two types of writing! The audience is interested in what worked, and why, so start with that.

Ifyou discuss approaches that were not successful, do so briefly, andtypically only after you have discussed the successful approach. Furthermore, the discussion should focus on differences from the successfultechnique, and if at all possible should provide general rules or lessonslearned that will yield insight and help others to avoid such blind alleysin the future.

Whenever you introduce a strawman or an inferior approach, say so upfront. A reader will (and should) assume that whatever you write in a paper issomething you believe or advocate, unless very clearly marked otherwise.

Apaper should never first detail a technique, then (without forewarning)indicate that the technique is flawed and proceed to discuss anothertechnique. This mistake isoften called “leading the reader down the garden path”. When there are multiple possible approaches to a problem, it is preferableto give the best or successful one first.

Oftentimes it is not even necessaryto discuss the alternatives. If you do, they should generally come after,not before, the successful one.

Your paper should give the most importantdetails first, and the less important ones afterward. Its main line ofargument should flow coherently rather than being interrupted.

It can beacceptable to state an imperfect solution first (with a clear indicationthat it is imperfect) if it is a simpler version of the full solution, andthe full solution is a direct modification of the simpler one. Lesscommonly, it can be acceptable to state an imperfect solution first if itis an obvious solution that every reader will assume is adequate; but usecare with this rationalization, since you are usually wrong that everyreader will jump to the given conclusion.

Make the organization and results clear A paper should communicate the main ideas of your research (such as thetechniques and results) early and clearly. Then, the body of the paper canexpand on these points; a reader who understands the structure and bigideas can better appreciate the details.

Another way of saying this isthat you should give away the punchline. A technical paper is not a jokeor a mystery novel.

The reader should not encounter any surprises, onlydeeper explanations of ideas that have already been introduced. It'sparticularly irritating when an abstract or introduction states, “Weevaluated the relationship between baldness and beekeeping”, with the keyresults buried pages later.

A better abstract would say, “Male beekeepersare 25% more likely to be bald (p=. 04), but there is no statisticallysignificant correlation for female beekeepers.

” The same advice applies at the level of sections and paragraphs Have traditionally been used in technical communication research and then exploring phers and field researchers work in the qualitative realm and recognize..

The technical communication research landscape - ann m

Instead, state the point first and then support it. The reader is morelikely to appreciate which evidence is important and why, and is lesslikely to become confused or frustrated.

For each section of the paper, consider writing a mini-introduction thatsays what its organization is, what is in each subpart, and how the partsrelate to one another. For the whole paper, this is probably a paragraph.

For a section or sub-section, it can be as short as a sentence. This mayfeel redundant to you (the author), but readers haven't spent as much timewith the paper's structure as you have, so they will truly appreciate thesesignposts that orient them within your text.

Some people like to write the abstract, and often also the introduction,last. Doing so makes them easier to write, because the rest of the paperis already complete and can just be described.

However, I prefer to writethese sections early in the process (and then revise them as needed), becausethey frame the paper. If you know the paper's organization and outlook,then writing the front matter will take little effort.

If you don't, thenit is an excellent use of your time to determine that information bywriting the front matter. To write the body of the paperwithout knowing its broad outlines will take more time in the long run.

Another way of putting this is that writing the paper first will make writing the abstract faster, and writingthe abstract first will make writing the paper faster. There is a lot morepaper than abstract, so it makes sense to start with that and to clarifythe point of the paper early on.

It is a very common error to dive into the technical approach or theimplementation details without first appropriately framing the problem andproviding motivation and background. Readers need to understand what thetask is before they are convinced that they should pay attention to whatyou are saying about it.

You should first say what the problem or goal is,and — even when presenting an algorithm — first state what theoutput is and probably the key idea, before discussing steps. Avoidproviding information that isn't useful to readers/users.

Getting started: overcoming writer's block and procrastination Some writers are overwhelmed by the emptiness of a blank page or editorbuffer, and they have trouble getting started with their writing.

Don'tworry! Here are some tricks to help you get started. Once you have begun,you will find it relatively easier to revise your notes or first draft.

The key idea is to write something, and you can improve it later. Explain what the paper needs to say to anotherperson. After the conversation is over, write down what you just said,focusing on the main points rather than every word you spoke.

Many peoplefind it easier to speak than to write. Furthermore, getting feedback andgiving clarifications will help you discover problems with your argument,explanation, or word choice.

You may not be ready to write full English paragraphs, butyou can decide which sections your paper will have and give themdescriptive titles.

Once you have decided on the section structure, youcan write a little outline of each section, which indicates the subsectiontitles. Now, expand that into a topic sentence for each paragraph.

Atthis point, since you know the exact topic of each paragraph, you will findthe paragraph easy to write. Write down everything that you know,in no particular order and with no particular formatting. Afterward,organize what you wrote thematically, bringing related points together.

Eventually, convert it into an outline and proceed as above. While writingnotes, use phrases/keywords, not complete sentences.

The phrasesare quicker to write and less likely to derail your brainstorming; they areeasier to organize; and you will feel less attached to them and morewilling to delete them. Rather than trying to write your entiredocument, choose some specific part, and write just that part. Find other text that you have written on the topic and startfrom that.

An excellent source is yourprogress reports — you are writingthem, aren't you? This can remind you what was hard or interesting, or ofpoints that you might otherwise forget to make. You will rarely want tore-use text verbatim, both because you can probably convey the point betternow, and also because writing for different audiences or in differentcontexts requires a different argument or phrasing.

For example, atechnical paper and a technical talk havesimilar aims but rather different forms. You must be willing to delete and/or rewrite your notes andearly drafts.

If you wrote something once, you can write it again(probably better!). Early on, the point is to organize your ideas, not tocreate finished sentences.

If a word does not support your point,cut it out, because excess verbiage and fluff only make it harder for thereader to appreciate your message.

Technical communication research: from traditional to virtual

Eliminate any text that does notsupport your point.

Here is one way you might go about this; it istime-consuming but extremely effective. First, examine each section of thepaper in turn and ask what role it serves and whether it contributes to thepaper's main point.

Next, within each section, examineeach paragraph.

Also ask whether that point contributes to thegoals of the section. Next, withineach paragraph, examine each sentence. If it does not make a single, clearpoint that strengthens the paragraph, delete or rewrite it.

Finally,within each sentence, examine each word, and delete or replace those thatdo not strengthen their point. You will need to repeat this entire processmultiple times, keeping a fresh perspective on the paper.

Some people find it easier to follow this approach bottom-up, firstcutting/rewriting words, then sentences, etc. Writing style Passive voice has no place in technical writing.

It obscures who theactor was, what caused it, and when it happened. Use active voice andsimple, clear, direct phrasing.

First person is rarely appropriate in technical writing. Never use firstperson to describe the operation of a program or system.

Itis only appropriate when discussing something that the author of the paperdid manually. (And recall that your paper should not be couched as anarrative.

) It is confusing to use “we” to mean “theauthor and the reader” or “the paper” (“In thissection, we . ”) or even “the system being described”(“we compute a graph” makes it sound like the authors did it byhand).

As a related point, do not anthropomorphize computers: they hate it. Anthropomorphism, such as “the program thinks that.

Avoid puffery, self-congratulation, and valuejudgments: give the facts and let the reader judge.

Do not use words like “clearly”, “easily”,“obviously”, and “trivially”, asin “Obviously, this Taylor series sums to . ” If the point isreally obvious, then you are just wasting words by pointing it out.

And ifthe point is not obvious to readers who are not intimately familiar with thesubject matter the way you are, then you are offending readers byinsulting their intelligence, and you are demonstrating your own inability tocommunicate the intuition. In “sequences inducegraphs”, it is not clear whether the two collections are inone-to-one correspondence, or the set of sequences collectively induces aset of graphs; “each sequence induces a graph” avoids thisconfusion. Likewise, in “graphs might contain paths”, it isunclear whether a given graph might contain multiple paths, or mightcontain at most one path.

When describing an experiment or some other action that occurred in thepast, use past tense. For example, the methodology section shouldnot say “We run the program”, but “We ran the program”.

However, it wouldbe correct to say “Our methodology was to run the program”, where you areusing the infinitive “to run”. When describing the paper itself, use present tense.

The reason for this is that the reader is experiencingthe paper in real time; the paper is like a conversation between theauthors and the reader. Avoid gratuitous use of the future tense “will .

”, as in, “switching thered and green wires will cause the bomb to explode”.

Instead, use theshorter and more direct “switching the red and green wires causes thebomb to explode” Jump to Make the organization and results clear - A paper should communicate the main ideas of your research (such as the techniques and results) early .

Use “previous work” instead of “existing work”.

What are the differences between research papers and technical

Avoid gratuitous use of the future tense “will . ”, as in, “switching thered and green wires will cause the bomb to explode”.

Instead, use theshorter and more direct “switching the red and green wires causes thebomb to explode”. In a list with 3 or more elements list, put a serial comma between eachof the items (including the last two).

As a simple example ofwhy, consider this 3-element grocery list written without the clarifyinglast comma: “milk, macaroni and cheese and crackers”. It's notclear whether that means milk, macaroni and cheese, crackers or milk,macaroni, cheese and crackers .

As another example, “I would liketo thank my parents, Rene Descartes and Ayn Rand,” suggests ratherunusual parentage, whereas “I would like to thank my parents, ReneDescartes, and Ayn Rand,” shows a debt to four people. I've seenreal examples that were even more confusing than these.

In English, compound adjectives are hyphenated but compound nouns are not. Consider “the semantics provide name protection” versus “the name-protection semantics”.

Some of the suggestions in this document are about good writing, and thatmight seem secondary to the research. But writing more clearly will helpyou think more clearly and often reveals flaws (or ideas!) that hadpreviously been invisible even to you.

Furthermore, if your writing is notgood, then either readers will not be able to comprehend your good ideas,or readers will be (rightly) suspicious of your technical work. If you donot (or cannot) write well, why should readers believe you were any morecareful in the research itself? The writing reflects on you, so make itreflect well.

Figures Use figures! Different people learn in different ways, so you shouldcomplement a textual or mathematical presentation with a graphical one. Even for people whose primary learning modality is textual, anotherpresentation of the ideas can clarify, fill gaps, or enable the reader toverify his or her understanding.

Figures can also help to illustrateconcepts, draw a skimming reader into the text (or at least communicate akey idea to that reader), and make the paper more visually appealing. It is extremely helpful to give an example to clarify your ideas: this canmake concrete in the reader's mind what your technique does (and why it ishard or interesting).

A running example used throughout the paper is also helpful inillustrating how your algorithm works, and a single example permits you toamortize the time and space spent explaining the example (and the reader's time inappreciating it). It's harder to find or create a single example that you re-use throughoutthe paper, but it is worth it.

A figure should stand on its own, containing all the information that isnecessary to understand it. Good captions contain multiple sentences; thecaption provides context and explanation.

For examples, see magazines suchas Scientific American and American Scientist. Neverwrite a caption like “The Foobar technique”; the caption shouldalso say what the Foobar technique is, what it is good for, or how it works.

Thecaption may also need to explain the meaning of columns in a table or ofsymbols in a figure. However, it's even better to put that information inthe figure proper; for example, use labels or a legend.

When the body ofyour paper contains information that belongs in a caption, there areseveral negative effects. The reader is forced to hunt all over the paperin order to understand the figure.

The flow of the writing is interruptedwith details that are relevant only when one is looking at the figure. Thefigures become ineffective at drawing in a reader who is scanning the paper— an important constituency that you should cater to! As with naming, use pictorial elements consistently.

Only use two different types of arrows (or boxes, shading, etc. ) when theydenote distinct concepts; do not introduce inconsistency just becauseit pleases your personal aesthetic sense.

Almost any diagram with multipletypes of elements requires a legend (either explicitly in the diagram, orin the caption) to explain what each one means; and so do many diagramswith just one type of element, to explain what it means. Many writers label all the types of figures differently — some as“figure”, others as “table” or“graph” or “picture”.

This differentiation has nobenefits, but it does have a drawback: it is very hard for a reader tofind “table 3”, which might appear after “figure 7”but before “freehand drawing 1”. You should simply call themall figures and number them sequentially.

The body of each figure might bea table, a graph, a diagram, a screenshot, or any other content. Put figures at the top of the page, not in the middle or bottom.

If a numbered, captionedfigure appears in the middle or at the bottom of a page, it is harder forreaders to find the next paragraph of text while reading, and harder tofind the figure from a reference to it. Export figures from your drawingprogram in a vector graphics format. If you must use a bitmap (which isonly appropriate for screenshots of a tool), then produce them at very highresolution.

Use the biggest-resolution screen you can, and magnify thepartion you will copture. Computer program source code Your code examples should either be real code, or should be close to realcode.

Never use synthetic examples such as procedures or variables named foo or bar. Made-up examples are much harder for readersto understand and to build intuition regarding.

Furthermore, they give thereader the impression that your technique is not applicable in practice— you couldn't find any real examples to illustrate it, so you had tomake something up. Any boldface or other highlighting should be used to indicate the mostimportant parts of a text.

In code snippets, it should never be used tohighlight syntactic elements such as “public” or“int”, because that is not the part to which you want to drawthe reader's eye. (Even if your IDE happens to do that, it isn'tappropriate for a paper.

) For example, it would be acceptable to useboldface to indicate the names of procedures (helping the reader find them),but not their return types.

Writing research papers

Never use terms like“approach 1”, “approach 2”, or “ourapproach”, and avoid acronyms when possible.

If you can't think of agood name, then quite likely you don't really understand the concept This article reports data from questionnaires assessing the day-to-day experiences that members of the technical communication field have in carrying out their ..

Think harder about it to determine its most important or salient features. It is better to name a technique (or a paper section, etc.

) based on what it does rather than how it does it. Avoid “elegantvariation”, which uses different terms for the same concept, to avoidboredom on the part of the reader or to emphasize different aspects of theconcept. While elegant variation may be appropriate in poems, novels, andsome essays, it is not acceptable in technical writing, where you shouldclearly define terms when they are first introduced, then use themconsistently.

If you switch wording gratuitously, you will confuse thereader and muddle your point; the reader of a technical paper expects thatuse of a different term flags a different meaning, and will wonder whatsubtle difference you are trying to highlight. Thus, don't confuse thereader by substituting “program”, “library”,“component”, “system”, and “artifact”,nor by conflating “technique”, “idea”,“method” and “approach”, nor by switching among“program”, “code”, and “source”.

Choose the best word for the concept, and stick with it. Do not use a single term to refer to multiple concepts.

If you use theterm “technique” for every last idea that you introduce in yourpaper, then readers will become confused. This is a place that use ofsynonyms to distinguish concepts that are unrelated (from the point of viewof your paper) is acceptable.

For instance, you might always use“phase” when describing an algorithm but “step”when describing how a user uses a tool. When you present a list, be consistent in how you introduce each element,and either use special formatting to make them stand out or else state thesize of the list.

Don't use, “There are several reasons I am smart. ” Instead, use “There are four reasons I am smart.

” Especially when the points are longer, thismakes the argument much easier to follow. Some people worry that suchconsistency and repetition is pedantic or stilted, or it makes the writinghard to follow.

There is no need for such concerns: none of these is thecase. It's more important to make your argument clear than to achieve“elegant variation” at the expense of clarity.

Choose good names not only for the concepts that you present in your paper,but for the document source file. Don't name the file after the conferenceto which you are submitting (the paper might be rejected) or the year.

Even if the paper is accepted, such a name won't tell you what the paper isabout when when you look over your source files in later years. Instead,give the paper or its folder/directory a name that reflects its content.

Another benefit is that this will also lead you to think about the paper interms of its content and contributions. Here is a piece of advice that is specific to computing: do not use the vague, nontechnical term“bug”.

Instead, use one of thestandard termsfault, error, or failure. A fault is an underlying defect in a system,introduced by a human.

A failure is a user-visible manifestation of thefault or defect. In other circumstances, “bug report” may be moreappropriate than “bug”.

Numbers and measurements Digits of precision: Don't report more digits of precision than the measurement process reliably and reproducibly produces. The 3rd or 4th digit of precision is rarely accurate and generalizable; if you don't have confidence in it, omit it.

Don't report more digits of precision than needed to convey your message. 13 and 4 will not make a difference in convincing readers, then don't report the extra digits. Reporting extra digits can even distract readers from the larger trends and the big picture.

Including an inappropriate number of digits of precision can cast suspicion on all of your results, by giving readers the impression that you are statistically naive. Use a consistent number of digits of precision.

(An exception is when data are known to sum to a particular value; I would report 93% and 7% rather than either 93% and 7.

Often it's appropriate to report percentages as whole numbers rather than using the same precision.

) If you do any computations such as ratios, you should internally use the full precision of your actual measurements, but your paper will report only a limited number of digits of precision. If a measurement is exact, such as a count of items, then it can be acceptable to give the entire number even if it has many digits; by contrast, timings and other inexact measurements should always be reported with a limited number of digits of precision.

Do not confuse relative and absolute measurements. For instance, supposeyour medicine cures 30% of patients, and the placebo cures 25% of patients.

You could report that your medicine's cure rate is . (Other correct, but less good, ways to say the same thing arethat it cures cures 20% more, 120% as many, or 1. ) It would be inaccurate to state that your medicine cures 5% more patientsor your medicine cures 120% more patients. Just as you need to correctlyuse “120% more” versus “120% as many”, you need tocorrectly use “3 times faster than” versus “3 times asfast as”.

A related, also common, confusion is between “3times faster than and 3 times as fast as”. “Half as many” is a much better substitute for“2 times fewer”.

Given the great ease of misunderstanding what a percentage means or whatits denominator is, I try to avoid percentages and focus on fractionswhenever possible, especially for base measurements. For comparisonsbetween techniques, percentages can be acceptable.

Avoid presenting twodifferent measurements that are both percentages but havedifferent denominators. Processing data Your paper probably includes tables, bibliographies, or other content thatis generated from external data.

Your paper may also be written in a textformatting language such as LaTeX. In each of these cases, it is necessaryto run some external command to create some of the content or to create thefinal PDF.

All of the steps to create your final paper should be clearly documented— say, in comments or in a notes file that you maintain with thepaper — and, preferably, should be automated so that you only have torun one command that collects all the data, creates the tables, andgenerates the final PDF. If you document and automate these steps, then you can easily regeneratethe paper when needed.

This is useful if you re-run experiments oranalysis, or if you need to defend your results against a criticism byother researchers. If you leave some steps manual, then you or yourcolleagues are highly likely to make a mistake (leading to a scientificerror) or to be unable to reproduce your results later.

One good way to automate these tasks is by writing a program or creating ascript for a build system such as Make or Ant. Related work A related work section should not only explain what research others havedone, but in each case should compare and contrast that to your work andalso to other related work.

After reading your related work section, areader should understand the key idea and contribution of each significantpiece of related work, how they fit together (what are the common themes orapproaches in the research community?), and how your work differs. Don'twrite a related work section that is just a list of other papers, with asentence about each one that was lifted from its abstract, and without anycritical analysis nor deep comparison to other work.

Unless your approach is a small variation on another technique, it isusually best to defer the related work to the end of the paper. When itcomes first, it gives readers the impression that your work is ratherderivative.

(If this is true, it is your responsibility to convey thatclearly; it it is not true, then it's misleading to intimate it. )You need to ensure that readers understand your technique in its entirety,and also understand its relationship to other work; different orders canwork in different circumstances.

Just as you should generally explain your technique first, and later showrelationships with other work, it is also usually more effective to defer adetailed discussion of limitations to a later section rather than the maindescription of your technique. You should be straightforward and honestabout the limitations, of course (do mention them early on, even if youdon't detail them then), but don't destroy the coherence of your narrativeor sour the reader on your technique.

Feedback Get feedback! Finish your paper well in advance, so that you canimprove the writing. Even re-reading your own text after being away fromit can show you things that you didn't notice.

When readers misunderstand the paper, that is alwaysat least partly the author's fault! Even if you think the readers havemissed the point, you will learn how your work can be misinterpreted, andeliminating those ambiguities will improve the paper.

Be considerate to your reviewers, who are spending their time to help you. As with submission to conferences, don't waste anyone's time if there aremajor flaws. Only ask someone to read (a part of) your paper when youthink you will learn something new, because you are not aware of seriousproblems.

If only parts are ready, it is best to indicate this in thepaper itself (e. , a TODO comment that the reader will see or ahand-written annotation on a hardcopy) rather than verbally or in emailthat can get forgotten or separated from the paper. It is most effective to get feedback sequentially rather than in parallel.

Rather than asking 3 people to read the same version of your paper, ask oneperson to read the paper, then make corrections before asking the nextperson to read it, and so on.

Directions and issues in technical communication research - jstor

If you ask multiple reviewersat once, you are de-valuing their time — you are indicating that youdon't mind if they waste their time saying something you already know.

Youmight ask multiple reviewers if you are not confident of their judgment orif you are very confident the paper already is in good shape, in whichcase there are unlikely to be major issues that every reviewer stumblesover A technical note should have a valid method for a novel technique with useful The Effect of Genre-based Scaffolding on Research Paper Writing of MA .

It usually best not to email the document, but to provide a location from whichreviewers can obtain the latest version of the paper, such as a versioncontrol repository or a URL you will update. That way, you won't clutterinboxes with many revisions, and readers can always get the most recent copy.

Be generous with your time when colleagues need comments on their papers:you will help them, you will learn what to emulate or avoid, and they willbe more willing to review your writing. Some of your best feedback will be from yourself, especially as you getmore thoughtful and introspective about your writing.

One good way to do this is to write a periodicprogress report that describes yoursuccesses and failures.

The progress report will give you practicewriting about your work, oftentimes trying out new explanations. Whereas you should start writing as early as possible, you don't need toput that writing in the form of a technical paper right away.

In fact,it's usually best to outline the technical paper, and get feedback on that,before you start to fill in the sections with text. (You might think thatyou can copy existing text into the paper, but it usually works out betterto write the information anew.

With your knowledge of the overallstructure, goals, and audience, you will be able to do a much better job. )When outlining, I like to start with one sentence about the paper; thenwrite one sentence for each section of the paper; then write one sentencefor each subsection; then write one sentence for each paragraph (think ofthis as the topic sentence); and at that point, it's remarkably easy justto flesh out the paragraphs.

Responding to conference reviews (This section is most relevant to fields like computer science whereconferences are the premier publication venue. ) Many conferences provide an author response period: the authors are shownthe reviews and are given limited space (say, 500 words) to respond to thereviews, such as by clarifying misunderstandings or answering questions. The author response is sometimes called a “rebuttal”, but I don't like thatterm because it sets an adversarial tone.

Your paper will only be accepted if there is a champion for the paper:someone who is excited about it and will try to convince the rest of thecommittee to accept the paper. Your response needs to give ammunition toyour champion to overcome objections.

If there isn't a champion, then themain goal of your response is to create that champion. Read the reviews and decide what points you will respond to.

You need tofocus on the most important and substantive ones. In your responses, admit your errors forthrightly.

Don't ignore or avoidkey issues, especially ones that multiple reviewers brought up. Your response to each point will be one paragraph in your response.

Startthe paragraph with a brief heading or title about the point. Do not assumethat the reviewers remember everything that was written by every reviewer,nor that they will re-read their reviews before reading your response.

Alittle context will help them determine what you are talking about and willmake the review stand on its own. This also lets you frame the issues inyour own words, which may be clearer or address a more relevant point thanthe reviews did.

Group the paragraphs into sections,and have a small heading/title for each section.

If a given section hasjust one paragraph, then you can use the paragraph heading as the sectionheading. This is better than organizing your response by reviewer, first addressingthe comments of reviewer 1, then reviewer 2, and so forth. Downsides ofby-reviewer organization include: It can encourage you not to give sufficient context.

It does not encourage putting related information together nor important information first. You want to encourage all reviewers to read the entire response, rather than encouraging them to just look at one part.

When multiple reviewers raised the same issue, then no matter where you address it, it's possible for a reviewer to overlook it and think you failed to address it. You don't want to make glaringly obvious which issues in a review you had to ignore (for reasons of space or other reasons).

You don't want to make glaringly obvious that you spent much more time and space on one reviewer than another. In general, it's best not to mention reviewer names/numbers in yourresponse at all.

Make the response be about the science, not about thepeople. They have spentconsiderable time and energy to give you feedback (even if it doesn't seemto you that they have!), and you should be grateful and courteous inreturn. Rejection If you submit technical papers, you will experience rejection.

In somecases, rejection indicates that you should move on and begin a differentline of research. In most cases, the reviews offer an opportunity toimprove the work, and so you should be very grateful for a rejection!It is much better for your career if a good paper appears ata later date, rather than than a poor paper earlier or a sequence of weakpapers.

Even small flaws or omissionsin an otherwise good paper may lead to rejection. This is particularly atthe elite venues with small acceptance rates, where you should aim yourwork.

Referees are generally people of good will, but different refereesat a conference may have different standards, so the luck of the draw inreferees is a factor in acceptance. The wrong lesson to learn from rejection is discouragement or a sense ofpersonal failure.

Many papers — even papers that later win awards— are rejected at least once Doing this for quite some time, we have some reasonably standard forms for technical research papers, which you should use for your capstone. You should do .

For writing a technical research paper - macalester college

Don't be put off by a negative tone in the reviews. The referees aretrying to help you, and the bast way to do that is to point out how yourwork can be improved.

I often write a much longer review, with moresuggestions for improvement, for papers that I like; if the paper isterrible, I may not be able to make as many concrete suggestions, or myhigh-level comments may make detailed comments moot. If a reviewer didn't understand something, then the main fault almostalways lies with your writing.

If you blame a lazy or dumb reviewer, youare missing the opportunity to improve. Reviewers are not perfect, butthey work hard to give you helpful suggestions, so you should give them thebenefit of the doubt.

Remember that just as it is hard to convey technicalideas in your paper (and if you are getting a rejection, that is evidencethat you did not succeed!), it is hard to convey them in a review, and thereview is written in a few hours rather than the weeks you spent on thepaper (not to mention months or years of understanding the concepts). You should closely attend to both the explicit comments, and to underlyingissues that may have led to those comments — it isn't always easy tocapture every possible comment in a coherent manner.

Think about how to improve your research and your writing, even beyond theexplicit suggestions in the review — the prime responsibility foryour research and writing belongs with you. Should you submit an imperfect paper? On the plus side, getting feedbackon your paper will help you to improve it.

On the other hand, you don'twant to waste reviewers' time nor to get a reputation for submittinghalf-baked work. If you know the flaws that will make the referees rejectyour paper, or the valid criticisms that they will raise, then don't submitthe paper.

Only submit if you aren't aware of show-stoppers and you arenot embarrassed for the community to associate your name with the work, in its current form. Norman Ramsey's advice Norman Ramsey's nice Teach TechnicalWriting in Two Hours per Week espouses a similar approach to mine:by focusing on clarity in your writing, you will inevitably gain clarity inyour thinking.

Don't bother to read both the student and instructor manuals — thestudent one is a subset of the instructor one. You can get much of thebenefit from just one part, his excellent “principles and practicesof successful writers”: Principles Correctness.

Write correct English, but know that you have more latitudethan your high-school English teachers may have given you. Refer to each significant character (algorithm, concept,language) using the same word everywhere. To distinguish one-to-one relationships from n-to-mrelationships, refer to each item in the singular, not the plural.

Put your important characters in subjects, and joineach subject to a verb that expresses a significant action.

In each sentence, move your reader from familiarinformation to new information.

For material you want to carry weight or be remembered, use theend of a sentence.

In a coherent passage, choose subjects that refer to aconsistent set of related concepts.

Order your text so your reader can easily see howrelated concepts are different and how they are similar.

In an abstract, don't enumerate a list of topics covered;instead, convey the essential information found in your paper.

Ignore the common myth that successfulwriting requires large, uninterrupted blocks of time — instead, practicewriting in brief, daily sessions.

Don't worry about the size orquality of your output; instead, reward yourself for the consistency andregularity of your input.

Don't be afraid to think before you write, or even jot downnotes, diagrams, and so on.

Use them to plan a draft or to organize or reorganize alarge unit like a section or chapter.

Value a first draft not because it'sgreat but because it's there.

Write the paper you want, then cut it downto size.

Plan a revision session in which your only goal is to cut.