One of the top questions I get asked by my Mac geek friends is how to beta-test Fusion. If you’re interested in participating in betas for either VMware Fusion or VMware Workstation1, fill out the form here. When we’ve got room in our beta program, we’ll send out invitations to those who have expressed interest.
I’m totally a fiend for dogfooding, and I’ve got to say that the next version of Fusion has some awesome stuff coming. More details to come later … !
Want to help us shape the future of VMware High Availability? Fill out this quick survey and tell us about your clustered environment and how you use (or don’t use) HA.
It’s obviously research season, so I’m sure I’ll have more research opportunities to talk about soon …
My user research team at VMware is doing a lot of research. Besides the vCloud Director study that I’m doing, one of my fellow researchers is looking for people who want to talk about their private cloud with us. If you’re interested in sharing details about your private cloud, fill out this very short survey (5 questions!).
My team is conducting research on vCloud Director. I’m interested in talking to org admins who have deployed vCloud Director to their end-users. I’m especially interested in deployments of vCloud Director to end-users who aren’t necessarily very tech-savvy.
In short, my team would like to conduct on-site research with 3-4 people for a given vCloud Director deployment. We’d like to visit you in person, talk with the org admin to learn about the environment and how things are working, and then we’d like to interview some of the vCloud Director end-users at their desks (or whatever else their working environment might be). Each interview would be 60-90 minutes.
If you might be interested in participating and helping to shape the future of vCloud Director, email me for more details.
Somehow, John Welch suckered me into doing a guest appearance on the Angry Mac Bastards podcast with him, Darby Lines, and Peter Cohen. I jumped on the bandwagon this week, mostly to have the opportunity to talk about the recent controversy surrounding Violet Blue’s blog post about WWDC. I’ve already written about it here, so you already know where I stand on the topic.
At one point, Peter asked me about Blue’s assertion that Apple has a monoculture and whether there was something that Apple should do about it. I said no at the time, but later John mentioned the work that he does to try to get more female speakers at Macworld Expo. I’m one of those people: John tracked me down (hmmm, I’m noticing a trend here) and suggested that I put together a talk. I did, and ended up speaking a couple of times at Macworld, which then led into a couple of talks at Exchange Connections too.
I didn’t attend WWDC this year, but I have several times in the past. I can’t recall seeing a woman on stage giving a talk. Maybe I just didn’t attend the right sessions, or maybe it was different this year. Unless there was suddenly a huge influx, that’s one thing that I think that Apple could do: get some more women on stage. I’ve met plenty of Apple women who are qualified to give technical presentations. Get ’em up there. It’s an awesome experience, and that kind of example and mentorship would be a great intangible benefit of WWDC.
The full topic list for my appearance is here, and you can download the podcast here.
Violet Blue, a self-described sex educator, wrote a blog post for ZDNet about WWDC. It’s a long rambling post which seems to be comprised of five blog posts that inexplicably got smushed into one. Smushing them into a single post results in a lack of cohesion and not fully explaining anything. Go read it for yourself: WWDC 2011: No innovation from Apple, developer discontent.
One of her points about WWDC seems to be about the gender imbalance there, with a side trek into an anecdote about trolling a couple of guys by playing dumb chick. The anecdote is pretty obnoxious. A guy comes up to her and another woman and asks what they’re doing here. As a conversation opener with a stranger, I don’t see this question as sexist. It’s just “hi, how are you?” They decided to say that they’re models on vacation, instead of the truth of, “I’m a tech blogger and this is my friend who’s a mobile developer”. If you decide to troll someone and they take you at face value, you don’t get to complain about their behavior afterwards.
Mike Lee, a well-known Mac developer, noted that her behavior is not helping actually get women into the field. She played to the stereotype. He’s right, that doesn’t help at all. But he uses her trolling behavior to jump into a rant about “push[ing] someone into something they are not going to enjoy or be any good at.”
For all that I think that Blue’s original blog post was poorly-written, I’m not sure how Lee got there. If we agree that there aren’t enough women in software engineering and we should do something about it, Lee appears to be saying that the only way to do it is to “look the other way at some terrible work because they wanted to make their diversity numbers”. This isn’t the case: if we want to get more women into software engineering, we need to take a thoughtful look at the research that’s been done to date about the gender disparity and decide the best way to move forward.
Frankly, what rankled me the most was this:
I think it’s cliched bullshit that society pushes women away from engineering with the mentality that “math is hard.” Math is hard. Coding is hard. Engineering is hard. That’s why we get paid so well—because the vast majority of people can’t do what we do.
Yes, there was a time when little girls were supposed to play with dolls and wear dresses, but among the families of the modern engineer, that time islong past. Every parent I know wants their kids to grow up to be great scientists and engineers.
You might think that it’s “cliched bullshit”, but there is plenty of current research that disagrees. There’s some fascinating stuff here about how we behave and how we communicate. The best overview of the research can be found in the report Why So Few? Women in Science, Technology, Engineering, and Mathematics. Although software engineering isn’t its focus, I think we can safely assume that many of the issues that face women in other engineering fields are also issues for women who are in software engineering. Speaking for myself, as a woman who holds two undergraduate degrees (one in CS, the other in math) and a graduate degree (HCI), and has been gainfully employed in software engineering for several years, the issues that are surfaced in that report match my own experience.
The idea that “every parent I know” wants their kids, regardless of gender, to grow up to be an engineer doesn’t necessarily mean that they’re setting them up for that engineering success. Even with the best of intentions, parents might actually still engage in behaviors that undermine girls’ and women’s participation in engineering fields. This isn’t to denigrate anyone, in fact quite the opposite: it shows how pervasive and subtle some behaviors can be, even by people who want to do the right thing and encourage more women to enter the field. For parents who are interested in learning more about these pervasive and subtle behaviors that impact girls starting from a very early age, I recommend Cinderella Ate My Daughter by Peggy Orenstein1. Told through the lens of Orenstein parenting her own little girl, it covers a lot of research about children, gender roles, and behaviors.
In response to my blog post about taking feedback, Bryan started off with the following:
Reading your post about how some developers can’t take “constructive criticism” or as you wrote, “feedback,”
I view “feedback” as a superset of “constructive criticism”. Not all feedback is constructive (nor, of course, is it criticism). Regardless of whether the feedback is positive or negative, or whether it’s critical or supportive, you’ve got to learn how to listen to it and decide what to do about it.
Listening to feedback and figuring out what to do about it is my job as a researcher. I do this all day, every day. Some of it is formal and follows a research methodology; much of it is informal, simply listening to the zeitgeist, understanding it, and applying it when it comes time to do more formal research. If you don’t have the luxury of having me around, there are some researcher skills that can help you in listening to and acting appropriately on feedback1.
Negative feedback hurts. This is true whether or not it’s constructive. We want to do well. When we’ve worked on something, when we’ve poured our blood, sweat, and tears into our application, we want that work to be recognized. If the feedback is constructive, it’s somewhat easier to take to heart. If the feedback is just of the form YOUR APP SUCKS, it’s easy to blow it off.
For constructive criticism, you probably have less work to do to try to understand that feedback. The person giving you the constructive criticism has taken the time to consider what they’re experiencing and how to share that message with you. You probably still have an emotional response to the constructive criticism, and that’s yours to deal with. After you’ve dealt with that emotional response, deciding what to do about it is easier because the other person has already done a lot of the work for you.
When feedback is negative, you’re hit with a double whammy. You’ve got your own emotional response to deal with, and you don’t have a clear path forward. To be more accurate: you have one obvious path forward, which is to blow off the feedback. After all, if someone is just telling you YOUR APP SUCKS and you’re pretty convinced that your app doesn’t suck (and how could it? you’re poured your entire being into that app!), blowing it off isn’t hard.
Blowing off feedback because you don’t like it is the wrong path. Constructive criticism takes time and effort on the part of the person giving it to you. You can’t reasonably expect that everyone who uses your app is going to spend that much time on it. You get much more feedback than you do constructive criticism. Constructive criticism doesn’t tell you the whole story, it only tells you the story from the people who are so invested that they’ll tell you what they perceive is their story. There’s much more out there. You want the whole story, so you’ve got to find out why you’re getting the YOUR APP SUCKS feedback. You’re going to have to do a lot of work to understand what that feedback means and what you should do about it.
This isn’t to say that you act on all feedback that you get. There are plenty of great reasons that you won’t. When you don’t act on feedback, you need to be able to both clearly articulate the problem that’s been shared with you and why you’ve chosen not to do anything about it. Own this, and love this. Knowing what you won’t do is powerful, and is ultimately part of you making an awesome app.
Taking the time to consider feedback will help you make better stuff. You have to let go of your ego, and you have to dust off your detective skills. Feedback is a gift. Take the time to unwrap it.
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 clients1, 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 started2, 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:
He doesn’t articulate another point, but this point is pervasive throughout his article:
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.
The Apple Store is now 10 years old. As I’ve been reading all of the articles in the tech press about it, I realized that I’m not sure when I last set foot in an Apple Store. I think it was about a year ago, when my first iPhone 4 died.
I’ve come to hate the Apple Store experience. I seem to be one of the few. They’re still the most profitable retail store per square foot. I only go into the Apple Store if I absolutely have to, which is to say when I’ve done enough troubleshooting on a piece of Apple hardware to know that it’s a hardware issue and they’re likely going to replace it.
I used to go into the Apple Store to browse, to check out the latest hardware, accessories, and software. I played with the in-store hardware and chatted with the employees. My husband and I would joke that we couldn’t go in there just to browse because bad things would happen to our chequebook. That concern is gone.
The Genius Bar is an awesome idea, and I used to love it. Here’s how it’s described in a 2007 Fortune article about the Apple retail experience:
“When we launched retail, I got this group together, people from a variety of walks of life,” says [Apple’s Ron] Johnson. “As an icebreaker, we said, ‘Tell us about the best service experience you’ve ever had.'” Of the 18 people, 16 said it was in a hotel. This was unexpected. But of course: The concierge desk at a hotel isn’t selling anything; it’s there to help. “We said, ‘Well, how do we create a store that has the friendliness of a Four Seasons Hotel?'” The answer: “Let’s put a bar in our stores. But instead of dispensing alcohol, we dispense advice.”
I think that the Genius Bar has little in common with either a bar or a good hotel concierge any longer. They don’t really dispense advice now. You’ve got to make an appointment if you actually want to talk to a Genius. You can try to talk to someone if you happen to drop in, but there’s a huge wait. There’s often a long wait even if you do have an appointment.
The bar aspect is gone. You usually can’t wait at the bar for your appointment, but just hang around hopefully. There’s no opportunity to be social or informal. They’re too busy to do anything other than give a cursory glance and try to get you out of the way as soon as possible.
I’ve observed that the way that they’re most likely to take care of a problem is simply to give the user a replacement piece of hardware. This, of course, results in a delighted user: their problem has disappeared, and it’s been replaced with a shiny new thing that (presumably) doesn’t have the issue. There’s usually not a lot of troubleshooting or attempt to actually fix the problem. I’ve certainly been quite pleased to have my old and busted iPhone replaced with a new and shiny one. Conceptually, though, I find it amusing that their response to something that isn’t working really isn’t all that different from the old “have you turned it off and back on?” tech support solution.
I don’t go to the Geniuses for software issues. I’ve too often heard them give entirely incorrect information. I once sorted out someone’s MobileMe syncing problem in under five minutes, after a Genius had spent more than an hour on it. I lost count of the number of times I’ve heard them give incorrect information about Office. I even corrected a Genius who told someone that Mail couldn’t work with Gmail.
A few years ago, Apple removed cash registers from their stores. This drives me absolutely batty. I walk in, I want to buy something, and now I’ve got to find someone who can actually do it. I can’t do it at the Genius Bar because they’re always way overbooked. I have to try to find an available employee, and that’s difficult in a packed store. Without a cash register, there’s no way for me to indicate that I want to purchase something without flagging down a passing employee. There’s no queue, and I’ve often been frustrated when someone who has just walked into the store gets the service that I’ve been desperately trying to get for several minutes.
Last week, I came across an essay from the director of a creative agency titled “Your Agency on PCs” in which he has a reasoned discussion about Windows versus Mac. He says this about the Apple Store:
If Apple cared about user experience, they’d build a store with a fucking cash register. I’d rather stab myself in the eye than have to walk past all those glassy-eyed zombies to talk to a “genius.” If I go to the London Drugs down the street, a real person will address my problem, without booking an appointment a week in advance. That’s for any product they sell, and there’s little likelihood of anyone there calling me “dude.”
Yeah, that. That paragraph pretty well encapsulates why I hate the Apple Store. It makes me feel better to know that I’m not the only one.
My colleague Duncan Epping, who is one of the co-authors of the shiny new Cloud Computing with VMware vCloud Director, is giving away a copy signed by VMware CEO Paul Maritz. Head over to his blog to comment and be entered into the drawing!
© 2010-2024 go ahead, mac my day All Rights Reserved