It's Not All Pencils and Paper

One reason I enjoy being a technical writer at NI is that we don't just write stuff and draw squiggly editing marks on other people's papers. True, that is some of it. But beyond the writing and editing, we are allowed (and encouraged!) to suggest and implement improvements to the software.

For example, all LabVIEW's VI/function help topics contain buttons labeled Place on the block diagram and Find on the Functions palette. Clicking these buttons opens an interactive pathway between the help file and LabVIEW itself. The idea for buttons like these originated with the LabVIEW technical writers. They saw a need, proposed a solution, follwed through, and the rest is history.

I recently proposed, and am in the middle of implementing, two help system improvements of my own. They both deal with LabVIEW MathScript and the way users interact with help in that environment. I was pretty nervous when it came time to present these proposals to the appropriate people because I'd never done this before. We all sat down in a brainstorming meeting to discuss the merits of my proposal. I started off basically by saying "Tell me what I did wrong." I was worried that I'd proposed some fatal flaw that would get my proposal rejected, or that I'd get the dreaded "That's great Ryan, but we don't have enough time to do this." But none of that happened.

That meeting was an eye-opening experience for sure. Now that I have that under my belt, I am moving forward with getting my idea actually implemented in software. It's pretty neat to see a checkbox there just because I asked for it (and several people approved it, of course). Oh, that sounds so geeky. But it's true.

I'm talking only about the two ideas I proposed, but I've watched several other LabVIEW technical writers, who are newer here than I am, have come up with other awesome ideas for the help system. These features improve the user's ability to submit feedback on our help files, scan and navigate a long help topic, and find what they're looking for in the index. I really think these features will add value to LabVIEW.

An interesting side effect of this process is that we get mini-tutorials in project management. We propose the feature, figure out how to (and who will) implement it, delegate tasks, manage resources and deadlines, and see everything through to completion. This is the norm for a developer or project manager, for but a technical writer? It's pretty cool. At least it is to me :-)

Sure, we might not impact a customer's life as much as if the developers decide to add a new ODE solver or signal window to the palette. But I can point to a particular feature and say "I thought of that and made it happen in reality."

A lot of software developers I know (both here and elsewhere) have expressed interest in designing/coding video games. In fact, that's originally why I entered college as a Comp Sci major. As a parallel, I wonder if any technical writers secretly dream of writing strategy guides.