Technical Writing and Documentation Service Provider in Singapore


    The Journal of My Technical Writing Career

    As a child, I dreamed of Pilot, as a young boy I dreamed of Doctor, but there are dreams that cannot be and storms we cannot weather. 

    I am now a Writer in the business of informing and persuading. I love to research and convey complex information in a simple, understandable, and user-friendly formats to capture the interest of readers. And as a writer, I am the bridge between engineers and end users to communicate the operation of a product in an elegant style, by arousing the reader's curiosity.


    Technical Writer
    In the process of attaining my dreams, I discovered something more precious - God of this universe through the Bible. It's an exciting adventure which I will share in future.

    During school days, my goal was to rank top in the class. I performed well in my studies and ranked among the top 10 students. On rare occasions, my rank slipped below my expectations, but I always bounced back. Life’s biggest goals were finishing exams, scoring well and traveling to my hometown - Kottayam, an adventurous journey by train for three days and two nights, passing through the hills, mountains, rivers, fields and tunnels. 

    After tenth, like every student in the science stream, my goal was to be a Doctor or an Engineer. I let go of all extracurricular activities and focused only on studies. In XII, most of us had private tuitions on top of what school teachers were already providing. But things didn't work out as per my plans. I did not qualify for Engineering or Medicine in the Gujarat board. Based on the merit system, I could pursue bachelor's degree in Science from the M.S. University of Baroda in 1995. 


    While in the first year, I pursued my dream by studying for Medical Entrance but due to clashes in the examination dates, I let go of my dream and carried on with a renewed mind. I scored 62% in the first year and expected similar performance in the second year but to my surprise, I scored only 52%.


    During the final year BSc., I decided to pursue Masters in Computer Applications (MCA) and prepared for MCA entrance examination. To qualify for the entrance examination, I needed to score at least 60% in the final year BSc, so that the average of the second and third year comes out to be 55%. By God's grace, I managed to score 62% in the final year. I wrote the entrance examination in May 1998 and ranked third in the exam. It was a miracle from God to see my rank in top 10, among hundreds of candidates from different parts of India. 

    When I attended the first semester classes, the subjects were very different from what I had studied until then. The programming languages were foreign to me. The only subjects, I was comfortable, were Maths and Economics. During the first year, I performed badly in the programming languages. But from the second year onwards, my grades improved. In the sixth semester, I did a six months project at the Railway Staff College. That was the time when I was exposed to the Internet for the first time. In the overall three years of MCA curriculum, I scored first class. 

    During the college days, every student's goal was to get through the campus interview. In the fifth semester, 2001, companies like Amdocs, TCS, Patni, Wipro, MBT hired more than half the class of our MCA graduates. But in the later part of the year, due to dot-com bubble burst coupled with WTC attack, companies canceled or postponed their job offers. It was a big blow to those who were given offer letters. Through God's favor, I managed to get into Amtel, a small US based company in Baroda as a Product Engineer. I was interviewed by Suresh Gajwani, the CEO of the company.


    At Amtel, I was involved in documentation, technical support, gathering customer requirements, writing persuasive RFP responses, assisting sales in identifying customer's business requirements and delivering technically correct solutions, testing, and even purchasing controllers and chips. I had hands-on experience with almost everything except coding. I loved the RFID and Security products and enjoyed my work there.

    I worked at Amtel for two and half years, but there was no salary increment. I decided to change the company. By this time, my programming skills got rusted, and I lost passion for coding. The only option I had was to work as a Testing Engineer or Sales Engineer. While browsing for jobs in the newspapers, I came across a post of Technical Writer that caught my attention. Until then I was not aware of a post called Technical Writer. 

    I gave two interviews, one with Impetus Technologies for the position of Testing Engineer and another with Zensar Technologies for the post of Technical Writer. I remember traveling Ahmedabad to attend the interview from Impetus Technologies. For Zensar, it was a telephonic interview.


    While I was in Kerala for our house warming celebration, I got the offer letter from Impetus. After reaching Baroda, I put forth my resignation and joined Impetus, Indore in Feb 2004 as a Software Testing Engineer. That was the first time I started living independently away from my parents. I was given a week's accommodation in a hotel. 


    Cross Roads
    Two weeks later, while working in Impetus, I got another offer from Zensar Technologies for the post of Technical Writer with a better salary. I was in a dilemma whether to accept the offer since I was happy with the role of Software Testing Engineer. After much pondering, I decided to go for Zensar's offer that established my career as a Technical Writer, a road not taken by the MCA graduates.

    Two roads diverged in a yellow wood,
    And sorry I could not travel both
    And be one traveler, long I stood
    And looked down one as far as I could
    To where it bent in the undergrowth;
    Then took the other, as just as fair,
    And having perhaps the better claim
    Because it was grassy and wanted wear,
    Though as for that the passing there
    Had worn them really about the same,
    And both that morning equally lay
    In leaves no step had trodden black.
    Oh, I marked the first for another day!
    Yet knowing how way leads on to way
    I doubted if I should ever come back.
    I shall be telling this with a sigh
    Somewhere ages and ages hence:
    Two roads diverged in a wood, and I,
    I took the one less traveled by,
    And that has made all the difference

    At Zensar, I wrote documentation for the UML tool - BluePrint Foundry, created a help file using a freeware tool “Cheetah”, and wrote ADDL syntax Programmer’s Guide.


    Sometime in Oct 2004, I received an email for Technical Writing position with Samsung Electronics, South Korea. I was offered flight tickets to attend the interview in Bangalore.
    When I entered the meeting room, I was surprised to see room full of Korean nationalities. The interview went well, but I was not sure of my performance. In December 2004, through God's favor, I received the confirmation letter from Samsung about my selection. During the same time, I received another offer letter from a company in Pune, but I decided to join Samsung Electronics. I resigned from Zensar Technologies on 10th Jan 2004.


    I arrived S. Korea on 21st Feb 2005. It was one of the coldest days with temperature below minus 15 degrees. You can read about my experience here http://www.thomasabeesh.com/2012/07/14/memoirs-of-south-korea/. I was with the Flash Management Software group, Memory Division, responsible for creating documentation for Samsung's XSR, Whimory, RFS, and TFS4 file systems.

    Memory Division, Samsung Electronics
    Memory Division, Samsung Electronics
    The best part of working in Samsung, Korea is that they provide fully furnished flat, festival bonuses during Chinese New Year (Feb) and Chuseok Festival (Sep), performance bonus equivalent to 2-3 months salary, year ending completion bonus, two-way flight tickets to your home country, relocation allowance, and zero tax for foreigners who have Master's degree and 3+ years of work experience. 
    Samsung Electronics Residence
    A view from my flat in S.Korea
    I enjoyed the weather in Korea especially the snow in winter. Some of the beautiful places I love there are Jeju, Busan, and Seoul. The company provided free Korean language training.

    When I joined the Memory Division, it was the most profitable division of Samsung Electronics, but in 2009 due to the global recession, the company suffered loss, and the management decided not to renew the contract for foreigners. Most of my colleagues opted to work in Samsung, Bangalore.

    Before the turn of these events, I had decided to work in the UK. In October 2008, I applied for the Tier 1 work permit and within a week, it was approved. I could stay in the UK and look for a job without requiring any company to sponsor my work permit.

    After my contract with Samsung, I arrived in the UK in March 2009. But it was an economic recession there too. I stayed in Cambridge with a Nigerian family for a monthly rent of 350 pounds. It was through them; I got the chance to attend the African-American Worship service at the City of David Church - one of the most vibrant and energetic people I ever met in my life. While staying in the UK for three months, I managed to get three interviews in Bristol and Cambridge, but no success. I decided to return India to continue my career as a technical writer. On June 2nd, 2009 I left Cambridge and came back to my hometown - Kottayam, Kerala. In the mid-June, I received an email from a consultancy in Singapore for the post of a technical writer with Savi Technology - A Lockheed Martin Company.

    Savi is the primary provider of active RFID technology and supports the U.S. Department of Defense, NATO and allied defense forces worldwide in building the world's largest Automatic Identification Technology-based cargo monitoring.
    Singapore
    Singapore
    There were five rounds of telephonic interview with ID Manager, Principal Writer, ID Director, Product Manager, and Vice President of Savi, Singapore. By God's favor, the interviews were successful, and I was selected to work in Singapore for Savi Technologies. I was supposed to join on July 15th, 2009 but later I discovered that I could not travel since my passport had less than six months validity. I applied for the tatkal passport in Kochi and got my passport after seven days. It took another one week to get my employment pass from the Singapore MoM.  I was provided the flight tickets and two weeks accommodation at Spottiswood Park, Tanjong Pagar. On July 26, 2009, I arrived Singapore and joined Savi Technologies. It was my first experience to work in an Agile Scrum environment.  I wrote SDK Installation Guide, User Guides, Installation Guides for Savi’s SmartChain RFID applications, using  XMetal as Single Sourcing tool for generating content in various formats such as Online Help, CHM, and JAR files, and performed quality assurance and usability testing in the process of producing user documentation.

    Savi Technology Collegues
    Savi Colleagues
    After working there for a year, in August 2010, due to company's financial performance, the US office decided to outsource development work to India. Nobody expected the closure of operations in Singapore.The employees were given the choice to work in India, but nobody opted for it. In the middle of September, through God's favor, I received two offers, one with Philips Electronics and another with Tagit Pte Ltd, an Indian company in Singapore, for a one-year contract. I was in dilemma to choose the company since both offered the same pay package but I decided to go for Tagit. My responsibilities were to create user guides, installation guides, and training materials for the mobile banking application, Mobeix. 

    In August 2011, history repeated itself. Due to the financial situation, Tagit started cutting staff, and I was also laid off. Since I was employed through consultancy, they tried their best to find another client but no success. Meanwhile, I applied for PEP and got approval within three weeks. I could work for any company in Singapore without requiring a company sponsored work permit.

    In the first week of October 2011, I got an interview call for a technical writing position with PayPal, an eBay company, at Suntec City, Singapore. It was a six months contract position. There were four candidates vying for the same post. On Oct 10, a day before my birthday, I got confirmation about my selection. Praise God. My responsibilities were to create API documentation for their SOA based financial instrument services. 

    On February 29, 2012, I received a call from the consultant informing that my last working day would be on April 16th, 2012. I was taken by surprise since I expected an extension of my contract.

    I started applying for jobs. In the third week of March 2012, I got an interview call from JDSU T&M Singapore Pte Ltd, a US based Telecom company. I attended the interview and within two weeks, I received confirmation about my selection. All praises to my Lord and Savior Jesus Christ. One thing I know for sure, God can do it again and again when you call Him. After my selection, PayPal wanted to extend my contract for three more months, but it was too late.

    After working for JDSU for three years and two months, the company split into two different groups, Viavi Solutions, and Lumentum. Because of the split, it carried a burden of 50 million USD. To manage the expenses, JDSU decided to close the R&D division in Singapore, phase by phase. I was given a month's notice period. The company provided the relocation expenses and three months salary for the number of years I worked.

    A week before leaving Singapore, I got an interview, through referral, from an ex-colleague. I cleared the first round which comprised of a written test, interview with a product lead, and with the director of the Singapore division. The second round was a telephonic interview with a senior writer in the US. I cleared that and then there was a third round of telephonic interview scheduled on 29th July with the VP of the R&D Division from the US. 

    I also had an interview scheduled with a different company on 30th July, but my visa was valid until 26th July. I went to ICA Singapore, to extend my visa, but it was denied.

    While in India, I completed the third round of the telephonic interview and submitted three references of my previous company.

    After two weeks, I received confirmation about my selection. The company applied for my Employment Pass, which was approved within a week. Praise God for His favor. After I joined the company on 26th August, I came to know there were other candidates vying for the same post. 


    Why Hire Me?

    I am surprised to see advertisements from high-tech companies in Singapore, looking for Technical Writers with just 2 to 3 years of experience. I believe it is because of the cost factor to hire experienced writers with 10+ years of experience. But the companies that adopt such an approach are unaware of its effect on the documentation quality. Due to lack of exposure to the document development process, a novice writer cannot contribute to the documentation development activity. If your documentation is written by engineers, you risk satisfying your customers. Check this link for potential costs of poor or missing documentation   http://www.stc-berkeley.org/MonthlyMeeting/october2012_meeting/Devney_Handout_2.pdf


    Technical Writing is an art as well as science. We practice our craft to service the reader, not our psyches. We don't expel raw material; we transmute it to provide what the reader most wants. 

    But bear in mind, that Technical Writers are not magicians who can generate content automatically. We need a thorough understanding of the product and a training if possible before we can come out with the first draft. That's why it's important to interact with engineers, QA, and product manager to gain first-hand knowledge of the product, and study the design and functional specifications to understand the product.

    When a writer has to work on multiple products, it is economical from the company's standpoint, but from the writer's perspective, it does not allow him to master the product. The writer's focus is on creating the content, crafting the content, and publishing the content on time. Time is critical when a writer has to work on multiple products.This approach is fine if the company does not expect writers to become subject-matter experts.

    Technical documents are designed to convey information clearly and persuasively but there are no definite, measurable standards to judge. It's possible that writing can be error-free and still not communicate effectively. There are no algorithms for writing. It takes years of experience and mentorship for writers to come out with quality documentation. The key to writing a good document is that it has to be a good experience for both partners, the writer, and the reader. The satisfaction of the writer and the reader are interwoven.You wouldn't want a layman walking into a hospital operating theater to deliver a child. Nor would you want a layman to design the next car you travel in. But writing? Can everybody do it? 

    My Advantage
    • Excellent inter-personal skills
    • Excellent communication skills 
    • IELTS score 8
    • Master of Computer Applications (MCA) and Bachelor of Science (Physics)
    • More than 14 years of writing experience with reputed companies
    • Mentored by professional Writers and Editors
    • Expert in using documentation tools such as XMetal Author, Robohelp, Altova XML Spy Adobe FrameMaker, Microsoft Word, Microsoft Visio for generating online help, and PDF files
    • Expert in creating API Documentation, SDK Developer Guide, User Guides, Installation Guides, White Papers, Training Materials, and Standard Operating Procedures (SOP)
    • Worked in Agile Scrum and Waterfall environment
    • Expert in working with Configuration Management tools such as Tortoise Subversion, ClearCase, and Snapshot CM

    My Experience
    • Telecommunications
    • Electronics
    • Mobile applications
    • Software
    • Security Systems
    • Financial Instruments
    • Client-Server applications
    • Scientific instruments

    If you have any questions, or you want to hire me, send me an email at abeeshthomas@yahoo.com.

    If you want to outsource your writing and documentation projects, visit Thomas English Cafe. Email info@thomasecafe.com or call +65-82086393 for a quote. Check out my post Hiring a Technical Writer or Outsourcing?

    How I write a White Paper

    An Overview of  White Paper

    White papers are a favorite marketing tool for companies. Companies aim to sell products as solutions to their customers through a white paper. The purpose of a white paper is to educate readers and help them make decisions in choosing the solution that suits their needs. In this case, the white paper becomes an excellent marketing and SEO tool that advertises the company's products or services.

    But writing a white paper is a challenging task. It involves an in-depth study of the product and its application, gathering information from the subject matter experts, and reviewing the design documents. The objective is not only to convey information but to spark reader's interest to engage him in reading the rest. Precision and clarity are the watchwords. Naked facts are not enough to invite a reader's invitation to the rest of the document. It's their context- the writing, the container of the information - that illuminates facts for the reader and gives them significant meaning.

    A typical length of a white paper varies from 8-12 pages.


    How I write a white paper

    I meet the product owner, understand the requirements, check the target audience, ask for a target date of completion, and get a brief introduction of the product.

    After the preliminary discussion, I do my own research. Once I gain knowledge, I write the first draft, juxtapose words, and convey information that gives a richer experience to the readers. When I am satisfied with the first draft, I send it for review.

    Occasionally, the first draft may not meet the expectations. It can be due to many factors such as I might have missed certain features, or it might not have been discussed in the first meeting. I then have a second round of discussion. This is when I get a fresh revelation. I capture these intricate details and put them in my second draft. This draft is almost a perfect piece. Over the years, I have learned that a writer needs a tough skin, for no matter how advanced one's experience and career, expert criticism cuts to the quick, and one learns to endure and to perfect.

    Principal components of a white paper

    • A good page layout - A good page layout ensures that language, graphics, and colors combine on a page to promote clear communication. Readers of the page will find it pleasing and easy to read even though they may not be conscious of all the page layout techniques.
    • A title that arouses curiosity - A good title is the title of a successful white paper. A good title is like coming to a house you have never been in before and having the owner open the door and say "Welcome". A good title can make a tremendous difference in the early acceptance of a white paper.
    • Table of Contents - TOC help readers in two ways: 1. they outline the structure of the document and thus provide insight into the document's organization. 2. they provide the page numbers for all sections and subsections, thus helping readers to locate parts of the document.
    • Background/introduction to the document - The introduction sets the stage. It normally includes the historical background of the product and establishes the scope of the product. In essence, the introduction is a road map, it orients the reader by providing a context for the reading. In short, the introduction prepares the reader for what will follow. 
    • Graphics - Graphics are essential for conveying key information in the white paper. Readers will recall one impactful graphic long after they have forgotten a thousand words of text. Create visuals first, write text last. Graphics are more emphatic than text and should, therefore, be designed early in the writing process.
    • How the product solves the problem
    • System functions
    • Benefits of the product.
    • Architecture of the product
    • Evaluation criteria for choosing the product
    • Conclusions
    If you need help in writing a white paper, contact Geenu Ann via email: info@thomasecafe.com or call +65-82086393.

    Essential Tips for Writing a Technical Article


    Writing a Technical Article

    Tips for Technical Writing

    • Get to the Point  - Your objective is to make the reader understand your topic quickly. The readers are not interested to spend hours reading the article.
    • Avoid wordy phrases. A fundamental of good writing style is to avoid unnecessary words.  Do not say All of a sudden. Just say, suddenly. Instead of a later date, say later. The shorter, simple words or expressions make your writing more concise and, consequently, make it look and sound more professional. 
    • Keep it Short and Simple - Write short sentences by eliminating punctuation without affecting the readability of the sentence. Use fewer commas, more periods, and no semicolons at all, if possible.
    • Improve the Presentation - Always provide a brief description of the subject followed by steps to achieve. Provide screenshots where possible.
    • Improve your Template - Use numbering if the steps are to be performed in a sequential manner otherwise use bullets. The title and headings should convey the subject matter. The headings, steps, and body text should follow a consistent format.
    • Use a Style Guide - Follow your company style guide. Otherwise, use Chicago Manual of Style or Microsoft Manual of Style.

    9 steps to create Technical Documentation

    9 steps to create a technical documentation

    Planning for Technical Writing

    1. Read the Marketing Requirements Document (MRD). The MRD should list out clearly the documentation requirements.
    2. On the basis of MRD, create a documentation plan that includes
      •  Product name, scope and purpose
      • Milestone dates 
      • List of documents that will be created and/or updated. If the project is updating an existing product, list the features to be documented. If the project is releasing a new product, additional planning is required. There are multiple customer documentation deliverable types a project could require, ranging from a single-paged addendum to a context-sensitive online help system.  
      • Features that will be documented
      • Work estimate and committed schedule for documenting each feature or completing each document 
      • Committed documentation milestones
      • Documentation Reviewers including review schedule. There are 2 ways to conduct review, collect edits individually from each reviewer or hold a review meeting to review everyone's comments. Multiple reviews may be required.
      • Depending on the program, include any training material needed for the Launch.
      • Risks, assumptions, and dependencies. Include the following: Main risks of the documentation project (e.g. last minute feature additions), probability of each risk, Impact of each risk, Risk mitigation plan, Owner of the mitigation plan)
      • Affected BOMs and/or document numbers
      •  Doc approval process and approvers (outside the tech pubs team)
      • Documentation delivery and distribution plan


    3. Distribute the plan to the core team members: PLM (Marketing), R&D lead (Engineering),  and PM (Program Manager) who will review and approve the plan.
    4. After the approval, create the draft technical documentation by attending core team meetings, interacting with SMEs, studying design documents.
    5. Send the document to reviewers identified in the documentation plan.
    6. Update the documents as per the review comments, address all major and critical documentation CRs and defects, during the documentation validation.
    7. Obtain a documentation approval from the designated reviewers/approvers.
    8. Generate the final version.
    9. Check in the final document into the build branch.

    Technical Writing in an Agile Environment

      While working as a Technical Writer at Savi Technologies, Singapore, the company strictly followed the Agile Scrum methodology. I was in the Typhoon team. Everyday the team gathered in one of the cubicles to discuss what we did the previous day, plans for the day, and any blocking issues. During the initial days of my joining, I came across the below slangs that were foreign to me
      • Scrum Team: A scrum team typically consists of five to nine people that includes a Scrum Master, s/w engineers, testing engineers, and a technical writer.
      • Stories: I used to wonder why they call the feature request as stories. Is it some new adventure stories of Hardy boys or Enid Blyton’s? But I liked the term ‘stories’, It describes why you want that feature to be included in the application.
      • Product Backlog: The “product backlog” is the list of stories in order of priority. The stories at the bottom of the backlog tend to be just ideas and perhaps still rather big chunks. They must be broken down into smaller stories as they approach the top of the list. Some people use the concept of an “epic” to group related stories and keep them together as they approach the top of the list. The requirements are collected in a prioritized product backlog by a product owner.
      • Sprint Backlog: The “sprint backlog” is the list of stories to be tackled in a particular sprint. During the sprint planning meeting, the project team determines which backlog items go into the sprint. No one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. The sprint must end on time. If requirements are not completed for any reason, they are left out of the release and returned to the product backlog.
      • Sprint: The iterations and incremental cycles in Agile are called sprints. This is an analogy to what happens in a race. We essentially "sprint" towards a race for completion of the development of software, testing and documentation. The “sprint” is a period often three weeks during which the development happens. During sprint, the Scrum team works in close cooperation and meet every day to discuss and resolve any problem.
      • Sprint Planning Meeting: There’s a planning meeting at the beginning of the sprint and a retrospective meeting towards the end. The idea is that each sprint delivers a potentially shippable product. In the retrospective meeting, each members' performance is evaluated. Members are free to criticize one another. During my tenure, the ID team received both appreciation and criticisms. But at all times, we took the criticisms in a positive manner and ensured that mistakes were not repeated.
      • Scrum defines 3 roles: The product owner creates and prioritizes the backlog, defines the stories, decides what goes into the next sprint. The scrum master works with the team, fixing anything that’s stopping the team from working. The team does the development.
      • Story Points: When estimating the stories, they use “story points” depending on the number of man hours and resources to finish the task. The story points are expressed as a number, based on the relative complexity of the work required. All the members are given a points card and each member decides points that need to be allocated for completing a task. And based on the majority of votes, the points are allocated. And they need to justify, why they think, the user story deserves that much points.
      • Burndown Chart: This is a graph and lets the team know how much work is left and completed in the sprint. We used Rally to generate the chart. Using this tool, any member of of the team or a person outside the team can see at glance whether the team will complete the work for the sprint.
      The good part about Agile development is that writers are involved in the product planning and the documentation development timeline is factored into the product release. Being part of an Agile team has the advantage of making you and your work far more visible. We all met in a meeting room for the sprint planning to commit the deliverables. We used a tool by name Rally to define our goals, achievements, pending tasks, etc.

      In an Agile environment, developers, QAs, and writers work together to meet the deadlines. In addition to the documentation, I also tested new features and logged the defects. This helped me in gaining good product knowledge. 

      Two key points in ensuring a successful scrum are 
      • having a set of agreed deliverables, and 
      • breaking the assignments into small tasks that can be estimated and tracked 
      In Agile, any problem that a member faces is the team’s problem. The role of the Scrum Master is to get rid of any impediments interfering with your work. For example, if you cannot start your documentation because developers haven’t finished coding, then that becomes an impediment. You can request them for a sample prototype. You do not have to wait until the completion of the coding to start the documentation, since that can cause your work to spill over to the next sprint. 

      I believe that every company that hires a technical writer should have a well defined process. It's paramount for documentation development to be integrated with the software development.

      If you have any questions, email me at abeeshthomas@yahoo.com

      7 Deadly Sins of Technical Writing

        As a writer, I have created documentation that I am proud of but I have also created some that were not up to the mark. Here are seven problems to look out for: 
        1. Poor Organization: Make sure that your users can easily find the information. It is tempting to organize the content as per what you see in the software application. But ideally, you must ask what the user wants and based on that you must organize your content. 
        2. Inaccurate information: Sometimes you may receive wrong information from Engineers and document this piece of information. To fix this issue, you must get your content reviewed by key stakeholders like product owners, scrum masters, engineers, and QA guys to check the veracity of the content. 
        3. Outdated information: This occurs when the product undergoes enhancement but the changes are not communicated to the writers by the development team.
        4. Incomplete information: Users often need more information than you give them. You must not only document how to perform any task, but also provide conceptual information answering what, when, and why. Your goal should be to tell the users everything they need to know without overwhelming them.
        5. Bad sentence structure: The general rule of thumb for technical documents is keeping your sentences short. Whenever possible, use tables, bullet points and numbered lists to organize information.
        6. Poor word choices: There are many words that mean approximately the same thing. Depending on the situation, you must make the judgment. When choosing between one or more words ask the following questions:

          Which word is the most clear?
          Which word is the most unambiguous?
          Which word is the most accurate?

          Once you have made a choice, the next step is to be consistent. Use the same word every time the situation and instructions are the same. For example, if you wrote,
          Click the OK button or Click OK, the first time, use the same statement every time you expect the same action. 
        7. Incomplete Review: Never take your writing for granted if your document has not undergone peer and technical review. You will be surprised to come across errors after review. So it’s worth the effort to get your documents first reviewed by a fellow technical writer and then by Engineers/QA/PLMs. During peer review, you can catch some good errors like missing links or broken cross-references which are normally missed out in the technical review.

        Ramblings on Technical Writing

        Tell me, and I will forget. Show me, and you will involve me. Involvement is the first step toward understanding. If you're concerned about whether in any passage or chapter you are telling rather than showing, there are some questions you can ask yourself:

        Are you allowing the reader to see what's going on? Showing means having actors do things that excite our interest, making those pages visual, letting us see what happens firsthand.

        How to show? Sight is our primary sense. We prefer to witness an event. Which is why, we must show a story instead of tell a story. Show, don't tell.

        https://www.quora.com/Why-are-adverbs-considered-to-be-evil

        Mark Twain - If you catch an adjective, kill it !. Most writers erect a Great Wall against the process of eliminating all but a minimal number of adjectives and adverbs.

        Most adjectives and adverbs are dispensable. The easiest ones to dispense with are "very" and "quite".

        Adjective surgery can be painful until you practice it rigorously and examine the results.

        There are several rules for determining which adjectives to keep:
        An adjective that is a necessity
        An adjective that stimulates the reader's curiosity and thereby helps move a strong along. Example: He has a pursued look, wouldn't work without the adjective. Moreover, the adjective raises curiosity about why he had the pursued look..

        An adjective that helps the reader visualize the precise image you want to project.

        An adjective of course modifies a noun. An adverb modifies a verb,. Most adverbs require the same tough surgery as adjectives.

        Leah wished he would call soon. The meaning of soon is implied. The adverb is unnecessary. The sentence is stronger without it.

        A frequent error is the use of two adverbs. She really, truly cared for him. Would you eliminate "really" or "truly"? You could take out either.

        Before you begin eliminating all adverbs by rote, keep in mind that sometimes adverbs can be helpful. There are 2 adverbs in the following short sentence. Each conveys something different.

        He ate heartily, happily.

        Heartily connotes eating a lot, "happily" connotes taking pleasure. If it's the author's intention to convey both meanings, the adversb should be retained. He ate without either adverb tells us little.

        The verb should agree in number with its subject. So a plural subject requires a plural verb, and a singular subject rquires a singular verb.
        A test was completed last week. (singular)
        Several tests were completed last week (plural).

        Ensure that your verbs agrees with your subjects.
        She works every day. (singular)
        They work every day. (plural)

        He has the answer. (singular)
        They have the answer (plural).

        Strong verbs shorten sentences and convey direct memorable messages.

        Subjects connected by and require a plural verb.
        The ceiling panels and fasteners have been fabricated.

        The software designer and the graphic artist agree that we should market the new instructional manual immediately.

        A personal computer and a photo copier are essential business tools today.

        Note: Sometimes words connected by and become so closely linked that they become singular in meaning, thus requiring a singular verb:

        Bacon and eggs is my favorite breakfast. My name and address on the inside cover. Simon & Schuster is an excellent publishing firm.

        Singular subjects connected by either...or, neither...nor, and...not oly...but also require a singular verb.

        Either the post-operative therapy or the inflammation is causing the acute pain.

        Neither the district engineer nor the superintendent has approved the plans.

        Not only the cost but also the design is a problem.

        Place the adverbs only, almost, nearly, merely, and also as close as possible to the word they modify.

        The engineer had almost finished the specifications.

        Choose adverbs, not adjectives, to modify main verbs:

        Our accounts predicted accurately that cash flow would be a problem.
        The manager asked quickly for the up-to-date estimates.
        The test engineers calculated roughly the expected power.

        Prefer active sentences. Use a passive sentence when you don't know or don't want to mention the actor.

        Use a passive sentence when the receiver is more important than the actor.

        Avoid wordiness:

        Use concise, direct sentences. The principles of writing direct, concise sentences

        The verbs should agree in number with its subject...So a plural subject requires a plural verb, and a singular subject requires a singular verb.

        The geologist has completed the tests. (singular). The geologists have completed the tests. (plurarl).

        A test was completed last week. (singular)

        Several tests were completed last week. (plural)

        Ensure that your verbs agree with your subjects.

        She works every day. (singular)
        They work every day. (plural)

        She is the candidate. (singular).
        They are the candidates. (plural)

        Avoid vague use of demonstrative pronouns.
        This is something to consider (better: This shortfall in payments is something to consider.)
        These are difficult (better: These exercises are difficult.).

        Indefinite pronouns used as subjects should agree in number with their verbs:

        Anyone likes to receive a positive performance review. (Anyone = singular; likes = singular)

        Several were contacted before we chose a final canddidate (Serveral = plural, were = plural).

        All of the sugar was tainted. (All of the sugar = singular, was = singular).

        All of the employees were notified of the new vacation policy. (All of the employees = plural, were = plural)