Today’s game:
s/cloud/clown/g
Go to your favorite tech news source and have fun. Here’s a random sampling from Business Week:
I’m now going to have to spend this afternoon’s meeting about vCloud Director trying desperately not to giggle every time there’s ‘cloud’ on a slide.
Casual sexism happens all the time in software engineering. If I hear one more person say that they want to make their app easy enough for their mother or grandmother to use, I’m going to scream. Let’s stop assuming that women aren’t technical or aren’t willing to understand something. And for the love of all that is good in this world, don’t try to justify this one to me. I don’t care if your mom isn’t actually technical, you can still come up with other examples of people who aren’t technical. Don’t be lazy
Women in software engineering have to deal with this casual sexism every day, and mostly we let it go. When you hear it so often, it’s hard to identify it for what it is, and you get tired of being told that it wasn’t actually intended to be sexism. But then you get hit between the eyes with yet another example of casual sexism, such as this displayed in Sqoot’s invitation to an “API jam” in Boston:
That’s right, ladies, you’re just a perk at a hackathon, like the massages and booze.
At first, they tried the “it was just a joke” defense. It took more outcry for them to issue an apology, first by saying that they were “really sorry” (a Google Doc that now no longer exists), and then by saying that “we can do better“.
Yes, you can do better. You can realize that women aren’t a perk. You can realize that you can’t blow it off as “just a little humor”. You can realize that your first non-apology apology isn’t acceptable, and that your second attempt saying that you were just trying to “call attention to the male-dominated tech world” can’t possibly be accurate. Beer wenches call attention to beer and breasts, they’re not an attempt to address gender inequality. Would you try to make call attention to the lack of diversity by pointing out that you’ve got Latinos cleaning the bathrooms?
There’s only one acceptable apology here: “I’m sorry. I was wrong.” No explanations, no posturing, just an admission that you got it wrong. After that admission, the next step is to figure out how you got it so wrong and what you’re going to do about it. Maybe, for example, you need to reach out to local women’s developer groups to try to do something about the “male-dominated” nature of hackathons. Do something, don’t just say that “we can do better”. Tell us what that better thing is that you’re going to do, and make sure that it actually is something better. If your solution is just making sure that there are hot boys to bring pink frilly drinks, you’re still missing the point.
My team has a very large research project coming up, and we’re looking for a contractor to come in and help us for at least three months. In this research project, we’ll be doing a lot of studies in the usability lab.
For this position, we need someone who will own the complete research project. Working with my team, they’ll define the scope of the project and how we will go about answering the questions that we have. They will create the research plan and all usability test materials, including (but certainly not limited to) creating a screener to find participants for the study, setting up the environment for testing, and creating the task list and script. They will conduct the research and analyze the results (which we anticipate will be a mix of qualitative and quantitative).
Candidates should have at least an undergraduate degree in HCI or a related field and 2-3 years of experience in conducting UX research. A stellar candidate will have experience in conducting research on highly-technical enterprise software.
Interested? Have questions? Email me.
In December, we released a tech preview of our View Client for Mac and View Client for Linux. They’re now generally available with updates and fixes. While we were in there updating the code, there’s also updates to the View Client for iPad and View Client for Android. You should go forth and download.
Earlier today, I read an interview with Karina van Schaardenburg, a user experience researcher at Twitter, in which she discusses what she uses to get her job done. In essence, she’s got a laptop for her own use, and she’s got some tools that she uses for data collection and analysis, and she’s got some hardware and software that she uses when she’s conducting her research. As I read it, it was all familiar to me. Specifics aside, Karina’s setup is pretty similar to my own. But I felt like something was missing.
The interview focuses on applications and hardware, and all of the interviews on the usesthis.com site focus on that. Which is fine, in term of the mechanics of what I do as a researcher. But the question that the site is trying to answer is “What do people use to get stuff done?” The tools that I use aren’t what I do to get stuff done.
As a researcher, what I actually do to get stuff done is communicate. I communicate with the design team, the program management team, the development team, and anyone else who I can get to talk tome. That communication is about deciding our goals and priorities. Then I communicate with our users to learn about what they do. Sometimes that communication is conducted via survey, sometimes by interview, sometimes by contextual inquiry, sometimes by usability study. After I’ve completed my research and conducted my analysis of the data, I then circle back with everyone at my company and communicate with them again: what I learned, what steps we should take next. I keep up this communication to ensure that actions are taken, based on my recommendations.
In my opinion, the tools themselves don’t matter that much. Yes, I’m a Mac user, and I use Morae to record my studies, and I use SlideRocket to give presentations to my team, and I use Apple Mail to communicate with everyone involved throughout the process. But those tools isn’t what makes me a good user experience researcher. If you took my Mac and my SlideRocket account away from me, I would still produce good research. The tools are all but orthogonal to the discussion of how I get stuff done. The thing that I actually use to get stuff done is communication.
This isn’t a complaint about the idea behind usesthis.com, and it’s certainly not a commentary on Karina. I think that we understand intrinsically that copying someone else’s setup won’t magically imbue you with their traits and talents. It’s pretty clear that using BBEdit and jailbreaking my iPhone won’t make me a novelist like Charlie Strouss. The tool is only the tool. Answering “what tools do you use to get stuff done” is very different from answering “what do you use to get stuff done”. Communication is what I use to get stuff done. Everything else is just a tool that supports that communication.
Today, the VMware Careers blog has a great post about how to prepare for a technical on-campus interview with VMware. It’s a great post about technical interviews, and reminded me that I should post about how interviews for our user experience team differ from those interviews.
We want to learn about your user experience skills. We’ll ask about projects that you’ve done, and ask about the design and research process that you went through during that project. If you’re doing a design interview, you can expect to do some sketching as we ask you to solve a design problem. If you’re doing a research interview, you can expect to devise a quick research plan to answer a question.
You can expect to flex your design and research skills during our interview. As you’re working through your design or your research approach, make sure to explain your thought process, and ask questions if you need clarification. Be comfortable in front of a white board as you sketch your designs.
Your resume doesn’t stand by itself. Tell us about what isn’t captured on your resume. If you’ve got portfolio pieces that are related to items on your resume, be prepared to show them and explain them.
Don’t be afraid to tell us about what worked and what didn’t work. For example, if you had a research project where no changes were made based on your results, talk about what happened, why it happened, and how you might approach it differently to get a better outcome. If your design didn’t work, tell us what didn’t work about it and what you learned from it.
We want to know that you’re going to fit into our team, and we want you to be happy here. Ask us questions. Is work/life balance important to you? Do you want to attend conferences and publish papers? In what areas do you want to grow in your career? Is working for a green company important to you? In other words, think about what you want in your first job out of college, and ask questions to make sure that you’re going to get that with us.
An interview is not, and should not be, a one-way street. It’s not just about the employer determining if you would be a good employee. It is just as important for you to decide if this is the right company and right team for you. If you’re not happy, your job performance will suffer, and ultimately your career will suffer. Take advantage of the time that you have with us to gather information that will help you decide whether this is the right fit for you.
Speaking of questions: if you’ve got ’em, ask away in the comments, or email me.
I haven’t yet met anyone who really likes Daylight Savings Time (DST). Every spring, everyone complains about losing an hour of sleep. Then you walk through your home and get annoyed by the clocks that aren’t updated automatically. You get even more annoyed when you have a clock that should’ve been updated automatically but wasn’t, or it somehow got updated incorrectly.
Anyone who has colleagues, family, or friends overseas knows that DST is more complicated than that. Other countries might or might not participate in DST, and the dates on which they change their time are not the same.1 When you’re trying to book a meeting or make a telephone call, there’s a few weeks every spring and autumn where you double-check to make sure that you’re not doing it at the wrong time.
DST is a massively complex beast. In the US, it wasn’t until 2007 that the dates for the time change were standardized across the country2. Before that, states and localities could opt out of DST, although you should note that Arizona and Hawaii still don’t observe it.3
“That doesn’t sound too bad,” you’re thinking to yourself right now. There’s not a lot of error conditions to be had here. You could get the date itself wrong, but it’s now standard enough that this isn’t too likely. You could get the time zone wrong, which is probably most likely to be a concern if you’re close to a time zone boundary or if you’re in one of the places that doesn’t observe it. Both of these are probably not going to require a lot of engineering effort.
And it’s not, so long as you’re only dealing with the US. But now pause and consider: as of this writing, there are 196 countries in the world4. Each of these countries potentially has their own dates for recognizing DST. For the countries which observe DST, the dates on which they do so might or might not be standardized, or might be standardized but get moved around if a local government decides to make a small tweak that year. Localities within these countries also can choose not to observe it. Don’t forget that the northern hemisphere is observing DST in one direction, and the southern hemisphere is observing it in the other direction. While you’re at it, realize that “Pacific time” isn’t just the name of a time zone in the US. Wikipedia has a huge page about daylight saving time by country, which gives you an idea of the complexity of this issue.5
All of this is complex enough when we’re thinking about a single clock that needs to update. Let’s add in another layer of complexity: client/server. Your computer has its own internal clock, and it updates against a time server somewhere. That cell phone in your pocket has at least two time sources. It’s got its own internal clock, and it’s also getting the time from the nearest cell towers. Your mail application gets its time from the local computer, and it’s also communicating with the mail server and getting items there that are timestamped. The examples here are all but endless.
In software engineering, we talk about “edge cases”. An edge case is a problem that occurs when you’re at the outside the usual operating parameters. DST is a rat’s nest of edge cases. You can come up with a dozen of them without even trying hard. Anyone who’s worked on an application that deals with this has a horror story about the year Venezuela changed their dates for DST at the last minute, or somehow one server didn’t get the latest code, or a million other edge cases.
I have to wonder: how much engineering time gets wasted on DST every year? Just think of all of the tech companies that have to deal with this: any company that makes a mail or calendar application (IBM, Microsoft, Apple, VMware, …), every mobile phone provider (AT&T, Verizon, T-Mobile, …). Maybe the tech industry could come together to abolish DST and succeed where so many others have failed.
VMware prides itself on how it listens to its users. Here’s another entry into the long list of ways that we listen: a survey about vCenter plug-in usage. It’s six questions, so you can quickly fill it out and help us understand you better!
One of my VMware colleagues is gathering data about the vCenter database. Please fill out this short survey (10 questions, so it’s super-quick!) and tell us about this important part of vCenter.
Some of my VMware colleagues are working on improving the process of managing your VMware product licenses and support. If you’d like to participate in the beta program for this new site, called My VMware, check out this blog post and sign up here.
© 2010-2024 go ahead, mac my day All Rights Reserved