It's Been Awhile ...

...but I wanted to link to two posts I saw on the User Advocacy blog:

Technical Writing in Transition: Part 1 and Part 2.

Makes for some interesting reading, I think.

Quote:

Technical writing has adapted with three fundamental changes:

1. Task-oriented writing. Instead of describing the parts of a system, we walk the user through tasks and explain technical knowledge incidentally.
2. Single-sourcing. Write-once, read many; we write in small blobs which can be reorganized for online help, web help, printed manuals or marketing.
3. Plain English/Simplified text. We describe the interface, not theory, using code-like patterns of if-then language and action sequences.

And this:

...to a public increasingly acquainted with the similarities between computer-based tasks, [writing a fantastic manual] does not provide the depth of information they need, so instead they buy third-party "power user" books to fill that need.

...

When the basics of technology are known, it is easier and cheaper to have an engineer type up notes and hire a college student to format them.

I can see how this statement applies to consumer electronics like digital cameras, MP3 players, etc. Those are situations where "the basics of technology are known." Has anyone looked at the user manual for their iPod?

However, I don't think this statement applies to LabVIEW, where the basics are not known -- except to those who've been using it for years, and even then, those people still get some surprises now and then.

So that's the key phrase -- "when the basics of technology are known." That is not always the case, especially not at a company like NI. You could argue that the "basic" of LabVIEW is dataflow programming (and possibly graphical programming also). Everything on top of that is LabVIEW-specific and needs to be explained in detail in our help system. And given that we fight for dataflow attention in a sequential world, I would say that we still need to teach people the basics of dataflow in our manuals (which we do). And that can get complicated pretty quickly.

Extend now to products like the Control Design and Simulation Module. Here the "basics" become control theory, dynamic systems, etc. These topics are the subject of graduate- and doctorate- level courses and degrees. While you could ask the engineers to educate users on these topics - with formatting assistance from a college student - the results would be geared towards graduate- and doctorate- level customers, which is not necessarily our audience. Plus, it's a well-known fact that many engineers either dislike writing or don't care that they're not good at it :-)

LV's also more complex than many software programs because it's not really a program - it's a programming language. Covering the limitless ways in which you can use LabVIEW is a, well, limitless task :-)

It's like if I were to document a toolbox full of wrenches, screwdrivers, drill bits, and such. I can tell you the purpose for each tool, what types of situations each tool are good for, and maybe give you some high-level examples. But I can't go specifically into how to use the wrench with a car, sink, light fixture, two-story house, lawnmower, etc. That would take way too much time and way too many resources, especially when you realize that I'd have to describe how every tool works with every task. But here also the manual would be incomplete, because how can I know what tasks you're going to use these tools for? Maybe you like building birdhouses, but we don't talk about that because we don't have a birdhouse expert on staff. So then you're still out of luck with just our user manual.

No, the specifics are things you have to learn by taking the groundwork in the manual and applying it to your project. Or, like the quote says, you might go out and buy a book on fixing cars, or even more niche, Using Wrenches with Cars. That's where companies like O'Reilly and Wiley come in. That's also where customers, blogs, and user forums and communities help fill in the gaps. We constantly monitor these sources of information, looking for real-world problems and successes that we can include in the documentation. By "we" I mean not only technical writers, but also engineers, salespeople, marketing, etc.

(As a side note, I think we do a great job of covering LV-based tasks in our help files. We make sure to include tons of how-to content in our docs.)

I'm sure the author of those posts didn't intend to mean that all technical writing is basic and therefore we can just outsource everything to college interns. But I thought a counter-example would be useful and informative.

Beatboxing with LV FPGA and PXI

File this one under "Coolest Things I've Ever Seen." Vineet samples himself beatboxing and singing. He can do this multiple times until he is giving himself a full backing melody.

His mic is hooked into a PXI-7831R running LabVIEW FPGA. The performance is from the NI Live Talent Show we have once a year; this one was on July 12 2007.

Watch this one to see Vineet turn it up a notch!

Try doing that with an oscilloscope!

NIWeek 2007

NIWeek 2007 starts next Tuesday, August 7th at the Austin Convention Center! This year, instead of simply attending, I'm giving a presentation! Here's the info:

Date / Time: Wednesday August 8th, 3:30 PM. Room 16A.
Title: Documentation Dividends: Help that Pays Off
Abstract: Well-planned product documentation can save time, reduce customer frustration, and improve your product’s reputation. Discover how LabVIEW can help you create and deliver effective documentation. Also learn tips from NI technical writers about optimizing the documentation process and getting the most out of documentation on LabVIEW.

Come learn how documentation can improve your product. We'll also discuss tips for planning and creating documentation and the different ways in which you can deliver documentation.

I invite you all to attend, and if you have any questions or comments for me, I'll be happy to answer them at the session.

Source Code Control for Documentation

Jim Kring and Joel Sumner have posted recently about the benefits of source code control (SCC) for software development. At NI, the technical writers also use SCC for our documentation development. For those who are unfamiliar with SCC, it works like this:

• Your source files are stored in a repository on a central server.
• To edit a source file, you must "check out" the file. Checking out a file downloads a copy to your computer, where you then make your edits. Typically, checked-out files are marked as such so others cannot check them out at the same time.
  

(You can configure some SCC programs to allow multiple checked-out copies simultaneously. The SCC program then can merge multiple changes back into a single file. I tend to distrust this method; I much prefer the security of knowing I'm the only one with the file checked out for editing.)

• When you are done making edits, you check the file back in, which involves uploading it back into the central repository. Others can then synchronize to the latest version of the file that contains your edits, check out the file themselves, and repeat the process.
  

SCC for documentation, at least the way we do it at NI, has many benefits that parallel what Jim and Joel describe for software.

• Because only one person can check out a file at a time, SCC ensures you don't overwrite ("blap") edits that someone else made. This benefit mainly is for larger groups of writers that all work on the same source material, like in LabVIEW.
• Because the most recent copy of the file is stored in a central location, everyone knows where to go to get the freshest copy of all necessary files. Again, this benefit mainly applies to groups of technical writers.
  
• Ensuring you have the latest version of a file is as simple as right-clicking a file and selecting Sync to latest revision.
• SCC allows you rewind time back to when a file was good. If you check a file in and suddenly the XML won't transform or the HTML looks wonky, you can synchronize to a previous revision of the document when you know everything was good. The SCC program can handle this revision history automatically, so you don't need to spend time renaming files, copying files to different directories, or marking files as read-only.
  
• Some SCC programs feature an integrated tool for differentiating ("diffing") between versions of files. With the click of a button you can highlight differences between the document you're editing and what's stored on the server. This tool is really powerful for documentation because you can see exactly what changes someone else might have made to your document. (Or, if you're a lone writer, what changes you made to your document!) Because the changes are highlighted onscreen, you're not distracted by unchanged text.
  

For this to work, the file must be stored as text (XML, HTML, etc.) and not binary (FrameMaker, MS Word, etc).

• SCC allows you to annotate the changes you made every time you check in a file. These annotations can be as simple as "Fixed some typos," but more descriptive annotations are even more helpful. By clicking "Revision history" in Perforce, the SCC program NI uses, I can see who's done what to the file. Some file histories extend back to 2001 and provide a rich timeline of the file's evolution over time. This benefit helps not only large groups of writers, but even lone writers who want a quick record of what they've changed and when.

I find that the only drawback with SCC is the overhead of editing a single file, which involves the following steps:

1. Launching Perforce. (Actually, I usually keep it running.)
2. Navigating to the file's place in the repository. (This can be slightly time-consuming if the server is being slow, the file is located on a different server, or if the file is buried in a deep directory structure.)
3. Checking out the file.
4. Launching the program to edit the file.
5. Editing the file.
6. Saving the file.
7. Using Perforce to annotate the changes you've made.
8. Submitting the file.

Without Perforce, only the opening/editing/saving steps apply. But you then would lose the benefits of knowing that these changes are permanent, trackable, and eraseable. These benefits are essential in a mid-to-large size organization like NI.

Also, it can get confusing if you sync to a file and then delete it by using Windows Explorer. In this situation, the SCC program still thinks you have the latest copy of the file, so you have to remember to force the program to actually download the file again. But this is really more of a "user error" issue, although it crops up for me frequently as I install and uninstall various development versions of LabVIEW on my computer.

For those of you who want to give SCC a try without spending a dime, check out subversion or the Perforce evaluation.

Documentation is Important

Even our developers think so :-)

What We Do All Day, Part 2

Interested in working as a technical writer but don't know what it is that we do? Our Texas Tech recruiting team gathered some alumni and put together an informative video that consists of interviews with technical writers and managers here at NI. The video also has some great tips for those who are applying for technical writing jobs. Top tip: Proofread your resume! :-)

Split over Splits

At NI we have a company-wide style guide. One of the weirdest things about it, and something which I've had the most trouble getting used to, is the guideline against splitting verbs.

Before I came to NI, I'd write a sentence like this:

You can also double-click the Add function.

But now I write like this:

You also can double-click the Add function.

Also:

You must manually specify the value.

Becomes:

You must specify the value manually.

See the differences? I had no idea that people wrote things like "also can" until I started at NI. And I disagree with the way it sounds and looks. (At least, for the first example. I can understand the way we rewrite the second one.) But since then I've noticed many other publications, such as the ESPN Magazine, do the same thing. I guess my brain had skipped over this construction before, but now that I actually have to write this way, I notice it more.

When I had the chance to write the documentation for MATRIXx 8.0, I decided against using this guideline. I just think it looks/sounds weird. But when I switched back to LabVIEW-based products, I had to ease back into using this construction again. Every time I start writing "can also," it's like I have to flip my brain around. I'm getting used to it again. I still think it looks weird and don't like using it. But now that I've seen other places use it, maybe I don't mind it so much.

I know some people don't care about verb-splitting, but others really enforce the "rule" against it. Our company-wide style guide is a communal effort that involves input from all the technical writing product groups. At least one time that I know of, we've voted to remove the restriction on splitting verbs. But even though the company style guide might say this, the product-specific style guide (which is our first point of reference) might disagree. Even if that isn't the case, your manager who reviews your content might not want the verbs split.

Anyway, just some random commentary on something that I find odd :-)

The LabVIEW Documentation that Anyone Can Edit

I don't know how I missed this, and I apologize for not posting it sooner! For those of you who are familiar with wikis, the LAVA (LabVIEW Advanced Virtual Architects) group has a wiki for LabVIEW. I encourage you all to go and contribute your knowledge to this compendium. Communication among customers about LabVIEW always is a good thing. It will be interesting to see how this wiki compares to and/or augments the documentation produced just around the corner from me at NI :-)

It's an interesting idea for official NI documentation, too. For example, see the MSDN wiki that I posted about a year ago. It's good to see this kind of thing spring up organically among customers.

Improving the Readability of Text Online

A company called Walker Reading Technologies has produced research showing that the human brain is not "wired" to read text in the traditional way we print it, which is in blocks. In short, we're constantly filtering out text that surrounds what we're trying to actually read. This filtering impedes our comprehension of the material.

Supposedly, the optimal format is a series of "short, cascading phrases" that look really odd but are easier for the human brain to comprehend. Of course, Walker Research makes a product that reformats text in this manner automatically :-) Apparently the company has improved some test scores by simply putting tests in this new format. A major textbook publisher also has contracted Walker Research for help with online textbooks.

I'm skeptical about company-conducted research that conveniently provides an excuse for purchasing a product from the same company. But the theory is still interesting. NI does a lot of documentation "online," meaning shipped as HTML. And the very essence of our jobs depends on readers comprehending the material. Maybe this new theory means we'll someday

be writing documentation

like this?

Edit: A link to the ensuing Slashdot discussion.

A Guide to LabVIEW Documentation, Part 1

As part of a great effort between our technical writers and the SW developers, LabVIEW has multiple entries into the LabVIEW Help. The LabVIEW Help itself is huge, which is mostly a function (hah!) of the number of things you can do with LabVIEW. Additionally, because many LabVIEW customers use the product to make other products, we have to account for a lot of use cases, generalities, and assumptions about what people actually do with LabVIEW. (That's why we try as much as possible to get feedback from users, but that's an issue for another post entirely.)

In this next series of posts, I'm going to cover the various ways in which you can access the LabVIEW Help from inside and outside the software itself. Here's the most general way.

Start>>All Programs>>National Instruments>>Labview xx: Going here shows you three useful entries: LabVIEW Help, LabVIEW Manuals, and Readme. The first link opens lvhelp.chm, which is located in the labview\help\ directory. ( where labview is the directory to which you installed LV.)

This help file is the gateway to just about anything you could want to find in the LabVIEW Help. Starting with LabVIEW 8, the technical writers made a decision to stop splitting content into PDF and HTML source. We decided to make (nearly) every topic available from within the HTML-based LabVIEW Help. We kept a couple of PDF and printed manuals, but who knows how long those will last? (The switching process itself was large, complex, and often painful. Maybe that's a subject for another post.)

The LabVIEW Help is modular and extensible. We use Microsoft's HTMLHelp framework (and FAR to do all the work of compiling and managing settings). Every time you install a LabVIEW add-on, such as the LabVIEW Real-Time Module or the LabVIEW Simulation Interface Toolkit, another book (or, more likely, several books) appears in the LabVIEW Help's table of contents. So whether you're looking for help on an FPGA topic or for information about the Control Design Construct State-Space Model VI, the LabVIEW help is your one-stop shop.

In fact, the lvhelp.chm file itself is mostly a reference to other install .chm files. For example, in the labview\help\ directory, glang.chm contains most of the VI & function reference information. glang = G Language, get it? :-)

lvhelp.chm "includes" both of these files (and many more), so the lvhelp.chm file itself contains very little content -- mostly just the legal and high-level organization topics.

The second link takes you to the labview\manuals\ directory. If LabVIEW or an add-on installs PDF manuals, those manuals will show up in this directory. Because of the aforementioned shift to HTML-based documentation, not too many add-ons use this folder. LabVIEW itself does, and two of my products (the Control Design Toolkit and the PID Control Toolkit) still install PDF manuals here. But products like RT and FPGA produce almost no PDF documentation anymore.

PDFs come and go all the time. For example, in the Simulation Module 2.0 release, we shipped a PDF manual. For the subsequent release, Simulation Module 8.20 (the version number jumped up to be consistent with LabVIEW's), I converted the PDF into HTML (like magic!). Some other groups in NI are doing the reverse; going from HTML documentation to PDF and/or printed documentation. It's all based on what works best for the customer.

The third link is to the labview\readme\ folder. I'm pretty sure that all LV add-ons install readme.html files, and these files get placed into this folder. (Of course the files are all named differently so they don't overwrite one another.) Readmes typically contain installation instructions (because the readmes are visible on the top level of the installation CD), information about new features, bug fixes from previous versions, last-minute documentation updates, and known issues with the current version. However, the presence or absence of this information differs from product to product, even among LabVIEW and its add-ons. In addition, some developers prefer to write their own readmes, whereas some prefer to hand off the readmes to us technical writers.

Horn Tooting

I opened my inbox this morning and found an email from my dad. He congratulated me because NI made FORTUNE magazine's "Top 100 Companies to Work For" list for the 8th consecutive year. I seem to remember that last year we were higher in the rankings, but being in the list is a good thing all by itself. It would have been neat to have been able to participate in the employee survey, but it's randomly distributed. I know people who have been here 10+ years who haven't ever been contacted.

Austin-based Whole Foods ranked #5. Go Austin!!!

Another funny tidbit is that Texas Instruments (TI), the company for whom NI is most often mistaken (don't worry, I did it too), is listed right below us.

Who is #1? Of course, that spot belongs to the six-million-dollar-a-share GOOG. I have to say though that free spa treatments would not necessarily attract me to a company. Free meals, however, are a different story :-)

NI-TC 2006

Every year at NI, we have an internal conference for all the employees in the Technical Communications department. This conference, conveniently enough called NI-TC (for NI-Tech Comm) is in late October and lasts for two days. It's a time for us to bring everyone up to speed on what's going on the department. We have multiple presentations/seminars, a demo fair that showcases the neat products we work on, and (of course) a deck party with food, drink, and music. This year we had some cameras floating around, so I wanted to share the event with you...

Breakfast on Day 1 consisted of bagels, cream cheese, and a big fruit tray. Oh, and coffee of course! Breakfast on Day 2 was a plethora of breakfast tacos. Mmmm.



A group of us getting ready for the first presentation in the morning.

This year, we all voted on superlative awards, like "Most Likely to Build a VI for Home Use" and "Most Likely to Out-Nerd an Engineer." Yeah, it's dorky, but it's fun :-) Here we see Nick distributing a prize pinwheel to Kyle while Kip looks on.



Another group of us between presentations.



Colin (r) and me about to give our presentation. Colin's in marketing, so he's no stranger to a suit. But me being in R&D, well, let's just say I wear suits for only family occasions :-) But when you're presenting to a team of co-workers, it never hurts to look snappy, right? I thought it would be funny, given that I dress so casually all the time. Some people got the joke, but some didn't. In R&D, you wear a suit only when you interview!



Some of us watching a presentation on how Windows Vista's online help is different from XP's.



This is the demo fair, and we have Mark demonstrating the NI Vision Builder for Automated Inspection.



Again at the demo fair. Bradley gives us a hands-on sneak peek at Windows Vista.



Okay, the learning is over and it's time for the deck party!



One of our tech writers (Robert, on the left with the bass) plays in a local band called The Hackles. They graced our deck party and played some good ol' country music for us.

What We Do All Day

6-7 years ago, NI created a website, in partnership with Texas Tech University, that walks you through A Week in the Life of a Technical Communicator. Because the design is so 90s, and because the "star" of the web site is no longer with NI, in January 2006 a group of writers decided to update the site with a more "modern" look. (Wow, that's a lot of quotes here.)

The result is a new-and-improved A Week in the Life of a Technical Writer (notice the title change) web site. The goal of this site is to explain what we do all day. We have two audiences in mind: 1) prospective employees and 2) students who are unaware of what technical writing is - or at least what we say it is, because the job title can mean many things depending on where you work.

Creating the site was an interesting exercise in collaboration and group work. It took us longer than we'd anticipated to decide who to "feature" on the site, come up with a design, write the content, decide on the page navigation, and so on. We unveiled the site on Sept 8th, 2006, after nine months of planning and implementation. Some of the group members are currently writing an article for the STC's Intercom magazine based on the effort.

Anyway, check it out!

Guest Appearance on the VI Road Show

Every Halloween, the LabVIEW team sets up various demos of our products for other members of the company. This year, the VI Road Show invaded and caught some of what went on. The following video shows Varun, myself, and Alex discussing and demonstrating the LabVIEW Simulation Module. Beware the horrible scrolling CRT monitors!

P.S: I feel I should explain my bloody face :-) My costume this year was Ash from Army of Darkness.

Not an Engineer

I was re-reading the post about April's interview in the Statesman, and the last sentence stuck out at me:

...the fact that she is not a programmer or engineer serves her well as a tech writer.

This phrase is very true. I said the very same thing to a class of students at UTSA last fall, and I find myself thinking it at the career fairs I've been to recently. Many job applicants hear "technical writer," or sees what NI does, and think "I'm not a programmer" or "I'm not an engineer." To these students, I say, good.

We need more non-engineers and non-programmers looking at our products: testing them, writing about them, and polishing them via documentation or other means. We need creative people with non-technical backgrounds to push back on the developers and say "This isn't designed well" or "If I can't understand it, how will a customer?" After all, just because we're a tech company, that doesn't mean all our customers are technology oriented. Engineers and programmers are trained a certain way, which doesn't always include ease of use or user-friendliness. That's (part of) our job. So in these cases, being a non-techie is very beneficial.

So we don't need, or sometimes even want, you to be tech-savvy when applying for the open technical writer positions we have (hint, hint). When we're interviewing or looking at resumes, what we are looking for is that you are interested in technology or are curious or passionate about it. We don't need you to come in and start writing C++ immediately - that's for the programmers.

We do, however, expect you to come in and start writing English immediately :-)

The VI Road Show

Welcome the newest NI Blog member - the VI Road Show. This is actually a vlog (video blog) that will take you around the country (and possibly world) as the owners showcase NI's employees and customers.

Interview w/April Brinkmeyer

The Austin American-Statesman recently interviewed a co-worker of mine, April Brinkmeyer. She is a technical writer for the LabVIEW core product. Here's a snippet:

Writing, reviewing, updating and improving the program's extensive help documentation in-program, in print and online is an on-going project for Brinkmeyer and the others on the documentation team. She also sits on committees that are tasked with improving help systems across the board and ensuring consistency. Though Brinkmeyer went through an intensive training program and had to learn several new applications, the fact that she is not a programmer or engineer serves her well as a tech writer.

UI, Documentation, and Polish

I'm not sure how it is at other places, but part of being a technical writer at NI is dealing with usability. We are often the first non-engineers/non-developers to see a feature in action. We come across many malformed and confusing dialog boxes, interface widgets, organizational structures, and so on. In LabVIEW we have a great usability advocate in Christina Rogers, who recently made a post about usability and UI. She's also documented many of the UI issues and standards that developers should take into consideration when implementing a feature. Having been present at numerous discussions of "What should this dialog box look like?" I certainly appreciate her work and guidance! She also serves as the arbiter on many UI issues, like, "Should this dialog box button say Close, Finish, or Exit?" It sounds like a trivial question, but as Christina can tell you, issues like these can profoundly affect the user experience and perception of our product.

I bring all this up because of a recent post on Ars Technica about Microsoft's last-minute polish of the Vista UI. Look at the two shots of the dialog box side by side. The Change button is now Rename. The Network ID button is now Join. The text accompanying each button has also been simplified. These are the kinds of changes that we, as technical writers at NI, deal with and have influence over.

(On a side note, you'll notice that I bold the name of buttons you click on -- this is a side effect of writing with NI's company style guide in mind for so long!)

The post about Vista relates to NI in so many ways. Like Windows, LabVIEW is NI's flagship product, the one with the most visibility. Obviously LV is not as big (in market dollars or in lines of code) as Vista, but still. The article's point about last-minute bugs being expensive to fix is a valid one. We have to deal with all those bullet points too, except for the Accessibility one. This is why technical writers are so important in catching/addressing usability issues as early as possible -- the earlier we file a request to change a UI, the less money it costs to fix the issue. At crunch time you have so many people doing so many different things that issues like these often get neglected or deferred in favor of more "Showstopper" issues. Not to mention the overall added stress on the developers during crunch time.

My point is this: an ounce of prevention is worth a pound of cure, right? This is what I tell myself when I file a bug report to a developer over a trivial little issue, like a radio button that should be a checkbox, or a text box that is too short, or a dialog box title bar that doesn't make any sense. This is also what I tell myself when I recompile a .CHM file to rearrange the words in a single sentence, fix one misspelled word, or resize a single image. All these little issues add up to a more professional product that I'm proud of being involved with.

Along the same lines ...

Last month I attended the Austin Game Conference, in which Blizzard VP of Game Design Rob Pardo spoke about Blizzard's legendary "polish," or the overall impression that you're using a well-developed professional product. He said that polish is not something you can just add at the last minute, or even at the last month. It has to be built into the software plan from the beginning. He also said that polish is not just one single thing, like the speed of World of Warcraft's mouse cursor or the shading on the menu bars. Polish is a combination of thousands of little decisions that all get implemented during the development cycle.

This part of his speech stuck with me, because it reminded me of what we tell developers when we hassle them about UI and documentation issues. Sure, in the grand scheme of LabVIEW, nobody cares if a button is labeled Close, Finish, or Exit. They all do the same thing, right? But if we can guide the user on the path they want to take, or anticipate their move and help them make it through intuitive UI design, that adds to the polish. Same with the documentation. No one's going to not buy LabVIEW if we misspell a word in the help. Along the same lines, we've shipped versions of LV that don't include any help for a given feature. I highly doubt that this situation affected sales.

But high-quality UI and documentation adds to the overall presentation of the product and helps users complete their tasks. All the hundreds of little things add up to make LabVIEW a more professional, usable, and complete product.

Bloggers vs. High Schoolers in Writing Competition

/. has a bit this morning about bloggers competing with high schoolers on the SAT essay. If you like, you can even rate the bloggers' submissions yourself!

Here's the essay question, timed at 20 minutes:

Directions: Think carefully about the issue presented in the following excerpt and the assignment below.

I have learned that success is to be measured not so much by the position that one has reached in life as by the obstacles which he has overcome while trying to succeed.'

-- Booker T. Washington

Assignment: What is your opinion on the idea that struggle is a more important measure of success than accomplishment? Plan and write an essay in which you develop your point of view on this issue. Support your position with reasoning and examples taken from your reading, studies, experience, or observations.

Interviewing

Since the day I started at NI, I knew I wanted to be involved in recruiting technical writers. We have a dedicated HR department at NI, but the people you see at career fairs are regular full-time employees. I like this method much better than having recruiters represent us, because I know more about technical writing at NI than the HR people do. Therefore, when students come up to me or I give a presentation, I can answer questions more effectively than someone in HR can. (It's not a "better" skillset, it's just a different one.)

So if you're at a career fair and see an NI booth, you'll likely be speaking with people who actually do the job you're talking about. Sometimes it's a strain on us, because we have actual projects to be working on, and it'd free up a lot of our time if we didn't have to be involved in recruiting. But the end result is worth it. I think our candidates and new employees are of a much higher caliber than they'd be if we didn't see them at all during the interview process.

Last year I did a couple class presentations and visits at UT San Antonio. I also wanted to go to Virginia Tech, but haven't been able to yet. So now I'm one of the three school sponsors for UT Austin. I'm in charge of maintaing our post on AccessUT, which is the job portal from Career Services. I also review resumes, interview candidates in our first round of interviews (there are two rounds), schedule and host candidates for "onsite" interviews (the second round), and pretty soon I'll be at UT's various career fairs for Business, Liberal Arts, and Communications schools.

I like the idea of contributing to NI in a sense other than documentation; recruiting is an additional skillset that makes me a valuable employee. I like meeting and interacting with people, especially new college graduates, which is where we focus the majority of our recruiting efforts. It also helps that I genuinely enjoy NI and my job, so I'm not faking it when I pitch the company to people!

Maybe sometime soon I'll post about what we look for in tech writers, resume tips, interviewing tips, and things like that.