I am contemplating the changes in technology and my role in the world of computing. I have worked at many contract and full time positions in the Pacific Northwest, including a large software company, a large airplane company, the first local cellular telephone company, a myriad of start-ups, and in industries as conventional as mortgage and insurance, as bleeding edge as streaming video on handheld devices, and as as Laser and bioengineering.
It’s probably not surprising that in this role I’m tasked to write about something that nobody has used before--creating helpful descriptions, scenarios, and processes that are woven together to support many layers of users. While I welcome these opportunities, I have to start each one with a blank slate and build new road map for myself and that supports past, present, and future releases. This investigative treasure mapping dates back my childhood habit of reading my older sibling's scouting book and school books to gain insight into the mysteries of knots, orienteering, and algebra.
I was hired as an engineering aid, first for a group of retired airplane engineers who started a company trading timber futures, and then for aerodynamics engineers, keying equations into programmable calculators and saving the "programs" on mag strip readers or onto punch cards in a "job deck" for submission on a mainframe, then manually plotting results to draw multi-layered views of airplane performance (thumbprint plots, lift/drag ratios) from four-inch thick stacks of 11x17 output--manually-generated graphical views of what we know today as big data--extracting and transforming data points from five-pound stacks oF output.
My "connecting the dots" role took a quantum leap when I was hired for CAD programming training where I learned to drive a 3-D tool tip along planar slices of the mathematical model of an airplane. Thermal paper replaced punch cards--hundreds of yards of paper logged the trial and error programmatic descriptions of I-beams, spars, rivets, skin thicknesses, offsets, access holes, pulleys, and mountings for commercial aircraft. The intermediate output could be plotted, or drawn, by an automated tool that was three times the size of a pool table, and the final output was run by an machine shop operator cutting 26 leading edge ribs from a single parametric program.
My colleagues in the CAD group who programmed computer-generated parts failed to add comments to their programs, so updating the software became problematic, even for the original author. My first technical writing assignment was to add comments to their code and recognizing the many redundancies--the many ways of redesigning the wheel--in the code base. The organization of routines and subroutines, parameter names, etc. varied with each programmer. Nesting may have existed, but parameter names were reused in different routines, routines may be copied rather than nested, and there was no such thing as a function library or coding standards.
In those early years (1980s), I was also a database manager for a library, or software repository, that tracked the use and contact information for various versions of mainframe and midsize (VAX) software applications--the earliest of version control systems, on a database written in System 2000 on a computer half a continent away. Access permissions and queries were awkward and expensive--with next-day answers and per-query costs in the hundreds of dollars. I wrote a cost analysis of the query reporting, which won me a cost savings award by the CEO, but also eliminated the database--and my job.
The 1990s marked the dawn of affordable electronic processing over networks that tied PCs to mainframes--the paper trail was on its way out and the world of SDKs and shrink wrap COTS (commercial off-the-shelf) software entered the workplace and even our homes. As a contract employee working in many corporate environments, I frequently saw two year old software still in its shrink wrap, and I learned that end users of all types are reluctant to adopt new processes--at individual, departmental , and corporate levels. I was frequently hired to help business units adopt and use new tools by drafting processes and offering individualized training. I created standard operating procedures (SOPs), roles and responsibilities, and even an application turnover guide to connect the dots and usher in streamlined processes. Operating procedures may include checklists, handshakes, contingencies, escalations, and notifications or messaging for a user, for a machine, or between user(s) and machine(s).
I often found myself in a company or project--primarily--because contributors had no idea how to use/share software products, including templates for MS Office tools, or versioning for content management products. This is without a doubt the highest cost to company profits/productivity. Problems arise when it is time to update a document or link documents. Rather than offering training, companies reorganize, and "new ways of documenting" a product are suggested. Each department should consider crafting a SOP. This "implementation issue" continues to plague many companies with shared systems. One person's update can break the in-work project files for everyone. An IT department with no defined (or adopted) coding standards or where peer reviews are nothing more than LGTM (looks good to me) signoffs has frequent issues when working on a new version or integrating a new feature. Invariably, someone considers standards individual prerogative and they test and approve checkins at a modular level. Problems are then reported downstream--perhaps by the customer. Look how far the 787 got before an assembly error was noted. Or Vista, where performance degrades over time and the only solution is to rebuild the machine every 6 months or so.
Too often, in a crunch, employees make accommodations for coworkers, resulting in error ridden rollouts, such as laptops without touch screens being sold with Windows 8 OS preinstalled. Perhaps risk analysis prioritizes the potential profit of reaching the greatest number of the newest devices. For example, the uselessness of Paperclip has a new face, but this helper has never resolved any connectivity or network adapter issues. We rely on the Internet for expert advice from a 3rd party site. Shouldn't be coming from the hardware or software manufacturer?>
Naming conventions within a project or across products continue to be the challenge. It is often my job to create an architectural diagram for end user audiences where the conceptual diagram for the project bears little resemblance; the graphical view needs to be an interactive link to features, configuration settings, and entry points for legacy systems as well as access points for product/technical support who are called to resolve these issues.
And while I believe there are many defined formulae for scheduling this work, and many tools with built in error checking, I also believe there is a craft to building richly interwoven detailed paths that support multiple user roles. I can share a few things that I've learned on the very unexpected, but very fulfilling road that started with RapidOGraph pens and mag strips and ended up with me having four different devices, each with its own operating system, that I use to create, edit, and monitor this content.
It’s probably not surprising that in this role I’m tasked to write about something that nobody has used before--creating helpful descriptions, scenarios, and processes that are woven together to support many layers of users. While I welcome these opportunities, I have to start each one with a blank slate and build new road map for myself and that supports past, present, and future releases. This investigative treasure mapping dates back my childhood habit of reading my older sibling's scouting book and school books to gain insight into the mysteries of knots, orienteering, and algebra.
When I started my academic studies, my goal was to go to college and find a cure for epilepsy, mental retardation, and cerebral palsy. The coursework of a Pharmacy degree didn't fit my imagined goal or my budget, so I sought employment in a field that used math and science, with the goal of repaying my school loans while I reconsidered my career options.
I was hired as an engineering aid, first for a group of retired airplane engineers who started a company trading timber futures, and then for aerodynamics engineers, keying equations into programmable calculators and saving the "programs" on mag strip readers or onto punch cards in a "job deck" for submission on a mainframe, then manually plotting results to draw multi-layered views of airplane performance (thumbprint plots, lift/drag ratios) from four-inch thick stacks of 11x17 output--manually-generated graphical views of what we know today as big data--extracting and transforming data points from five-pound stacks oF output.My "connecting the dots" role took a quantum leap when I was hired for CAD programming training where I learned to drive a 3-D tool tip along planar slices of the mathematical model of an airplane. Thermal paper replaced punch cards--hundreds of yards of paper logged the trial and error programmatic descriptions of I-beams, spars, rivets, skin thicknesses, offsets, access holes, pulleys, and mountings for commercial aircraft. The intermediate output could be plotted, or drawn, by an automated tool that was three times the size of a pool table, and the final output was run by an machine shop operator cutting 26 leading edge ribs from a single parametric program.
My colleagues in the CAD group who programmed computer-generated parts failed to add comments to their programs, so updating the software became problematic, even for the original author. My first technical writing assignment was to add comments to their code and recognizing the many redundancies--the many ways of redesigning the wheel--in the code base. The organization of routines and subroutines, parameter names, etc. varied with each programmer. Nesting may have existed, but parameter names were reused in different routines, routines may be copied rather than nested, and there was no such thing as a function library or coding standards.
In those early years (1980s), I was also a database manager for a library, or software repository, that tracked the use and contact information for various versions of mainframe and midsize (VAX) software applications--the earliest of version control systems, on a database written in System 2000 on a computer half a continent away. Access permissions and queries were awkward and expensive--with next-day answers and per-query costs in the hundreds of dollars. I wrote a cost analysis of the query reporting, which won me a cost savings award by the CEO, but also eliminated the database--and my job.
The 1990s marked the dawn of affordable electronic processing over networks that tied PCs to mainframes--the paper trail was on its way out and the world of SDKs and shrink wrap COTS (commercial off-the-shelf) software entered the workplace and even our homes. As a contract employee working in many corporate environments, I frequently saw two year old software still in its shrink wrap, and I learned that end users of all types are reluctant to adopt new processes--at individual, departmental , and corporate levels. I was frequently hired to help business units adopt and use new tools by drafting processes and offering individualized training. I created standard operating procedures (SOPs), roles and responsibilities, and even an application turnover guide to connect the dots and usher in streamlined processes. Operating procedures may include checklists, handshakes, contingencies, escalations, and notifications or messaging for a user, for a machine, or between user(s) and machine(s).
I often found myself in a company or project--primarily--because contributors had no idea how to use/share software products, including templates for MS Office tools, or versioning for content management products. This is without a doubt the highest cost to company profits/productivity. Problems arise when it is time to update a document or link documents. Rather than offering training, companies reorganize, and "new ways of documenting" a product are suggested. Each department should consider crafting a SOP. This "implementation issue" continues to plague many companies with shared systems. One person's update can break the in-work project files for everyone. An IT department with no defined (or adopted) coding standards or where peer reviews are nothing more than LGTM (looks good to me) signoffs has frequent issues when working on a new version or integrating a new feature. Invariably, someone considers standards individual prerogative and they test and approve checkins at a modular level. Problems are then reported downstream--perhaps by the customer. Look how far the 787 got before an assembly error was noted. Or Vista, where performance degrades over time and the only solution is to rebuild the machine every 6 months or so.
Too often, in a crunch, employees make accommodations for coworkers, resulting in error ridden rollouts, such as laptops without touch screens being sold with Windows 8 OS preinstalled. Perhaps risk analysis prioritizes the potential profit of reaching the greatest number of the newest devices. For example, the uselessness of Paperclip has a new face, but this helper has never resolved any connectivity or network adapter issues. We rely on the Internet for expert advice from a 3rd party site. Shouldn't be coming from the hardware or software manufacturer?>
Naming conventions within a project or across products continue to be the challenge. It is often my job to create an architectural diagram for end user audiences where the conceptual diagram for the project bears little resemblance; the graphical view needs to be an interactive link to features, configuration settings, and entry points for legacy systems as well as access points for product/technical support who are called to resolve these issues.
And while I believe there are many defined formulae for scheduling this work, and many tools with built in error checking, I also believe there is a craft to building richly interwoven detailed paths that support multiple user roles. I can share a few things that I've learned on the very unexpected, but very fulfilling road that started with RapidOGraph pens and mag strips and ended up with me having four different devices, each with its own operating system, that I use to create, edit, and monitor this content.
Mentoring
People make all the difference in life. One of the best things you can do is to find--or be--someone you admire and trust. This applies not only to networking, but primarily to learning. Learning to ask questions and learning to listen. Watch how the experienced person--or the newbie behaves, absorbs information, or accepts an inconvenient truth. Mentors help you to see opportunities and to learn--from the things that went wrong, things that went right, and things that you can or cannot control.
Beyond self
Stellar performers and those in management positions are often the most ambitious, but leadership needs different skills from those used for personal gain.Your worth on a project is less about what you personally accomplish and much more about the success of the team. Appreciating the accomplishments of everyone on the team helps you generate more useful information about the product. Documentation is a service role and it requires you solicit criticism from others--you'll need a great deal of humility to listen, consult, and revise.
Have integrity
It seems obvious, but never compromise ethics and integrity. No matter how many kudos a team member may have, I would not publish content I knew to be false. It helps to identify people you can trust rather than those who are seeking to please or appease. As you become more successful there are more and more of the latter. Try to discern who is telling you what you need to know from who is telling you what they think you want to hear.
Recognize opportunities
Finally, remember that good documentation isn't created nor ordained by titles in an org chart. The best resources emerge at every level and in every situation and are recognizable by actions and decisions – not by a nameplate. Good technical writing depends on realizing that accurate content is built by finding opportunities to work together with the people as well as the available tools; both resources are required to build documentation that is both used and useful.
Accept change
For all of us, our career is an accidental route, one that we could not have envisioned. I may be where I planned or expected to be, but in hindsight, I have made significant contributions and today's situation is a privilege for me to reflect on and take in the astonishing changes in technology that nonetheless require accurate and flexible instructions for treasure maps that can be viewed by a wide audience.
No comments :
Post a Comment