I found today that I had inadvertently made a kind of Finder sculpture.
MONEY Magazine: “MONEY Magazine and Salary.com researched hundreds of jobs, considering their growth, pay, stress-levels and other factors. These careers ranked highest.”
What’s highest? Software engineer. That means what I always suspected—that I have, and people like me have, the best job in America. ;) (I do love it, you bet.)
Steven Frank: More On Tech Complexity: “If you made a little box, and all it did was read email, and it did it exactly perfectly, but it didn’t do anything else—well, nobody would buy that. Or close enough to nobody that you would only survive as an extremely niche product. Where’s the web browser? Where’s the MP3 player? Where’s the streaming value-add broadband content?” (Via Gus. Okay, actually I subscribe to Steven’s feed too, but Gus linked to this post before I did. ;)
Daniel Jalkut: Easy Programming: “Surely it must be easy. In fact, that’s my new mantra.”
Daniel makes the excellent point (among many) that adding features has to be done carefully. One of the lessons a new developer learns is that everyone is always asking for features, and hardly anyone ever asks you to take anything out. Hardly anyone ever thanks you for the features that aren’t in there.
But you learn—they’re thinking it, even if they don’t say it. (And, if they’re not, pretend they are.) My advice is to remember that fact, especially when nine out of ten emails you get are feature requests, and all the comments you see are about some feature that doesn’t exist, and it seems like the only way to get anywhere is to add a ton of features. Stay cool.
(In case it’s not obvious, I take pride in having removed the weblog editor and the Notepad. Those were big features in NetNewsWire 1.x, and now they’re not in the app at all. I’m always on the lookout for features I can get rid of—in fact, I’ve occasionally thought about how it would be to cool to have anti-feature request days, where folks are invited to write about what they’d get rid of and why.)
I will add a note of caution, though—simple doesn’t do well in the market just because it’s simple. An app can have few features and be inelegant and bad; an app can have tons of features and be elegant and good. Various forms of quality enter into it. However, it’s easier to achieve elegance with a smaller list of features.
P.S. I’m still learning how to use my iPod. The thing is, it’s not really intuitive and simple. How do I know that pressing and holding the whatever button will make it turn on or off? Trial and error, mainly: there’s nothing to indicate it. What makes the iPod great isn’t that it’s so easy-to-learn, it’s that it’s fun to learn.
Here’s Paul Kafasis on how Rogue Amoeba got its name.
When people ask me how Ranchero Software got its name, I wish I could tell a great story—but I can’t.
The year was 1997. The hot companies and products had names like Marimba, Java, Lasso, Tango—names ending in vowels, often Spanish. So we looked for a similar name ending in a vowel with an available domain name. We found ranchero.com. (And liked it.)
(It had nothing to do with the Adam Ant song Los Rancheros. ;)
Life and Deatherage: More unfortunate headline juxtapositions: “Tests for what? Intelligence? Humanity?”
It was cool to see Greg Reinacker’s in-depth Anatomy of an outage which details what happened (what caused NewsGator to go down) and what’s being done.
Rogue Amoeba: Pistols At Dawn or How Not To Request A Feature.
Different developers have similar experiences, absolutely.
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....
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.
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 , then email the report to support at newsgator. (Also include any details you can think of, such as: this happens every time I do _____.)
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.
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...)
I pointed to a Crazy Apple Rumors Site story from ranchero.com the other day: Developers To Mac Users: “Just Boot Into Windows.” (There’s a fake quote from me in there—which is pretty much a guarantee of a link back from me.)
And then I got interview requests and people arguing with me about it. ;)
That’s what I get for linking to it straight, I suppose.
On another subject... is anyone else impressed with Niall Kennedy’s 21 years of Java experience? (The post talks about 15 years, but I added 6 because it was talking about the year 2000.)
Niall Kennedy: “Starting next week I will join Microsoft’s Windows Live division to create a new product team around syndication technologies such as RSS and Atom.”
Congrats to Niall! (And congrats to Microsoft—smart move hiring Niall.)
Nick Bradbury wrote more about Niall and his new job and RSS at Microsoft.
I’ve got a spare monitor and an old spare Windows machine and a spare bit of desk—I was thinking of installing Linux.
(I’ve used Linux before, LinuxPPC especially.)
So... Ubuntu or Fedora? (Or something else?)
I have two main reasons for running Linux:
1. To check out the latest progress in the Linux desktop world, to see what’s cool and how folks are doing.
2. To have a light-duty in-house server. (Just for private use, not Internet-facing.)
Yes, these are two very different needs. But this is Linux, it can handle it. ;)
It seems like Ubuntu gets a lot of attention for its desktop.
The website is a bit touchy-feely for me, though. I don’t like the smiling faces of those people in a circle looking up at me. But then, I laugh when people cry on TV. I’m mean.
Fedora seems like it might be more the geek’s Linux, and I’m a geek—but that goes against #1: I really do want to see a Linux desktop that’s made usability gains, and it sounds as if Ubuntu is where it’s at. (Since I’m a Mac OS X geek, I’m a user interface geek as well as a command-line geek.)
I have a cell phone—but it’s a basic, plain phone. Not a Blackberry or Treo or anything.
I was thinking it would be cool to get something where I could get my email, read my (synced!) feeds, even browse the web.
But then, I was looking at these cool phones, and from everything I’ve read they sound slow and under-powered.
One option was to go with the latest Palm PDA instead. The TX includes Wi-Fi support, so it would actually be relatively fast, which is important. It wouldn’t connect to the Internet when I’m out of range of a network, but that’s not that big a deal.
(I’m a long-time Palm OS user—my current PDA is way old, though: it’s a Handspring visor. Yes, Handspring.)
I think that, eventually, the smartphones thing will be the way to go, and PDAs won’t exist as separate products anymore. But I’m just not sure the phones are ready yet for people like me who are so profoundly impatient.
But I’m just thinking out loud. What do you think? Are any of the current phones good to go? Or is there some other PDA that’s better? Or...?
A bunch of crunchy screechy noises, then the folder with a question mark in it—it looks like the hard drive in my development machine is a goner.
It’s not an old machine, either—I just got it in February. (Or March. I forget.)
Anyway... having learned the lesson years ago about making backups, I only lost a couple hours of work. (The work happens to be easy to re-create, which is lucky.) Naturally I have other Macs here in the lab, so I’m not stuck.
But, still, sheesh, it’s a downer when your cool new machine needs to go to the shop.
(If there’s a lesson for anybody, it’s that making backups is a Very Good Idea. Dew eet.)