Job 1: Ansys
At the beginning of 2001, I was finishing up my Junior year in college and my wife was expecting our first child. Shortly before the end of that school year, the company where we both worked closed its doors without any advance warning or severance. The co-founders of the company had worked previously at a company called Ansys, and put in strong referrals for my wife, who started full-time work as a technical writer. I wasn’t able to arrange for another summer internship by the time Spring Semester was over, but she let me know that her team was looking for some summer help to convert several thousands of engineering formula graphics into better formats for online help.
Through the process of converting these images, I also familiarized myself with some of the other systems they used to create and publish documentation for Ansys. Ansys is a highly technical Computer Aided Engineering (CAE) suite that had been (and still is) used by engineers (real engineers, not software engineers) in aerospace, auto manufacturing, and similar industries. As such, their software documentation was very complex, very technical, and very long. Writers authored in an XML-based language called DocBook (standardized and widely used by O’Reilly Publishing). The entire set of manuals printed out at more than 10,000 pages, and was written as a single XML document. (Somebody estimated this was the largest single DocBook instance in the world, but I don’t know how accurate that was.) One of the technical writers had some coding experience, so had primarily been responsible for how this XML document was converted into HTML, PDF, and online help systems, but wanted to spend more time writing. After the image conversion piece was done, I started to pick up some of the work he was doing, and continued working part time into the Fall semester of my senior year.
It may not be everybody’s cup of tea, but I had always loved experimenting with my word processing software at home. (I used different fonts and styles on almost every high school paper I wrote, just because I could.) Working on the XML publishing system at ANSYS meant I could do the desktop publishing side in an automated fashion, and not have to be responsible for coming up with the words. After September 11, 2001, came around, any other job prospects for me started to look pretty unlikely, so when Ansys offered me a full-time job after graduation, I took it, and was pretty happy for it.
Over the next two years, I worked to automate as much of this process as I could. A lot of my best ideas came from my internal customers in the writing department. (Well, one internal customer in particular. Remember that my wife started there first.) I researched newer and faster XML parsers to make it easier to validate XML before documentation was updated, tried out new visual editors to make it easier to write XML, and came up with various extensions to DocBook and the DocBook stylesheets to improve the look and feel of the documentation. I wrote my own documentation on how all this worked, and used that as my playground for testing out new ideas.
Over time, I found ways to do a little more traditional software development, mostly in Java, as part of this job. I wrote some Java extensions that integrated into the XML parsing step directly to improve how we would handle file references for images (broken image links had been an issue before this). I replaced the standard Windows copy commands with a multi-threaded Java program for copying images over the network (I am still surprised this worked at being faster, but it was much faster), wrote a small Java program for integrating Sun’s JavaHelp system for our UNIX applications, and even remember writing a small GUI program (in TCL/Tk for some reason) for conducting user surveys at one of our user conferences.
Research was always a big part of this job. I spent a lot of time reading standards and specifications for XML, XSLT, HTML, XHTML, CSS, etc. as part of figuring everything out. Internet Explorer was the dominant browser on Windows systems, but we had UNIX systems, so our HTML designs had to work across multiple browsers, and then we had to replicate those (or similar) designs in PDF. One of the writers in the department had worked for a print shop, so learned a lot about print design, layouts, and fonts from him.
As with much of the old Internet, the user groups and email forums for DocBook were a valuable source of information, and I became very active on these, to the point that I ended up on the Technical Committee for DocBook for a year or so. I don’t remember making major contributions to the specification, but helped enough in some way in the user groups to warrant a mention in Bob Stayton’s book DocBook XSL: The Complete Guide. (I'm still there in the Acknowledgments section.)
1: Lessons I’m Still Learning
Over time, I developed a very abstract view of the work I was doing that wasn’t always helpful to the writers on my team. For me, the XML document was a semi-structured database that happened to contain words — what those words said was almost entirely irrelevant to me. Obviously, the writers did not have the same view. I don’t think I ever expressed this view out loud, but there was at least one time where I was making some sort of suggestion that required several extra steps for writers in order to get the “database” into a state I wanted it to be in, and for writers who were already stressed and undervalued, having a 21- or 22-year old CS graduate telling them how to do their job didn’t come across very well.
In some ways, this was a lesson I practiced better then than I do now. Everything I was doing in this job was new, so I had to pick up new technologies and habits all the time. I was constantly looking for new ideas on how to do the technical aspects of my job better and trying out new ideas and tools in the process. Sometimes, the more I learn the harder it is to remember that I have to keep learning.