About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 30 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Google Ads

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

Always do right. This will gratify some people and astonish the rest.

— Mark Twain



Navigation





<September 2014>
SMTWTFS
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 7/23/2014

Totals
Posts - 2304
Comments - 2495
Hits - 1,658,724

Averages
Entries/day - 0.56
Comments/entry - 1.08
Hits/day - 406

Updated every 30 minutes. Last: 6:34 AM Pacific


  12:04 PM

I share an office with a fellow writer—let's call him Colleague B. We work on the same team, and thus we do joint planning and work and reporting. For example, every Monday afternoon we have a look at the upcoming week and plan our work. And on Fridays, we put together a joint status report that rolls up all the things we actually worked on.

The nature of our work, however, adds a certain chaos factor to our planning. On Mondays, we can certainly attempt to plan out what we need to do for the week. But every day—literally every day, and sometimes more than once a day—something new pops up. People send us email requesting a review of some documentation, or a developer will stick his head in the office and want input on some UI, or a bug will come in from a customer, or ... well, the possibilities are wide and varied, but there's always something.

Now, Colleague B is, by his free admission, a bit OCD. He is consistent and orderly both about our planning and our reporting, and he has that thing where he intuitively understands the delta between today and some upcoming date. Me, I'm a bit more on the other side, and my sense of time and dates is referred to around our household as "magical thinking."

Colleague B is not a big fan of the daily dose of chaos. Here we've planned out our week on Monday, and people keep coming in and asking for stuff. As he says, in his ideal world, people who have something for us would get in line, and we'll get to them when we're done with what we're working on.

On the other hand, I don't mind nearly as much the drop-what-you're-doing interruptions. I'm apparently happy to put aside the thing I'm working on in order to work on this new thing, or at least, till some other yet newer request comes in.

The world of computers has an analog for us: Colleague B is FIFO: first in, first out. Take a number, and we'll service you in order. In computing terms, FIFO describes a queue. Me, I'm LIFO: last in, first out. Like stacking trays in a cafeteria—the last on the stack is the first one off, and indeed, in computing terms, LIFO describes a stack.

Happily, it turns out that this combination of work styles works out well. Colleague B works his way through our Monday list, odds are good that by Friday, items can be checked off. But at the same time, we've handled a half dozen or so new jobs that came up during the week, things we had no idea about on Monday. In fact, Colleague B says that occasionally he'll finish up something and go read email, and by the time he's become aware of some new request, I've already handled it.

Of course, there's a certain amount of literary license here. It's not as if Colleague B won't handle ad-hoc queries with alacrity, and it's not as if I'm unable to handle anything other than whatever the most recent emergency is. Still, programmers know that sometimes the right data structure is a queue and sometimes it's a stack. As long as there are two of us, and as long as we divvy up the work correctly, we can handle pretty much all of it.

[categories]   ,

|


  09:50 AM

As has been discussed at great length over the years, English has no gender-neutral way to use a pronoun for a singular and sexed thing:

Everyone should bring [his|his or her] own lunch.

In previous eras, people didn't really blink at using the masculine generically:

To each his own.

... and some still maintain that this is fine, although the insistence that his in such contexts is gender-neutral is easily shown to be questionable:

A nurse is expected to provide his own stethoscope.

Anyway, vernacular English has solved this problem for centuries (like, at least as far back as Shakespeare) by using so-called singular they:

Everyone should bring their own lunch.

Still, as widely used as singular they has been, proscriptions on it have been strong for formal writing. Garner doesn't like it, tho he allows that they is sometimes the "most convenient solution" and that using the singular in some cases can result in "deranged" sentences, and, seemingly falling for the Recency Illusion, says that "they has increasingly moved toward singular senses," and "nothing that a grammarian says will change [these developments]."[1] Chicago [16] is pretty clear: "Although they and their have become common in informal usage [Recency Illusion again?--M], neither is considered acceptable in formal writing." Our own style guide at work: "Avoid using they or them to refer to a singular noun of indeterminate sex. You can usually accomplish this by changing the noun to a plural. In other cases, you can rewrite a sentence to avoid the need for a pronoun altogether."

This last indicates to me how strong the proscription is—rather than take the chance of using a vernacular usage, you write around the need for a pronoun altogether.

Anyway, all of this came to my mind again when I saw an article today about poets, a group known to consist of both male- and female-type people. Observe this interesting struggle by the author:
If you’ve ever been to a poetry reading, the following scene will be familiar. After being introduced, a poet steps onstage and engages the audience with some light social speech. Maybe they* talk about their forthcoming book, [...]
Take note of the asterisk, which leads to the following footnote:
* I'm using "they" as the singular gender-neutral pronoun here to avoid suggesting that "Poet Voice" is a gendered thing (it's not), and also to avoid the clunkiness of "his or her."
This strikes me as an interesting development. Garner often labels entries in his usage guide using the following index:

Stage 1: New form/innovation used by a small number of users.
Stage 2: Vernacular for speech, not acceptable in standard usage.
Stage 3: Commonplace but avoided in careful usage.
Stage 4: Virtually universally used but still decried by SNOOTs.
Stage 5: Universal.

The article seems like evidence that singular they is hovering somewhere between stages 2 and 3.

The question is how many people would really notice the use of they here if the author had not gone to such pains to point it out. Are we really at Stage 3 or 3-1/2? John McIntyre, who knows a thing or two about copyediting, advises singular they, to which one of his commenters says "A year or two ago I gave in and started using 'they' in the singular. What a relief! It's easy to use and only occasionally sounds awkward. There's no going back for me now."


[1] The use of singular they is often ascribed to a sensitivity to sexism in language, but I doubt that Shakespeare or Austen was much concerned about that.

[categories]  

[5] |


  09:22 PM

The default color for a lot of devices is, it seems, black. I can look up from where I'm typing and spot these items in black: monitors (3), keyboards (2), USB hub, computer speakers, mouses/mice (2), laptop, external hard disks (2), modem, router, TV, remotes (3), Roku device, cellphone, chargers, almost all cords, headphones. Not everything is black, but that certainly seems to be ... popular.

It's, what, elegant, I suppose, but it has its downsides. Whenever I'm rooting around in the dark recesses of my backpack for my mouse (black) or bag o' connectors (black) or earbuds (black), I find the near invisibility of these items somewhat inconvenient. However, I accidentally made a discovery that has begun to change my life, so it's got me thinking about this mania for black.

After I got my most recent phone, I was looking for a one of those protective silicone jackets for it. I found one at a kiosk at the mall, but the girl was apologetic: sorry, the only color we have is red. Oh, well, I thought, I can live with that.

And boy, can I ever. With its bright-red cover, my phone now is quite visible. Indeed, I never have trouble finding it, even if I've carelessly left it on our (green) couch or if it's ended up in the passenger footwell of the car.

A guy I used to work with is a big fan of the classic Moleskine notebooks and carries a couple of them everywhere—one for work notes, one for personal notes. After I'd had my epiphany about the red phone cover, I noticed that one of his notebooks was black, the other red. When I asked him about it, he had a similar story: they'd been out of black, so he got a red one, and that had actually worked out well, since not only could he distinguish his notebooks, but he had a lot less trouble finding them.

Since then, I've gone out of my way to look for bright colors. When I ordered a Kindle Paperweight (black, of course), I ordered an orangey-red (!) leather cover for it. I never, ever have trouble finding it in my backpack, by the bedside, or halfway under the couch when I've fallen asleep reading.


My phone and Kindle

I can probably continue to work fine with my black keyboards and monitors, but if I could paint the TV remotes, I would definitely do that. Yes, I think my life us going to be a lot more colorful in my future.

[categories]  

[1] |


  09:58 AM

Andrey Karpov, who analyzes software for defects, has identified what he calls the "last line effect." This happens when people use copy and paste to quickly create a bunch of similar lines of code. He's figured out that mistakes are most often made in the last pasted block of code. He backs up his thesis with hard numbers and with examples taken from real code. He muses:
I heard somewhere that mountain-climbers often fall off at the last few dozens of meters of ascent. Not because they are tired; they are simply too joyful about almost reaching the top—they anticipate the sweet taste of victory, get less attentive, and make some fatal mistake. I guess something similar happens to programmers.
I've certainly made this mistake while writing code. This also made me wonder how often this syndrome is evident in writing or editing. What would this look like? Obviously, there are many pitfalls associated with copying and pasting, but is there an analogue in writing and editing to the last line effect?

[categories]   ,

[1] |


  10:23 PM

Because I apparently don't have enough to do, gah, I took a notion recently to make updates to this blog. I had seen something somewhere about Google Fonts, which made me think about updating the typeface from the venerable Verdana that the blog has sported for the last 10 years.[1]

Making that change required messing about in the blog's stylesheet, and that got me to wondering about the ungodly awful table-based layout that I threw together 11 years ago. I experimented a bit with a 2-column, div-based layout until I got something reasonable working.

If you have feedback, by all means, leave me a comment.

And here it is. I only played with the main page, and I still need to do a lot of weeding and pruning in the style sheet. There's no real effect for readers, I don't think. As with the whole blog project from the beginning, it's all just been about me learning about web development ...

[1] Should you be wondering, you're now looking at Lato by Łukasz Dziedzic.

[categories]  

[5] |


  06:41 PM

As a technical writer, you will frequently find it useful to be on the consuming end of information and to take some lessons away from that experience. I had such an experience today.

I was working with some internal tools and couldn't get things working. I pinged the experts, and one of them sent me back instructions that ran something like this (altered to be suitable for public consumption):

1. Save the attached configuration file.
2. Overwrite the current config file in the X folder.
3. Try the process again.

I saved the file and overwrote the config file. No luck, so I contacted the expert again. I got this response:

Please follow the instructions exactly.

So, I tried again. Still no luck, so I sent a dense response detailing what I'd tried and where it had failed. The expert, I must say, became a little impatient.

Long story short, the process I was trying has two configuration files in two places. I had overwritten the wrong one. The part of step 2 that said "in the X folder" had somehow not penetrated to me, probably because I was looking right at an actual configuration file and I had no reason to imagine that there were two of them. So the "in this folder" qualification hadn't really registered.

It's arguable of course that it's my own damned fault for not reading the instructions carefully enough. But I've done (and indeed, still do) technical support, and I generally don't blame customers for not being careful enough in reading the docs. If instructions aren't working for people, I try to take away a message that the instructions aren't clear enough. I certainly don't respond to confused customers with the message that they're just not reading instructions carefully enough—especially the instructions that obviously don't seem to be working.

But those are after-the-fact issues. What would have prevented the confusion in the first place is for the expert/writer to have anticipated a possible problem, along these lines:

2. Overwrite the current config file in the X folder. (Note that there are two config files—make sure you overwrite the one in folder X.)

That is, it helps tremendously if the writer can anticipate trouble spots and steer the reader around them. Of course, it would be best if processes didn't have such trouble spots—why are there two files with the same name in different folders?—but there are many cases where things are just going to be a bit confusing, oh well.

It would have saved an hour or more of time, not to mention aggravation on both sides, if this small issue would have been anticipated.

So look out for where users might be confused when reading docs. And if readers tell you that they're confused with your existing docs, take that as your problem, not theirs.

[categories]  

[1] |


  09:44 PM

It's probably a cliché, but it's still true: riding a motorcycle regularly has made me into a better (car) driver. Here's a list of the skills that I've been honing on the motorcycle that I think have translated back into car skills.

Watching other drivers

The most obvious skill is that when you're on a motorcycle, you become hyperconscious of what other drivers are doing or might do. You might think of this as defensive driving, except on steroids. Another term is situational awareness. Anticipating what others might do becomes essential on a motorcycle; bikers are usually familiar with the phenomenon of SMIDSY ("Sorry, mate, I didn't see you"). You just learn to assume that people don't see you, even if they seem to be looking right at you (inattention blindess). And since they might not see you, you better watch out for them. This proves to be a useful skill when driving a car, too.

Using mirrors

I think that most car drivers don't know how to use their mirrors effectively. First, mirrors have to be adjusted correctly. On a bike, it's not as easy to do headchecks, since it's often an odd angle (for me, anyway). So I've learned to arrange my mirrors so that I have a complete view of what's behind me, including my blind spots, and now I feel comfortable changing lanes and turning without a headcheck.


Second, you have to actually use your mirrors. Again, I think a lot of car drivers don't scan their mirrors regularly (like, every 5 to 10 seconds just for toodling along, and constantly when changing lanes or stopping or turning), and some seem to change lanes or make turns without looking in the mirror. Do that on a motorcycle and soon enough you'll be dead.

In a kind of related point, I also try to stay out of car drivers' blind spots. If I notice that I'm in the blind spot of a car in the lane next to me, I'll either try to hang further back or get ahead where there's a somewhat better chance they'll see me if they decide to lunge into my lane.

Braking

Braking on a motorcycle is a bit of a fraught exercise. Do it wrong—too hard, while turning, or with a mismatch between rear and front brakes—and you can earn yourself a case of road rash. A simple way to reduce the chance of bad braking is simply to slow down earlier, such as when you see a red light or stop sign ahead. (Some drivers seem to race up to stop like that and then hit the brakes.) I've become quite conscious of when I'm braking while I ride, and this has inevitably translated to thinking about it in the car.

And my other solution to better braking is …

Following appropriately

What is it with people who tailgate? On the bike I've learned the discipline of the two-second rule: when the car ahead of you passes a specific point, you should be able to count "one-mississippi-two-mississippi" before you pass the same point. I do not want to have to hit the brakes hard (see previous point). I'm still better about this on the bike than I am in the car, but I'm getting better.



Watching for motorcycles

Finally, being a motorcycle rider makes you see other motorcycles. Many bikers wave at one another as they pass, which is a nice protocol. I've become so used to this that when I drive the car I now sort of reflexively want to wave at an oncoming bike. That would be silly, but it does mean that I'm much more conscious of bikes now, even in a car.

If you ride a motorcycle, do you also have a list of skills that you feel have made you a better driver?

[categories]  

|


  12:37 PM

In the U.S. today, it's time for the semi-annual grump-fest about the changeover to Daylight Saving Time, aka DST. As we say around here, we "spring forward" an hour on the clocks, such that the first thing you do on Sunday morning is run around the house and slice an hour off your clock. You woke up at 9:00? Guess what, it's actually 10:00!

Some people don't understand why we do this, and lots of people don't like it, citing reasons from sleep deprivation to communism. It's true that DST doesn't make sense everywhere, and indeed, DST is not imposed everywhere. In the US, it's not uniform in Arizona, and Hawaii doesn't play at all.

Basically speaking, DST makes more sense the further north you go (or south, in the southern hemisphere), because it's an effort to even out, so to speak, the differences between the shortest and longest days. The closer you get to the equator, of course, the less of a difference there is, and at the equator, there is no difference (ok, only a very small difference) between the length of days on the solstices.

Ever since the beginning, offsetting the clock was proposed as a way to save energy (by Ben Franklin, who else, who calculated energy costs in terms of candles burned). The idea is to shift the bulk of daylight to the hours when people are most active.

Consider our latitude here in Seattle. Here's a graphical illustration of the times for sunrise and sunset at the solstices and with DST (not entirely to scale[1]):

Winter solstice[2]



Summer solstice without DST



Summer solstice with DST



The general theory of DST is that more people are active on the evening side of the day than on the morning side. Or to use the numbers, more people are active at 9:09 pm than they are at 4:11 am. And being active, they need light, and why use energy (candles, electricity, whatever) when you could use daylight instead.

From the simple perspective of saving energy, it would theoretically be better to let areas impose DST that can actually benefit from it (Seattle, upper Alberta, whatever) and allow those areas that don't benefit from it (Key West, FL, Brownsville, TX) to give it a pass. But the benefits of having a standardized time system seem to (so far) outweigh the issues of imposing DST uniformly across the country.

Me, I'm not a morning person myself, so the longer the evening lasts, the happier I am. Daylight in the sky at 10:00pm? Fine by me. Sure, there's a hit today in terms of a lost hour, but that's like traveling one time zone, which is not considered that odious. And so tonight I'll be happy that there will be light in the sky well after 6:00pm.


[1] h/t to stepdaughter Emma for the Photoshop work here

[2] Altho daylight here is represented by a sunny yellow, I can assure that, what with this diagram representing Seattle, it should actually be a kind of steel gray.

[categories]  

|


  11:13 PM

I just installed Word 2013 and was disappointed to note that some of the long-standing keyboard shortcuts no longer work. For example, I've been using Alt+V,A for years (decades?) to invoke an ancient menu command to toggle between hiding and showing revision marks. Even when they introduced the ribbon and the menus went away, a lot of those old menu-command shortcuts still worked. And some still do; but this particular one no longer does, darn it.

I spent a little while trying to map keystrokes to the show-revision and hide-revision commands in the Review tab. Either I'm not finding them or (as I believe) there's no longer a single command to toggle show/hide of rev marks in the way I've come to rely on.

So, macro time. Using the macro recorder and some editing, I created the following macro and then mapped Alt+V,A to it. Macros are stored in Normal.dotm, so as long as that remains available I should be good. (Right?) However, I'll have to update Normal.dotm on each machine on which I install Word 2013.

Perhaps there's an easier mapping for this functionality. If this macro thing doesn't work out, I'll investigate further.
Sub ShowOrHideShowRevisions()
If ActiveWindow.View.RevisionsFilter.Markup = wdRevisionsMarkupNone Then
' Hide revisions
With ActiveWindow.View.RevisionsFilter
.Markup = wdRevisionsMarkupAll
.View = wdRevisionsViewFinal
End With
Else
' Show revisions
With ActiveWindow.View.RevisionsFilter
.Markup = wdRevisionsMarkupNone
.View = wdRevisionsViewOriginal
End With
End If
End Sub

[categories]   ,

|


  06:11 AM

Jeez, I totally missed it: this blog just turned 10—my first entry was on June 27, 2003. I had previously used Livejournal but found that (at the time) they had no search facility. And I needed a coding project to accompany a writing project I was on, and hey, how hard could it be?

The entries have wandered around a bit through coding, writing and editing, family news, and other topics (see the Categories list over there on the left). This has reflected, among other things, job changes. The blog has also accreted a variety of blogging-related features, like a blogroll, trackbacks, an RSS feed, a Google AdSense box, a Facebook Like button, and so on—a microcosmic revue of blogging trends.

The actual code that runs the blog is a rat's nest, tho as recently as this weekend I was still poking around in it to make changes. (I would never wish that onto anyone else, gah.) Nonetheless I find it fun even now to wallow around in the code and add some small improvement.

What a learning experience it's been.

The volume has fallen off, as happens. I have a couple of other, more-focused blogs, and I contribute to a gang blog at work. And there's Facebook. One thing that hasn't changed is my tendency toward blather. Thank goodness there's the Internet, eh? :-)

[categories]  

[2] |