Remember “The Daily”?  It launched in February.  It’s a subscription newspaper for your iPad, commissioned by Rupert Murdoch’s News Corp.  The main UI is a carousel, allowing you to flip through the pages of the paper to get to the section that you want.  The UI got panned by many people.  Take this quote from The Telegraph’s review (which starts off by calling the app “a complete failure of imagination”):

After being asked your location, you’re through to the carousel. Imagine tearing out each page of a magazine and having a friend wave them in front of you one at a time.

I think it goes without saying that the rest of this review isn’t any nicer.  But it got worse when Loren Britchter, the dev behind the official Twitter Mac and iOS clients¹, released a YouTube video that he described as “Evening project – The Daily, less slow: 60 fps, full AA, physically correct reflections, (different stacking style).”  His tweet got retweeted all over the place, and most subsequent reviews of The Daily mentioned his video when discussing the UI.

Just before WWDC started², I read a blog post from Marcus Zarra, one of the guys behind the popular Cocoa Is My Girlfriend blog, who has now outed himself as someone on the development team of The Daily.

Go read that post.  This has obviously been bugging him for months.  His post is a case study in the wrong way to take feedback.  Combine that with the earlier complaining from another indie Mac/iOS developer about how “useless” is a loaded word.  At the time, I just pointed out that loaded words matter.  But now, I’m beginning to wonder if the whole indie dev community doesn’t need a lesson in how to put their big girl panties on.

Marcus says that he was surprised by the feedback he got from his fellow Cocoa developers.  He asserts that, back in some golden age pre-iOS, there was a community and it was all full of sunshine and delight.  But now, iOS has come, and somehow there’s a “disturbing trend in the community”.  He describes his fellow indie devs as “hostile” and “piss[ing] on” other applications, especially if those other apps have been discussed in the tech press.

I can’t agree that the Cocoa development community is one that’s always been perfectly open and loving.  I’ve spent enough WWDCs where many other developers and designers wouldn’t talk to me at all once they read my badge and saw that I worked for a very large company.  (Or are you going to try to tell me that it’s okay to shit on your fellow software engineers when they work for The Man instead of by themselves in a local coffee shop?)  I’ve watched my apps get torn apart by other developers, asserting that anyone who worked on those apps must be a complete moron who couldn’t code their way out of a paper bag.  So no, Marcus, it’s not new.  It’s just new for you to be on the receiving end of it.

Taking feedback sucks sometimes.  You’ve got to put your big girl panties on and deal with it.  Don’t rail against the feedback, and don’t let it get you down either.  Take what you can from the feedback.  Learn from the experience, fix what you can, and don’t repeat the same mistakes next time around.  While you’re at it, learn the lesson of how to give feedback when you’re in a position to do so later.

So how do you take feedback?  You listen to it all.  Let go of your emotional reaction to the negative feedback, and then deeply consider all of the feedback.  This doesn’t necessarily mean that you do what you’re directed to do by some of those who are offering the feedback.  It means that you think about what they’ve said (and what they haven’t said), and you then make a decision about what you do about it.

One thing that Marcus points out is that “doing something first sucks”.  He’s right.  Doing something new means that you have to listen to the initial feedback, and then you have to keep on listening for the ongoing feedback.  For an application, the initial feedback tells you a lot about first impression and usability.  Ongoing feedback tells you about usage and learnability.  If the initial feedback hurts but the ongoing feedback is good, you’ve got one problem to solve.  If the initial feedback is so bad that you never get ongoing feedback, you’ve got a different problem to solve.  Without listening to the feedback, you’ll never know which it is, and you’ll never learn anything.

Marcus writes up a few points that he calls “some thoughts from the trenches”.  I sincerely hope that he remembers these in the future, because his points apply to every development project that’s longer than Hello World:

• Deadlines suck. A deadline was chosen for some reason, and changing that deadline is going to be painful — if it’s even possible.
• It’s not as easy as it looks. The duck glides across the water, but underneath, those little legs are kicking away.  On the outside, you might think that it’s got to be easy, but any developer can point out a case where they thought they’d be done in a day but that piece of code somehow took three weeks.
• The last little bit will kill you. This is a corollary to the above: you get the easy stuff done quickly, but then the edge cases are big and messy.
• There’s more to putting an application out there than developing. If you see a number and think “why did they [spend that much | hire that many developers]?”, remember that the number probably doesn’t represent just the development effort.
• Doing a V1 hurts. You’re going to get dinged for not following closely enough to what came before.  What’s more, you’re going to learn so much from doing that V1 that your V2 is better, which will further make your V1 not look quite so sexy.

He doesn’t articulate another point, but this point is pervasive throughout his article:

• The team worked hard to make that app happen. They had constraints that you don’t know from the outside.  Before you come out and piss on someone else’s work, give them the benefit of the doubt.

But still, developers: feedback is a gift.  Sometimes you have to work hard to unwrap that gift.  Every piece of feedback has something in there for you.  Don’t take it personally, but make sure that you listen and you learn.