technical paper example

How to write a technical paper or a research paper

By michael ernst, april, 2005 last updated: august 18, 2023, which details to include, make the organization and results clear, getting started: overcoming writer's block and procrastination, writing style, computer program source code, numbers and measurements, processing data, related work, when to submit your paper for publication, responding to conference reviews, norman ramsey's advice, other resources, introduction.

This document describes several simple, concrete ways to improve your writing, by avoiding some common mistakes. The end of this document contains more resources for improving your writing.

Some people believe that writing papers, giving talks , and similar “marketing” activities are not part of research, but an adjunct to it or even an undesirable distraction. This view is inaccurate. The purpose of research is to increase the store of human knowledge, and so even the very best work is useless if you cannot effectively communicate it to the rest of the world. If a paper is poorly written, then readers might conclude you spent as little effort on the research that it describes.

Equally importantly, writing papers and giving talks will clarify your thinking and thereby improve your research. You may be surprised how difficult it is to clearly communicate your ideas and contributions; doing so will force you to understand them more deeply and 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 them to 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 key points. If any of these is missing or unclear, the paper will not be compelling.

• The problem is important . The problem has a significant impact and consequences. You can buttress your argument by showing that others consider the problem important.
• The problem is hard . Explain that obvious techniques and existing approaches do not suffice. Showing what others have tried can be effective here.
• You have solved the problem. This is often demonstrated via experiments. Keep in mind how you expect the behavior of readers to change once they appreciate your contributions. You'll also need to convince readers that your contributions are novel. When expressing this, it is helpful to explain why no one else thought of your approach before (or why, if they thought of it, they would have rejected the approach) , and whether similar insights apply to other problems.

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 person to take away from your paper? Once you know the thesis and audience, you can determine what points your document should make to achieve its purpose.

For each point in your paper, you need to explain both what and why . Start with what, but don't omit why. For example, it is not enough to state how an algorithm works; you should explain why it works in that way, or why another way of solving the problem would be different. Similarly, it is not sufficient to present a figure or facts. You must also ensure that reader understands the significance or implications of the figure and what parts of it are most important.

Your purpose is to communicate specific ideas, and everything about your paper should contribute to this goal. If any part of the paper does not support your main point, then delete or change that part. You must be ruthless in cutting every irrelevant detail, however true it may be. Everything in your paper that does 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 not write your paper as a chronological narrative of all the things that you tried, and do not devote space in the paper proportionately to the amount of time you spent on each task. Most work that you do will never show up in any paper; the purpose of infrastructure-building and exploration of blind alleys is to enable you to do the small amount of work that is worth writing about. Another way of stating this is that the purpose of the paper is not to describe what you have done, but to inform readers of the successful outcome or significant results, and to convince readers of the validity of those conclusions.

Likewise, do not dwell on details of the implementation or the experiments except insofar as they contribute to your main point. This is a particularly important piece of advice for software documentation, where you need to focus on the software's benefits to the user, and how to use it, rather than how you implemented it. However, it holds for technical papers as well — and remember that readers expect different things from the two types of writing!

The audience is interested in what worked, and why, so start with that. If you discuss approaches that were not successful, do so briefly, and typically only after you have discussed the successful approach. Furthermore, the discussion should focus on differences from the successful technique, and if at all possible should provide general rules or lessons learned that will yield insight and help others to avoid such blind alleys in 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 is something you believe or advocate, unless very clearly marked otherwise. A paper should never first detail a technique, then (without forewarning) indicate that the technique is flawed and proceed to discuss another technique. Such surprises confuse and irritate readers. This mistake is often called “leading the reader down the garden path”.

When there are multiple possible approaches to a problem, it is preferable to give the best or successful one first. Oftentimes it is not even necessary to discuss the alternatives. If you do, they should generally come after, not before, the successful one. Your paper should give the most important details first, and the less important ones afterward. Its main line of argument should flow coherently rather than being interrupted. It can be acceptable to state an imperfect solution first (with a clear indication that it is imperfect) if it is a simpler version of the full solution, and the full solution is a direct modification of the simpler one. Less commonly, it can be acceptable to state an imperfect solution first if it is an obvious solution that every reader will assume is adequate; but use care with this rationalization, since you are usually wrong that every reader will jump to the given conclusion.

A paper should communicate the main ideas of your research (such as the techniques and results) early and clearly. Then, the body of the paper can expand on these points; a reader who understands the structure and big ideas can better appreciate the details. Another way of saying this is that you should give away the punchline. A technical paper is not a joke or a mystery novel. The reader should not encounter any surprises, only deeper explanations of ideas that have already been introduced. It's particularly irritating when an abstract or introduction states, “We evaluated the relationship between baldness and beekeeping”, with the key results buried pages later. A better abstract would say, “Male beekeepers are 25% more likely to be bald (p=.04), but there is no statistically significant correlation for female beekeepers.”

The same advice applies at the level of sections and paragraphs. It is a bad approach to start with a mass of details and only at the end tell the reader what the main point was or how the details related to one another. Instead, state the point first and then support it. The reader is more likely to appreciate which evidence is important and why, and is less likely to become confused or frustrated.

For each section of the paper, consider writing a mini-introduction that says what its organization is, what is in each subpart, and how the parts relate 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 may feel redundant to you (the author), but readers haven't spent as much time with the paper's structure as you have, so they will truly appreciate these signposts 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 paper is already complete and can just be described. However, I prefer to write these sections early in the process (and then revise them as needed), because they 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, then it is an excellent use of your time to determine that information by writing the front matter. To write the body of the paper without 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 writing the abstract first will make writing the paper faster. There is a lot more paper than abstract, so it makes sense to start with that and to clarify the point of the paper early on.

It is a very common error to dive into the technical approach or the implementation details without first appropriately framing the problem and providing motivation and background. Readers need to understand what the task is before they are convinced that they should pay attention to what you are saying about it. You should first say what the problem or goal is, and — even when presenting an algorithm — first state what the output is and probably the key idea, before discussing steps. Avoid providing information that isn't useful to readers/users. It just distracts from the important content.

Some writers are overwhelmed by the emptiness of a blank page or editor buffer, and they have trouble getting started with their writing. Don't worry! 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.

Start verbally . Explain what the paper needs to say to another person. After the conversation is over, write down what you just said, focusing on the main points rather than every word you spoke. Many people find it easier to speak than to write. Furthermore, getting feedback and giving clarifications will help you discover problems with your argument, explanation, or word choice.

Outline . You may not be ready to write full English paragraphs, but you can decide which sections your paper will have and give them descriptive titles. Once you have decided on the section structure, you can write a little outline of each section, which indicates the subsection titles. Now, expand that into a topic sentence for each paragraph. At this point, since you know the exact topic of each paragraph, you will find the paragraph easy to write.

Stream-of-consciousness notes . 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 writing notes, use phrases/keywords, not complete sentences. The phrases are quicker to write and less likely to derail your brainstorming; they are easier to organize; and you will feel less attached to them and more willing to delete them.

Divide and conquer . Rather than trying to write your entire document, choose some specific part, and write just that part. Then, move on to another part.

Re-use . Find other text that you have written on the topic and start from that. An excellent source is your progress reports — you are writing them, aren't you? This can remind you what was hard or interesting, or of points that you might otherwise forget to make. You will rarely want to re-use text verbatim, both because you can probably convey the point better now, and also because writing for different audiences or in different contexts requires a different argument or phrasing. For example, a technical paper and a technical talk have similar aims but rather different forms.

You must be willing to delete and/or rewrite your notes and early drafts. If you wrote something once, you can write it again (probably better!). Early on, the point is to organize your ideas, not to create finished sentences.

Be brief. Make every word count. If a word does not support your point, cut it out, because excess verbiage and fluff only make it harder for the reader to appreciate your message. Use shorter and more direct phrases wherever possible.

Make your writing crisp and to the point. Eliminate any text that does not support your point. Here is one way you might go about this; it is time-consuming but extremely effective. First, examine each section of the paper in turn and ask what role it serves and whether it contributes to the paper's main point. If not, delete it. Next, within each section, examine each paragraph. Ask whether that paragraph has a single point. If not, rewrite the paragraph. Also ask whether that point contributes to the goals of the section. If not, then delete the paragraph. Next, within each paragraph, examine each sentence. If it does not make a single, clear point that strengthens the paragraph, delete or rewrite it. Finally, within each sentence, examine each word, and delete or replace those that do not strengthen their point. You will need to repeat this entire process multiple times, keeping a fresh perspective on the paper.

Some people find it easier to follow this approach bottom-up, first cutting/rewriting words, then sentences, etc.

Passive voice has no place in technical writing. It obscures who the actor was, what caused it, and when it happened. Use active voice and simple, clear, direct phrasing.

First person is rarely appropriate in technical writing.

• First person is appropriate when describing something that the author of the paper did manually. Recall that your paper should not be couched as a narrative.
• Do not use “we” to mean “the author and the reader” or “the paper”. For example, do not write “In this section, we ...”.
• Do not use “we” to describe the operation of a program or system. “We compute a graph” makes it sound like the authors did it by hand. As a related point, do not anthropomorphize computers: they hate it. Anthropomorphism, such as “the program thinks that ...”, is unclear and vague.

Avoid puffery, self-congratulation, superlatives, and subjective or value judgments: give the objective facts and let the reader judge. Avoid vague terms like “sizable” and “significant” (which are also subjective). Don't overuse the word “novel”.

Do not use words like “clearly”, “easily”, “obviously”, and “trivially”, as in “Obviously, this Taylor series sums to π.” If the point is really obvious, then you are just wasting words by pointing it out. And if the point is not obvious to readers who are not intimately familiar with the subject matter the way you are, then you are offending readers by insulting their intelligence, and you are demonstrating your own inability to communicate the intuition.

Prefer singular to plural number. In “sequences induce graphs”, it is not clear whether the two collections are in one-to-one correspondence, or the set of sequences collectively induces a set of graphs; “each sequence induces a graph” avoids this confusion. Likewise, in “graphs might contain paths”, it is unclear whether a given graph might contain multiple paths, or might contain at most one path.

When describing an experiment or some other event or action that occurred in the past, use past tense . For example, the methodology section might say “We ran the program”. It would be ungrammatical and confusing to use present tense, as in “We run the program”. Present tense is for ongoing events (“I write this letter to inform you...”) or regular events (“I brush my teeth each day”), but not past events (“Yesterday, I eat dinner with my family”). It is also correct to say “Our methodology was to run the program”, where you use past tense “was” and the infinitive “to run”.

When describing the paper itself, use present tense . “This paper shows that ...”. The reason for this is that the reader is experiencing the paper in real time.

Avoid gratuitous use of the future tense “will ...”, as in, “switching the red and green wires will cause the bomb to explode”. It is unclear when the action will occur. If it is an immediate effect, use the shorter and more direct “switching the red and green wires causes the bomb to explode”.

Use “previous work” instead of “existing work”. Your work exists, so “existing work” would refer to it as well.

In a list with 3 or more elements list, put a serial comma between each of the items (including the last two). As a simple example of why, consider this 3-element grocery list written without the clarifying last comma: “milk, macaroni and cheese and crackers”. It's not clear whether that means { milk, macaroni and cheese, crackers } or { milk, macaroni, cheese and crackers }. As another example, “I would like to thank my parents, Rene Descartes and Ayn Rand,” suggests rather unusual parentage, whereas “I would like to thank my parents, Rene Descartes, and Ayn Rand,” shows a debt to four people. I've seen real 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”.

Prefer unambiguous words to ambiguous ones. Do not use “as” or “since” to mean “because”. Do not use “if” to mean “whether”.

Use quotations sparingly. A clear paraphrase of the points that are relevant to your own work (along with a proper citation) is usually better than a long quotation from a previous publication.

Avoid third-person pronouns when you can. The old standard was “he”, which is masculine chauvinist. The new standard is “he or she”, which can be viewed as heteronormative and which some people find clumsy. An emerging standard is “they” as a first-person singular pronoun, which is inclusive but grammatically incorrect and confusing (see comments above about singular vs. plural number).

Some of the suggestions in this document are about good writing, and that might seem secondary to the research. But writing more clearly will help you think more clearly and often reveals flaws (or ideas!) that had previously been invisible even to you. Furthermore, if your writing is not good, then either readers will not be able to comprehend your good ideas, or readers will be (rightly) suspicious of your technical work. If you do not (or cannot) write well, why should readers believe you were any more careful in the research itself? The writing reflects on you, so make it reflect well.

Use figures! Different people learn in different ways, so you should complement a textual or mathematical presentation with a graphical one. Even for people whose primary learning modality is textual, another presentation of the ideas can clarify, fill gaps, or enable the reader to verify his or her understanding. Figures can also help to illustrate concepts, draw a skimming reader into the text (or at least communicate a key idea to that reader). Figures make the paper more visually appealing.

It is extremely helpful to give an example to clarify your ideas: this can make concrete in the reader's mind what your technique does (and why it is hard or interesting). A running example used throughout the paper is also helpful in illustrating how your algorithm works, and a single example permits you to amortize the time and space spent explaining the example (and the reader's time in appreciating it). It's harder to find or create a single example that you re-use throughout the paper, but it is worth it.

A figure should stand on its own, containing all the information that is necessary to understand it. Good captions contain multiple sentences; the caption provides context and explanation. For examples of good, informative captions, see the print editions of magazines such as Scientific American and American Scientist . The caption should state what the figure illustrates or what conclusion a reader should draw from it. Don't write an obvious description of what the figure is, such as "Code example". Never write a caption like “The Foobar technique”; the caption should also say what the Foobar technique is, what it is good for, or how it works. The caption may also need to explain the meaning of columns in a table or of symbols in a figure. However, it's even better to put that information in the figure proper; for example, use labels or a legend. When the body of your paper contains information that belongs in a caption, there are several negative effects. The reader is forced to hunt all over the paper in order to understand the figure. The flow of the writing is interrupted with details that are relevant only when one is looking at the figure. The figures 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 they denote distinct concepts; do not introduce inconsistency just because it pleases your personal aesthetic sense. Almost any diagram with multiple types of elements requires a legend (either explicitly in the diagram, or in the caption) to explain what each one means; and so do many diagrams with just one type of element, to explain what it means.

Some writers label all the types of figures differently — some as “figure”, others as “table” or “graph” or “picture”. This differentiation has no benefits, but it does have a drawback: it is very hard for a reader to find “table 3”, which might appear after “figure 7” but before “freehand drawing 1”. You should simply call them all figures and number them sequentially. The body of each figure might be a 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, captioned figure appears in the middle or at the bottom of a page, it is harder for readers to find the next paragraph of text while reading, and harder to find the figure from a reference to it.

Avoid bitmaps, which are hard to read. Export figures from your drawing program in a vector graphics format. If you must use a bitmap (which is only appropriate for screenshots of a tool), then produce them at very high resolution. Use the biggest-resolution screen you can, and magnify the portion you will capture.

Don't waste text in the paper (and tax the reader's patience) regurgitating information that is expressed more precisely and concisely in a figure. For example, the text should not repeat the numbers from a table or graph. Text in the paper should add insight or explanations, or summarize the conclusions to be drawn from the data in the figure.

Your code examples should either be real code, or should be close to real code. Never use synthetic examples such as procedures or variables named foo or bar . Made-up examples are much harder for readers to understand and to build intuition regarding. Furthermore, they give the reader the impression that your technique is not applicable in practice — you couldn't find any real examples to illustrate it, so you had to make something up.

Any boldface or other highlighting should be used to indicate the most important parts of a text. In code snippets, it should never be used to highlight syntactic elements such as “public” or “int”, because that is not the part to which you want to draw the reader's eye. (Even if your IDE happens to do that, it isn't appropriate for a paper.) For example, it would be acceptable to use boldface to indicate the names of procedures (helping the reader find them), but not their return types.

Give each concept in your paper a descriptive name to make it more memorable to readers. Never use terms like “approach 1”, “approach 2”, or “our approach”, and avoid acronyms when possible. If you can't think of a good name, then quite likely you don't really understand the concept. 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.

Use terms consistently and precisely. Avoid “elegant variation”, which uses different terms for the same concept to avoid boredom on the part of the reader or to emphasize different aspects of the concept. While elegant variation may be appropriate in poems, novels, and some essays, it is not acceptable in technical writing, where you should clearly define terms when they are first introduced, then use them consistently. If you switch wording gratuitously, you will confuse the reader and muddle your point. A reader of a technical paper expects that use of a different term flags a different meaning, and will wonder what subtle difference you are trying to highlight. Thus, don't confuse the reader 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 the term “technique” for every last idea that you introduce in your paper, then readers will become confused. This is a place that use of synonyms to distinguish concepts that are unrelated (from the point of view of 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 the size of the list. Don't use, “There are several reasons I am smart. I am intelligent. Second, I am bright. Also, I am clever. Finally, I am brilliant.” Instead, use “There are four reasons I am smart. First, I am intelligent. Second, I am bright. Third, I am clever. Fourth, I am brilliant.” Especially when the points are longer, this makes the argument much easier to follow. Some people worry that such consistency and repetition is pedantic or stilted, or it makes the writing hard to follow. There is no need for such concerns: none of these is the case. 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 conference to 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 is about when you look over your 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 in terms 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 the standard terms fault, error, or failure. A fault is an underlying defect in a system, introduced by a human. A failure is a user-visible manifestation of the fault or defect. In other circumstances, “bug report” may be more appropriate than “bug”.

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 that it is both repeatable and generalizable to new experiments, omit it. Another way to say this is that if you are not confident that a different set of experiments would produce all the same digits, then don't report so much precision.
• Don't report more digits of precision than needed to convey your message. If the difference between 4.13 and 4 will not make a difference in convincing readers, then don't report the extra digits. Reporting extra digits can 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. If the measured data are 1.23, 45.67, and 891.23, for example, you might report them as 1.23, 45.7, and 891, or as 1.2, 46, and 890, or as 1, 50, and 900. (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.4% or 90% 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, your computations should internally use the full precision of your actual measurements, even though your paper reports 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, suppose your medicine cures 30% of patients, and the placebo cures 25% of patients. You could report that your medicine's cure rate is .3, the placebo's cure rate is .25, and your medicine's cure rate is either .05 greater or 20% greater. (Other correct, but less good, ways to say the same thing are that it cures 20% more, 120% as many, or 1.2 times as many patients.) It would be inaccurate to state that your medicine cures 5% more patients or your medicine cures 120% more patients. Just as you need to correctly use “120% more” versus “120% as many”, you need to correctly use “3 times faster than” versus “3 times as fast as”. A related, also common, confusion is between “3 times faster than and 3 times as fast as”. And, “2 times fewer” makes absolutely no sense. I would avoid these terms entirely. “Half as many” is a much better substitute for “2 times fewer”.

Given the great ease of misunderstanding what a percentage means or what its denominator is, I try to avoid percentages and focus on fractions whenever possible, especially for base measurements. For comparisons between techniques, percentages can be acceptable. Avoid presenting two different measurements that are both percentages but have different denominators.

Your paper probably includes tables, bibliographies, or other content that is generated from external data. Your paper may also be written in a text formatting language such as LaTeX. In each of these cases, it is necessary to run some external command to create some of the content or to create the final 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 the paper. Preferably, they should be automated so that you only have to run one command that collects all the data, creates the tables, and generates the final PDF.

If you document and automate these steps, then you can easily regenerate the paper when needed. This is useful if you re-run experiments or analysis, or if you need to defend your results against a criticism by other researchers. If you leave some steps manual, then you or your colleagues are highly likely to make a mistake (leading to a scientific error) or to be unable to reproduce your results later.

One good way to automate these tasks is by writing a program or creating a script for a build system such as Ant, Gradle, Make, Maven, etc.

A related work section should not only explain what research others have done, but in each case should compare and contrast that to your work and also to other related work. After reading your related work section, a reader should understand the key idea and contribution of each significant piece of related work, how they fit together (what are the common themes or approaches in the research community?), and how your work differs. Don't write a related work section that is just a list of other papers, with a sentence about each one that was lifted from its abstract, and without any critical analysis nor deep comparison to other work.

Unless your approach is a small variation on another technique, it is usually best to defer the related work to the end of the paper. When it comes first, it gives readers the impression that your work is rather derivative. (If this is true, it is your responsibility to convey that clearly; if 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 can work in different circumstances.

Just as you should generally explain your technique first, and later show relationships with other work, it is also usually more effective to defer a detailed discussion of limitations to a later section rather than the main description of your technique. You should be straightforward and honest about the limitations, of course (do mention them early on, even if you don't detail them then), but don't destroy the coherence of your narrative or sour the reader on your technique.

Get feedback ! Finish your paper well in advance, so that you can improve the writing. Even re-reading your own text after being away from it can show you things that you didn't notice. An outside reader can tell you even more.

When readers misunderstand the paper, that is always at least partly the author's fault! Even if you think the readers have missed the point, you will learn how your work can be misinterpreted, and eliminating those ambiguities will improve the paper.

Be considerate to your reviewers, who are spending their time to help you. Here are several ways to do that.

As with submission to conferences, don't waste anyone's time if there are major flaws. Only ask someone to read (a part of) your paper when you think you will learn something new, because you are not aware of serious problems. If only parts are ready, it is best to indicate this in the paper itself (e.g., a TODO comment that the reader will see or a hand-written annotation on a hardcopy) rather than verbally or in email that can get forgotten or separated from the paper.

Sometimes you want to tell a colleague who is giving you feedback that some sections of your draft are not ready to be read, or to focus on particular aspects of the document. You should write such directions in the paper, not just in email or verbally. You will then update them as you update the paper, and all relevant information is collected together. By contrast, it's asking for trouble to make your colleague keep track of information that is in multiple places.

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 one person to read the paper, then make corrections before asking the next person to read it, and so on. This prevents you from getting the same comments repeatedly — subsequent readers can give you new feedback rather than repeating what you already knew, and you'll get feedback on something that is closer to the final version. If you ask multiple reviewers at once, you are de-valuing their time — you are indicating that you don't mind if they waste their time saying something you already know. You might ask multiple reviewers if you are not confident of their judgment or if you are very confident the paper already is in good shape, in which case there are unlikely to be major issues that every reviewer stumbles over.

It usually best not to email the document, but to provide a location from which reviewers can obtain the latest version of the paper, such as a version control repository or a URL you will update. That way, you won't clutter inboxes 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 will be more willing to review your writing.

Some of your best feedback will be from yourself, especially as you get more thoughtful and introspective about your writing. To take advantage of this, start writing early. One good way to do this is to write a periodic progress report that describes your successes and failures. The progress report will give you practice writing about your work, oftentimes trying out new explanations.

Whereas you should start writing as early as possible, you don't need to put 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 that you can copy existing text into the paper, but it usually works out better to write the information anew. With your knowledge of the overall structure, goals, and audience, you will be able to do a much better job that fits with the paper's narrative.) When outlining, I like to start with one sentence about the paper; then write one sentence for each section of the paper; then write one sentence for each subsection; then write one sentence for each paragraph (think of this as the topic sentence); and at that point, it's remarkably easy just to flesh out the paragraphs.

You should not submit your paper too early, when it does not reflect well on you and a submission would waste the community's reviewing resources. You should not submit your paper too late, because then the community is deprived of your scientific insights. In general, you should err on the side of submitting too late rather than too early.

A rule of thumb is to submit only if you are proud for the world to associate your name with the work, in its current form . If you know of significant criticisms that reviewers might raise, then don't submit the paper.

Submitting your paper prematurely has many negative consequences.

• You will waste the time of hard-working reviewers, who will give you feedback that you could have obtained in other ways.
• You will get a reputation for shoddy work.
• You will make the paper less likely to be accepted in the future. Oftentimes the same reviewers may serve two different venues. Reviewing a paper again puts a reviewer in a negative state of mind. I have frequently heard reviewers say, “I read an earlier version of this paper, it was a bad paper, and this version is similar.” (This is unethical because reviewers are not supposed to talk about papers they have reviewed, but nonetheless it is very common.) Now the paper will likely be rejected again, and the whole committee gets a bad impression of you. A reviewer who has read a previous version of the paper may read the resubmission less carefully or make assumptions based on a previous version. To sum up: it's harder to get a given paper accepted on its second submission, than it would have been to get the identical paper accepted on its first submission.

Here are some bad reasons to submit a paper.

It's true that the feedback from reviewers is extraordinarily valuable to you and will help you improve the paper. However, you should get feedback from other scientists (your friends and colleagues) before submitting for publication.

Those are true facts, and some people do “salami-slice” their research into as many papers as possible — such papers are called a “least publishable unit”. However, doing so leads to less impact than publishing fewer papers, each one with more content. If a paper contains few contributions, it is less likely to make a big impression, because it is less exciting. In addition, readers won't enjoy reading many pages to learn just a few facts.

Note: This point refers to taking a single research idea or theme and splitting it into multiple publications. When there are multiple distinct research contributions, it can be appropriate to describe them in different papers.

The reviewing process can be frustrating, because it contains a great deal of randomness: the same paper would be rejected by some reviewers and accepted by others. However, all great papers are accepted and all bad papers are rejected. For mediocre papers, luck plays a role. Your goal should not be to write great papers, not mediocre ones. Find a way to improve your paper. Recognize the great value of reviews: they provide a valuable perspective on your work and how to improve it, even if you feel that the reviewer should have done a better job.

If you aren't excited about the paper, it is unlikely that other people will be. Furthermore, the period after submitting the paper is not a time to take a break, but an opportunity to further improve it.

After you submit a paper, don't stop working on it! You can always improve the research. For instance, you might expand the experiments, improve the implementation, or make other changes. Even if your paper is accepted, you want the accepted version to be as impressive as possible. And if the paper is rejected, you need to have a better paper to submit to the next venue.

(This section is most relevant to fields like computer science where conferences are the premier publication venue. Responding to journal reviews is different.)

Many conferences provide an author response period: the authors are shown the reviews and are given limited space (say, 500 words) to respond to the reviews, such as by clarifying misunderstandings or answering questions. The author response is sometimes called a “rebuttal”, but I don't like that term 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 the committee to accept the paper. Your response needs to give information to your champion to overcome objections. If there isn't a champion, then the main goal of your response is to create that champion. Your response should also give information to detractors to soften their opposition.

After reading the reviews, you may be disappointed or angry. Take a break to overcome this, so that you can think clearly.

For every point in the reviews, write a brief response. Do this in email-response style, to ensure that you did not miss any points. You will want to save this for later, so it can be better to do this in the paper's version control repository, rather than in a WYSIWYG editor such as Google Docs. (This assumes you have a version control repository for the paper, which you should!) Much of this text won't go in your response, but it is essential for formulating the response.

Summarize (in 5 or so bullet points, however many make sense) the key concerns of the reviewers. Your review needs to focus on the most important and substantive critiques. The authors of the paper should agree on this structure before you start to write the actual response.

Your response to each point will be one paragraph in your response. Start the paragraph with a brief heading or title about the point. Do not assume that the reviewers remember everything that was written by every reviewer, nor that they will re-read their reviews before reading your response. A little context will help them determine what you are talking about and will make the review stand on its own. This also lets you frame the issues in your own words, which may be clearer or address a more relevant point than the reviews did.

Organize your responses thematically. Group the paragraphs into sections, and have a small heading/title for each section. If a given section has just one paragraph, then you can use the paragraph heading as the section heading. Order the sections from most to least important.

This is better than organizing your response by reviewer, first addressing the comments of reviewer 1, then reviewer 2, and so forth. Downsides of by-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 your response at all. Make the response be about the science, not about the people.

In your responses, admit your errors forthrightly. Don't ignore or avoid key issues, especially ones that multiple reviewers brought up.

Finally, be civil and thankful the reviewers. They have spent considerable time and energy to give you feedback (even if it doesn't seem to you that they have!), and you should be grateful and courteous in return.

If you submit technical papers, you will experience rejection. In some cases, rejection indicates that you should move on and begin a different line of research. In most cases, the reviews offer an opportunity to improve the work, and so you should be very grateful for a rejection! It is much better for your career if a good paper appears at a later date, rather than a poor paper earlier or a sequence of weak papers.

Even small flaws or omissions in an otherwise good paper may lead to rejection. This is particularly at the elite venues with small acceptance rates, where you should aim your work. Referees are generally people of good will, but different referees at a conference may have different standards, so the luck of the draw in referees is a factor in acceptance.

The wrong lesson to learn from rejection is discouragement or a sense of personal failure. Many papers — even papers that later win awards — are rejected at least once. The feedback you receive, and the opportunity to return to your work, will invariably improve your results.

Don't be put off by a negative tone in the reviews. The referees are trying to help you, and the bast way to do that is to point out how your work can be improved. I often write a much longer review, with more suggestions for improvement, for papers that I like; if the paper is terrible, I may not be able to make as many concrete suggestions, or my high-level comments may make detailed comments moot.

If a reviewer didn't understand something, then the main fault almost always lies with your writing. If you blame a lazy or dumb reviewer, you are missing the opportunity to improve. Reviewers are not perfect, but they work hard to give you helpful suggestions, so you should give them the benefit of the doubt. Remember that just as it is hard to convey technical ideas in your paper (and if you are getting a rejection, that is evidence that you did not succeed!), it is hard to convey them in a review, and the review is written in a few hours rather than the weeks you spent on the paper (not to mention months or years of understanding the concepts). You should closely attend to both the explicit comments, and to underlying issues that may have led to those comments — it isn't always easy to capture every possible comment in a coherent manner. Think about how to improve your research and your writing, even beyond the explicit suggestions in the review — the prime responsibility for your research and writing belongs with you.

Norman Ramsey's nice Teach Technical Writing in Two Hours per Week espouses a similar approach to mine: by focusing on clarity in your writing, you will inevitably gain clarity in your thinking.

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

• Correctness. Write correct English, but know that you have more latitude than your high-school English teachers may have given you.
• Consistent names. Refer to each significant character (algorithm, concept, language) using the same word everywhere. Give a significant new character a proper name.
• Singular. To distinguish one-to-one relationships from n-to-m relationships, refer to each item in the singular, not the plural.
• Subjects and verbs. Put your important characters in subjects, and join each subject to a verb that expresses a significant action.
• Information flow. In each sentence, move your reader from familiar information to new information.
• Emphasis. For material you want to carry weight or be remembered, use the end of a sentence.
• Coherence. In a coherent passage, choose subjects that refer to a consistent set of related concepts.
• Parallel structure. Order your text so your reader can easily see how related concepts are different and how they are similar.
• Abstract. In an abstract, don't enumerate a list of topics covered; instead, convey the essential information found in your paper.
• Write in brief daily sessions. Ignore the common myth that successful writing requires large, uninterrupted blocks of time — instead, practice writing in brief, daily sessions.
• Focus on the process, not the product. Don't worry about the size or quality of your output; instead, reward yourself for the consistency and regularity of your input.
• Prewrite. Don't be afraid to think before you write, or even jot down notes, diagrams, and so on.
• Use index cards. Use them to plan a draft or to organize or reorganize a large unit like a section or chapter.
• Write a Shitty First Draft™. Value a first draft not because it's great but because it's there.
• Don't worry about page limits. Write the paper you want, then cut it down to size.
• Cut. Plan a revision session in which your only goal is to cut.
• Norman Ramsey's advice , excerpted immediately above .
• “Hints on writing an M.Eng. thesis” , by Jeremy Nimmer
• my notes on reviewing a technical paper , which indicate how to recognize — and thus produce — quality work
• my notes on choosing a venue for publication
• my notes on giving a technical talk : a talk has the same goal as a paper, namely to convey technical ideas
• my notes on making a technical poster
• Ronald B. Standler's advice on technical writing
• Dave Patterson's Writing Advice
• Advice on SIGPLAN conference submissions (at bottom of page)
• The Elements of Style , William Strunk Jr. and E. B. White, is classic book on improving your writing. It focuses at a low level, on English usage.
• Style: Toward Clarity and Grace , by Joseph M. Williams, is another general-purpose writing guide, with a somewhat higher-level focus than that of Strunk & White.
• The Sense of Style: The Thinking Person's Guide to Writing in the 21st Century , by Steven Pinker, is an excellent guide to writing. It gives reasons (from psychology and other scientific fields) for its advice, making it more authoritative than someone's opinion.

Back to Advice compiled by Michael Ernst .

Writing a Technical Paper By Bronwyn Brench, N.C.E.

Introduction Whether experienced at writing papers or just beginning, it is always useful to have your memory refreshed on what constitutes a successful technical paper. Clearly, a successful paper is one that is accepted into a technical publication and then is read and referenced by others. To achieve this end, it must first be determined that a particular body of work is unique and valuable to others. Second, the paper must be well written and follow the style guide of the chosen publication. This article covers the basics of paper acceptance, and reviews many of the writing pitfalls made by both veteran and beginner authors alike.

I. Paper Acceptance It is vital to know the criteria for the type of publication, and to understand the audience for which the paper is intended. Two typical venues for technical papers in the EMC field are the IEEE EMC Transactions and the IEEE EMC Symposium. A third option is the Practical Papers section in the IEEE EMC Society Newsletter. Here, papers are generally shorter and cover topics of wider interest to readers. The focus of this article is on papers submitted to the IEEE Transactions on EMC and the IEEE International Symposium on EMC Proceedings publications.

IEEE EMC Transactions The IEEE Transactions on EMC has very clear instructions, located on the inside back cover of the journal, on the requirements for a paper submitted for publication. Basically, work of archival (long lasting) value is sought, including advances in the state of the art, both theoretical and experimental. There are two paper length options; a full length, eight page Paper, and a Short Paper. Full length papers are peer reviewed in detail and edited, and multiple review periods are possible. Short Papers are generally four pages in length and typically narrower in scope. These are either accepted as submitted without any substantial changes, or rejected.

IEEE EMC Symposium Paper submittals to the annual IEEE International Symposium on EMC may be directed toward the Regular or Special Sessions, and all papers have the same requirements: they must be significant to EMC, have technical depth, be readable in clear English, and contain new, unpublished work. These papers are peer reviewed, although not as heavily as for the IEEE Transactions on EMC papers. Manuscripts will be either: accepted, accepted with required changes (requiring a second peer review), accepted with suggested changes, or rejected.      If the paper is directed toward one of the Special Sessions at the Symposium, do not make the mistake of thinking it will be automatically accepted because it was “invited”. These sessions are typically organized by an individual or EMC Society Technical Committee (TC) on a topic that is of particular interest. Therefore, think of it as an invitation to submit a paper on a special topic; a topic that will not necessarily be repeated the following year. All Special Sessions papers are peer reviewed, and are held to the same required high standards as Regular Session papers.      Regular Session papers may be presented orally or in a Poster Session (Open Forum). Both types receive equal peer reviews; it is merely the presentation that differs. One common misconception is that papers in the Poster Session are of lesser value or have more relaxed standards. This is far from the truth as it is always a goal of the Symposium review committee to ensure that a good variety of topics are presented in the Poster Sessions. The major benefit of a Poster Session to the author is the ability to directly interact with interested attendees, which can be a great source of information to those doing similar work.

II. Key Parts of a Technical Paper

The Writing Overview Once the requirements for the paper have been reviewed and the work has been completed and researched for technical value, the writing may begin. Writing a technical paper, especially for an international audience, can be a daunting task. Not only can the English language be a problem, but many scientists and engineers never learned how to write a formal technical paper. There are a few good instruction guides on line, [1] and [2], if a tutorial is needed; however, the highlights of technical paper writing and a few notes on many of the common errors are given in this article.      A technical paper is not an English paper. It is also not a science lab report. The layout of a formal technical paper typically consists of the following key elements: Abstract, Introduction, Work Done, Results & Discussion, Conclusion, and References. The Abstract and Introduction are standard with their titles and content. The meat of the paper is contained in the middle sections, Work Done, Results, and Discussion, and the labeling or titles for these sections vary depending on the topic. The final two sections, Conclusion and References, are also relatively standard with their titling and content. Sometimes an Acknowledgements section is inserted between the Conclusions and References.      Working drafts often begin with the Work Done, Results, and Discussion sections. The Introduction and Conclusion sections can be started a bit later, to aid in binding the flow of the paper together. Make certain that any goals and objectives stated in the Introduction are addressed in the Conclusions. Oddly enough, the Abstract should be written last. It is only after the introduction and conclusions have been written that there will be clarity in how to phrase this special, brief summary of the paper.

Abstract The Abstract is the most important part of a technical paper, and perhaps one of the most misunderstood parts. Everyone reads them, and they are essentially the “selling point” for the paper. Even experienced authors lose sight of the purpose of an abstract and how it should be written. The key thing to remember about an abstract is that it should be a stand-alone mini-summary of the paper. Abstracts are typically extracted from each paper and published separately in an abstract listing, for readers to browse when deciding which papers they want to read in full or attend for the actual presentation of the paper. For this reason, it is especially important to spend detailed writing time on the abstract to get it precise.      The Abstract should be clear and concise, a single paragraph, typically 200 words maximum. It should include the purpose, a brief description of the work, and the pertinent results or conclusions. The English should be impeccable, especially if an international audience is expected. A special effort had to be made at the 2007 IEEE International Symposium on EMC, for example, where the EMC Society celebrated its 50 year anniversary, to grammatically edit a large majority of the extracted abstracts so that they could be clearly understood by the wide set of international attendees.      The most common mistake made is to treat the abstract as a brief introduction to the paper. The author mistakenly believes that this is where the reader’s attention must be caught with eye grabbing phrases, and then leaves them with a cliff hanger to hope they will read on. The reality is that the abstract loses its conciseness and the crucial results/conclusions synopsis is left out. Other points to note include:

• Using too many words can cause readers to skim and possibly miss important points.
• Leaving out the summary results or conclusions can cause readers to lose interest.
• Using acronyms should only be done if used again within the abstract.
• Making a reference with a footnote is never allowed.
• Making a reference with a citation at the end of the paper is never allowed.
• Make certain the English is perfect.
• Avoid background information; that is for the Introduction.

     If these guidelines are followed, then your abstract will become a perfect selling point for your paper.

Introduction The Introduction is the true start of the paper. Do not make the mistake of thinking that the Abstract is a sort of first paragraph; it is totally separate. The Introduction does just that – it introduces the reader to the work.      A typical Introduction includes four paragraphs. The first paragraph is the place for those wordy, eye catching phrases giving the reasons for and importance of the work, and why someone would want to read the paper. The second and third paragraphs contain a brief description of the background to the problem and the connection of the present work to the background. The final paragraph includes a clear statement of the purpose or goal of the work; it is an expansion from the Abstract. This will lead the readers smoothly into the start of the actual work of paper.      One error that is frequently found in paper submittals is that little, if any, research was done by the authors to determine that the work is indeed new and original. No matter how well written the paper is, it will be rejected if it is not original. ­Researching the subject matter is a good fundamental engineering practice. Why would you want to spend time doing the work and writing it up if the answer is already known? This vital step can save a great deal of wasted effort.

The Main Body This is the main part, or “meat” of the paper, and includes the work done, results, analysis, and discussion sections. The exact layout and section titles will vary depending on the topic.      A description of the work and methods used, i.e. how the work was performed, should be given in the first section. A mistake sometimes made is to list the equipment used, as if it were a lab report. If a description of any of the equipment used is necessary in understanding the work, then it is acceptable to describe that key equipment.      Next, the results should be given and analyzed. The results section is sometimes separated from the discussion section, but usually they are combined. Tables, graphs, and diagrams should be used to help visualize and explain the results and analysis. Each table and figure needs a written explanation; do not assume the reader can understand it on their own. What may be obvious to the authors may not always be obvious to others.      Frequent problems are found with tables and figures when they are shrunk down to fit in a two column format. Please, use the sizes and formatting as defined in [3] or [4]. Using anything different makes the paper harder to read and follow, and causes it to look unprofessional. If the details of the figure cannot be seen when shrunk down, then consider breaking it into multiple figures. Pay attention to any labels or wording in figures that get reduced; these must be 8 to 12 point type after reduction. Also, it is important to make sure the curves in multiple curve plots are distinguishable. Even though the use of color is now acceptable, solid fill colors are preferred as they contrast well both on screen and on a black-and-white hardcopy.      Discussing the results is also important, but leave the conclusions for the Conclusion section. The objective here is to provide an interpretation of your results and a description of any significant findings. This will logically lead readers into the Conclusion section.

This is a place many authors get stuck. They have written up their work and described, analyzed, and discussed their results. What more can be said without repeating everything in the summing up? This is the time for the author to sit back and think about how their work relates to the big picture.      The author should review their original stated purpose, the results, and discussions. Perhaps there is more that can be done to further the work. With these thoughts fresh on the mind, the conclusion can then be written such that it is not simply a “we did this, this, and that”, but rather a concise summing up, or review, followed by a brief discussion on how your findings relate to the big picture. A discussion of any recommendations for further work is also a fine addition, if relevant.

Acknowledgements & References Sometimes an Acknowledgement section is inserted just before the Reference section. This is especially important if funding has been received from a special source for the work and research that was performed. Co-workers who assisted in the work but were not involved in the final writing may also be listed here.      There are many categories of references or works cited, so use the style guide in [3] or [4] for details on how to list each type. It is essential to supply a comprehensive and relevant set of references. This is necessary because it gives credit to those who have done similar work and it indicates to the reviewers that you have done your homework. Papers that only reference the author’s previous work or a few recent papers attract the reviewer’s attention as being incomplete.      A word about authors and co-authors: the IEEE has a policy [5] concerning who should be included as co-authors on a paper; an extraction of this policy is quoted below:      “The IEEE affirms that authorship credit must be reserved for individuals who have met each of the following conditions:

• Made a significant intellectual contribution to the theoretical development, system or experimental design, prototype development, and/or the analysis and interpretation of data associated with the work contained in the manuscript,
• Contributed to drafting the article or reviewing and/or revising it for intellectual content, and
• Approved the final version of the manuscript, including references.”

     Anyone not meeting each of the three conditions should therefore be included in the Acknowledgement section.

III. And Finally … Proofread! Once the final draft of the paper is finished, do not forget to leave time for the review, both technical and grammatical. Incomplete sentences, redundant phrases, misspellings, and grammatical errors are unprofessional. Waiting a day or two before reviewing helps to provide a fresh approach, and more mistakes can be found. Another good way to catch errors is to give the paper to somebody else to read. The more people who review it, the more comments will be received, creating opportunities to improve the paper. If English is not your native language, it would help if one of the reviewers is a native English speaker, or have a trained technical editor proofread your paper. It may be that your heavily accented English is passable to a native English speaker, but can other non-native English speakers also understand? I heard a story about how one native English speaker had to act as an interpreter between two others speaking their own accented versions of the English language! It will increase your chances for success if the grammar is correct.      Writing an effective paper is time consuming, but is worth the effort when it is finally published and others can read and reference your work in their own research. Know and follow the criteria for the particular publication to which you are submitting, and make sure that all the components of a good technical paper are included in the next one you write.

IV. Acknowledgement I would like to thank Colin Brench, who has reviewed technical papers for many years for the IEEE International Symposium on EMC, for his input on what reviewers look for in Symposium and Transactions papers.

References [1] D. R. Caprette (updated Aug. 2010) Rice University class notes on Writing Research Papers. Available:       https://www.ruf.rice.edu/~bioslabs/tools/report/reportform.html [2] H. Schulzrinne (updated Oct. 2009) Columbia University class notes on Writing Technical Articles. Available:       https://www1.cs.columbia.edu/~hgs/etc/writing-style.html [3] IEEE sample paper template for IEEE Transactions, Preparation of Papers for IEEE TRANSACTIONS and JOURNALS (May 2007).      Available: https://www.ieee.org/publications_standards/publications/authors/authors_­journals.html#sect2      Click on: Updated-Template and Instructions on How to Create Your Paper (DOC, 92KB) [4] IEEE sample paper templates for IEEE conference proceedings, Sample IEEE Paper for US Letter Page Size , Version 3, original version      of this template was provided by courtesy of Causal Productions ( www.causalproductions.com ).      Available: https://www.emcs.org/technical-committees.html [5] IEEE Publication Services and Products Board Operations Manual, Piscataway, NJ: IEEE Publications, amended Feb. 2010,      Section 8.2.1.A. Available: https://www.ieee.org/portal/cms_docs_iportals/iportals/publications/PSPB/opsmanual.pdf

Professional Writing Services at an affordable price. Get assistance from our experts for best writing help.

Enhance user experience effortlessly!

Sign up today for FREE Website Accessibility Audit.

Section 1: Choosing Your Topic

Section 2: literature review, section 3: structuring your paper, section 4: peer review and feedback, section 5: editing and proofreading, section 6: references and citations, section 7: submission and publication, research papers made easy: a comprehensive writing guide.

• Read in 07 mins
• 26-Oct-2023

Writing a technical or research paper can be both a tricky and enjoyable experience. It's an essential skill for researchers, scientists, and academics, as it allows you to communicate your findings and contribute to the world of knowledge. However, the question that arises is: How to write a technical paper?

The method of writing a technical paper can be complicated if you don't have a specific structure and plan in place. We will guide you through the fundamental elements and tips to help you write an effective research paper in this step-by-step guide. Whether you are a skilled writer or just starting, having a well-defined structure is key to maintaining clarity and coherence in your technical or research paper.

The first step in technical paper writing is to choose a topic that is interesting as well as relevant to your field of study. Consider the current trends and advancements in your field, and identify a topic that you are passionate about and have a good understanding of. It's important to choose a topic that is neither too broad nor too narrow, as this will facilitate thorough research and analysis.

The Significance of a Well-Chosen Topic

The journey to writing a successful research paper begins with selecting a topic. This initial step is crucial as it shapes the entire research process. Two primary factors should influence your choice:

1. Your Interest

When you are genuinely interested in a topic, you are more likely to dedicate the time and effort needed to explore and analyze it thoroughly. Passion for your chosen topic is a driving force in research. It keeps you enlightened and committed throughout the writing process. Research is a long-haul commitment, so make sure you're passionate about the subject you're about to delve into.

2. Relevance and Significance

Select a topic that's relevant and significant. Your paper's impact largely depends on the relevance of the topic to your field of study or area of interest. By selecting a topic that aligns with your field of study or area of interest, you can contribute to the pre-existing body structure of knowledge and make a valuable contribution to your academic community.

3. Finding Your Research Question

Once you've identified your area of interest, you need to narrow it down to a specific research question. Your research question should be clear, concise, and researchable. It acts as the guiding star throughout your research journey.

A well-crafted research question will help you focus your efforts and ensure that you gather relevant data and information. It should be specific enough to provide meaningful results but broad enough to allow for exploration and analysis.

Bonus Read: Exploring the 11 Types of Technical Writing

The literature review serves multiple purposes, including providing a comprehensive understanding of the present condition of details in your field, identifying gaps or inconsistencies in previous research, and informing the development of your research question.

The Foundation of Your Research

A thorough literature review is required before carrying out your research. This step involves exploring existing work in your field, understanding the landscape of your chosen topic, and identifying gaps in knowledge. For example, let's say you are researching the effects of social media on mental health among teenagers.

In your literature review, start by examining existing studies and theories on both social media and mental health. You may find that there is a significant amount of research on the negative impacts of excessive social media usage, such as increased anxiety and depression among teenagers.

However, during your review, you noticed a gap in the literature regarding the possible positive effects of social media on mental health. This observation leads you to develop your research question: "What are the potential positive effects of using social media for promoting mental health among teenagers?"

From this example, a thorough literature review not only helps you understand what has already been studied but also identifies gaps in the existing research. This research question opens up new possibilities for exploring how social media can be utilized as a tool for promoting mental well-being among teenagers, potentially leading to innovative interventions and strategies in this area.

A well-organized structure is the backbone of a research paper. It helps convey your ideas clearly and logically. A typical structure comprises:

Introduction

• Research Question: Clearly state your research question.
• Objectives: Mention the objectives of your research.
• Significance: Explain the significance of your research topic.
• Structure: Outline the structure of your paper.

Literature Review

• Existing Work: Summarize and analyze relevant literature.
• Identified Gaps: Highlight the gaps that your research addresses.
• Framework: Provide a conceptual framework for your research.

Methodology

• Data Collection: Describe the methods used to gather data.
• Participants: Provide information on your study's participants (if applicable).
• Ethical Considerations: Explain ethical considerations.
• Data Analysis: Describe the methods used for data analysis.
• Data Presentation: Present your research findings using tables, graphs, or other visual aids.
• Statistical Analysis: If necessary, use statistical analysis to support your findings.
• Interpretation: Understanding the results in the context of your research question.
• Implications: Discuss the implications of your findings.
• Limitations: Acknowledge the limitations of your research.
• Future Research: Suggest areas for future research based on your findings.
• Summary: Summarize your main findings.
• Contributions: Emphasize the contributions your research makes.
• Final Thoughts: Conclude with your final thoughts on the research.

Simple and easy-to-understandable writing is necessary. Avoid complex, convoluted sentences that may confuse readers. Simplicity enhances comprehension. Make use of graphs, charts, and tables to present data effectively, enhancing reader engagement.

Seeking feedback from fellows, mentors, or professors is invaluable. Peer review ensures the quality of your paper and helps identify areas for improvement. During the research paper writing process, it is crucial to engage in peer review and seek feedback from peers, mentors, or professors.

This step is essential as it helps ensure the quality of your paper and allows you to identify areas that need improvement. Incorporating feedback from others not only enhances the overall quality of your writing but also helps you gain a fresh perspective on your work. By soliciting input from others, you can address any possible weaknesses or gaps in your argument, ensuring that your paper is comprehensive and well-rounded.

Editing and proofreading are the final touches that transform your research paper into a polished gem. It's essential to edit your paper for clarity, grammar, style, and formatting. During the editing process, you can also check for any inconsistencies or redundancies in your writing.

Additionally, proofreading allows you to catch any spelling or punctuation errors that may have been overlooked. By taking the time to edit and proofread your paper carefully, you demonstrate your commitment to producing a high-quality piece of work.

Some tools that can help with editing and proofreading a research paper include:

• Grammar and spell checkers, such as Grammarly or Hemingway Editor, can catch any errors in grammar, spelling, and punctuation.
• Style guides, such as the APA or the MLA style guides, can also be useful for ensuring consistency in formatting and citations.

This section is crucial as it allows readers to find and confirm the sources you have used in your paper. When writing a paper, it is important to avoid plagiarism by properly citing your sources in the references and citations section. It is essential to ensure this and follow the guidelines provided by the specific style guide you are using, like APA or MLA.

These style guides provide detailed instructions on how to format different types of sources, including books, journal articles, websites, and more.

• Suppose you are writing a research paper on climate change, and you want to include a statistic from a scientific study. In that case, you need to cite the source in your references and citations section properly.
• In the APA style guide, you would format the citation as follows: Smith, J. D., Johnson, A. B., & Thompson, C. (2019). The impact of climate change over global temperatures. Journal of Environmental Science, 45(2), 132-150. (Note: This is just an example, and the actual citation format may vary depending on the specific guidelines of the APA style guide).
• By including this citation in your paper, readers can locate the original study and verify the information you have included. It not only adds credibility to your paper but also gives proper credit to the authors of the study.

Once your paper is polished and ready, it's time to consider submission and publication. This step is the culmination of your hard work, where you share your findings with the academic community. Each journal or conference will have its submission guidelines that you must adhere to.

For example, suppose you are submitting a paper to a scientific journal. In that case, you may be required to include an abstract or keywords and follow specific formatting guidelines. These guidelines are crucial to ensure that your paper meets the standards and requirements of the publication.

This guide discussed various steps on how to write a technical paper or research paper. It is a journey of discovery where you not only contribute to the collective knowledge of your field but also enhance your own research and writing skills.

Remember, the journey starts with choosing a compelling topic that resonates with you. The literature review lays the foundation for your research, and rigorous data collection ensures the credibility of your work. Our technical writing services can provide valuable assistance in organizing and presenting your findings clearly and straightforwardly.

• proofreading
• content development
• copy editing

ABOUT THE AUTHOR

Mary has extensive experience of over 5 years in writing on a wide range of topics, including healthcare, technology, science, and business. She is highly knowledgeable and skilled in researching and crafting accurate, well-structured, and engaging content. Mary is a reliable and professional writer who is always willing to go the extra mile to ensure her clients are satisfied with her work. She is committed to delivering quality content on time and within budget.

• Previous eLearning Content Development - Future Trends 2024
• Next How to Conduct a WCAG Audit to Assess the Accessibility of a Webpage?

You Might Like

The Essential Guide to Writing Safety Data Sheets

Creating Safety Data Sheets (SDS) can help with this by providing details on the hazardous chemical products that may be encountered in the workplace.

• Read in 09 mins

How to Create Standard Operating Procedures (SOP) for Your Businesses ?

By implementing SOPs, businesses can streamline their operations and improve overall productivity.

How is Technical Writing Different from Writing an Essay

When we think of writing, we often connect it with articles, blogs or essays. But do you know there are many different styles and formats to consider while writing content?

Subscribe to our newsletter

Join our newsletter.

Stay in tune with Acadecrafts latest news and updates.

Clients Testimonials

Acadecraft's Voice-Over service was amazing! The team provided accurate and culturally relevant recordings for what we expected. They showed true professionalism and expertise. We highly recommend Acadecraft for their excellent Voiceover services.

• Manav Malhotra
• Sr. Manager – Operations

Always impressed with Acadecraft's expertise! Their translation services play a vital role for our company to drive international growth within our team and clients.

• Alex Capizola
• Business Operations Executive

AcadeCraft's assessment content creation team was able to understand our unique requirements and created customized assessments that fit our needs. The team was prompt and professional, and the quality of their work was good.

Acadecraft have recorded several audiobooks for us. They have a wide range of talented artists with different accents who really bring our stories to life. Their work is of high quality, with good attention to detail.

Acadecraft are reliable, efficient and friendly. Their services are highly recommended by us.

• Mazlini Kirsty Louise
• Editorial Head

As a producer, I've had the pleasure of using Acadecraft for sourcing VO and liaising with artists for several film projects. They offer a wide range of VO profiles and the artists I have collaborated with all were talented and professional. The team at Acadecraft have supported me with great professionalism, responsiveness and creativity. I highly recommend their services.

• Katia Hérault
• Head of Production

Acadecraft has been helpful with connecting our editorial team with subject matter experts (SMEs) who help us QA assessments and create solutions for computational assessments. They have been able to find SMEs to meet our needs and our deadlines. We are happy to continue to partner with Acadecraft.

• Managing Editor

Acadecraft team is always very supportive, and we and Acadecraft corroborate to create educational contents for K12 Students in India.

We appreciate Acadecraft teams' professionality, punctuality, creation skills in each subject.

• Mikiko Matsuoka
• Content Manager

I am thrilled to share my testimonial for Acadecraft which creates interactive and engaging content. Working with this team has been an absolute pleasure from start to finish. Not only did they create outstanding content for our project, but they also went above and beyond to ensure that it was interactive, engaging, and effective.

Throughout the entire process, the team was highly cooperative and communicative, always available to resolve any issues or concerns that arose. They truly made us feel like partners in the project, and their dedication to delivering high-quality content was evident in every interaction.

Thanks to their exceptional work, our project was a huge success, and we couldn't be happier with the results. I highly recommend them to anyone looking for a team that is passionate, professional, and committed to excellence. Wishing them all the best in their future endeavors.

• Hemika Kumar
• Ed-Tech Program Lead

The team at Acadecraft has truly been an end-to-end service provider for us, providing content development services and their commitment, attention to detail and expertise have made the project a success. Their team's dedication, attention to detail, and expertise have been unmatched, making our partnership an absolute pleasure. We highly recommend Acadecraft to anyone looking for a reliable and efficient education solutions provider.

• Yogesh Malhotra
• Senior Manager Team - Program Management

Our experience working with Acadecraft has been great. Their highly knowledgeable team of experts was always available to answer our questions, provide guidance, and ensure we were delighted with the services. Their thorough, accurate assessments provided valuable insights that helped us make informed decisions about our exam performances.

We look forward to continuing our partnership with Acadecraft and leveraging their expertise to help us achieve our business goals.

• Sohail Ahmed
• Senior Manager

I recently used Acadecraft's Video Editing services and I am extremely impressed with the quality of their work. The team at Acadecraft was highly professional, attentive and skilled in delivering my company’s project on time and within budget.

Their attention to detail was impeccable, and they understood my needs and requirements very well. They were able to create a video that not only met my expectations, but far exceeded them.

Throughout the process, they kept me informed and updated on the progress of the project, and were always available to answer any questions I had. Their customer service was excellent, and they were always friendly and easy to work with.

I highly recommend Acadecraft's Video Editing services to anyone who is looking for a high-quality and professional video editing experience. They are truly experts in their field and I look forward to working with them again in the future.

• Senior Executive

The video creation team of Acadecraft is insightful. They understood my requirements carefully and delivered a winning video that perfectly aligned with my business needs.

With a good script, content, sound, and editing – Acadecraft helped me with the best video content to strategize my marketing and promotional campaigns. Their tremendous experience in video editing and professionalism in serving the customer before and after delivering services are commendable.

The passionate team knows great about getting into the details and providing impeccable video services. I am extremely impressed by the work Acadecraft has delivered to me.

I appreciate my collaboration with Acadecraft and look forward to availing of services again.

• Ganesh Sonawane
• Founder & CEO

I required an explainer video for my business, and I am mesmerized by the work Acadecraft’s video editing team delivered to me. The perfectly aligned video elements and superb editing demonstrate the experience, knowledge, and professionalism Acadecraft has.

Acadecraft’s 3d video solutions are amazing. They used a perfect blend of art, color, shape, sound, and editing to create the video, making the video engaging and immersive.

I have always been excited to explore the opportunities of videos in business, and it was my pleasure to make Acadecraft my companion for the best video solutions. I highly recommend this organization and would love to collaborate with them again.

With a holistic approach to creating powerful blended videos, Acadecraft delivered me a well-developed video solution. I appreciate the relentless efforts of the video editing team, whose in-depth knowledge and analytical skills effectively catered to my needs.

The services Acadecraft has given me exceeded my expectations; the team was effective and listened to my requirements carefully, and went the extra mile in researching and creatively developing awesome pieces of video content.

Not only from a quality perspective but on the management and delivery front, Acadecraft’s services are prolific. They stuck to the turnaround time and were constantly in touch with me throughout the creation process.

I recommend Acadecraft for video solutions as they have great hands-on use of animation, graphics, and other creative assets.

• Shweta Patidar

I am thoroughly astounded by Acadecraft's proficient skills! Their exceptional voiceover and translation services were instrumental in amplifying our marketing endeavors and video promotions. They enabled us to communicate effectively with varied audiences and significantly propelled growth across numerous media platforms.

• Sparsh Verma
• Marketing Strategist

Working along with Acadecraft has been an exceptional journey. Their meticulous attention to detail and commitment to maintaining the essence of the content in the transition from English to Arabic was truly impressive. The collaborative spirit and timely communication made the entire process smooth and enjoyable. Without a doubt, I wholeheartedly endorse their services for a remarkable translation experience.

• Yashashwini V Rathod
• Account Director

Grab a FREE Accessibility Audit Today!

Expand your website reach.