4 years, 3 weeks

I happened upon some old posts - one from 4 years, 3 weeks ago and one from 4 years, 1 day ago. The company I worked for when I wrote those posts was purchased by another company after I left. I'm not quite sure why, but I started thinking about all the work I would have been doing, had I stayed. I would have spent my days: 

• keeping the the documentation / help text up-to-date with the changes that were made by Development for the release. The ratio at the time was challenging about 15 developers to me.
• Side note: If documentation / help text is not up-to-date with the information the user needs to do their task, why even allow the software to access the documentation? Why allow a user to even access obsolete information? Because you want to frustrate the user? Because you want to teach the user not to trust the documentation? It was hard work - damn hard work - to get the users to trust and then nurture their trust of the work I did. After all, if the documentation I wrote had to be not accessible to the users and time / energy because I couldn't keep up or whatever, and the decision was made to remove access from the software to the help text . . . I'd be speechless about the terrible disservice to the users! The time and energy wasted by the Developers to hopefully just hide (comment out) the code and to do that for all the software applications I documented! I would have felt lower than low. All that work, never seen by the users And then, when I had gotten through busting my a$$ to get it updated and ready to be redistributed to the users, the Developers would have to make their code unhidden. And *then* the time spent retesting each application to make sure the documentation / help text was accessed correctly. 
• replacing the feedback@(old_company_name.com) with the feedback@(new_company_name.com). That sounds simple but, really, when my mind starts processing.... Wow.
• Off the top of my head, I'd first change, then test :
• all the hundreds of HTML files.
• I had multiple RoboHelp projects. For each one, I would have to:
• change the text in "Design" view in Dreamweaver
• change the text in the "Code" view in Dreamweaver.
• I'd have to do both! I'd be 100% wrong to only change the documentation@(new_company_name.com) text that the user would be clicking. If I did that, the underlying (unchanged HTML) would mean the actual email would be sent to the wrong address - documentation@(old_company_name.com) address!
• all the 15ish JavaScript files (.js) files
• those files included references to documentation@(old_company_name.com) - especially the one that was used to create the Documentation Feedback section at the bottom of each and every HTML page! 
• all the 200+ Word docs that were converted to PDF, then distributed to clients. 
• The last page prior to the Index was a "Contacting Documentation Team" page.
• replacing all the references to the previous software version with the new version in the footer of the HTML files.
• Side notes:
• Vividly, I remember taking the time to do this to my source files prior to each release. It had to be done before the documentation I wrote was bundled with the software for distribution. 
• I remember using (and loving) how powerful FAR and / or Dreamweaver were for this type of work!
• trying any strategy I would have conceived to make the release notes not look like multiple people added entries.
• Instead of still seeing:
• Modified the program to...
• Changed the program to...
• The program was changed to...
• Program changes were made to...
• I would have suggested again and again if necessary
• Changed the program to...
• Changed the program to...
• Changed the program to...
• Changed the program to...
• Side note: There is absolutely no feasible or sensible reason for consistency when conveying "technical information" about the way users are going to do their job with the changes in the software that the release notes describe. After all, when technical documentation is inconsistent, all you really do is make the reader guess whether there's a difference between "changing a program" and "modifying a program." All that happens when you are inconsistent is you change the focus from "what" is written to "how" it is written. Focus on the content. Inconsistency screams with all the force of the Metallica / Lou Reed collaboration, "Are you kidding me? Who thought inconsistency was "okay" for the audience?
• replacing all text references to the (old company_name) with the (new_company_name) in all source files
• HTML files
• JavaScript files
• Word docs (the ones converted to PDF prior to distribution)
• keeping up with the user interface changes I was responsible for. The work to do that would be similar to the documentation changes. Off the top of my head, I'd be changing the references on the screens, in the title bar, and (probably) the logo that used to be accessed through the "About" link on the Help menu as well as what used to be in the corner of the screen. And that wouldn't be all! Any one of those UI changes could impact the documentation, I'd have to review all of the existing screen captures in the aforementioned documentation / help text and decide either I needed to replace the screen capture because it helped the user or remove the screen capture because it didn't help the user. Sincerely, based upon the work I do now on a daily basis, I would be slicing and dicing the screen captures out. I am not anti-screen captures - I am anti-fluffy screen captures. 
• Side note:
• Just the other day, I was editing a user guide. I came to a section in the user guide where I saw a small cropped graphic of just the button the user clicks to complete the task. There was no context on this graphic for where the button is actually located on the screen. I think that would help the user find it and be useful.  But this little "Add New User" button. Really? It looked like this:
• Click Add New User.
  <graphic>
• replacing all the references to the previous software version with the new version in the footer of the HTML files.
• I remember doing this in my source files prior to the documentation being bundled with the software for distribution. I really loved FAR and / or Dreamweaver, for this type of work!

My, how time flies. I like reflecting about my professional career. Comparing "now" and "then" while thinking about where I am now v. where I was, I can't help but grin ear to ear.