Maura van der Linden – Blog

Most users of Microsoft Word make good use of Word’s autosave functionality and have appreciated the ability to retrieve documents that fell victim to sudden power failures, mysterious operating system or application crashes, or even the cases of overly helpful children or pets. At least you are able to get back the work up until the last autosave so (assuming you don’t have the period between saves set to a huge number, will often give you enough to get you back on track pretty quickly.

But how many users have had some sort of situation where they have to quickly close their document (or have had someone else close it for them)? Have you ever carefully poured work into your document and then clicked to close it and responded “Don’t Save” when prompted whether you wanted to save the changes? This is usually followed by open-mouthed disbelief, curse words and sometimes tears. How long was it since you saved your document?

In prior versions of Word, you were hosed. As soon as you clicked on the “Don’t Save” button, your autosave files were deleted and you were back to your last saved work.  If this was a brand new document, you were entirely hosed because there would be no last saved work to return to.

Word 2010 has added a new feature to autorecover that will help you retain your sanity and your editor’s good graces. There is now an option to save the last autosaved version if you close a document without saving. (Sorry, Mac people or those on prior versions of Word, this is a Word 2010 for Windows only feature at the moment though I will bet it will show up in the next Mac Office version.)

First, you need to turn on the feature:

1. Open any document in Word 2010.
2. Select File -> Options.
3. In the left-hand pane, select Save.
4. In the right-hand pane, ensure Save AutoRecover information is checked and you have a reasonable time period set (I generally advise 5-10 minutes.)
5. Check the box for Keep the last autosaved version if I close without saving.
6. Choose OK to save your changes.

Now if you close a document without saving your changes, you can do the following to get your last autosaved version back:

1. Open the document you need to recover in Word 2010.
2. Select the File -> Info.
3. Under Manage Versions, you’ll see any number of entries but one will say (when I closed without saving) after the date and time. That is your last autosaved version. Select that version.
4. Select Restore in the yellow banner at the top of the recovered document.

If you want to see the differences between the saved document and the last one autosaved, you can select Compare and Word 2010 will open a somewhat confusing screen to show you the differences between the two documents.

Mentoring is a subject I am passionate about. I have a fiction mentor currently and have had other mentors for other disciplines in the past. I also mentor others on a pretty regular basis. I’m not sure if it’s my love for instructional design that makes me so passionate about mentoring, but I don’t remember more than a month or two over the last decade when I wasn’t active mentoring someone. I just love to teach others and see their successes.

Although I’ve been a published technical author for years, I only became a full-time writer in January of 2009, right after I was laid off in the first round of the big layoffs at Big Software Company. For the twelve years prior to that, I was a software tester (both as a software test engineer (STE) and a software development engineer in test (SDET)). I had already been in the process of trying to move to a writing role within the company when I was laid off, so I set up an LLC at that time and began taking on freelance technical writing jobs. Not long after that, I was hired back at Big Software Company as a Programming Writer – first contract, then as a full-time regular employee.

When I came back to Big Software Company in a role completely new to me, I really was a bit adrift. I knew the company and I knew how to write but I didn’t know what tools my new group used or where documents or databases were located. I didn’t know who the various team members were and who was in charge of what. I didn’t know my new product. I was really confused and was pretty much plopped down at a (not set up yet) computer and left to sink or swim. I’m pretty resourceful and very stubborn so I set out learning how to swim. I introduced myself to some of the other writers, the editors, the content production people. I asked them for any “new hire” information they might have. I went to the engineering team for our product and started introducing myself around there too.

It was a very interesting first couple of months when you combine the newness, the fact my lead didn’t have time to bring me up to speed, the fact there was more than a little bad blood between the content and the product teams. The little getting started information I had was out of date, too. It’s not called “drinking from a firehose” for nothing.

Now, as a tester, there were almost always documents, plans, new hire guides, etc. available that would help you get up to speed. And the other testers on my teams had always been able to spare an hour or two to give me a brain dump so I’d get up to speed faster and start being productive. About half the time I approached someone and about half the time the more veteran testers on a project approached me. My test leads were always big advocates of buddying new testers up and would often make time to do their own “lay of the land” orientations as well. The goal was always to get the new people up to speed as quickly as possible and doing real work.

After I’d gotten my own feet under me and, partly as a by-product of a change in the content group’s management, began to take on responsibilities and be productive as a writer, I started keeping my own set of information on all the things a new hire to the team needed to know – both hard information and the sort of tribal knowledge that you tend to only learn from making mistakes. As this body of knowledge grew, I started asking both my lead and his own lead why there wasn’t some sort of mentoring or buddy system in technical communications – or at least not in OUR technical communications group.

The sad thing was – no one could really answer me other than to say that writing tended to be a very solitary job.

I’ve now been a full-time technical writer for two years, I’ve talked to a bunch of other writers and I’ve got a list of what I think may play a role in the lack of mentoring. This may be biased toward Big Software Company, because that’s where I’ve been able to see situations play out and talk to others but maybe it’s not as company-centric as I think.

• Mentoring is not a formulaic process and contains a fair amount of uncertainty, playing it by ear, and brainstorming without clear answers being evident. This ambiguity is often not a great match for many of the writers I’ve talked to. They much prefer being able to show how to do something in clear steps and are not able to easily change modes or be comfortable with merely offering some insight or tossing around a bunch of ideas without a definitive right or wrong.
• Mentoring means taking time from your focused work. Most writers try very hard to stay focused on their work and mentoring has a degree of randomness built into it. If you mentor someone physically near you, you may get interrupted for questions on an ad-hoc basis.
• Mentoring is a partnership between mentor and mentee and unless clear rules are defined, either of the parties (or both) can feel neglected or pestered. Yet it’s rare to find a set of reasonable ground rules for mentors and mentees.
• Mentoring can be abused. Mentees can want the mentor to do their work for them or find their answers instead of showing them how to find them. Mentors can try to offload work or research on mentees in the guise of teaching them. Mentees can even use a lot of the mentor’s time to get help but then be unwilling to actually act on any of it.
• Mentoring means teaching someone your tricks. In some corporate cultures, great stock is placed in individual knowledge and performance and not as much in team knowledge and performance. I’ve heard more than once that a writer is unwilling to mentor another writer because then the other writer will improve and thus threaten that first writer’s standing.
• Mentoring means putting yourself out there. Mentors have to offer to help. Mentees have to be able to ask for help. These can both cause feelings of vulnerability and can be taken as a sign the writer isn’t “good enough” and it takes some moxy to get past that.
• Mentoring can be unsupported by management, management can place time limits on it or can even decide it’s a waste of time. When a writer can get chastised for giving or asking for help, they will tend to either not do it or hide it.
• Mentoring requires an ability to look beyond what both parties are writing and toward more universal concepts and skills or even different ways to apply knowledge outside the box it was originally learned in. It requires more of a big picture view, especially on the part of the mentor.
• Mentoring requires both parties to check their egos at the door. It’s really more of  a two-way learning experience than many give it credit for.

The next installment in this series will talk about being an effective mentor.

I’ll be giving my short (1 hour) walk through the cheat sheets of my Word for Writers class at this year’s Emerald City Writers conference in October. Right now I’m scheduled for Sunday at 11am!

Hope to see folks there!

Today I gave a shorter talk on my Word for Writers class to the Greater Seattle Romance Writers group. I came away with great data on adding Word 2003 to the book/class and some good questions on issues people have faced with Word specifically. I’d love to hear more challenges/problems/question as well. Just drop a comment.

I’m looking forward to finishing the book and deciding on a venue to set this up as a moderated/mentored class as well. I think it really fills a niche.

Being able to taking a screen capture and effectively and clearly annotate it are essential skills in both my prior job as a software tester and my current job as a programming writer. I work in the software industry and it’s extremely common for me to have to visually explain how to perform a task or where something is. When I started in software testing, over a decade ago, the only real option was to use Print Screen to capture a screenshot to the clipboard, then paste it into Paint and annotate whatever I needed to there. It was tedious, very annoying and often time consuming but for years was good enough. Most screen captures I did as a tester were destined to either be pasted into a test plan or into a bug report to document a defect, so they didn’t have to be all that clean nor consistent, as long as you got the message across.

A few of the more masochistic testers would pull the screenshot into Photoshop or another heavy-duty graphics program and work on it there. I wanted something lightweight and, to be honest, less expensive.

Then about four or five years ago, my husband (also a tester) demonstrated a tool to me that a co-worker of his had shown him. Snagit by TechSmith. Here was a tool that wasn’t expensive and which could do exactly what I wanted without pain or fuss. I was hooked and have used it from then on. Now that I am working as a technical writer, I still use it constantly.

I just installed the latest version of Snagit on my Windows machine and wanted to walk through with a quick overview of its features. I’ll also point out that TechSmith offers a 30-day free trial so you can try Snagit for free. You may be hooked by then, though.

Installation

Installation is very simple via an installation wizard. By default, on a Windows system, Snagit binds to the Print Screen key but you can change that option if you wish. I find the Snagit UI to be easy to understand and user-friendly. (Note that because Snagit is designed to “get out of the way” when you are doing screen captures, I did have to cheat and take the screenshot of the basic Snagit UI and the Snagit Editor UI with Windows 7′s snipping tool, then pulled that into the Snagit editor to trim it down and annotate it.)

Here I’ve used the basic tools to annotate the screenshot. This literally took me two minutes to do, at the most.

The annotation previously shown was done in Snagit’s Editor which also has a simple UI.

Features

I won’t go over every feature offered by Snagit since you can read about those on the TechSmith website but I did want to mention my favorites (in addition to the ease of annotation) with a few quick examples of some of them.

Timed Captures

You can minimize Snagit and will end up with just button in the Hidden Icons area of your taskbar. This gives me the chance to show off timed captures; another thing Snagit is great at. One of the banes of my existence as a tester was trying to capture tooltips, flyouts, and other actions that are cursor-based. This is typically not an easy task but it took me only setting the timed capture delay time to 3 seconds, popping open the hidden icon area and then selecting it for capture when the timer went off.

Scrolling Window Captures

I remember struggling to either minimize a window enough to get it all on the screen at the same time or sometimes having to take multiple screen captures and try to paste them together in order to get the entire contents of a window. Snagit will do automatic scrolling window content captures with one press of the capture button.

Area Magnification

I use this to show the area in detail without removing it fully from its background.

Area Blurring

I find this feature very useful for blurring out confidential client information.

Torn Edges and Torn Out Sections

These are useful to show that more of what you have captured exists.

Stamps

You can get or make stamps for your images and I find these really useful for things like telling people where to click or indicating problem areas. A small set of stamps is included with Snagit and I believe others are available separately.

Video Capture

Snagit can do a nice amount of video capture, including with audio if you choose. This is great for tours, etc.

Bottom Line

I consider Snagit to be a must have in my toolbox. At $49.95 for a single license, it’s well worth the small amount of money. See the TechSmith website for tours and more in-depth information on Snagit and it’s video capture cousin, Camtasia.

Disclosure: This review is based on software I purchased and own personally. I received no compensation or guidance on this review and it’s purely my own opinion as a long-time user and fan.

Last week, in the course of commenting on James Bach’s blog, I explained that I liked to learn by laying my beliefs and understandings in front of others for them to question things I may not have questioned and, in turn, to question them to see if knowledge or views they have fill in something for me. James responded that this was called “transpection.”

It has a name? Who knew?

Transpection basically means to learn by putting yourself in place of another (to quote James’ blog post on transpection). This is different from introspection (contemplation of one’s own thoughts and feelings) and extrospection (examination of things outside oneself). It’s also different than the often-referred to “put yourself in someone else’s shoes” because you need to put yourself in someone else’s brain, really. It’s less role-playing where you imagine what that person might be thinking (which I think would be still be highly subject to your own views) and more based on really asking questions of someone else about a subject you are interested in.

Honestly, this truly fascinated me. I was not only interested in the fact there was a word for this process but the fact there was spurred me into reading and thinking about the process of transpection. As with many things that catch my interest, I mentioned it a few times and James kindly pointed me at a few other definitions of it.

Then James invited me to join him on skype to have him run me through a transpection session with him. This was a really interesting experience – not terribly comfortable in some ways and yet quite eye-opening in others. Now, mind you, this is coming from a person who has experience with James’ personality and does understand what he’s trying to do in advance. I got frustrated once or twice and felt obtuse several times but it was really fascinating to experience it and, at the end, hear what James’ response to the questions he asked me were.

I’ve read James’ list of problems with transpection on his blog and thought I’d give you my views:

• Feeling interrogated or tortured – I did feel a bit interrogated but wasn’t that part of the point? On the other hand, because I can see what the goal was, I knew repetition of a question/set of questions meant either that I had an interesting view or I really needed to look at my answers. Tortured, no – other than when I could NOT, even to myself, validate a stance I had taken. Time for that stance to go.
• Being judged – We all judge each other all the time. I expected it but, in return, I was judging my reactions and James’ approach too. It was definitely a two-way street.
• Being treated like a lab rat – Yep. But I had a psych minor and undergrads are the lab rats of the psych world. So it was familiar ground and I don’t feel demeaned by it at all. I learned and James learned and that’s the point.

What did I learn?

• I have fallen a bit into a trap of reliance on metrics and my own fixed idea of what a test/test case consist of. This is more limiting than I would have guessed, actually. This is probably rooted, at least in part, in having done test automation recently.
• My particular order of examination seems to put visual appearance lower on my list than many people would have it. I need to consciously push it further up my list to compensate. This is almost certainly rooted in the fact I have no real visual memory so it can be quite difficult for me to deal with visual appearance and it’s never my default behavior.

I saved our skype session so I can examine it a few more times to see what else I learn from it. I will note that I did experience a bit of James’ excitement when he hears something interesting. In this case it was my mentioning the fact I had no visual memory. The questions were rapid and many but I didn’t interpret it as sharp or angry – just very curious and wanting to gather information.

I will point out that this type of questioning does require that the need to “be right” or “win” be analyzed as well. I suggest that if you go into a transpection session to prove you are right, you will limit the benefits you can get from it. I also think this desire could be at the root of people feeling attacked or offended. Being right is not the point. Learning is the point and, to learn, you need to be willing to examine what you think you know and your views and reassess them in light of new information. If I went into this session with something to prove, I would not have gotten out of it what I did.

After the skype session with James, I ended up thinking more about my lack of visual memory and ended up trying a somewhat clumsy version of it on my husband, Chuck. I asked him questions about how he finds things around the house and remembers where they are. It sounds simple but it can be cause for friction. I thought it might be interesting because he, unlike myself, is highly visual.

• We both start by looking for an object in its designated “home” if it has one.
• If it is not in its home or has no home, Chuck pictures where he last saw it and looks for it there.
• If it is not in its home or has no home, I remember where I last put it and look for it there.
• If that fails, we both try nearby areas to the one we expected to find the object in.
• If that fails, we both resort to trying to figure out where the other person would have decided to put in instead and then check there.

It’s a very simple example but it pointed out something interesting to us. It answers the question of why if I cannot find something, Chuck usually can and vice versa. It also points out a symptom of my lack of visual memory. I cannot picture where I saw it. Instead I rely on where it SHOULD be or where *I* put it.

Since then I’ve done a lot of thinking about how I cope with my weird brain wiring and compensate for it, when necessary. I’ll have to write a separate post on that.

I have the dubious pleasure of trying to provide documentation for a small application that is basically a helper application for our product. It’s NOT complicated and it shouldn’t be causing nearly the amount of drama that is currently occurring. This has been probably twenty times more frustrating than my big project.

Now, one thing to understand is that the doc team (of which I am a member) is not integrated with the project team officially. We are a separate organizational unit. With the product team of my big project, they use Scrum and I attend their weekly planning meetings and the daily standups if I feel I need to. They are very transparent and I can check the tracking log at any time to update my plans.

This little project (a single program manager, dev and tester) keep telling me they are “agile” but they have no idea what they are doing beyond having a daily meeting which seems to take an hour every day, pestering everyone else and changing schedules and basic assumptions so quickly I swear I am getting whiplash. There is No Clue here.

I’m frustrated – VERY frustrated – at this point. My team does run on a Scrum process and I keep having to defend my prioritization, my schedule and deal with each time they change their minds and (often) never tell me. The following seems to be unclear to them:

1. Changing schedule dates – drastically – at least once every week or ten days does NOT mean you are agile. It means you have no idea what the scope of your task is and you are allowing schedule creep and bad planning to win while you rush to try to get this project out the door.
2. Changing core deliverables and/or concepts without talking to those you depend on to provide you with something you must have before you can ship and which these changes affect does not make you agile. It means you are risking your project, your shipping and your working relationship with these people you are dependent on because you either think you can push them into doing your will or you are incapable of remembering your dependencies.
3. Refusing to provide the requested information so a team you are dependent on can do their job and “rolling your own” version of what you think they need instead does not mean you are agile. It means you are unwilling to work with that other team and can come across as passive-aggressive or ignorant and the other team still needs the information they requested.
4. When given a schedule by another team, pestering for updates constantly when they are meeting their schedule does not mean you are agile. It means you are annoying them and making them less likely to try to get things done early because they are spending that precious time responding to random emails on things that have already been discussed multiple times.
5. Trying to push a release out the day before a three day holiday that backs up on a week when most staff are on vacation does not make you agile. It means you are foolishly focused on the earliest date you might bully people into shipping instead of having contingency plans for when things may go wrong
6. Asking for documentation to be done off a non-finalized UI to “speed things up” does not make you agile. It means you are asking your doc team to write documentation at least twice and hoping they catch any instances of the non-final UI before the docs ship. Skeletons are okay, but you won’t get RTM ready docs.
7. Shooting of wild plans from the hip does not make you agile. Disorganization, lack of ability to plan and think through processes as well as a lack of ability to track issues, decisions and schedules makes you a project from hell and someone that quickly becomes the person no one wants to work with.

That is all. My tongue may bleed soon from biting my tongue at work.

Today I was asked an interesting question about how I felt as a female tester and whether I thought I needed or wanted a group focused on Women in Agile.

I had to think a bit about my own history in test and remember the few bad times I’ve had as a female tester. Most of the times I had problems was not because of my skills as a tester but because of other people’s impressions of what a female tester was or could do. Their own prejudices were the issue. What did I do? In one case the person was outright disrespectful and I personally confronted them. In the other two, I did my job and I did it well and I refused to worry about what they thought of me.

When I think of any group called “Women in X”, I immediately try to figure out what the purpose of the group is. I am never a fan of any type of diversity quotas or rules. But I consider that there are HUGE numbers of ways to be different from another person. Things like skillsets, experience, interest, hobbies, etc. Being a female is a part of my makeup but it’s only a small part of the puzzle. I’m more likely to consider myself an Agile tester or a security tester than I am a female tester because I don’t think being female is a major point I bring to the table.

Is that wrong? I don’t think it’s wrong or right, per se. It is how I strongly believe in selling myself and how I try to judge others.

Another aspect to consider is that having a group like this also tends to polarize people (mostly men but some women as well). It carries undertones of political correctness, quotas and reverse judgement. A Men in Agile would do the same to some women, if you’re honest. It’s similar to the argument of why to have a Black Music Awards and not a White Music Awards. Someone is always left out and offended. It’s not unifying, it’s divisive.

As a female tester who works in an Agile environment, I’m not sure I’d appreciate the idea that someone put a divide between myself and my team, at least in some people’s perception. Agile is a much more collaborative and peer environment for test than many, does it need a division like this? Why just in Agile? Why not at a much higher and broader level?

I’ve been a member of diversity councils before and, in fact, worked with the women’s organization within Microsoft for over 8 years. I do believe that women should be given early exposure to all the variety of professions they could enter. Too many women don’t consider fields they could enjoy and be successful at because of misconceptions of those professions for the women in them. I believe this is a valid effort but I think this is true for some socio-economic groups and ethnic groups as well. Being women isn’t much different from any of those other groups other than it’s an identifiable social programming. I have issues when an effort to become and foster technology and technical skills becomes more about fostering resentment and a victim mentality than anything else. And it’s very tricky not to fall into that trap.

In this case, I do NOT know the charter of the group Women in Agile. I have no idea what they are trying to accomplish, why they feel it’s needed and what they think they can do. I’m purely talking about my own experiences here. They may have a great plan, I’ve not had a chance to check it out yet. Agile doesn’t seem to pose a unique challenge to women – most problems appear to be more women in IT than Agile in particular.

Diversity is valuable – ALL diversity is valuable. In my co-workers, I want as diverse a set of skills, knowledge, experience and aptitude as I can get. Yes, gender is a part of that but it’s not a huge piece. At least in my own case, I’m content with being a “tester” (though more a programmer-writer anymore) than a “female tester”.

This week the rodent program managers have become Nutria:

When I stopped to talk to them on Thursday, they told me that one of the development leads had confessed to both the capybara and nutria monikers and they think another PM had started it off with the squirrels tag but they’re not sure who labeled them hamsters.

Have to see what happens next week!

As in most offices, there is a bit of a tradition of pranking at my office. Pranks that cause physical damage, make it impossible for the victim to work or which are mean are discouraged but some fun pranks still take place. It does help lighten the day, I’ll admit. Right now there seems to be an ongoing prank being perpetrated on two program managers who share an office but it’s a mystery as to who is doing it.

Each office in our building at work has what’s called a relight. It’s a floor to ceiling, about 12 inch wide window that runs vertically next to the door to allow light into the hallway and the office. It’s also very useful for seeing if the person you need is busy if the door is shut for quiet. Right now our building is crowded and all non-managers are sharing their office with at least one other person. It’s not ideal but it’s not horrible.

Two members of the product team I work as a writer for share an office. These are two of my absolute favorite team members and they are true rockstars. They have a great sense of humor and it’s a Good Thing that they do.

About 4 months ago, I think, I walked by their office to discover that someone had taken a whiteboard marker and written “Squirrels” on the relight. I asked why but no one seemed to know the reason or who had done it. Guesses were made that it had to do with the movie “Up” but most people just shrugged. The funny thing is, the two PMs are a bit like squirrels. They are industrious, busy, and running about getting things done.

I will confess that I started calling them “The Squirrels”. Hey – don’t glare at me! I did tell them that if it bothered them, I’d try to stop but they said they didn’t mind. I guess that’s a good thing because it spread. Pretty soon my co-workers started calling them The Squirrels, too. Then when we were speaking about just ONE of the two, we had to differentiate — I tended to use “Tall Squirrel” and “Not-So-Tall Squirrel”. They took this with incredibly good graces, I’ll confess. Everyone seems to know who I mean when I say I need to talk to the Squirrels or run by the Squirrels’ office.

(I felt relatively safe with calling them that because they didn’t erase the moniker from their relight for months. I figured they couldn’t be too annoyed if they left it there.)

Then about a month ago, “Squirrels” disppeared from their relight. I inquired when I noticed the deletion because if they had gotten sick of it, I wanted to TRY to not call them that anymore. But they said they hadn’t erased it – they’d just come in and it was gone. It seemed to be the end of the prank. I was sad. A little humor goes a long way sometimes.

Two days later, I walked by and a new word had been written on the relight – “Hamsters”! They asked me if I wrote it and when I asked why they thought I did, they said it looked like female writing. (There’s female writing??) For some reason they seemed more eager to figure out who had dubbed them hamsters than squirrels – did they consider it a step back? Hamsters are cute too but I couldn’t see them so much as hamsters – most hamsters I knew were only energetic at night and slept a lot of the time. I continued to call them the Squirrels, in defiance of their new moniker.

I’m not sure they ever followed through on their idea of gathering writing samples from various suspects’ whiteboards, though. Last I heard they’d narrowed in on a couple of people and were asking questions.

But, again, they let the writing stay.

Yesterday I stopped by to ask a few questions and “hamsters” had been replaced by a new moniker – “Capybara”. I’m afraid I DID crack up at this one. Plus someone had written “Python food” and drawn an arrow pointing to “capybara”. They just shook their head when I managed to point at the relight and shrugged. One of them did admit they had to look up what it was. (It’s actually a giant South American rodent. Think 140lbs or so giant.)

I wasn’t paying a lot of attention but I think the three different names were each in different handwriting. I’m not sure who is responsible or what group of people might be but it’s truly hilarious and I can’t wait to see what the two PMs are dubbed next. The combination of the escalation (or maybe descent?) of rodent species and the way the two PMs can take a joke makes it a lot of fun and has really livened up what has otherwise been a highly stressful and incredibly busy few months.