Entrepreneurs: Writing a technical paper is not that difficult of a proposition.
At some point in time, many entrepreneurs may have to write a technical paper or technical report. It sounds like an arduous task, but it need not be so. A little preparation work up front can save many headaches later down the line. I strongly recommend that as a starting point, one read the book "Elements of Style" by William Strunk and White. This is a very good publication outlining many of the important items that writers (of all types) need to focus on. Here are a few recommendations for consideration (it is a long read!):
Research Publications:
A professional research publication has a clear statement of the problem the publication is addressing, the proposed solution(s), and the results achieved (or to be achieved). An executive summary, or the like, should go right up front. The executive summary describes clearly what has been done before regarding the problem, what is new, or, key/salient points the publication makes.
The goal of many technical publications is to describe novel technical results. As such, there are four basic types of technical results:
- An algorithm: Please be sure to double-check all algorithms and mathematical formulas! Normally, a formula will be by its own, centered on a page or below a paragraph. Placing it in a paragraph tends to hide it from clear view, a key message might be lost this way.
- A system construct: such as hardware design, software system, protocol, etc.; One goal of the publication is to ensure that the next person, who designs a system like yours, doesn't make the same mistakes, and takes advantage of some of your best solutions. Here, the writer needs to make sure that the hard problems (and their solutions) are discussed and that the non-obvious mistakes (and how to avoid them) are also well presented.
- A performance evaluation: obtained through analysis, simulations or measurements; and,
- A theory: consisting of a collection of theorems.
A technical publication should focus on:
1.) Describing the results in sufficient details to establish their validity;
2.) Identifying the novel aspects of the results, i.e., what new knowledge is reported and what makes this new knowledge non-obvious; and,
3.) Identifying the significance of the results: what improvements and impact(s) do the results suggest.
Publication Structure:
The typical length of a (technical) publication is between 250 and 350 pages, or so - but a publication can be shorter, or longer:
- Abstract (for use in advertising the publication or for placement into professional journals): Typically not more than 100-150 words; abstracts are generally very short.
- Executive Summary: Briefly outline the most important points of the publication � what is the minimum amount of knowledge the reader should walk away with. One page, if possible.
- Introduction (this needs to be brief!): Introduce the problem, outline the solution; the statement of the problem should include a clear statement why the problem is important (or interesting). At most, 2-3 pages.
- Main Index Page: Chapter 1 - xxxxx; Chapter 2 - yyyyy; Chapter 3 - zzzzz; etc.
- Problems or technical challenges should be discussed early;
- Approach, architecture, etc, can go in the middle; and,
- Results
Each chapter should contain sufficient motivation, with at least one example scenario, preferably two, with illustrating figures, followed by a crisp generic problem statement model, i.e., functionality, particularly emphasizing the "new" functionality. General evaluations of algorithm or architecture, e.g., material proving that the algorithm is O(log N), should be discussed in earlier chapters, not in the evaluation section.
- Realization: contains actual implementation details when implementing architecture isn't totally straightforward. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent.
- Evaluation (towards the end of the publication): How does the innovation really work in practice? Provide real or simulated performance metrics, end-user studies, mention external technology adaptors, if any, etc.
The last chapter or the last main section in the publication:
- Related work, if not discussed at the beginning
- Summary and Future Work; this is often repeated from the main result
- Acknowledgements
- Bibliography
- Appendix (to be cut first if forced to due to length considerations):
- Detailed protocol descriptions
- Proofs with more than two lines
- Other low-level but important details
It is recommended that a writer write the "approach" and "results" sections first, which go together. Then the "problem" section, if it is separate from the introduction. Then write the conclusions; and finally, write the "introduction" section last. Most writers in fact write the introduction section once they are finished with the other sections, since an introduction section closely mirrors the conclusions in one of the last paragraphs. Finally, write the abstract. Last, give your paper a title.
Title:
Abbreviations in titles: Please avoid all but the most readily understood abbreviations.
Please avoid common phrases like "novel", "performance evaluation" and "architecture", since almost every paper does a performance evaluation of some architecture and it better be novel. Unless somebody wants to see 10,000 Google results, nobody searches for these types of words.
Use adjectives that describe the distinctive features of your work; e.g., reliable, scalable, high-performance, robust, low-complexity, or low-cost. (There are obviously exceptions, e.g., when the performance evaluation is the core of the publication. Even in that case, something more specific is preferable, as in "Delay measurements of X" or "The quality of service for FedEx deliveries".)
When presenting simulation results, provide insight into the statistical confidence of your data collection techniques. If there's a "strange" behavior in the graph (e.g., a dip, peak or change in slope), this behavior either needs to be explained, or reasons must be given why this is simply due to statistical aberration. In the latter case, gathering more samples is probably advised.
Figures should be chosen wisely. You can never lay out the whole parameter space, so provide insight into which parameters are significant over what range, and which ones are less important. It's not very entertaining to present lots of flat or linear lines.
The description of the graph should not just repeat the graphically obvious such as "the delay rises with the load", but explain, for example, how this increase relates to the load increase. Is it linear? Does it follow some well-known other system behaviors such as standard queuing systems?
Things to Avoid:
- Too much motivational material; three reasons are enough -- and they should be described very briefly.
- Describing the obvious parts of the result - "Obvious" is defined as any result that a program/project participant would suggest as a solution if one poses the problem that the result solves.
- Describing unnecessary details - A detail is unnecessary, if its omission will not harm the reader's ability to understand the important novel aspects of the result.
- Spelling errors - With the availability of spell checkers, there is no reason to have spelling errors in a manuscript. If you as the author didn't take the time to spell-check your paper, why should the editor or reviewer take the time to read it or trust that your diligence in technical matters is any higher than your diligence in presentation? Note, however, that spell checkers don't catch all common errors, in particular word duplication ("the the"). If in doubt, consult a dictionary such as the (on line) Merriam Webster.
- Text in Arial - Arial and other sans-serif fonts are fine for slides and posters, but they are harder to read in continuous text. Use Times Roman or similar serif fonts for published/printed works. Unusual fonts are less likely to be available at the recipient and may cause printing or display problems.
- Write like a newspaper reporter, not a college student. The end objective is clear communication to the reader, not beauty, eruditeness or eloquent narration of a writer's discoveries and reasoning process. Don't waste the reader's time, or at least don't waste it up front.
- Hit the important conclusions in the first few sentences so the reader will read them. If you'd like to wrap up with the conclusions at the end of a chapter, I think that that's fine too, in case anybody's still reading by then; but conclusions come first.
If you're trying to express something complex, simplify your writing so it doesn't get in the way. - - - For something simple, 10th grade language structures will do, but if it's really hairy stuff, back down to 8th grade or so. It need be recalled that the average American reads and understands at the 6th-7th grade level. If your audience is more comfortable discussing technical issues, then a more complex writing style is appropriate.
- Think about what your audience knows and doesn't know, and what they want to known and don't want to know. Expressing things in terms of what they know and want, not what you know, is a good approach.
Top down design:
- Starting with an outline and working out the details is the normal way of tackling an engineering problem.
- Checking your facts: Engineers and technical specialists should be used to checking anything that is even remotely doubtful before committing to it. So should writers.
- Failure mode analysis: For each sentence ask yourself, could it be misread? How? What is the best way to fix it?
- Dependency analysis: Are the ideas presented in an order that assures that each point can be understood on the basis of the readers assumed knowledge and the information provided by preceding points?
- Optimization: Are there any unnecessary parts? Does the structure require the reader to remember too many details at once, before linking them?
- Structured testing: If you read what you have written, assuming only the knowledge that the reader can be expected to have, does each part work the way you intended? If you read it aloud, does it sound the way you intended?
I also recommend that you give your semi-finished manuscript draft to a few other, trusted individuals, to read. If you can, please find two people:
- one person familiar with the technical matter; and,
- another only generally familiar with the subject matter.
You can easily select more than two people. These people will give you good tips and ideas that will really help. A "buddy check" is a good idea to consider, especially when writing. Go for it - write away!
Research Publications:
A professional research publication has a clear statement of the problem the publication is addressing, the proposed solution(s), and the results achieved (or to be achieved). An executive summary, or the like, should go right up front. The executive summary describes clearly what has been done before regarding the problem, what is new, or, key/salient points the publication makes.
The goal of many technical publications is to describe novel technical results. As such, there are four basic types of technical results:
- An algorithm: Please be sure to double-check all algorithms and mathematical formulas! Normally, a formula will be by its own, centered on a page or below a paragraph. Placing it in a paragraph tends to hide it from clear view, a key message might be lost this way.
- A system construct: such as hardware design, software system, protocol, etc.; One goal of the publication is to ensure that the next person, who designs a system like yours, doesn't make the same mistakes, and takes advantage of some of your best solutions. Here, the writer needs to make sure that the hard problems (and their solutions) are discussed and that the non-obvious mistakes (and how to avoid them) are also well presented.
- A performance evaluation: obtained through analysis, simulations or measurements; and,
- A theory: consisting of a collection of theorems.
A technical publication should focus on:
1.) Describing the results in sufficient details to establish their validity;
2.) Identifying the novel aspects of the results, i.e., what new knowledge is reported and what makes this new knowledge non-obvious; and,
3.) Identifying the significance of the results: what improvements and impact(s) do the results suggest.
Publication Structure:
The typical length of a (technical) publication is between 250 and 350 pages, or so - but a publication can be shorter, or longer:
- Abstract (for use in advertising the publication or for placement into professional journals): Typically not more than 100-150 words; abstracts are generally very short.
- Executive Summary: Briefly outline the most important points of the publication � what is the minimum amount of knowledge the reader should walk away with. One page, if possible.
- Introduction (this needs to be brief!): Introduce the problem, outline the solution; the statement of the problem should include a clear statement why the problem is important (or interesting). At most, 2-3 pages.
- Main Index Page: Chapter 1 - xxxxx; Chapter 2 - yyyyy; Chapter 3 - zzzzz; etc.
- Problems or technical challenges should be discussed early;
- Approach, architecture, etc, can go in the middle; and,
- Results
Each chapter should contain sufficient motivation, with at least one example scenario, preferably two, with illustrating figures, followed by a crisp generic problem statement model, i.e., functionality, particularly emphasizing the "new" functionality. General evaluations of algorithm or architecture, e.g., material proving that the algorithm is O(log N), should be discussed in earlier chapters, not in the evaluation section.
- Realization: contains actual implementation details when implementing architecture isn't totally straightforward. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent.
- Evaluation (towards the end of the publication): How does the innovation really work in practice? Provide real or simulated performance metrics, end-user studies, mention external technology adaptors, if any, etc.
The last chapter or the last main section in the publication:
- Related work, if not discussed at the beginning
- Summary and Future Work; this is often repeated from the main result
- Acknowledgements
- Bibliography
- Appendix (to be cut first if forced to due to length considerations):
- Detailed protocol descriptions
- Proofs with more than two lines
- Other low-level but important details
It is recommended that a writer write the "approach" and "results" sections first, which go together. Then the "problem" section, if it is separate from the introduction. Then write the conclusions; and finally, write the "introduction" section last. Most writers in fact write the introduction section once they are finished with the other sections, since an introduction section closely mirrors the conclusions in one of the last paragraphs. Finally, write the abstract. Last, give your paper a title.
Title:
Abbreviations in titles: Please avoid all but the most readily understood abbreviations.
Please avoid common phrases like "novel", "performance evaluation" and "architecture", since almost every paper does a performance evaluation of some architecture and it better be novel. Unless somebody wants to see 10,000 Google results, nobody searches for these types of words.
Use adjectives that describe the distinctive features of your work; e.g., reliable, scalable, high-performance, robust, low-complexity, or low-cost. (There are obviously exceptions, e.g., when the performance evaluation is the core of the publication. Even in that case, something more specific is preferable, as in "Delay measurements of X" or "The quality of service for FedEx deliveries".)
When presenting simulation results, provide insight into the statistical confidence of your data collection techniques. If there's a "strange" behavior in the graph (e.g., a dip, peak or change in slope), this behavior either needs to be explained, or reasons must be given why this is simply due to statistical aberration. In the latter case, gathering more samples is probably advised.
Figures should be chosen wisely. You can never lay out the whole parameter space, so provide insight into which parameters are significant over what range, and which ones are less important. It's not very entertaining to present lots of flat or linear lines.
The description of the graph should not just repeat the graphically obvious such as "the delay rises with the load", but explain, for example, how this increase relates to the load increase. Is it linear? Does it follow some well-known other system behaviors such as standard queuing systems?
Things to Avoid:
- Too much motivational material; three reasons are enough -- and they should be described very briefly.
- Describing the obvious parts of the result - "Obvious" is defined as any result that a program/project participant would suggest as a solution if one poses the problem that the result solves.
- Describing unnecessary details - A detail is unnecessary, if its omission will not harm the reader's ability to understand the important novel aspects of the result.
- Spelling errors - With the availability of spell checkers, there is no reason to have spelling errors in a manuscript. If you as the author didn't take the time to spell-check your paper, why should the editor or reviewer take the time to read it or trust that your diligence in technical matters is any higher than your diligence in presentation? Note, however, that spell checkers don't catch all common errors, in particular word duplication ("the the"). If in doubt, consult a dictionary such as the (on line) Merriam Webster.
- Text in Arial - Arial and other sans-serif fonts are fine for slides and posters, but they are harder to read in continuous text. Use Times Roman or similar serif fonts for published/printed works. Unusual fonts are less likely to be available at the recipient and may cause printing or display problems.
- Write like a newspaper reporter, not a college student. The end objective is clear communication to the reader, not beauty, eruditeness or eloquent narration of a writer's discoveries and reasoning process. Don't waste the reader's time, or at least don't waste it up front.
- Hit the important conclusions in the first few sentences so the reader will read them. If you'd like to wrap up with the conclusions at the end of a chapter, I think that that's fine too, in case anybody's still reading by then; but conclusions come first.
If you're trying to express something complex, simplify your writing so it doesn't get in the way. - - - For something simple, 10th grade language structures will do, but if it's really hairy stuff, back down to 8th grade or so. It need be recalled that the average American reads and understands at the 6th-7th grade level. If your audience is more comfortable discussing technical issues, then a more complex writing style is appropriate.
- Think about what your audience knows and doesn't know, and what they want to known and don't want to know. Expressing things in terms of what they know and want, not what you know, is a good approach.
Top down design:
- Starting with an outline and working out the details is the normal way of tackling an engineering problem.
- Checking your facts: Engineers and technical specialists should be used to checking anything that is even remotely doubtful before committing to it. So should writers.
- Failure mode analysis: For each sentence ask yourself, could it be misread? How? What is the best way to fix it?
- Dependency analysis: Are the ideas presented in an order that assures that each point can be understood on the basis of the readers assumed knowledge and the information provided by preceding points?
- Optimization: Are there any unnecessary parts? Does the structure require the reader to remember too many details at once, before linking them?
- Structured testing: If you read what you have written, assuming only the knowledge that the reader can be expected to have, does each part work the way you intended? If you read it aloud, does it sound the way you intended?
I also recommend that you give your semi-finished manuscript draft to a few other, trusted individuals, to read. If you can, please find two people:
- one person familiar with the technical matter; and,
- another only generally familiar with the subject matter.
You can easily select more than two people. These people will give you good tips and ideas that will really help. A "buddy check" is a good idea to consider, especially when writing. Go for it - write away!
About
Events
CONTACT VICTORY
Newsletter & Updates:
email me directly: Victory -at- BigLife -dot- ws
MY WEBSITES:
Learn how to bootstrap:
UniversityOfVictory.com
Social Entrepreneurship 2.0:
WorldVisionEntrepreneurs.org
Marketing using Linkedin:
LinkedinBuilder.org
Design your ultimate life:
Find Your Life Coach
Marketing help for coaches
Life Coach Marketing & Promotion
Controversial new movie: sequel to The Secret (sequel)!
**All clients have my toll free number to get their questions answered quickly!
Live Webcam Chat with Members NOW!
WEBCAM CHAT WITH MEMBERS ONLINE NOW
you can still watch other people on their cams, and do text chat.
[ LOGIN NOW ]
Don't have a webcam? My friend is giving away 777 of them at www.BIGLIFE.ws
you can still watch other people on their cams, and do text chat.
[ LOGIN NOW ]
Don't have a webcam? My friend is giving away 777 of them at www.BIGLIFE.ws
Start YOUR OWN web 2.0 Ning site
Would you like to start your own Ning site just like this one?
It's free and easy and can even be used to run a small web business
(see www.LinkedinBuilder.org as an example).
If you know the value of strong SEO, you will be amazed at the GOOGLE PAGE-1 results we have accomplished with this site.
Anything you can do on a static html website can be done here, plus much more!
Do you already know the power of testimonials for marketing? ...my custom Ning sites will take that to a new level.
If you want to employ sticky widgets and member generated content, my custom Ning sites are on the leading edge of Web 2.0 and viral marketing.
get more information here!
~V.
It's free and easy and can even be used to run a small web business
(see www.LinkedinBuilder.org as an example).
If you know the value of strong SEO, you will be amazed at the GOOGLE PAGE-1 results we have accomplished with this site.
Anything you can do on a static html website can be done here, plus much more!
Do you already know the power of testimonials for marketing? ...my custom Ning sites will take that to a new level.
If you want to employ sticky widgets and member generated content, my custom Ning sites are on the leading edge of Web 2.0 and viral marketing.
get more information here!
~V.
Become an INSTANT Authority!
BECOME AN INSTANT EXPERT, AUTHORITY, GURU or MAVEN
Success Coaches, business and marketing consultants, speakers, authors, online educators, teleseminar and webinar hosts, mc's, entrepreneurs can make 3x to 10x their current income simply by having an industry recognized name.
Complete service for personal branding and name/face/logo/slogan/usp recognition/exposure including professional online/offline press release, social network profiles and automated lead generation system for Linkedin, Facebook, Ning, Xing, Ryze, Myspace etc.
Did you know that the experts featured in THE SECRET all paid to be there? (PAID, not "were paid")
They each paid $25,000 - $50,000! Was it worth it? One now well known speaker used to earn $2k a gig, now earns $20,000 per engagement! Many others experienced 5x to 10x earnings increase! We can provide many case studies if you find this hard to believe. Our services range from FREE to $7,000.
Check out the group "Promotion & Marketing for Success Coaches" for more info.
Victory Darwin and Associates
Success Coaches, business and marketing consultants, speakers, authors, online educators, teleseminar and webinar hosts, mc's, entrepreneurs can make 3x to 10x their current income simply by having an industry recognized name.
Complete service for personal branding and name/face/logo/slogan/usp recognition/exposure including professional online/offline press release, social network profiles and automated lead generation system for Linkedin, Facebook, Ning, Xing, Ryze, Myspace etc.
Did you know that the experts featured in THE SECRET all paid to be there? (PAID, not "were paid")
They each paid $25,000 - $50,000! Was it worth it? One now well known speaker used to earn $2k a gig, now earns $20,000 per engagement! Many others experienced 5x to 10x earnings increase! We can provide many case studies if you find this hard to believe. Our services range from FREE to $7,000.
Check out the group "Promotion & Marketing for Success Coaches" for more info.
Victory Darwin and Associates
© 2010 Created by Linkedin-Entrepreneurs.com Victory Darwin on Ning. Create a Ning Network!
