Monthly Archives: June 2014

women

stop talking about the pipeline problem

2 Comments

I attended a talk last week where an executive was asked about what we can do to better support women in tech.  He listed a couple of initiatives, and closed with a lengthy discussion of the pipeline problem.  The oft-quoted stat, which he included, is that only 18% of computer science degrees are being awarded to women.  It’s time to stop talking about the pipeline problem.

The pipeline problem takes attention away from the real problems that face women in tech today.  The pipeline problem is part of the problem that tech companies have in hiring women who have just completed their college.  The pipeline problem is not the problem for the population of women already in tech.  It ignores that women drop out of technical careers at a significantly higher rate than other careers.  It ignores that women have difficulty acquiring mentors and champions.  It ignores that women are more likely to be judged to be less competent without clear points of excellence, and that they are more likely to be judged as not likable (“bossy”, “pushy”), and that being both competent and likable are important for career success.

The pipeline problem makes the problem someone else’s.  Tech companies say, if only colleges would award more CS degrees to women.  Colleges point out that women aren’t starting CS programs, let alone finishing them, so the problem is really that high schools aren’t preparing girls for CS degrees.  High schools will say that girls aren’t signing up for CS courses, so it must be that middle school isn’t making CS interesting to girls.  Everyone gets to point their finger elsewhere.  No-one takes responsibility.  No-one is accountable.

The pipeline problem ignores that having a job in tech doesn’t require a CS degree.  While I do have a CS degree, many of my colleagues don’t.  My previous officemate’s degree was in history.  One of the best developers I’ve ever met has a degree in philosophy.  Getting a job in tech is not dependent on having a CS degree.  There are lots of jobs in tech, like quality assurance or technical writing or program management, where a CS degree isn’t even necessarily the most desirable degree.  Many of my user experience colleagues have degrees in psychology or the arts.

Focusing on the pipeline problem is an easy answer to a difficult question.  It gives executives an easy out when confronted with the problem.  We do need to do more to get girls interested in technical careers.  We don’t need to pretend that it’s the only problem facing women in tech.

Apple, VMware

Q&A: why virtualize OS X?

The question of why one would virtualize OS X came up on the Mac Enterprise mailing list this week.  I got asked that question elsewhere this week too, so it seems like it’s time for a blog post on the topic.

Given that the OS X EULA requires that you virtualize OS X on Apple hardware, and given that the only Apple hardware that is fully supported by VMware isn’t the most current Mac Pro1, what are the benefits of virtualizing OS X?

  • More efficient use of resources. Even if you’re just running two VMs on a Mini, that’s half the capex of needing two Minis for the same purpose.
  • The ability to add new servers quickly, without needing to buy new hardware.
    • You can add services that you would never be able to justify the hardware spend.
    • If you get an idea for something that might work in your environment, it’s pretty quick and easy to try it out.  You can create a new VM or clone an existing one and try it out.  It lets you tinker.
  • Easy creation of test environments. For those of us who are developing Apple apps (either Mac or iOS), virtualization makes running different test environments a whole lot easier. I’ve heard from a lot of iOS dev shops that have thousands of OS X VMs that run Xcode for dev and test purposes.
  • If you’ve got That One App that only runs on Snow Leopard, you don’t have to have dedicated hardware for it.
  • If you upgrade something in a VM and it doesn’t go well, you can roll back to an earlier snapshot quickly and easily.
  • In a disaster recovery scenario, you can replicate VMs off-site so that you don’t lose anything.
  • High availability increases your uptime.
  • Storing a VM on external storage allows you to bring up that VM on another host (that’s running Apple hardware, of course).

 

 

  1. You can successfully run vSphere on a Mac Mini, it’s just not a supported configuration.  Here’s a recent blog post from New Relic about doing so. ↩
Nadyne

The Atlantic wants “Adventures with Technology” stories

The Atlantic has put out an open call for stories around the theme “Adventures with Technology”.  Here’s what they’ve got to say:

Here’s what we’re looking for: Adventures with technology. We want exciting stories—the kind that warrant telling your friends—about what it’s like living with technology these days. We want you to be able to execute quickly, on a scale measured in days. You don’t have to be at the center of the story, but someone should be.

I’m quite sure some of my friends have excellent stories …

Nadyne, user experience

my perception, your perception

After a presentation, I never know how it went.  I know how I feel after the presentation, which is a mix of still-lingering stage fright and relief that the presentation is over.  There’s also that annoying awareness and self-consciousness that I forgot a point1, which bothers me because I practiced and practiced and still it got lost somewhere in between making sure that the presentation clicker actually worked and that I’m on the slide that I’m intending to be on and making sure that I’m making eye contact with my audience and all of the million other things that are going on in my head when I’m presenting.

As I was driving home after my AltConf talk today, it struck me that this is a lot like what we go through in user experience (and, for that matter, in software engineering).  We remember that awesome thing that we designed back at the very beginning of our project.  And during the project, as we had to make hard decisions about what would stay and what would go, that awesome thing that we designed could become slightly less awesome.  We intended to deliver a whole new world, and the reality of software development is that we don’t always get to deliver that whole new world.  Sometimes we only get to deliver a part of that whole new world.  We measure what we actually delivered versus our perception of what we had planned to deliver, back before we found out that something would be a lot more difficult than we thought it would be or before a key member of the team had a family emergency that set development back six weeks.  We don’t measure what we actually delivered versus our user’s perception of what is available today.  Our users compare our new shiny thing to the old version.  We compare our new shiny thing to the much more shiny thing that only ever existed in our heads and perhaps on an early schedule.

A presentation is the same.  The audience doesn’t know what you intended to say.  It doesn’t know about that fantastically funny anecdote that you intended to include.  It doesn’t know about that quote that perfectly illustrates the point that you wanted to make.  It doesn’t know that you had fantastic bridges from one section to the next constructed.  Your audience only knows what you actually presented in your time on stage, and whether what you presented gave them something new to think about.

I hope that, some day, I’ll be able to divorce my own feelings about a presentation from the presentation itself.  As I said to someone today, watching video of yourself give a presentation is one of the worst forms of torture available.  You can see exactly when you stumbled or stuttered, you can see that point where you skipped that fantastically funny anecdote.  You get to watch yourself make mistakes, and you are watching for an external sign that you made a mistake.  If you’ve done a great job, the audience is never aware of the stumble.  If you’ve done a really good job, they might notice the stumble at the time, but forget it instantly because the presentation continues and they get something out of the presentation.  If you’ve done a good job, they might notice the stumble and even remember it, and they forgive you because you’re human and they know that giving a presentation is hard.

If you attended or watched my AltConf talk today, this is a great example of confirmation bias.  My belief is that I’m not good at giving presentations.  When I watch a video of myself giving a presentation, I see all of the mistakes that I made, or I imagine that I see mistakes.  I notice the mistakes, and I remember them, and it confirms my belief that I’m not good at giving presentations.  I’m not at the point where I can see past my self-consciousness.

To be clear: I’m not fishing for compliments.  I won’t believe you anyway, because you’re not confirming my strongly-held bias.

Slides forthcoming, possibly tomorrow.  The video is available now.

  1. … or two … or more … ↩