I went to XOXO. If you want a summary of what happened Anil live blogged it. If you want a shorter summary Jason has it.

Though I agree with Jason in that no summary will really capture what it was like because “you had to be there.”

But this isn’t about XOXO, it’s about something I saw there. It’s about something I have been obsessing about since I saw it and it’s about a possible future.

I have been aware of the MakerBot and 3D printing for many years. Sometime in 2002 a friend mailed me a Klein bottle he secretly made on his company’s multi-million dollar machine. The curves of the bottle were made up of tiny segmented angles that when viewed from a distance looked like a smooth curve, but up close you could see where the computer was. It was very pretty and very fragile (oops).

This weekend among the toys, art, games, and electronics being shown in the Market there was a MakerBot working away on a watchband. In front of the device were some of the items it had made, and I was surprised to see that the plastic quality and accuracy was much better than I would have imagined.

You can still see those segments in this Klein bottle printed on a MakerBot. But the difference is that it is much cheaper to use and maintain.

But it still didn’t click for me. What clicked is when my friend told me how she got her new ring. She said she complimented someone on their ring at XOXO and that person just went and printed one for her. Now they both had the ring.

DSCF2549 preview card

You can make one for yourself here.

Rather than thinking about the MakerBot as a printer or creator of objects. It feels more like one end of a doorway between computer models and physical objects. Sort of how printed (on paper) words as representations of text files can be OCR’d right back into the computer for archiving.

Anil Dash has already walked down this road. In his post a MakerBot (when paired with a 3d camera) could “teleport” your cool ring or wine stopper to a friend by scanning and sending the bits to their fabricator. Rather than thinking of it as a fax machine or simply a printer of new things, you can think of it as a kind of “teleporter” of existing things. Either from here to your friend over there or from here to yourself a few years from now.

It’s funny to me that I had read Anil’s post last year, but only after touching and seeing a MakerBot work did it really click with me. My mind has been racing with ideas of a future where you could scan all your possessions and archive them along with digital photos for unarchiving. All the chairs, salt shakers, lamps, computer keyboards, picture frames, alligator clips, and stuff you keep around because you might need it someday could be archived on disk in case you do need them someday.

I really, really want a MakerBot.


I’ve had this idea bouncing around in my head for a while, and I want to do it, but the project would require a lot of time that I do not have. So here is the idea for someone else to take and make.

The point of this site is to help people build sites they are dreaming of building (THE IRONY).

Description: A site that you sign into with Github. You create a new project and then point it at a publicly accessible Git repo containing a suite of tests that you wrote for your project. Yes, you have to write all the tests first.

But here is the cool part: people can fork your project of tests, build the app that the tests are testing and then issue a pull request. You then can initiate tests (here be some magic) via a brand new EC2 instance that gets fired up, and if all tests pass you can accept the pull request and thank/pay/whatever the person who submitted the completed or partial project.


I did this today. I thought I’d write it up so I can remember for next time.

I’m working on another project using Django and have liked using the ORM more than any other of the big Python ORMs out there. On MLKSHK we use the beloved FlyingCow, one that we (Ivan) wrote, but when working for clients I like to use as much existing, tested code out there as possible.

First, create a new directory in the root of your project. Throw two files in there: __init__.py and models.py.

Next, create a settings.py file in your project, fill in the necessary stuff for your database and for INSTALLED_APPS include the name of the directory you made. In this case I made a directory/module called “orm”.

    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': '',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',


Now create your models in models.py. Note the Meta class.

from django.db import models

class Doink(models.Model):
    name = models.CharField(max_length=25, blank=True)
    created_at = models.DateTimeField(auto_now_add=True, null=True)
    class Meta:
        db_table = u'doink'
        app_label= u'orm'

The first attribute:

is self-explanatory, but
is there to help Django know this is part of the orm package. Normally it would infer this from the module it lived in inside of Django but since we’re not in Django it breaks without it.

Last thing you need to do is set the DJANGO_SETTINGS_MODULE environment variable:


You can now run

django-admin.py syncdb  --pythonpath=.
and your models will be created.

In your code, use your models like normal:

from orm.models import Doink

Doink will now work like any other Django model.


This past _why day an email made the rounds that _why had sent two years prior to someone asking how they could become a better programmer.

The crux of the email was: if you follow the rules you are not going to maximize your risk and your creativity will suffer. Programming, for him, was about experimentation and discovery versus adhering to rules to produce objectively good code. He didn’t write tests. He didn’t follow any particular style or convention. He did some pretty amazing things. (And then he disappeared.)

The entity/story/folk hero that was _why is one of my favorite subjects to talk about when I’m drunk and talking about Ruby or Rails. If you haven’t read about _why you really should start with his Wikipedia page and definitely his book: Why’s (Poignant) Guide to Ruby. (I’m a fan of _why, can you tell?)

BUT…here at Simpleform one of our (and I will use this word even though my Catholic mother would give me a dirty look for using it that way) religions is testing. The other is shipping. We love shipping. Shipping is what makes your day worth it and if I leave my office having not shipped anything I mope.

The shipping is the fun part, the work is the testing. Testing builds trust amongst our team and with our clients. Without testing we’re potentially handing our clients a time-bomb, and worse, we’re charging for it. I hate this feeling.

So we test because we want to ship. And we ship because we want to make our clients happy. And if we can’t ship then nobody is happy. So we adhere to a set of standards and styles guides on how to test and how to organize our code.

There’s this line religious people use when they encounter atheists: “Without religion, where do you get your morals from?” Which is hilarious because I responded the other day to someone, “Without tests, where do you get your confidence in the code from?” and then realized what I was sounding like and laughed and laughed—but really I don’t get where the confidence comes from.

I used to think I was good enough to write code without tests. And to be honest, I never experienced a problem so major that data was lost or leaked. At FM every engineer was responsible for their own code and that plan mostly worked. Nothing catastrophic ever happened. But in the back of my mind there was always a worry that it might. It would only be a matter of time before something bad happened and I always felt a little nervous when I’d hear something wasn’t working correctly.

Even worse, changing a critical part of the application was always an arduous task of user testing and re-testing. It wasted time. It created a lot of worry and even when it was done I’d never feel great about it. Automated testing means you can make those changes and feel great when you ship.

And we love to ship.

When you’re done reading _why’s email, you’ll notice the top comment that was voted up is:

“As someone who maintains _why's code these days, please, write some tests.”


Back during SXSW Caterina posted about FOMO. The Fear Of Missing Out. I'm a big consumer of social media but sometimes I realize I’m consuming because of FOMO rather than having time or an interest in what people are sharing at that moment.

When I first read her piece we were deep into MLKSHK and trying to get it out the door. It stuck with me that I was very likely helping to create FOMO for our users and I wanted to be sure we gave them some control over that.

One feature of MLKSHK is the bookmark. It looks like this:

A bookmark gets automatically generated when you first hit MLKSHK and will (try) to stay in that location even if adjacent files are deleted.

The part that says “You started reading here 5 minutes ago” is how it launched about two months ago. As you read through your paginated stream you would run into your previous location and know that you had caught up. The problem with this is that it sometimes felt like a bottomless pit. When am I going to hit the end?

We just added the second part: “Jump to previous”. This allows you to jump back in time to your last bookmark and begin reading forward. You’ll be able to get an idea how far back you are by the post times on files.

We have a lot more ideas on how to combat FOMO. I hope to be showing you some more of them in the coming weeks as we roll them out.


“Complain about the way other people make software by making software.”

I keep wanting to tweet that, but I feel like it's too big of an idea to stuff in a tweet without explanation. It should be unpacked because not everyone can make software, and not everyone works somewhere that they can contribute to good software. Plus, it is complaining about people complaining and meta-complaints never seem to work on Twitter.

But I do feel that many people who take shots at products (some they don't even pay for) are overly critical of them with no goal of providing their readers or friends with a constructive perspective.

Worse is when the people doing the complaining also make software or web sites or iPhone applications themselves. As visible leaders of the web, I think there are a lot of folks who could do a favor to younger, less experienced people by setting an example of critiquing to raise up rather than critiquing to tear down.

If you're a well known web or app developer who complains a lot on Twitter about other people's projects, I am very likely talking about you. You and I both know that there are many reasons why something works a certain way or why something in the backend would affect the way something works on the front-end.

As I tweeted a few weeks ago:

Many of my favorite blogs are change logs.less than a minute ago via Twitter for Mac Favorite Retweet Reply

I love reading the changelogs for apps I use. On my iPhone I read each update before upgrading, excited to see where the developers are spending their time. From libraries I rely on I use changelogs to figure out where the library is going and if the engineers still have their hearts in it.

I love making software. I feel like it's my way to state what I believe is a good way of doing things. When we didn't do infinite scrolling on MLKSHK it was because we wanted to say "We don't think that's an experience that's needed for viewing images and engaging with others—it's a way to quickly scan." We have very little AJAX except where it serves to keep the user from navigating away from a page. We love to think about these things. It's fun.

Because of this I feel a lot of empathy for other teams that end up as punching bags on Twitter due to rough edges on their products or missing features that "would just be so easy to add". While I don't want to make excuses for real, poorly run and developed products, or dysfunctional teams or teams with sales and marketing with their fingers in the product, I just don't see how complaining in 140 characters can solve anything.

I think making the right choices when you face them is the best way to say how things should be done. Having empathy for people doing what you are doing is as important as having empathy for your own users.

I'm the co-founder of MLKSHK an image and video sharing site I started with my wife. Sign up for the waitlist we'll let you know when we're ready to add more users.


You may have heard that Delicious is shutting down (or not?). Someone on Twitter suggested that a group of engineers should get together on a weekend and build a Delicious clone. In anticipation of this mystery group of people sitting down and doing this, I thought I'd make a quick todo list for them.

  1. Account System - You'll have to adopt all the standard patterns that are typical of a web application:
    1. Database to hold accounts.
    2. Register and install an SSL cert to appease the security minded. Also: where are you hosting this? What database? MySQL? Good. InnoDB? If you're deploying with another engineer, have the typical 30 minute conversation about deploying databases every two hours.
    3. Decide on the ORM, or just write some lightweight classes that do the tedious crap. Hopefully you selected a framework that has some helpers for all the verification options otherwise…
    4. Methods in the User account model to verify email, length and strength of password, a good idea of the account names you want to hold back so you can still make paths like /admin or /static later on.
    5. Lost password flow. You'll want to generate a key and store it someplace for when someone requests to reset their password. So that's another email that has to go out.
    6. Sign In flow.
    7. Sign Out flow. (Be sure and use a POST method to sign out. See why here <- signs you out of delicious)
    8. Sign up, display errors.
    9. Update your settings, name, password, email—Doh! You'll have to verify the email again.
    10. An account verification system done through email so you can verify people have given the correct information.
    11. Scheduled backups of your database being pushed to a separate location. Binlogs? Mysqldump? You'll have to write a script or configure your off-site DB slave. You might also want to test that it works.
    12. Oh hey, you can delete your account on Delicious? What does this mean for the bookmarks, favorites, and friend relationship interfaces you haven't even written yet? Save that one for later I guess.
  2. Following and being followed flow. This includes:
    1. A database for holding friend relationships.
    2. An interface for looking at everyone you follow.
    3. An interface for looking at everyone who follows you.
    4. Ability on each of the above pages to follow (or unfollow), probably using AJAX because people don't want to leave the page. Also you're going to want to paginate that, some people are popular.
    5. Blocking followers and the processes that recognize a follower has been blocked when displaying content.
    6. The required database indexes for extracting and displaying follower counts.
  3. So before we get to bookmarks, what about import tools? Why would anyone move to your system without import tools? You will need:
    1. A task queue. Hopefully distributed so you can pass importing off to your workers on other boxes when things get overloaded.
    2. Some sense of the different formats you'll need to process. Delicious being the big one, but there's Google's product, Diigo, Xmarks and Pinboard. Also people are going to want to import from their browsers. I'm not even talking about actually processing these things, just understanding and researching the formats and pitfalls is going to take some time.
    3. Actually doing the processing. What happens when something fails? Do you offer a report? There's a new page. Can they retry without duplicating inserts? I'm really only scratching the surface here, this is tedious shit.
  4. Tags. Related tags. Searching tags. Recent tags. Explore tags. You gotta use that task queue for offloading a lot of this. When does it run? What happens when it fails? Seriously, I don't even want to think about tags right now. There has to be a module out there that will do it. Go read the docs to that.
  5. Three letters: A P & I.
  6. You are going to write unit tests for all this, right?

You still haven't fully inspected all your XSS issues, implemented the searching of content, thought about design and UI, errors and documentation, the various methods for storing links like bookmarklets (tested in every browser), or, you know, actually saving bookmarks to a database for presentation to you and others.

Then there's pattern matching on URLs that can be an issue (http://xyz.com/ versus http://www.xyz.com versus https://xyz.com/ versus http://xyz.com/index.html ), I never really thought about that problem, I'm sure it will only take a few minutes. We can deal with it later.

(Thanks to usernameguy and Anil for some inspiration.)


I probably don't understand the iPhone 4 antenna attenuation issue (I barely get Photoshop) but…


The internal layout likely dictates why the antenna has the break below rather than above—meaning they needed space for the camera—but still, I was holding my phone and I noticed my finger never goes between those buttons.

Update: Turns out you can't have an antenna at the top of the phone.


Geeking out with this, but here's an idea on how templates and the template languages should do date formatting. Instead of requiring me to type (and remember) something cryptic like:

"%A %d %B %Y %I:%M%p"

I should be able to type something like this:

"Monday 12 July 2010 02:30PM"

And the formatter be smart enough to figure out that the first word is obviously a day name, the next number a day of the month since you wouldn't put a bare year after a day name, the month, the full year, and then following that is obviously a time.

So tired of looking up date formatting strings for every framework and language.


"If VHS home recording is made legal then our industry is ruined."
"If CD quality music is allowed to be sold then our industry is ruined."
"If DAT is made legal then our industry is ruined."
"If the Rio PMP3000 is allowed to be sold then our industry is ruined."
"If file sharing is permitted then our industry is ruined."

The tactic is as old as the hills and used by some pretty dishonest people in the last few years to combat technology they feared would upset the nice apple cart they'd set up. If X happens, then 100% of Y will happen.

Because we are early adopters and because we live at the edge of emerging tech we laugh at the ridiculous arguments lawyers have managed to get in front of judges to uphold, until reason and consumer demand ran over those judgements.

That's why when I read posts about the iPad as this great creativity doom machine I feel a little bothered. Yes, if everyone is required to purchase an iPad tomorrow and not permitted to seek out other computing devices then, yes, it's true: we're fucked. But also nobody will be able to make iPad apps and uh, hmmm.

John Philip Sousa in 1906 (in)famously pointed out that recording devices were a danger to creativity. The quote is laughed at by many because it is similar to the statements at the top of this post. Not only does he predict creativity will be stifled: "These talking machines are going to ruin the artistic development of music in this country." Sousa also makes the claim it will be total: "When I was a boy...in front of every house in the summer evenings, you would find young people together singing the songs of the day or old songs. Today you hear these infernal machines going night and day. We will not have a vocal cord left. The vocal cord will be eliminated by a process of evolution, as was the tail of man when he came from the ape."

OBVIOUSLY the "vocal cord" in that quote is placeholder for musical creativity. Which of course, he was wrong about. But I think he was right to raise the flag about what recording devices meant and the industry they would give birth to. The stifling did actually happen. It was so accepted that we as consumers growing up in last half of the century didn't know a time when "remix and burn" was a normal and legal thing to do.

However, his argument about total annihilation of creativity was bogus, and I think to do it now is even more ridiculous given the century-long conversation that has occurred. Be wary of closed systems: yes. Accept that future generations will only have gray paint and DRM'd pencils to choose from? Come on. You and I grew up (probably) punching Hayes AT codes into modems when others were out running around on the playground. And generations before us were soldering capacitors and breathing lead infused smoke. And generations before that were relaying bawdy jokes by tapping magnets that would send an electrical charge across town.

Anyway, to get back to the title of this post, I will be buying an iPad this weekend because I enjoy using thoughtful, well engineered products. I have tried many times to use non-Apple computers, to use the open and "free" choice and you know what? They are terrible. Really bad! Worse than bad, they're almost creatively stifling.

I think more of those who bang the "freedom of computing" gong should spend a little less time proclaiming the end of creativity at the hands of others and instead start using these products. These are good products! They are built on top of Unix! Why not use them to build even better ones? Under the hood are bash prompts and frameworks that maybe even have lines of code they themselves wrote.

I would buy and use something as free and open as Ubuntu if I actually thought it worked very well. I am completely receptive to its story but absolutely repulsed each time I try to get anything done that isn't in a shell.

Basically I am saying:

If someone builds a better iPad/OS then 100% of my money will go to them.

That is the only true thing I can predict.



I'm in the middle of a book called Coders at Work. Buzz just quoted something from it that is worth reading. The whole book is great. There is a lot of intensely geeky stuff in it that makes me want to hop on my computer and start programming. Totally the way watching Powell + Peralta videos used to make me want to run out and skate.

Last month there was a post by Henry Blodget on things you need to know to become a media mogul. I can't speak for much of it except item #5 "Treat engineers as kings" which bothered me a lot. That's just the wrong way to think about your relationship with engineers and I don't know (or want to work) with many engineers who would accept that kind of treatment.

HOWEVER, going back to the list just now I noticed that item #6 is "Treat customers like kings." Which I think means the bit about engineers is just a fancy way to say get them everything they need to do their job which I can completely agree with. Dual monitors, fast computers, nice chairs, all that stuff. Great.

But I think the whole "king" moniker is a terrible way to position this sort of thing. They're not gods, they're not rock stars, they're just smart (perhaps introverted) people trying to solve complex technical problems in ways that are unlike sales or marketing or accounting. That doesn't make them special, it just means they have different needs.

In the end though, both "as" and "like" are squishy words that ultimately mean "but not really <wink>".


Thingiverse is a database of digital designs that can be made into real, physical objects. You'll need some tools.


Interested in developing a game for the Mac? Matt Gallagher just kicked off a multi-part tutorial on making your own game using CoreAnimation.



I had this idea almost 4 years ago and since my New Year's resolution is build it or let the domain expire, I went ahead and built it on Google App Engine with CherryPy because they both make making things fun.

Basically I wanted a way to have some lists handy that I usually end up converting to some other format, this is that. I'm going to be rich.



Work related post ahead.

Nice to see one of my favorite co-workers at FM talking about something our engineering team believes so strongly in.

It is not easy explaining these principles to people who want to see a detailed six month GANTT chart that takes six weeks to create and six days to undo. If you spend six weeks actually doing the work, you'll be six weeks closer to the goal and six weeks wiser.

The dude with a GANTT chart just has a GANTT chart.

One of our investors has a great analogy about choosing between being a bus or a heat-seeking missile. The bus has a route, a destination, and an itinerary that it must stick to. The heat-seeking missile is built to adjust. You fire it in the general direction then iterate and evaluate as you move forward. Hit the thing that's hot, even if it moves (and it will move).

I'll leave you with a Winer-ism I like a lot from 1995 called We Make Shitty Software…With Bugs! It's just the first four paragraphs (pre-permalink era?) so don't worry about seeing the phrase "Indigo Girls" on that page.


Here's how I'd like to rate things on sites where you rate things.

Pretend these blocks are books, or movies, or video games in a particular genre. Let's say they're movies. Here is how I've arranged (drag and dropped) three of those movies. The better movie is on the right.


A few other people rate some movies in that genre.


Because I share a common pattern (3 items) with Ted, and a few with Alice and Bob, the following are recommended:


What I like about this type of rating is that it forces you to make decisions about what is better than another item. There are no five star movies or percentage ratings that can tie. This is better than that. If you see something new and fit it into the continuum it says something about that movie.

When people ask you if Iron Man is good, you don't say "yes, I gave it four stars" you say, "it's better than Spiderman II but not as good as the Dark Knight." That's meaningful.


Here is how I would like to define relationship permissions to content on social networking sites like Flickr.


In the first image I am assigning someone to a particular friend group. In the second image I'm telling the system which outer-most friend group I want to be able to access newly added content.

Something about selecting cones of permissions this way interests me. I would even like to use it to define severity of bugs, immediacy of problems, or even estimating the magnitude of difficulty something might have.

Oh neat: Caterina, one of the founders of Flickr, responds with some background on this idea and how it is not really a good way to define permissions. Nice to see that someone actually did it. I still think it'd be a nice UI feature for selecting magnitudes.


Now that Youtube has linking directly to specific times in a video all we need now is a "play until" variable and someone can put together a Re-CAPTCHA-like product for transcribing Youtube videos.

After our son was born we started watching TV with closed captioning enabled for when the heater starts blowing. Otherwise we were just blasting the TV to hear above the noise. What I discovered is closed captioning (looking at you CaptionMax) sucks. There's no reason it needs to suck so much for deaf people on the web.

Semi-related: Ryan has a good idea that I hope to see soon. Basically someone needs to auto-generate synopsises so I don't have to watch a whole video or decipher a slideshare to get the gist. Seems like a job for scraping blogs to me, everyone generates a synopsis when linking, why not do some magic on it and produce a blurb for people. Seems like every site could include some JavaScript on their page to pull a synopsis if one has been generated.


This is not so much lazy web idea, more of a wouldn't that be interesting: but how neat would it be to make a web site solely for the purpose of attracting bots which, as they crawl, would create profiles, connections, and activity streams. Something like a digital ant farm, I guess.

I don't know enough about bot cycles to know if they'd even visit much, but I'd sure like to find out.


Two projects released this weekend that are pretty cool if not a bit nerdy.

Huffduffer.com solves the problem of turning a list of MP3s (found on the web or your own) into an RSS feed for people to subscribe to. Excellent story behind the name, too.

Domai.nr helps you identify more creative ways to get the domain name you want by showing you how you can use the other less known TLDs out there.


Joel from BB Gadgets shares a story about his hacker grandfather.

I love that damn blog.


Programmer font surveys show up every couple of months. This one is pretty complete. I had been using Dina for a while, and before that Inconsolata. Recently I installed Droid for no reason other than it came from Google and it was free.

In productivity talks Merlin Mann refers to things like this as fiddling with your work environment as a form procrastination and he's right. Any monospaced font would produce perfectly fine code—but did you see that Ti92Pluspc? So nice. Installing it now…


Two things made me very happy to discover today:

Garrett Murray started a new Flickr group called "My Day, Yesterday" for this video. Dean Allen joined him with this one. Let's have more of this!

Andy Baio and Joshua Schachter created Memeorandum Colors to help identify conservative/liberal bias (and shades in between) in their linking activity. If you're simply interested in running it head over and download now.

If you're into the geeky side of how it works, Andy includes it at the bottom. Today I learned about Singular Value Decomposition. Sweet.


For some reason I finally started poking around in Amazon's Mechanical Turk last week. It figures Andy'd be way ahead of me and used mturk for his latest project Girl Turk.

Andy also links to this survey done (on mturk of course) asking why the turkers turk. I read all of the responses (the whole time visualizing myself getting paid for each of those tasks) and there seems to be a general theme running: people do it because they want to kill time and they like seeing the money accumulate. I wish the surveyor would have asked how much people make on a weekly basis.

Seeing Andy's experiment go so well, performing a few HITS mysefl, and reading these responses, I'm suddenly completely fascinated with the system.


I've been playing around with the Google App Engine for the past few weeks. I threw a simple Django app [http://c-o-l-o-r.net/] up there to test out how the deployment tools worked and found them to be really nice. And if it were a popular app the usage reporting tools look like they'd be just as cool.

Brad Fitzpatrick just announced he and a few other Perl hackers are using their 20% Google time to create a Perl version of the GAE with no promises from the GAE team that it will be included. But if you're a Perl hacker looking for a project to contribute to, that seems like a really good one.


I love these Soda Can Stoves. Not sure if it's age or money, but I seem to remember doing a lot of projects like this when I was younger. Maybe I just don't have time anymore.


Not sure where this is from, but I love it.

Sine vs Cosine.gif
sine vs. cosine

Update: Mike pointed out in the comments that it's sometimes called a "bullshit grinder" which lead me to a Wikipedia article with a little more information.


A dream longtime coming: the ability to use your phone's camera to scan barcodes and then scrape all kinds of APIs to deliver data about the product. Be sure and watch the video demo.

It's interesting to me that the APIs he scrapes for data aren't Google's. I was shocked to find out that Google's replacement for their excellent Search API was a very light-weight AJAX search widget last month. I am hoping Google releases the real Search API at their developer conference this month.

thnx Brian White.



The Economist on the OLPC: "This leads to the final problem that has done the most to disappoint OLPC’s fans: the hubris, arrogance and occasional self-righteousness of OLPC workers. They treated all criticism as enemy fire to be deflected and quashed rather than considered and possibly taken on board." twittered by James


Google Reader's new friendz feature is the worst thing that has ever happened to me in my life! I think it's worth pointing out that when we don't like software, people can turn around a fix quickly. I think Paul's take was best: had Google made it work correctly from the start or soon after launch, people wouldn't have adapted to the broken-ness of the software.

I just like noting things like this to file away in my own development experience. Of course I'm joking about it ruining my life, but I did hide all my friendz; if I want to know what they're sharing I'll read their weblog.