I'd Rather Be Writing » feedback

Building on Past Successes for Future Directions

Tom Johnson — Wed, 13 Jul 2011 06:56:39 +0000

The many directions one can go

I have a lot of flexibility and freedom in my job. That’s part of the appeal. The other day I was reflecting on the best route to take, the most fruitful path I should follow.

There are quite a few directions I could go. I could become meticulously detailed about style, knowing the ins and outs of every handbook (and being able to compare them with wit and perspective). I could become a tools guru in skinning online help, branding it with the right look and feel for our department. I could become a content producer, immersing myself in the product to write longer, more comprehensive topics.

Or I could become a SME project leader, organizing the writing efforts of a dozen or more subject matter experts (SMEs). I could become a manager, leading and inspiring my team. I could become a champion for usability, inserting myself into the design process and working towards better interfaces. I could become a content management specialist, managing the content for an entire team. I could become a community leader, or a single source champion, a taxonomist, a metadata specialist, a content strategist, a failing fiction writer, and many other things as well.

After reflecting on directions, I decided to focus on past successes. By successes, I mean those things from which I constantly hear praising feedback from customers. My main successes in tech comm have been with the following:

Quick reference guides
Screencasts

My longer documentation is fine, but no one ever writes in to say how much they enjoyed the user manual. In contrast, quick reference guides win users over every time, and screencasts actually show them how to use the product. People are always submitting feedback about how helpful the video tutorials were.

Outside of work, my two main successes have been as follows:

Blogging
Podcasting

Writing is my core strength, especially the blog format. And podcasts — well, I seem to go in spurts with them. I don’t think I’m a particularly good podcaster — I just happen to be one of the few people recording podcasts in tech comm. Regardless, I love the conversations and connections I make in my podcasts. That professional interaction is rewarding.

Of all the above, I think screencasts hold the most promising future. I plan to move more fully in this direction for several reasons:

I prefer to learn software by video (for example, by watching the videos at lynda.com). Text makes sense for a lot of things, but when people are learning software from ground zero (rather than searching for a specific question), visual learners prefer video more than text.
Videos are something others cannot usually do. Everyone seems to think they can write, but few can actually record a screencast. This ensures that I’m putting effort into a skill that can’t easily be replaced or outsourced.
Video has a lot of room for growth. I can learn so much about audio and video themselves. I want to learn After Effects so that I can better demonstrate concepts. This would be a powerful skill.

My screencasting prowess is only mediocre at best. Eventually I’d like to get good enough to create videos such as the WordPress release videos, or Mailchimp’s tutorials. I think there’s a high demand for people who can create this type of content.

That said, I’m also fascinated by findability, and there’s still so much here I haven’t explored. Even though it’s not my strength, perhaps I’ll add it as a key area of focus.

That’s me: quick reference guides, screencasts, blogging, podcasting, and findability. I guess that narrows it down enough. What’s your specialization?

——————-

photo from Flickr

Blog Sponsors

Praise: The Worst Feedback You Can Give Developers?

Tom Johnson — Mon, 15 Feb 2010 08:31:33 +0000

Lately I have been logging a lot of bugs in JIRA, our bug-tracking database. In one day I logged 25 bugs. This past week I logged about 60 overall. It feels good to log bugs. I feel like I’m finding valuable gaps in the application where code simply isn’t working.

Despite these benefits to the project team, in a recent triage meeting with the lead developer, as we discussed the bugs that needed fixing, it looked like the world was on his shoulders. I realized that developers like to hear about bugs as much as writers like to hear about typos and grammar errors in their writing. With many of the bugs, the developer would softly say, “Okay, we can look into it.”

It made me wonder. If developers only hears about bugs, problems, quirks, errors, and other issues, where’s the motivation to code?

In a recent post on Joel on Software, Joel Spolsky stresses the importance of giving positive feedback to developers, not just negative:

A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.

In other words, programmers need both positive and negative feedback on their work in order to grow. But when I’m wearing my testing hat, all I’m finding are problems. This doesn’t work. This looks out of alignment. This lookup field is returning the wrong results. This button doesn’t respond when I edit the item. This page isn’t styled like the prototypes. This modal takes too long to appear. When I click this button twice, the rich text editor blows up. And so on.

Logging 25 bugs in one day was sadistically fun in the moment. But in retrospect, especially during the triage meeting with the developer present, the weight of the bugs was like sin on a priest’s back. Every new bug I added seemed to make his heart beat faster into anger or slower into death.

I’m sure that developers like to solve problems. So it’s not as if problems are necessarily depressing in themselves. But as I’m logging bugs in the bug-tracking system, there’s no way to balance out the negative with some positive praise.

A few days ago, near the close of the day, I was investigating a complex scenario in the application I’m documenting. It was a new feature we built into the application that added a level of sophistication the previous version lacked. I thought I would discover a bug, but instead the application worked beautifully. Elegant, fast, and clean. I stared at the screen for a minute, in awe at the neatly arranged display of information. This is perfect, I thought.

But there was no where to log my praise in our bug tracking system. Apart from the occasional iteration meeting where we demo new features, there is no built-in mechanism to provide positive feedback to developers. I was the last one at work that day, so I just went home.

A System of Positive Feedback

Exactly how could I implement a system of positive feedback for developers? Would it be a waste of time? Do I fire off an email now and then? How do I even know which developer coded the page I’m looking at?

The next day I decided to ask a developer who sits next to me: “If all you ever see are problems and bugs, and you never see the praise, how do you stay motivated? Don’t you need a balance of both positive and negative feedback on the work you do? JIRA only allow us to give you the negative.”

He thought for a minute. At first he acknowledged that he did receive occasional user feedback from both users and the project manager (the project manager has an especially encouraging attitude). The developer also explained that he gets to work on an application that matters to him personally, which is a reward in itself. But then he paused and thought a bit more.

“I think at some point you have to find your motivation from within yourself,” he said. “Sure it’s nice to hear positive feedback, but that’s not ultimately what keeps me going.”

Praise as Manipulation

He’s exactly right. In fact, a system of praise might be the worst feedback you can give developers. According to Alfie Kohn in Five Reasons to Stop Saying “Good Job”, telling your children “good job” can distort their intrinsic desire to do an activity to a desire for the “good job” praise. Kohn writes,

The more we say, “I like the way you….” or “Good ______ing,” the more kids come to rely on our evaluations, our decisions about what’s good and bad, rather than learning to form their own judgments. It leads them to measure their worth in terms of what will lead us to smile and dole out some more approval.

… “Good painting!” may get children to keep painting for as long as we keep watching and praising. But, warns Lilian Katz, one of the country’s leading authorities on early childhood education, “once attention is withdrawn, many kids won’t touch the activity again.” Indeed, an impressive body of scientific research has shown that the more we reward people for doing something, the more they tend to lose interest in whatever they had to do to get the reward. Now the point isn’t to draw, to read, to think, to create – the point is to get the goody, whether it’s an ice cream, a sticker, or a “Good job!” …

In short, “Good job!” doesn’t reassure children; ultimately, it makes them feel less secure. It may even create a vicious circle such that the more we slather on the praise, the more kids seem to need it, so we praise them some more. Sadly, some of these kids will grow into adults who continue to need someone else to pat them on the head and tell them whether what they did was OK. Surely this is not what we want for our daughters and sons.

In other words, as soon as you start praising your children, they seek more praise, so that instead of doing an activity out of the pure enjoyment of it, they do it for your praise. Your praise has begun to manipulate their behavior. When the praise stops, the children lose interest in the activity.

In the developer scenario, implementing a system of praise might similarly diminish the intrinsic motivations of developers. It would manipulate the pure enjoyment they feel when they solve problems, figure out solutions, and conquer cryptic, seemingly impossible scenarios. If you begin patting developers on the back each time they do something right, soon their motivation switches from internal rewards to external praise.

Not Just Advice for Children and Developers

The other day I was eating lunch with some colleagues. One of my colleagues said he was interested in starting a blog, but wanted to know what to do when he publishes a new post and only hears crickets. In other words, what do you do if you write and no one provides any feedback? If no one says, Good job, Tom. Way to go, Tom. Excellent post, Tom. I loved reading this, Tom. Then what do you do? What happens if all you hear is silence?

When silence is all you hear, you have to find an intrinsic motivation for writing. You have to write for a higher purpose, more than simply writing for feedback and praise. You may find yourself writing because you love story, or because you enjoy thinking about ideas, or because you like playing with language.

Comments may provide short-term feedback about the effectiveness of your writing. But in the long run, “good job” comments are detrimental to stoking the writing muse. The day the praising comments stop, your motivation wanes.

So now I’m back to logging bugs, but this time I do it without feeling mixed about where to log the praise. I’m not against giving feedback to developers about the application interface and functionality. Analytical, reasons-based feedback isn’t detrimental, because it helps people evaluate their work from another perspective. But when I have nothing to say besides “Good job here,” I’m witholding my comment.

Blog Sponsors

Documentation Feedback: Don’t Ask if You Don’t Care

Tom Johnson — Mon, 18 May 2009 15:38:51 +0000

Documentation Feedback: Don’t Ask if You Don’t Care

Blog Sponsors

Added a Blog Wall to my site

Tom Johnson — Tue, 27 Jan 2009 06:18:42 +0000

I occasionally receive encouraging emails from blog readers, podcast listeners, people who attended my presentations, and others. These email messages float too quickly through my inbox, so I’ve created a new site feature called a Blog Wall (see the top navigation bar) to capture them more permanently.

On my Blog Wall you can add any general feedback you have about the site, a presentation I gave, or anything else. Of course you can also add comments below posts, but sometimes you just have something general to say. Well, now you have an entire wall to write on.

Blog Wall, a new feature on the site

Blog Sponsors

Adding a Send Feedback link to Your Online Help / RoboHelp Project

Tom Johnson — Fri, 07 Dec 2007 06:32:23 +0000

I was reading an article in a previous STC Intercom magazine about how to add a Send Feedback link to your online help project, but the javascript didn’t work. Here’s an alternative method that does work. This Send Feedback link grabs the page title and URL and includes it in the e-mail that the user sends.

The method below describes the integration using RoboHelp, but the principles apply to almost any online help editor.

To add a Send Feedback link in your RoboHelp project:

Right-click the Templates folder and create a new template (or access an existing one). Then expand the footer section and put your cursor where you want the link inserted.
In RoboHelp 7, go to Insert > HTML > Advanced > Scripts. Insert the following code:

document.write(“ Send Feedback”) ;

This will put the page title and URL in the subject of the e-mail. However, I had some problems with character limits, so here’s an alternative script that puts the URL in the body of the message.

document.write(“Send Feedback”);

The link will now appear in every one of your topics that uses the template.

If you aren’t using the Insert > HTML > Advanced > Scripts method to insert the code, then you need to include script tags around the statement.

Note: In the above scripts, replace joe@support.com and Sample Application with your own email and application name. Also note that if you copy the text, the characters may not copy as displayed.

How do you gather feedback from your users? I’m interested to hear if you have other scripts or techniques.