Category Archives: VMware

the sysadmin as tinkerer

I’ve spent most of the past four years talking to sysadmins.  Sysadmins come in many different varieties.  Some sysadmins work by themselves, and they either know enough about everything under their purview or they know how to work a search engine well enough to fake it.  Other sysadmins are specialists, and they know one thing backwards and forwards, and they know a lot about what hooks up to their one thing, and they usually know at least something about many other things.

When I’m asked to describe sysadmins, I often describe them as people who are very good at solving problems.  I still think that this is true.  Now I think it’s the side effect of something more central.

Sysadmins are tinkerers.  They might be buttoned-up tinkerers who always have a backup of whatever it is that they’re working on so that they can revert to a known good state.  They might be inveterate tinkerers who will have an idea and just try it out, and rely on their tinkering skills to be able to get themselves out of a jam.  In either case, they’re tinkering to get it to work better.  “Better” can mean anything from using less power to integrating with another application to giving more meaningful alarms.

Sysadmins tinker not just for the satisfaction of tinkering.  They tinker to make their lives easier.  A friend told me that the best sysadmins are lazy.  They don’t want to get woken up in the middle of the night, they don’t want to have to repeat the same thing.  They tinker so that they have less to worry about and less work to do.

The form that this tinkering takes can be of many types.  It could be learning all of the internals of an application so that they can better integrate it into their infrastructure.  It could be scripting so that they can automate something that is important to them, or annoys them, or that they just wish that they didn’t have to do.  It could be playing with the latest and greatest technology to see if it really is as great as the hype to see if it meets their needs.

The sysadmin gets an idea and tries out solutions.  They tinker with it to see if they can get it right.  They poke and prod at it, and try it from different angles, and see what works.  They don’t decide on a solution (although they might have a solution decided for them) and go out and read up everything on it and get trained on that solution.  They try out the solution to see if it really does fit their needs.  If their tinkering results in something really useful, they might invest in something like training, or they might just continue tinkering and figuring it out on their own.

VMworld call for papers is now open

The VMworld 2014 call for papers is now open!  The deadline is May 2.  More details are here.

Mac admins, I’d love to see some presentations about effectively virtualizing Mac environments.  There’s lots of Mac users at VMworld.  It’s time to show great examples of Mac virtualization beyond the desktop.

“why I like the vSphere web client a lot!”

I missed this post over the holidays: “why I like the vSphere web client a lot!”  There’s a couple of things in it that are near and dear to my heart, such as Mac support1, Works in Progress2, and tags3.

  1. I’ve been advocating for this ever since I joined
  2. Internally, we still call it by its original name, TIWO (tee-whoa): Things I’m Working On.
  3. My first major research project at VMware was about tags.

requirements for being a UX researcher

A major requirement for being a UX researcher is flexibility.  User research has many moving pieces.  Any of them can fail, and a researcher has to be able to handle it with aplomb and with minimal disruption.

If a user study involves a prototype or working code, there is always a chance for error.  There can be bugs in the prototype or unexpected technology issues.  The user could also come up with a different solution than the one intended to be studied by the researcher, which might not work at all.  The user researcher has to try to minimize the chances of such issues in advance, as well as handle them discreetly during the study in such a way that the research participant doesn’t feel interrupted.

Research that involves participants at scheduled times comes with its own set of challenges.  Participants can be late (or early!), or need to reschedule, or not show up.  There is also the chance that a carefully-selected participant might not be a good participant, in which case the researcher has to gently handle the situation to ensure that the participant doesn’t have a bad experience and also that anyone who is observing the research doesn’t draw invalid conclusions.

There are several characteristics that I look for in researchers to indicate how good they are.  Researchers tend to be scrupulously on-time (often early), because they never want to keep a participant waiting.  They tend to keep their calendar updated so that they can accurately schedule participants.  They build in time for unforeseen issues.  They are excellent communicators, and are also very good at following up.  They take excellent notes, and they are able to get to the heart of the matter quickly.  They can get up-to-speed on something new very quickly, and ask excellent questions along the way.

This is all a very long way of saying that my team is currently hiring for a researcher.  Ping me if you’re interested.

vCenter Operations Manager users needed

I’m conducting a usability study for vCenter Operations Manager (vCOps) next week, and I’m looking for users of that application to participate.  I’m interested in people who use vCOps frequently to manage and monitor their vSphere environment, and I would prefer people who are running it in a production environment and aren’t just testing it out.  If this is you, please fill out this questionnaire to tell me more about how you use vCOps and what your environment is like.

Feel free to send this to anyone you know who uses vCOps.  If you have any questions, feel free to either email me or add a comment here.

I love easter eggs

I love easter eggs.  They’re a great user experience if done right. They make people feel more connected to your product because they know one of its secrets.  Easter eggs remind people that there are real people behind what they’re using.  They let the team show some personality and a sense of humor.

Last year, someone discovered that we’ve shipped a game of Pong.  Last week, someone else discovered that there’s more to Pong than meets the eye.

I’ll leave it as an exercise for the reader to discover other easter eggs …