{"id":430,"date":"2011-06-08T14:28:56","date_gmt":"2011-06-08T21:28:56","guid":{"rendered":"http:\/\/www.nadynerichmond.com\/blog\/?p=430"},"modified":"2011-06-09T13:14:19","modified_gmt":"2011-06-09T20:14:19","slug":"on-taking-and-giving-feedback","status":"publish","type":"post","link":"https:\/\/www.nadynerichmond.com\/blog\/2011\/06\/08\/on-taking-and-giving-feedback\/","title":{"rendered":"on taking, and giving, feedback"},"content":{"rendered":"

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

After being asked your location, you\u2019re 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.<\/p><\/blockquote>\n

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

Just before WWDC started2<\/a><\/sup>, I read\u00a0a blog post<\/a> from Marcus Zarra, one of the guys behind the popular\u00a0Cocoa Is My Girlfriend<\/a> blog,\u00a0who has now outed himself as someone on the development team of\u00a0The Daily<\/a>.<\/p>\n

Go read that post. \u00a0This has obviously been bugging him for months. \u00a0His post is a case study in the wrong way to take feedback. \u00a0Combine that with the earlier complaining from another indie Mac\/iOS developer about how “useless” is a loaded word<\/a>. \u00a0At the time, I just pointed out that loaded words matter<\/a>. \u00a0But 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.<\/p>\n

Marcus says that he was surprised by the feedback he got from his fellow Cocoa developers. \u00a0He asserts that, back in some golden age pre-iOS, there was a community and it was all full of sunshine and delight. \u00a0But now, iOS has come, and somehow there’s a “disturbing trend in the community”. \u00a0He 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.<\/p>\n

I can’t agree that the Cocoa development community is one that’s always been perfectly open and loving. \u00a0I’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. \u00a0(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?) \u00a0I’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. \u00a0So no, Marcus, it’s not new. \u00a0It’s just new for you to be on the receiving end of it.<\/p>\n

Taking feedback sucks sometimes. \u00a0You’ve got to put your big girl panties on and deal with it<\/a>. \u00a0Don’t rail against the feedback, and don’t let it get you down either. \u00a0Take what you can from the feedback. \u00a0Learn from the experience, fix what you can, and don’t repeat the same mistakes next time around. \u00a0While you’re at it, learn the lesson of how to give feedback when you’re in a position to do so later.<\/p>\n

So how do you take feedback? \u00a0You listen to it all. \u00a0Let go of your emotional reaction to the negative feedback, and then deeply consider all of the feedback. \u00a0This doesn’t necessarily mean that you do what you’re directed to do by some of those who are offering the feedback. \u00a0It 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.<\/p>\n

One thing that Marcus points out is that “doing something first sucks”. \u00a0He’s right. \u00a0Doing something new means that you have to listen to the initial feedback, and then you have to keep on listening for the ongoing feedback. \u00a0For an application, the initial feedback tells you a lot about first impression and usability. \u00a0Ongoing feedback tells you about usage and learnability. \u00a0If the initial feedback hurts but the ongoing feedback is good, you’ve got one problem to solve. \u00a0If the initial feedback is so bad that you never get ongoing feedback, you’ve got a different problem to solve. \u00a0Without listening to the feedback, you’ll never know which it is, and you’ll never learn anything.<\/p>\n

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