wshaffer: (Default)

September 2017

     1 2

Custom Text

Most Popular Tags

One of the work projects that pretty much consumed my work life from last August through this March is now in beta:

We made a little video to talk about the project and why we did it:
I've been working on a PowerPoint slide deck for a project at work. The idea is to have a short presentation that we can take around to different groups to introduce the project.

I did a first draft and sent it to a colleague for feedback. "Can you improve the visuals?" she asked, and sent me some examples. I improved the visuals. We sent it out for wider review.

All the feedback got was of the form, "Change X, Y, and Z. Oh, and can you make it more visual?"

I did a complete rework of the presentation. I scrawled pictures and diagrams longhand for days before I created a single new slide. I spent hours experimenting with different types of charts and diagrams. I searched for stock photos. I took screenshots.

I sent the revised draft to my colleague yesterday. Her response, "The content is great but I'm not sure about the visuals."


This is what they call a growth opportunity, isn't it?
I was woefully underprepared for my Toastmasters Club's "humorous speech" competition today. I'd sketched out the outlines of my speech, but hadn't really had time to practice it or flesh it out. And I'd actually intended to bow out of giving a speech, but my fellow club members persuaded me to give it a go. Then I won the contest by virtue of being the only entrant. So, I'm going to represent my club at a local competition in a few weeks.

Then I gave an impromptu table topics speech that was substantially funnier than my half-prepared speech, so I'm going to use that material in my reworked speech. So when I do go to the local competition, I will actually have something funny to say.

Actually, the experience was very much like workshopping the first draft of a short story, except with the added adrenaline of being entirely unsure whether I could bring my speech to a successful conclusion.
I've been asked to interview a potential candidate for a tools developer on my team at work. The job posting is here.

I've worked with plenty of developers, so I've got a pretty good notion of what I want in a candidate. I'm not planning on asking a lot of technical questions - there are other people on the team who will do that. Also, I really care much more about a hypothetical candidate's problem-solving abilities and their ability to understand the user mindset well enough that they'll build things that not only meet the technical requirements but actually help us do our jobs better. (In theory, translating writer requirements into language that developers can understand is part of my job. In practice, I've found that that's nearly infinitely easier to do with a developer who is willing to meet you halfway.)

Anyhow, I know that many of you are developers or regularly interview developers. I would love to hear about your favorite interview questions, or things you look for as red flags, or whatever. Please, give me advice.

Also, if you know anyone who would be a good candidate for the position, send them my way. The current candidate looks quite promising, but it never hurts to have a larger pool to choose from.
The VMware Information Experience team has started a new video series called Blogger Talk, where we interview VMware bloggers about their favorite topics. I talked to Mike Foley about vSphere security topics like why a VM escape is unlikely on ESXi, how to deal with internal security threats, and how to use the vSphere Hardening Guide.

Please like, comment, or share if you are so inclined.

In a recent performance review discussion with my manager, she suggested that I do some work on my presentation and public speaking skills. Mine are adequate, but I think I'm more distinguished by my lack of fear of public speaking than by great skill. As a child, I was actually terrified by public speaking, and would do almost anything to avoid it. This fear was slowly ground out of me by stints on the high school debate team (I was terrible at debate), Constitution team, and various other academic competitions that required impromptu speaking; class presentations in college; and teaching during grad school. In the middle of my first year of grad school, I stepped onto a stage in a 150-person lecture hall on the U.C. Berkeley campus to deliver a pre-exam review. I looked into the lemur-like eyes of a full house of undergraduates desperately hoping that I would impart to them in the next three hours the knowledge that they had failed to acquire all semester. The atrophied remnants of my fear sighed heavily and slunk off somewhere down Telegraph Ave., never to trouble me again.

Anyhow, there was one obvious place to go to get some training for my fearless semi-competence: Toastmasters. People have been recommending to me that I do Toastmasters for years now, but I've always found some excuse not to do it. But my employer has their very own Toastmasters chapter, that meets right here on campus, so I decided that I would bite the bullet and go visit a meeting today.

The meeting started with someone giving a pre-prepared speech, which we all got to evaluate. Then there's this thing called "Table Topics", where someone comes up with a topic, and everyone who wants to can give a 1-2 minute speech on this topic. Our topic today was "reincarnation," and what immediately sprang to my mind was my character in the Legend of the Five Rings game I'm currently playing in, who has been repeatedly reincarnated. So, I began my speech with, "I don't believe in reincarnation, but I do play role playing games." I then managed to give a reasonably concise explanation of what a table top roleplaying game is, what Legend of the Five Rings is about, and how my character discovered that she was reincarnated. And then wrapped it up by observing that playing RPGs is sort of like being reincarnated, because you get to experience being many people. All in 1 minute 58 seconds.

At the end of the meeting, everyone voted on their favorite table topic speech. I was the winner. I got a ribbon and everything! Not too bad for my first try!
From a training course on discrimination law:

The law protects not only people belonging to traditional organized religions such as Buddhism, Christianity, Hinduism, Islam and Judaism, but also those with sincerely held religious, ethical, or moral beliefs.
There's a phrase that I've been hearing a lot lately in corporate contexts that's becoming a bit of a pet peeve of mine. It's "[Insert positive quality here] is in our DNA," as an attempt to convey, "[Positive quality] is part of the essence of who we are." I've been thinking about why it bugs me so much. It reinforces a kind of casual biological determinism that I'm not really fond of in general, but I think the real thing is that the metaphor gets weird if you actually have more than a casual understanding of how DNA works.

The thing about DNA is that it doesn't, by itself, do anything. DNA has to be expressed and translated into RNA or protein in order to have an effect. And a huge amount of our DNA (up to 90% by some estimates) is never translated. Excellence may be in my DNA, but so are the mangled bits of feline retroviruses that generations of my ancestors picked up from their pet cats.

Even bits of DNA that could be translated can have their expression regulated up or down or switched off entirely by environmental factors. And genes rarely work like the simple dominant/recessive Mendelian pairs from your high school biology homework where you had to figure out how many of a given couple's offspring would have blue eyes. You've got traits controlled by dozens of genes, working together in complicated ways. So a trait may be in your DNA, but whether it's in you is the result of a messy process influenced by other things in your DNA, your environment, and your own behavior.

Hmmm...maybe it's actually a better metaphor than I thought.
I have spent, I kid you not, the better part of the past 5 work days trying to figure out the source of an arcane publishing problem that results in English language titles occasionally appearing in the tables of contents of non-English-language documents. It's entirely too arcane to go into here. If you will forgive me for being vague, it results from Thing A (which is a little counterintuitive but needs to happen to keep the software usable) combined with Thing B (which is a little counterintuitive but has sound reasons behind it), followed by Thing C (which is basically dumb behavior and in my opinion, a bug).

So, I filed a bug report, where I tried to explain in as comprehensible a way as possible that "We have a problem because Thing A --> Thing B --> Thing C, and I think the solution is to have the software not do Thing C, which arguably it really shouldn't do according to the spec, which I have linked here." The title of the bug, by the way, is basically, "Thing C should not happen."

I got back a "Sorry, why can't you just not do that in the first place? And also, do you want a fix for Thing A, Thing B, or Thing C?"

So I wrote back an even simpler explanation of the problem, with diagrams. And reiterated, "The problem here is Thing C."

I have just been offered a solution that prevents Thing A from happening. Yeah, the one that "needs to happen to keep the software usable." I have just written back explaining why that is not a fix from my point of view, and reiterating, once again, that the problem is Thing C.

I'm starting to worry here that the real solution is going to end up being Ugly Error-Prone Workaround D, which I came up with while I was writing my second bug update, but explicitly nixed because it was a pain in the butt and people would forget to do it correctly and not catch the error until the document came back from translation.

I'm working on a doc plan for a new project, and instead of diving in and creating a document outline, I'm writing:
A description of who the intended audience for the documentation is, and what they need.
A description of the purpose of each intended documentation deliverable, what it needs to include to help users succeed, and what it shouldn't include.
And a list of open questions that I need answered by the product manager and/or the development team before I can have confidence in the first two items.

I appear to have absorbed something from all the content strategy conferences I got sent to last year.

Let's see if this provokes more fruitful discussion than a typical doc plan review.
Last night and this morning, I helped two coworkers work through problems with an internal tool that I happen to have written the internal documentation and training for. It looked to me, from what I was able to see in the logs, like the problem was user error - both of them were, completely separately and independently, doing Operation X instead of Operation Y.

Which really made me think, "Gee, how crappy must my training and documentation have been, if it left them so confused? What the hell did I do wrong?"

Until I asked the second colleague, "Hey, why did you do X instead of Y?"

And she replied, "Oh, Y isn't visible in my user-interface."

It's looking like the tool administrator borked up a bunch of people's permissions. Fortunately, my documentation covers what to do in that case.

(no subject)

Oct. 1st, 2015 04:35 pm
wshaffer: (Default)
Having the kind of day where I have to have a long, hard think about whether it is ever appropriate to use the term "half-assed" in a business email.

I decided not. I settled for just listing the things that had not been done that still needed to be done.
I have just replaced my increasingly unreliable 13-year-old printer with a brand-new Epson inkjet. It prints, it scans, it copies, it makes a mean strawberry daiquiri*.

Setup was fairly smooth, but when I installed the printer drivers, I got a little popup that said something like, "Print queue was not added. Please consult the User's guide for instructions on adding a print queue manually." So, I found the online User's guide, found its nice search box, and put in "add print queue."

No hits.

Okay. I tried just searching for "queue". No hits.

Scanned through the table of contents looking for anything that resembles adding a print queue. No hits.

Memo to all those software developers out there: if you're going to put text in the user interface of your software telling people to look in the manual for something, please tell the person who writes your manual that you've done that.

* Okay, it doesn't make strawberry daiquiris, but in this weather, it totally should.
That moment when you realize that you've gotten so good at speaking engineer that the sys admin and the web application developer only talk to each other through you.

(The database admin is still only speaking to the sys admin, though.)
A trend I've noticed with some amusement at my place of employment is the use of "feedback" as a countable rather than uncountable noun. For example, "Let's collect all the customer feedbacks into a single document."

Have other people heard this, or is this idiosyncratic to my place of employment?
3 times in the past 2 days, I've been asked for my advice by a colleague on a writing problem. And it goes something like this: the colleague describes the problem to me, while I listen. And at appropriate points I do one of three things:
* Say, "What do you think is the most important thing to communicate to the user here?"
* Say, "So, what I think you're proposing is this..." and sketch something on a whiteboard or a sheet of paper.
* Say, "It seems to me you have two logical options here: A or B. Which do you think would work better?"

At the end of the conversation, they always tell me that I've been very helpful. And I suppose I have been, but given that 90% of the ideas have come from the other person, I'm not sure if what I've offered is "advice", exactly.
I just got the results of the surveys that members of the audience filled out at my last conference presentation. 71.4% "strongly agreed" with the statement, "The speaker was effective," while 28.6% merely "agreed". In the written feedback, respondents described me as "a confident speaker," and praised the clarity and efficiency of my presentation.

I say this not just to brag, but because seeing the results brings back a rather vivid memory of the first debate tournament I participated in back in high school, and the evaluation forms the judges filled out. I was a terrible public speaker back then, and I knew it, and the fact that I knew it was obvious in my performance and made it more terrible. The scores on my evaluation forms were justly terrible, and one judge told me that I was so awful that I should quit. There may have been a "for God's sake!" in there. Looking back, I'm kind of surprised I didn't quit - at least not right away. I stuck it out for the better part of a school year before my mom persuaded me that I needed to cut an extracurricular activity from my schedule. I got good enough to win the odd debate, but never got particularly comfortable with it, nor did I rid myself of my conviction that I was a terrible public speaker.

I'm fairly sure I still was a terrible public speaker at that point. I was definitely still terrified of public speaking. Years later, when I started graduate school, they sent someone around to videotape us teaching a lab session, so that we could review the tape and improve our performance. I never watched my tape. I couldn't bring myself to do it, because I was convinced it would be utterly terrible.

Grad school at least rid me of the fear of public speaking. After teaching so many undergraduate lab sessions, exam reviews, doing literature reviews for lab meetings, and surviving my qualifying exams, the mere idea of speaking in front of a group lost its terror. Once an activity stops making you break out in a cold sweat, it's a lot easier to improve it. And a lot more pleasant. I'm not sure exactly when I got "good" at public speaking, but just in the past few years there's been a distinct uptick in how often I get asked to give presentations. That may be some kind of indicator. (I put "good" in quotation marks because there are lots of people who are still much better speakers than I am. I am good enough now that I can give a talk and people will learn something from it and not be bored in the process. I've seen speakers who can hold a room full of people spellbound for an hour. That ain't me. Not yet, and possibly not ever.)

For a lot of the time in my life when I was scared of public speaking, I thought that the people who were good at it had some kind of inborn talent. Or that they were just extroverted, or charismatic, or something that I wasn't. So, if you're also scared of public speaking, let me assure you that that's not true. Public speaking is a set of skills, and you can learn those skills with practice.

And in the unlikely event that anyone out there is a judge for Lincoln-Douglas debate tournaments: Don't ever tell a kid to quit.
I'm moving offices at work, which means I'm sorting through and packing up a bunch of stuff. I came across the following page of notes from May 2006, which are curiously context-free, although I'm pretty sure they were written about the Virtual Center licensing server:

After the grace period expires, there is no more grace.

Actually, there wasn't that much to begin with.
So, when I get handed a new documentation project to do, it goes like this. There's a period of weeks or months where I read the spec, I write a doc plan, I play around with the software, I scrawl incomprehensible diagrams on graph paper, and I think. A lot.

And during that whole time, I get an chorus from release managers, developers, product managers, etc. of "Have you started writing yet?" It starts as a gentle chorus, and gradually gets more strident.

At some point, the chorus begins to dent my serene self-confidence that I know what I'm doing, and I am gripped by an Unreasonable Dread during which I become convinced that I've forgotten how to actually write documentation and that I probably ought to quit and do something more suited to my talents, like guinea pig herding.

Then I pull myself together, build a playlist of energetic music, and begin cranking out documentation at speed.

I've been through this enough times to recognize that this is exactly how it works, but I wonder if I'll ever get to skip the Unreasonable Dread. At least it was pretty short in duration this time around: I think it lasted less than 24 hours.

The funny thing is that with fiction I'm very much a "just dive in and start writing" kind of writer, but that really doesn't work with technical documentation.
So, often when I read articles about sexism in the workplace, I find myself saying to myself, "Of course, I know this stuff happens, but I'm very fortunate to not have to deal with that."

And then articles like this Guardian piece come along, and I'm like, "Oh. That. Yeah."

...almost everything a woman does at work is considered "a favor" that is off the clock. To put it another way, when a woman takes on a project no one else will, or does something helpful or thoughtful, it's seen as something she does for fun. When a man does it, it seen as real work.

The revelation of this structural ingratitude explains a lot. It's a pivotal point in understanding a key issue in workplaces: why can't women form lasting alliances, even though they spend more time contributing to their organizations by mentoring?

Alliances are often based on favors; if a favor is not counted, a potential ally is lost.

This plays out in complicated ways - I've actually made a lot of progress in my career by volunteering to do stuff that other people wouldn't or couldn't. And it's not like I'm never thanked or acknowledged for going the extra mile. But I have observed that merely "being helpful" often doesn't buy you as much as saying, "Sure, I'd like to contribute to your project - let me talk to my manager to see if she can spare some of my time for this." Or asking people to help me and then making sure their contributions are publicly recognized.