How to manipulate me (or, Tuesday Whipper-Snapping)

If you read my weblog, there’s a good chance you use my software—and there’s a good chance you’d like me to do something. Something specific—fix a particular bug, add a particular feature.

How do you make it more likely that I’ll do that thing you want me to do? Here’s how to manipulate me....

Mental preparation

You can’t just go into it blind. Getting someone to do something first requires being able to see things from their side.

Imagine you’re in my shoes: you’re me, for a minute. Think about feature requests, for example—you have a list several hundred items long of really, really good ideas. You’ve heard pretty much everything multiple times, though now and again you do hear new ideas. Which just makes the list longer!

Then of course there are bugs to fix, schedules to meet, tests to run, docs to update, user interfaces to design, lots and lots of things. Most of your time is spent just sitting in a chair, coding, because that’s the only way things get done. (Oh, and then there’s email. And writing blog posts. And so on.)

Okay, to put it in a nutshell—the input is like a firehose, and there’s a ton of work to do, and both things are always true.

Back to you being you

Enough of you being in my shoes... here are a few things that don’t work (at least, not anymore ;).

The “just one thing” maneuver

This is the one where if I did “just one thing” then you’d _____ (insert something good). This doesn’t work because, well, I know you really want more than one thing—or you will, anyway. And of course there are lots of people who want just one thing—but it’s a different “just one thing” for each person.

The “I consider the lack of feature x a bug” ploy

When you’d like to see a feature, you can’t make it happen faster by telling me you consider the lack of a feature a bug. It’s clever, yes, but not the nth time. I really do classify stuff by bugs and features, and a feature really is a feature. (Yes, some features are obvious to-dos, but they’re still features.)

The “surely it must be easy for a developer like you” scheme

This one almost works, but I’ve grown immune. (Slowly, over many years.) Very few things are easy. Quite often the coding is easy—the actual coding is one of the easier parts of the job. It’s the user interface design and software architecture that’s harder. Many of the “easy” requests aren’t easy at all. (Some of them require advanced artificial intelligence—and raw computing horsepower—not seen outside the wreckage of the Roswell craft. “Easy” often means “easy to a human”—and, much as I love my Mac, no amount of ardor will give it human intuition.)

The “maybe you should put it to a vote” finagle

I’ve learned not to take that as an insult. It’s not meant that way. I used to think the person was besmirching my ability to determine what’s best for the product based on what I think and the feedback I get. I’ve learned that lots of software developers do in fact take votes from users, and that’s cool—it’s just that I get so much feedback already that setting up voting means more work with not much added benefit. I already know what people are asking for the most.

Being mean

Okay, this one is hugely rare—Mac users being the way they are. (Super-nice folks!) But now and again someone does come across as less than polite. It doesn’t work. I take the bug or request seriously, but I’m not going to give something a higher priority just because the person was rude. (Better to butter me up. Don’t worry about going too far—you can’t. ;)

The secret formula

Now I’ll tell you straight up how to manipulate me: save me time.

Time is so precious, it’s everything.

Saving time with bug reports

Consider bug reports. What’s the hardest thing about a bug report? Almost never is it actually fixing the bug that’s hard. (Sometimes, but not usually.) The hard part is reproducing the bug—that is, understanding what’s going on and being able to make it happen at will.

Once I understand a bug and can make it happen, I can fix it.

Good bug reports contain as much detail as possible and are specific. Generalizing and leaping to conclusions in a bug report is not helpful and is usually incorrect.

For instance, I’ve had bug reports like this: “NetNewsWire doesn’t support UTF-8.”

Well, of course it does. I have no idea what the person is seeing and why he reports this bug. I end up having to play 20 questions, which is a waste of my time and his.

In the end we get it narrowed down to the actual bug—which (for instance) is that the descriptions for a specific feed show as garbage characters rather than the expected characters. Imagine how it would have helped to know the URL of the feed and the specific problem in the first place! (This particular class of bugs, by the way, is usually bugs in the feeds rather than NetNewsWire—but I still check out each report.)

The best bug reports follow this form:

1. What I did. (With as much specific detail as possible. Including URLs of feeds or URLs of weblogs when appropriate!)

2. What I expected to have happen. (Again, with detail.)

3. What actually happened. (With detail.)

Things like screen shots can really help, too—as long as you also use text to explain what’s wrong.

(Why is step #2 important? Because some bugs are expectation bugs. That is, it’s working fine, but you expected something else to happen. Expectation bugs sometimes point to a user interface design or documentation bug. But not always.)

There are two other things that can be super helpful.

1. Send crash logs if the software crashes.

When you send a crash log to Apple, it doesn’t get to me. Until NetNewsWire and MarsEdit have a send-crash-log feature (one of those hundreds of good ideas), you can find the crash logs on disk at [your home folder]/Library/Logs/CrashReporter/[AppName].crash.log.

2. Run sample reports.

If it seems like the software is using the CPU when you don’t expect it to, you can run a sample report and send me the report.

Launch Activity Monitor (/Applications/Utilities/Activity Monitor.app), select the app in the main window, then choose View > Sample Process, then email the report to support at newsgator. (Also include any details you can think of, such as: this happens every time I do _____.)

(Then, if you’re talking about NetNewsWire, disable plugins and JavaScript for news items and web pages, because that’s probably what’s causing the CPU usage. Seriously.)

Sample reports are great because they let me know what the software was actually doing. No guesswork—facts, which saves me tons of time.

Saving time with feature requests

Most people think they’re like most other people most of the time.

And they’re right—except when it comes to software.

The first thing to know when writing feature requests is that, despite what your intuition tells you, despite your experiences in the rest of your life, you are not the representative user. You are specifically you, an individual, with your own ideas and needs and wants. (It’s a Good Thing! Don’t be scared! I’m a doctor, and I’m here to help!)

So... let’s imagine a feature: Tuesday Whipper-Snapping.

It may seem obvious that Tuesday Whipper-Snapping is a slam-dunk. Surely it’s easy to do, surely every user wants Tuesday Whipper-Snapping, surely that would take the software to the next level—surely it’s a bug, really, that Tuesday Whipper-Snapping isn’t already in there.

Say I agree that Tuesday Whipper-Snapping is a good idea. I add it to the list: it’s now the 347th good idea.

The trick, though, is getting me to think it’s a super good idea.

The trick is not, as you might expect, to convince me that it’s something lots of people would want. The trick is to tell me how you would use it, how it would benefit you, how it solves a problem that you have.

Forget about other people—let me do any extrapolating. (It’s my job.) Instead, just tell me a great story about how this feature would be cool for you. (It goes without saying, by the way, that it’s the “just one thing” you have to have. ;)

Also remember that, lots of times, software developers pay more attention to the problem being solved than to the exact feature being requested.

Think of Exposé—I doubt the folks at Apple had feature requests that read like this, “Please make it so that I hit a hot key and all my windows fly around and make it so I can mouse-over them and pick the one I want.” Instead, they probably had feature requests like this: “Please add a global window menu to the Dock so I can more easily pick a window from any app.”

But they listened to the problem and came up with another solution, one that probably nobody had requested specifically, but that is really cool.

Sometimes that happens, sometimes not: I’m just saying that telling a good story is important, because my goal is really to solve problem, not just implement specific requests.

If you tell me good, specific stories about you and the software and the problem you want to solve, then I’ll know why the feature is important, and that makes it more likely I’ll get to it sooner.

That’s it

Have fun with your new Mac Developer Real Life Action Figure! Just remember to treat him right and don’t leave him out in the rain.

(Or, you know, just boot into Windows. ;)

PS 18 days

If I’m so busy coding, how do I have time to write such a huge post as this? It took me 18 days, a little at a time. (And maybe it reads that way, but I don’t have time for editing...)

15 Apr 2006

Archive

Ads via The Deck