Technical Writing. Details Of A 2-Day Course On Technical Writing: Fill & Download for Free

Read, read, read, read, read, read. Everyone else said this also because it's true. But not just anything, read various styles of writing, and create a basic taxonomy of styles of writing that you can refer to mentally, in a mindset that's more like concentrated practice than just breezy reading. Pay attention to structure, tone, form, use of (or wilful disregard for) grammar, and cadences, etc.Learn how to break down basic sentence structure. Know what a gerund phrase and subordinate clause are, or a sentence splice. You can ignore the "rules" but you need to know them.Clarification to #2 that's the most important: identify instinctively the subject, verb, and object of your sentences. Every sentence has 'em, at least subject and verb. This isn't a firm rule but there's an excellent chance that your sentence's perceived meaning hinges on them, no matter how complicated. That last sentence by the way was "there" "is" and "chance" mind you, not the thing that looks like a sentence and follows the word "that." Now that you know what they are exploit them. Chances are there's a better verb than variations on "to be" like "is" "was" "has been" to be had, for one example.Write. But don't just write whatever comes to mind (though you should do that too): write to form. Now that you're being observant of how certain styles are structured and their conventions you can try for yourself. Attempt to mimic the way certain kinds of prose are written.Here are a few examples of the same thing in various styles picked at random:"Triangle" - straight news format aka New York Times or AP styleWilson Phillips, an internet user from Skokie, Illinois, visited the popular online site Quora today in an attempt to learn how to write. In a visit Mr. Phillips described as "disturbing," site contributors were alleged to have committed several acts of hostility, including accusations he was an disgruntled former employee of Myspace, a claim Mr. Phillips denies."Time Magazine" - famous backwards construction used in featuresThe clicks on the keyboard started out even, but soon picked up in speed. As comments were added, tempers flared. A voice rang out. "They should be so lucky as to work for Rupert!" it said, as minutes became hours. Broad daylight gave way to a dim monitor glow, and a grim realization took hold. It was almost midnight, and Wilson's secret was out."Gawker" - ie snarky news/blog styleIt looks like Wilson won't be getting off this island any time soon. Sources tell us the ex social-ite had a run in with the valley mafia late last night on Quora, which is quickly turning from a minor Mike Arrington masturbatory obsession into a digital mob."Gonzo" - Hunter S. Thompson, the masterThey're a vile bunch, mean on a good day and as vicious as a badger when cornered. And to them Wilson was prey. A life and reputation torn into meat and bone, the bastard never had a chance. Of course for predators that's the price of a meal, and he wasn't even the first that day.Heh. The details matter. Ask most people to write the first sentence of a story about a run of the mill news event like a house fire and they'll probably do something like "A house on Main Street burned down today" when in real life those stories usually come at the news sideways. For example: "Broken windows and car alarms were among the unpleasant sights this morning at the site of a residential blaze that claimed three downtown homes".And so on... ya get the point. And that's just journalism; do the same with modern fiction, magical realism, classic literature, your favorite writers, etc. Once you can separate style from subject you have a set of tools that can evoke a mood. Like a musician practices ear training to identify pitch or major from minor keys you should know the mechanics that underpin a certain feel or tone, and use them, even when you forget you're using any style and just have your own voice.$0.02

14 Indispensable Books to Learn Technical WritingClassic and general books on how to write well and plainly (like “The Elements of Style” by Strunk and White, or “How to Write Well” by William Zinsser) are of course great. You should read them by all means to learn the A-B-Cs of good communication in English.However, when it comes to writing a technical document like a user guide or an installation manual, those books would not help you at all.Specific style guides (“Microsoft Manual of Style”) and books formatted like a dictionary (“Handbook of Technical Writing” by Alred et al.) with an entry for each important concept would help a little but since they present information in a fragmented manner, or they address the kind of formatting rules that may not apply to your project at all, again, they are not probably what you need. You cannot read these books (which were not designed and written to be read at one sitting anyways) and then sit down and write a great user manual, for example.You need to read books that approach the specific topic of writing technical documents with lots of detailed examples, including information about putting together the individual components of a document and some techniques specific to procedural writing.That’s why I’d recommend the following additional books that I’ve kept for years on my book shelf and consulted frequently:(1) “Why Not Say It Clearly” by Lester S. King, M.D. Even though out of print, try to get a copy of this book by all means. The author is a medical writer, a specialty within the general topic of technical writing, and as his last name suggests, he is truly a King of technical editing! Even though slim as a volume, after finishing this book and thinking about the examples he provides, you’ll be a much better writer for sure.(2) “How to Write a Manual” by Elizabeth Slatkin. How to plan, design, write and review a manual, and how to produce it. It even includes a section on page layout techniques (and you’d be amazed the amount of page layout you’ll be doing as a technical writer).(3) “The Elements of International English Style” by Edmond H. Weiss. Why this book? Because more and more, technical writing is writing for an international audience. Most tech documents are translated (“localized”) to different languages. Knowing how write for an international audience is a must these days for all tech writers. This is a good source to learn that.(4) “Letting Go of the Words” by Janice (Ginny) Redish. The best source to learn, with hundreds of examples, on how to write for the web. This breaks through the assumption that a technical document is a printed “book.” No, it’s not. There are as many tech documents these days on the Internet as they are in printed form. And the web has its own rules and requirements. Read this milestone book if you ever want to write on the web as a technical writer.(5) “Agile Documentation” by Andreas Ruping. This is a rather advanced level book for those tech writers working in a Agile (software production) environment. Even though the field is advancing and changing too rapidly to be captured properly by a book published back in 2003, it still gives you a great birds-eye view of the whole topic. Great introduction to a very technical (and well paying) sub-niche in technical documentation.(6) “Technical Writing for Engineers and Scientists” by Barry J. Rosenberg. A bolts-and-nuts guide to how to write a great manual including chapters on audience, documentation plans (which you won’t find in too many other books), how to write sentences, paragraphs, lists, lab reports, PPT presentations, and much more.(7) “How to Write Usable User Documentation” by Edmond H. Weiss. This is an old book that is obsolete in its coverage of many subjects like page and book formatting. However some of the sections like how to create a decision graphics, or how to write a chapter or section headline are still superb. It’s approach to how to write and organize “modules” of a technical document is equally priceless. You’ll discard half of this book since modern technology made that section totally irrelevant. But the other half you’ll keep and continue to benefit from.(8) “Technical Communication” by Mike Markel. This the all-time best seller classic book on technical writing for a very good reason — it’s as good as it’s cracked up to be! It’s somewhat expensive — that’s one of its drawbacks. But if you can find a used copy, even of earlier prints, get one. Jam-packed with great how-to-do examples of every conceivable technical writing topic, this is one volume that I enjoyed consulting over the years. It’s a must for your tech writing library.(9) “Editing Technical Writing” by Donald C. Samson, Jr. Writing is one thing, editing is another. Every good tech writer is not a good tech editor, trust me. This is one of those rare and precious books that go into the details of technical editing (text and images) with examples. Some of those examples are dated but the main principles they illustrate are still valid and good. There is an answer key for the exercise questions and even a section on how much to charge for your writing (also outdated of course).(10) “Making Money in Technical Writing” by Peter Kent is one of those rare books devoted to the business of freelance technical writing. There are golden tips and techniques int his book about how to set up your freelance tech writing business, how to market your services, how much to charge (outdated into), and how much you can expect to make (also outdated). How to pay taxes, whether to incorporate yourself, how to negotiate with agencies… are some of the many interesting topics that you can read and benefit from. It’s almost a source without an alternative even though some of the information is outdated.(11) “Creating Technical Manual” by Gerald Cohen. As the subtitle says it all: “A step-by-step approach to writing user-friendly instructions.” It’s good to remember from time to time that all tech writing is about writing instructions. This book’s no nonsense approach provides road maps and detailed example sheets of accomplishing that goal. This is one of my main sources for writing clear step-by-step procedural descriptions even though some of the graphic examples provided are outdated (as most everything becomes quickly in this crazy age of non-stop of progress and innovation).(12) “Technical Writing - Process and Product” by Sharon J. Gerson and Steven M. Gerson. This is a book in the same category as Mike Markel’s classic reference book. It’s well designed, well written, and covers a lot of ground by focusing on individual tech doc products like resumes, fliers, brochures, newsletters, reports, proposals, and even oral presentations. The volume is capped with a good section on grammar, spelling and punctuation.(13) “Writing and Speaking for Technical Professionals” by Martin S. Roden and Teresa E. Murphy. This is an excellent book that teaches how to communicate, and not necessarily how to write any specific technical documents. Its unique angle is, it’s written specifically for engineers and scientists who find it difficult to express their ideas in a coherent manner. The authors get down to the craft of actually writing a technical document only after page 200. But the valuable communication ideas and drills that come before then is especially useful for all academicians and especially engineering students.(14) “Technical Writing 101” by Alan S. Pringle and Sarah S. O’Keefe. Written by two well-known technical writers, this is another book that you must have on your book shelf. It’s a “real-world guide to planning and writing technical documentation” as the subtitle claims and it lives up to that promise. The second edition includes sections on XML and structural authoring (the cutting edge of tech writing) as well.And last but not the least, if you’re looking for a comprehensive online introduction to the craft of document design, technical writing and editing, I’d like to suggest my own best-seller course: https://www.udemy.com/technical-writing-and-editing/Wish you good luck!

I published 12 journal papers in good journals (10 or so as first author), a 100-page book chapter, a dissertation, and numerous conference papers during my 4-year PhD, here’s how I did it:Collaboration. Every PhD student should find some way to work with others and provide value to their work. I had a very good senior PhD student (2–3 years ahead of me) that mentored me, helping to show me the ropes, and in time I provided a valuable contribution to their work, earning me a co-authored journal paper. Likewise, I helped mentor the next PhD student, showing them the ropes, envisioning a research idea, project, and methodology, and helping with analysis - this led to a first author journal paper and some future co-authored papers. This is within a group where we had a minority element - there weren’t a whole lot of people that were on this research thread, but I made the most of it. That can be good for a few papers (in my instance) or many more if you have a large research group. It’s very important to publish first author papers too, though!Methodology. I had a combination of using previously developed methods, but also adding unique elements and methods myself. In this manner, down the road when papers were submitted, it wasn't turned away for lack of creativity or just applying what everyone is doing - these papers have a much more difficult burden of needing to find something new. In some ways, by envisioning new methods and ways of analyzing results, in many cases I already knew that what was at the end of the study was going to be novel in some way.Short letters and long papers. I used a combination of short and long journal papers. I evaluated whether the results of the study could be described in a short article and took advantage of that. My first short letter took me less than a day to write. I only had to have 3–4 figures. There was a lot of work behind that, but I didn’t have to describe everything to get across the point that I was trying to make with this article. And, the review process is much, much faster! This paper was in print in a few months - wow! Now, I often wrote much more detailed papers as well. In these, I could describe the methodology in detail, I could show multiple figures and tables, I could expand upon the discussion. I learned to use both, because they both play a role in communicating research.Different research areas. I used three different research areas and communities. I would publish a paper in one area and switch to another area. I had ideas for how to move ahead creative studies in each of these areas, and I had a plan for how I was going to do that. I didn’t start out thinking this way; it just happened. However, in my experience, you will find some resistance if you try to publish too many papers in the same confined research thread.Battle rhythm. I invested my first two years in learning almost everything that I would need, so that when it came time, I could sprint to the finish. I read the papers. I mapped out the ideas in my head. I knew where other groups were going, and where they weren’t going. I wrote the codes to execute the different research areas. I figured out how to visualize my data, how others write papers, how to present, etc. When it came time, I was executing a study, processing results, writing it up, and submitting to the review process. But, I wasn’t doing this in serial, I had this going in parallel. While I was writing paper #1, I was running study #2 - once I submitted paper #1, I was analyzing and writing up study #2, and running study #3. Once paper #1 came back with review comments, I addressed those ASAP to keep the train rolling. I got in a rhythm, so to speak.Review process. I learned how to get through the review process. Initially, I took some things personally and didn’t give ground. However, over time, I learned that there is usually a compromise or a way to address reviewer comments without giving up the points that you are trying to make. I almost never take things personally now. If they are confused, I don’t look at them as if “they must not be an expert in my field” or “they just don’t get it,” I say to myself, “this is a smart person on the other end, how can I clarify things so that they understand as well.” When you start to think about the reviewer as someone that’s trying to help you, even if it is through harsh criticism, you produce a much better product.Conference papers, then journal papers. I started honing my skills on conference papers in years 2 and 3, then moved on to journal papers. Lots of practice and feedback from your advisor is helpful.Figures. I took a lot of time to learn how to polish the figures. I thought about creative ways to show data. If you are spending time showing data in the same way as everyone else, sometimes that’s boring. I really like reviewing those papers where the authors have taken the time to look at their results in new ways. What is that for your field?Connectivity of papers. I had a way of connecting things together, but adding unique thoughts/ideas/findings/elements to each. So often, the reviewers may look at prior work and if there is none, then they are more critical because this may be the first study of its kind. I used parts of prior studies—methodologies, for instance— that were already reviewed, as a connecting piece. Then I would identify those parts that are new and unique. In that way, you are building on your other studies.Technical writing. I can’t impress enough how important technical writing is. I am an excellent writer, but I wasn’t that way from day 1 of PhD. Actually, when I couldn’t take some required course for PhD students, I took the “Technical Communications” class in lieu, which was mainly for foreign nationals. It was great! I learned a lot. I am a very logical person, and I learned tricks, format, etc., that helped me write in a very structured way. Essentially, to eliminate the need for thinking too hard about the writing. For instance, abstract—one sentence about background, one sentence about research/study objective, one sentence about methods used, a sentence or two about an important finding, a sentence about the significance of that finding. I’ve never thought about how to write an abstract again, I have a quick formula.Know your reviewers, know your journals. Can’t emphasize this enough. When they ask who can review your work, think of people that are in a similar research area that would appreciate this work. You find these people at conferences, in the literature, etc. Even if they reject it, you are starting to be on their radar. Their critical comments are fuel for that paper and perhaps a future paper. If you try to choose the “easy” reviewer, you may get it published, but the feedback doesn’t help you become a better researcher or improve your research. Same thing goes with journals - aim high, get feedback, use that feedback to improve.Don’t give up. I submitted my first paper to Physical Review B, a premier physics journal. I received major revisions with multiple pages of critical comments. I took it personally. I thought the work must not have been good enough. I never submitted that work again. Looking back, that was excellent work and I could have addressed the comments fairly easily, but I didn’t know that at the time. I could have had an excellent paper in a premier journal by addressing reviewer comments (from an excellent faculty—I have an inkling of who that is now), but I took the comments personally rather than as them trying to point me in the right direction to improve the work. Still kicking myself for that. Don’t give up!Luck? I obviously was fortunate to pick an area and advisor where the research project and studies aren’t ruled by the “let’s keep throwing out hypothesis, and test, and if we find something, let’s publish” mantra. I chose areas where I could design a study, execute that study, and I knew that the community could learn something new based on the results—good or bad. Not all areas are the same. I turned down another excellent advisor at a different university because the project sounded like “we do this, then look at what happens on the nanoscale, and if we find something, then it will be groundbreaking.” My question, “but what if you don’t?” “Well, then we do it again, over the years you find ways to increase the likelihood that you find something.” Hmm… sounds like luck to me. I steered away from that one.Best of luck everyone!