Typical Day
Jane McScribbles still isn't used to the idea of having her very own desk in her very own cubicle. She's been employed as the technical writer for Really Smart Software for three months, and the only things marking her workspace as hers are the technical writing reference books, her battered copy of The Elements of Style, and some white papers about the oil and gas industry.
She swears to herself that she'll bring her peace lily in tomorrow morning, although she'll probably forget.
Jane drops her laptop on her desk and scurries across the open office to the conference room, where she sits down with her cup of coffee. Most of the company's other forty employees are already in the room, ready to give their twenty-second rundown on what they'll be doing today.
The 9:00AM meeting is a holdover from the days when RSS was naught but a wee startup with fifteen employees. The company has grown by leaps and bounds over the last year, however, and Jane has a couple of suggestions for making the morning meeting more efficient (or eliminating it altogether) that she'd like to bring up once she's more established in her new role.
The CEO steps inside the conference room promptly at 9:00AM. He briefly outlines his tasks for the day. Then, everyone in the room takes their turn. Then, the three guys working remotely from places like Indiana and Chicago and New York City take theirs. The meeting breaks, and Jane finds herself back at her desk, ready to get to work.
Really Smart Software currently has one customer: a company that owns and operates one of the largest natural gas pipelines in the country. Almost a decade ago, RSS wrote the software that now runs all of the pipeline's commercial operations.
Unfortunately, when the software was written, no one bothered to do any documentation on the code. Now, the pipeline is buying RSS' software so RSS can move on to other projects, but there's nothing to tell the service team at the pipeline how RSS' code works.
This is where Jane comes in. She's been tasked with writing thirty different documents that will cover everything from the code's infrastructure design to business processes to human support processes. If RSS was still a small company, one or two of its developers would've been assigned to write the documentation. However, with all the other projects RSS is working on, its developers are far too busy to do any technical writing. This is why Jane was hired three months ago.
Jane pulls up the document she was writing yesterday and gets to work. This particular piece is about the source code's infrastructure and is relatively easy to write; all she has to do when she has a question is reference the code itself. The developers who worked on this particular section of the code are also still employed at RSS, and she can go to them with any really thorny problems.
Once this document is finished, it will be sent over to the pipeline's service team for review. The team will come back to Jane with either an "A-OK" or a list of questions and/or revisions—in all likelihood, she'll have to revise the document several times. Jane also still has a couple of diagrams she needs to create for the document, although those shouldn't be too hard.
Jane types away until 11:30AM, when she gathers up her laptop, a notebook, and a pencil and heads to the conference room for a lunch meeting with three of RSS' senior developers. The developers spend an hour-and-a-half going over in-depth information Jane will need for the two documents she'll be producing next.
In the afternoon, Jane finishes up her infrastructure document and the diagrams that go along with it. She forwards the piece to her supervisor, who looks it over before sending it on to the pipeline's service team. Jane then dives into producing a very rough draft of her next document.
While she's definitely gotten a crash course on the pipeline's commercial software over the last three months and now knows quite a bit about it, there are still processes she's not very familiar with. This is especially true for those processes that were built by people who are no longer with RSS.
At 5:30PM, Jane stops writing, her brain exhausted. She spends the next thirty minutes organizing her things for tomorrow. She feels really good about her job with RSS: she likes her nine-to-six schedule, she likes learning about the pipeline's commercial software, and she really likes that she's ahead on producing the documentation for the pipeline's service team.
Jane never planned on becoming a technical writer. In fact, her undergraduate degree is in computer science. However, when she went to work as a junior developer for an enormous software development company with a branch in Austin, Jane discovered that she's really good at writing about how software works. She ended up doing more and more technical writing at her job, until she felt she had enough experience to look for a straight-up technical writing gig. That was how she came to RSS.
Once Jane is finished with the documentation for the pipeline's commercial software, she'll move on to writing patents. Over the years, RSS' developers have come up with a variety of ideas and processes, but no patents have ever been filed. Jane is looking forward to this new challenge, and to working directly with RSS' CEO and attorney on the patents.