Robert, Author at High-Tech Writing and Engineering

Train travel are an alternative to flying for professionals in the Pacific Northwest, using the Amtrak Cascade route between Eugene, OR and Vancouver B.C. Because the delays associated with airport security don’t happen with trains, the total trip time is not much less traveling by air, and the train provides a much better working environment for business travel. Amtrak trains offers a convenient alternative to flying and long-haul driving even to people like me who live in the country.

For eight months, I commuted two days a week to a client’s site 122 miles away from my office. I live in Blodgett, Oregon, a small town in Oregon’s Coast Range, not far from Corvallis and Oregon State University. My client was a semiconductor firm just over the border in Camas, Washington.

For me, this was something of a luxury. Most of my clients are in Silicon Valley and are so overworked that they actually don’t want to see me more than absolutely necessary. They meet with me, on average, once or twice per project, and we keep in touch mostly by email. This gives them the maximum amount of control over their time. I am an electrical engineer by training (one of only a handful in the writing business), and I don’t need much support to get the job done.

But this client was only 122 miles away and actually wanted to see me a couple of days a week. This frequent contact tends to result in a faster and better document, but with a much larger investment of the client’s time.

I drove the 244-mile round-trip two days a week in June and July. It was very wearing, especially on the return trip. I started giving thought to riding the train.

The Amtrak Cascades are high-class commuter trains, with good seats, AC power in every row, and a Bistro car with an excellent menu, as these things go. The fares cost less than the standard mileage rate.

The basic problem with the Amtrak commute was this: I could drive to the station closest to my home (Albany) and get on the train. No problem. There was plenty of free parking. But what about the other end? The closest station to Camas was at Vancouver, Washington, which was a twenty-minute drive to my client’s site.

I was mulling this over when it dawned on me that Vancouver, too, had free parking. Why not keep an old car in the station parking lot and use it to shuttle between the station and my client? I even had an old car I wasn’t using for anything; my trusty VW Rabbit, which I’ve had since the Carter administration. I asked at the Vancouver station, and the station staff had no objection. There was plenty of free parking, and there had been no trouble with vandalism. With a Burlington Northern and Santa Fe depot right next to the Amtrak station, I figured that railroad people would be coming and going at all hours, and even vandals are probably smart enough to avoid confrontations with railroad workers.

So I was looking at a drive from my farm in the Coast range to the Albany station, a train ride to Vancouver, and another drive from Vancouver to Camas. Was it practical? Was it an advantage? Here is how a commute looked before and after the switch to the train:

Before

5:30 AM	Get in the car and hit the road
8:00 AM	Arrive at the client’s site
5:00 PM	Leave the client’s site (bill 8.5 hours of work)
8:00 PM	Arrive at home.

After

5:30 AM	Get in the car and hit the road
6:28 AM	Board the train at the Albany station
9:07 AM	Get off the train at the Vancouver station (bill 2.5 hours of work)
9:08 AM	Get in my second car
9:30 AM	Arrive at the client’s site
4:00 PM	Leave the client’s site (bill 6 hours of work)
7:15 PM	Get off the train at the Albany station (bill up to 2.5 hour of work)
8:00 PM	Arrive at home

As you can see, the total time away from home was the same (a very long day) in both cases. The important differences were twofold:

If I felt tired, I could relax, close my eyes, or even sleep on the train, which I couldn’t do when driving. When driving, I always arrived home exhausted. When taking the train, I was in much better
If I didn’t feel tired, I could work up to five hours on the train, stretching my working day to 11 hours. When driving, the maximum was eight hours.

On an average day, I worked straight through in the morning, but didn’t work on the return trip at all, but took it easy. But the extra time was there when I needed it. Even an hour spent working on the trip home helped put me on top of my workload.

Work Environment

What kind of work environment does the train provide? I was surprised at how easy it was to get work done on the train. There aren’t a whole lot of distractions. The movement of the train makes your handwriting shaky, but it doesn’t interfere much with using a laptop computer. I have drawn intricate diagrams using my laptop while traveling over bumpy stretches of track. It slows you down some, but not much.

The seats and tray tables are much larger than on airliners, and there’s more leg room. The crew encourages you to work in the dining car if it isn’t crammed wall to wall with diners. And you can always get up, stretch your legs, or have a snack on the train. All in all, I find an hour on the train is much more productive than an hour on an airplane, and you don’t have to go through security or arrive early the way you do when flying.

Cell phone reception is pretty good, too, but I rarely used the phone while on the train. As a writer, one of my biggest obstacles to success lies in coming up with large blocks of ininterrupted work time, and I used my time on the train to get things sorted out and written down. Other riders often made one phone call after another on the train.

Fellow passengers were usually quite friendly and were understanding if I wanted to keep my head down and plow through work instead of talking to them. The trains are rarely full south of Portland, though they are frequently full between Portland and Seattle. The upshot was that I could always use the seat next to me, and its tray, between Albany and Portland.

Schedule

The trains sometimes run late. My experience was that the morning run was almost always on time, and often arrived a few minutes early in Vancouver. The evening return trip almost always arrived in Albany between 15 and 45 minutes late. The people who were most upset by the erratic arrival times of the evening trip were those who were being met at the station. They would have to get on their cell phones and give updates to the long-suffering friends and relations who were going to pick them up. Since I was driving my own car, this was not a problem for me.

The train is much more likely to be on time in Washington than Oregon. In Washington, the tracks are owned by BNSF (Burlington Northern & Santa Fe), which has a good relationship with Amtrak. Their dispatchers whisk the train along as briskly as they can. In Oregon, the tracks are owned by the Southern Pacific, which is apparently engaged in a permanent feud with Amtrak. The train will spend random amounts of time on sidings to allow slow freights to lumber by.

Movies

There are several TVs mounted near the ceiling in each car, and each seat has a headphone jack so you can listen to it. If you take a full round-trip between Eugene and Seattle, you will see four movies: one between Eugene and Portland, one between Portland and Seattle, and two more on the return trip. What kind of movie is shown seems to vary randomly over time. It could be anything from the latest Tom Clancy thriller to black-and-white classics. Sometimes they change the movies weekly, sometimes monthly. Once they showed the Marx Brothers in “Duck Soup” on every trip for six weeks!

If you forget your headphones, you can buy a set in the Bistro car.

Costs

Tickets bought with a AAA discount varied from between about $25 and $40 (between Albany and Vancouver), depending on how many people got in ahead of me and bought up the cheaper seats. Various promotions are used, off and on, during the slower parts of the year. The best deals seem to be available over the Internet (http://www.amtrak.com/), as Amtrak is trying to shift people to this convenient booking mechanism.

Limits

I felt that the Albany-Vancouver run was about my limit for twice-a-week commuting, but I met one guy on the train who commuted between Eugene and Portland five days a week. He would step onto his morning train at 5:30 AM and step off his evening train at about 8:30 PM. That’s an awfully long day, but he seemed happy with it.

From the Albany station, I can reach Seattle after lunch and be on my way home in the early evening, spending roughly half a day at the client’s site. This gives me roughly the same schedule I have when I fly in for a whirlwind client visit to Silicon Valley.

Update, September 2005

I rode the Cascades again recently, and things are much the same. The Albany station has been remodeled, and the horrible gravel parking lot has been replaced by a nice paved one. The Oregon City platform is open, adding a much-needed station between Salem and Portland. Otherwise, it’s much the same and still very pleasant.

One thing that surprised me was that my tickets were cheaper than ever! But the train was unusually empty. The conductor reported that the train is usually full between Portland and Seattle, as it has always been, though it wasn’t that day.

Tips

Try the clam chowder.

The tables in the dining car don’t have AC outlets, so it’s hard to use a laptop there for long periods.

The back rows in some of the cars have only one seat. Taking this seat can guarantee you don’t have a neighbor. The row in front of you has two seats, so you get a second tray table you don’t have to share.

The tables on the seats are big enough for a laptop, but not a laptop and a mouse.

The train sometimes has its water system shut off while sitting in major stations (Portland, Eugene, Seattle), so if you’re in the bathroom and put sixteen pumps of liquid soap on your hands and discover there isn’t any water, don’t say you weren’t warned.

If kids going constantly back and forth and families yakking at each other drive you crazy, upgrade to business class for the extra calm. It’s only a few dollars more.

Be nice to the crew. They give back what they get. If you’re pleasant, they’re pleasant. The conductors are quick to remove belligerent passengers from the train at the next station.

For More Information

See the Amtrak Cascades Web Page at http://www.amtrakcascades.com

A Guide for Marketing and Engineering Managers

mouse_in_maze_with_cheese Having trouble getting documentation written? This guide is written for managers who are not technical writers, but who have been assigned the task of ensuring that documentation happens.

What Kind of Technical Writer?

First off, keep in mind that many technical writers are not writers at all! Some do nothing more than the desktop publishing and light copy-editing that you would expect from a secretary. This shades by imperceptible degrees through increasing levels of editing and rewriting until we reach the true writer, who writes the documentation from scratch, based on hands-on experience.

The more technical the specialty, the harder it is to find someone to write documentation from scratch. There just aren’t many writers with the necessary technical background. Most technical writers were liberal arts majors. Many are gifted writers, but no one can write clearly about a topic they do not understand, so their talents are not easy to bring to bear.

Technical topics can be learned, of course, and many writers are self-taught or have received training in the relevant topics. Support for this common-sense approach varies from company to company. In the short term, you’re stuck with what you’ve got (though as a manager, it’s your job to make the long term turn out the way you want it to).

Working With the Non-Technical Technical Writer

When the technical writer on your project cannot master the technical material being presented, the draft must be written by somebody else. This draft is vitally important, and the person it needs to be given the time and resources to do a good job. The technical writer will be able to clean up the draft, but without a deep understanding of the subject matter, there is a limit to what can be done, especially in the case of omissions. More than likely, no one will catch omissions unless the document is structured carefully at the start.

The technical writer should be involved in blocking out the documentation. Most technical documents have a fairly simple structure that can be settled upon without actually knowing the details of how anything works. For example, when doing chip or board documentation, I start by drawing a block diagram that shows the product from the customer’s point of view. The document then has one chapter per major block, plus an introductory chapter. Material that is not shown on the block diagram, such as instruction set descriptions, register descriptions, and AC/DC specifications, follow along after the one-chapter-per-block section. Procedural issues (installation, troubleshooting) don’t fit on the block diagram, either, but a flow chart of what the user has to do serves a second block diagram, which you treat in the same way as the first one.

There are other ways to do this. My point is that, while this is not rocket science, people manage to get it wrong anyway, by not attending to the fundamentals. Your technical writer ought to be of use here.

Ideally, the people in charge of the various sections of the draft should know what’s expected of them, down to an almost fill-in-the-blanks level. By this I mean that the headings, tables, and diagrams should have been roughly blocked out before writing begins. By breaking down the task in this way, the draft tends to go more smoothly, and fewer items are omitted. In addition, people who are not professional writers tend to be intimidated by writing projects, and breaking them down tends to reduce the fear factor. It also gives management a list of elements that the contributors can be held accountable for, so you don’t have to accept vague assurances that the draft is coming along fine. Bits and pieces will get knocked off the list if any real progress is being made.

The end-user should be kept in mind at all times. Everything in the document should help the reader to understand the product. Early in the writing cycle, it’s tempting to bloat up the document with junk copied verbatim from the technical specification or other readily copied sources, or to use meaningless repetition. This doesn’t help the end-user.

(If you must create a false sense of progress, I recommend that old standby, the bald-faced lie. While it sullies your reputation, it leaves the documentation intact.)

Working with the Technical Technical Writer

Highly technical writers should write their own drafts whenever possible. They tend to be more willing and less overworked than the engineers and marketers who would otherwise have to do it. Sometimes these technical writers have the skills to structure their documents with relatively little feedback from the group, and can get to work without the elaborate outlining described above. I rarely use outlining myself; just unstructured lists. But I’ve been doing this forever and can visualize the finished product clearly without such aids. But a detailed, structured outline is useful when there’s any doubt, to keep everyone on the same page.

It is easy to starve a technical writer for information. If anything interferes with the technical writer’s research, progress will slow dramatically. I have seen projects where the lead engineers’ time was considered so precious that the technical writers were expected to not talk to them at all. Instead, they were expected to be psychic, or reverse-engineer the product, or produce a work of fiction, or something. This always results in bad documentation, though it probably doesn’t matter very much—this level of mismanagement means that the project is doomed in any case.

Reviews

The technical writer will edit and, unless there is a separate layout department, lay out the document in its proper form. Both editing and layout always introduce new errors, so the result should be reviewed very carefully.

Reviews rarely appear on anyone’s schedule, and the most indispensable reviewers are the ones who are most overbooked, so they go through the document in a blinding rush. Of course, having employees who feel too rushed to do a good job is symptomatic of management problems: as a manager, you should work to fix this.

Documentation should be read slowly, and at least one person should check the math in all the examples and try all the examples and procedures. When reviewing, anything you have to read twice should probably be flagged; it probably needs to be reworded for greater clarity.

New hires and anyone else you can find who hasn’t read a given document before should be used as reviewers. Reading the entire documentation set from cover to cover is one of the quickest ways to bring a new team member up to speed, so it’s a win-win policy. Also, people who have reviewed a document before are reluctant to do it again, and even if they do, their familiarity with the old version means they miss things that a newcomer wouldn’t. This also means that no one is more blind to errors in a document than its author.

Reviews also introduce errors, especially in organizations where, in the case of disagreement, any reviewer outranks the author. Rather than empowering absolutely everyone to mess up the document, one person needs to be in charge.

Speed

I’ve done all kinds of writing, and technical writing is one of the slowest forms of writing, second only to poetry. In general, the more complex and difficult to understand the product is, the slower the writing. In engineer-to-engineer communication, it’s fairly standard to assume 1-2 finished pages per person-day. That is, a single writer would be expected to crank out 250-500 pages per year. With easier content, the pace can be greater.

My own rate is probably slower than this, because my writing is fairly terse, and I avoid unnecessary repetition. Sometimes I even achieve a valuable level of negative productivity. For example, on one project, when I was done cutting the redundancy and useless bloat from a document set, I’d reduced it by over 90%—from 5,700 pages to 560! As you can imagine, the increase in usability and maintainability was at least in proportion with this reduction in size. It went from something that no customer could read, and no employee could review, to something that could.

Author: Robert

Commuting by Train on the Amtrak Cascades