Update: Path’s CEO answered those three questions a minute after I posted this. His response to #2 is a cop out. “Industry best practice” is just a way of avoiding blame. Protect your users data and do what’s right, not what’s typical.

Second time playing it tonight.

There’s lots of stuff going on right now that I’m not part of. That’s the way it goes. Me and Facebook are over. It’s going to stay that way. And if I’m on a ship that’s sinking, well I’ve had a good run, and I can afford to go down with the ship, along with people who share my values. It’s a cause, I’ve discovered, that’s worth giving something up for.

Dave Winer - Scoble: I’ll go down with the ship.

After we write and ship code that probably contains a bug or two (or three), our job is to then write more code, which will also contain bugs. It’s a bad cycle.

This means that someone has to be in the middle, as the face of Flickr, acknowledging these mistakes and going to great lengths to fix things. This is often a thankless job, as users just want their problems to go away and developers (usually) don’t like to be told they messed up. But they do it for the good, and for the love, of the site. Every bug that gets filed and every support case that gets carefully answered makes the site that much better.

After being a liaison between these two worlds long enough, you end up knowing more than anyone else on the team. When you have millions and millions of users that hit every button and link in combinations you would never dream of, then reporting the “interesting” outcomes of their explorations, these support agents become walking encyclopedias of the ins-and-outs of the site and with Flickr, there are odd edge cases waiting on every page. Having people on your team aware of everything the site does is huge. You literally can’t buy that or replace it or outsource it, though it appears that Yahoo thinks it can.

Nolan Caudill - The Front Line. (via MK)

I try to minimize the number of times I use easy in a support reply. I avoid phrases like “Setting up custom menus is easy…” or “Writing a new post is easy…” There are a few reasons for this.

First, if a feature or product were legitimately easy the user would not be writing in to support about how stuck they are. Sure, some percentage of users will find questions to ask about any interface. But do you want to start the conversation by assuming the user falls into that percentage? You venture to learn much more if you assume the software is wrong, not the user.

Second, describing something as easy sets a dangerously high bar for the user when they walk away and try it for themselves. Before you characterize a feature as easy you should be certain it actually is. If you say “easy” and the user does not get it they will, at best, feel like they are wasting your time and, at worst, feel like it is not worth using your product.

Finally, the worst part about saying a product is easy is that it immediately starts the conversation by putting you in command. You are the expert. You are the one who said it was easy. In some cases that is okay. It will work out. But doing so shuts down your opportunity for learning from your users. If, instead, you think back to the days when you did not know everything, you can start the conversation on an equal ground. Help the user accomplish their goal but also learn about where the pain points are so that you can make the user’s experience, and your product, better.

The best support is a conversation. The best support happens when a user learns how to do something new and you learn about how your product can be better. This can only happen when you do not immediately think of your software as easy, intuitive, or simple. If you can remember that you too were once new to things you will end up with a better product and, most importantly, happier users.

Copying only got easier following the passage of these laws—copying will only ever get easier. Right now is as hard as copying will get. Your grandchildren will turn to you and say “Tell me again, Grandpa, about when it was hard to copy things in 2012, when you couldn’t get a drive the size of your fingernail that could hold every song ever recorded, every movie ever made, every word ever spoken, every picture ever taken, everything, and transfer it in such a short period of time you didn’t even notice it was doing it.”

Cory Doctorow - Lockdown: The coming war on general-purpose computing.

• Happiness Takes (A Little) Magic
• All aboard the Cocaine Express
• The Devastating Costs of the Amazon Gold Rush
• The New French Hacker-Artist Underground
• Lockdown: The coming war on general-purpose computing
• Back to Work episodes #48 and #46
• Seminars About Long-Term Thinking: Universal Access to All Knowledge