So, a Researcher and Six Developers Join a Coding Challenge

Editor’s Note: Hey, a new author! Colleague and Friend of the ‘Lab, Joyce Ohgi, a principal usability researcher here at Oracle Applications User Experience, joined several of our guys and tall man, all-around good dude and Friend of the ‘Lab, Rafa Belloni (@rafabelloni), to form a super-powered team last week.

This is her story, as told from the inside. Enjoy.

I earned $600 in a coding challenge without writing a single line of code.

Well, strictly speaking, $600/7 = $85.71, 7 being the number of members on our team. The challenge in question? The Oracle Applications User Experience Beacons Developer Challenge, a contest between internal Oracle teams to devise a creative solution using Estimote’s beacons and Oracle Facilities data provided by Oracle Spatial.

We were given: the beacons, some sample data, icons, and images, an example app, a pack of poster gum to stick the beacons on walls, and the freedom to do whatever we could: 1) dream up and 2) execute in 48 hours.

Fast forward: Anthony Lai (@anthonslai) and I are standing in front of a room of developers and five judges about to give a presentation on our app, whose back end I still did not fully grasp. How did I get there?

My journey started two days before the official challenge start date. I ate lunch with Tony, one of the developers, and he suggested I join the team because “Why not? It’ll be fun.”

I had heard of the challenge but thought it wasn’t for someone like me, as my now-rusty coding skills were last used for an Intro to C programming class in college; what could I contribute to a contest whose purpose is literally to generate code? But I like Tony, and he promised me it would be fun. So I decided, well, if the team will have me, I’d like to try it out. So I signed up.

One day before the challenge: the team decides to meet in order to: 1) learn each other’s names and 2) come up with a list of ideas, which would be narrowed down once the contest started.

After we all introduced ourselves, the brainstorming began immediately and organically. But, to my surprise, not a single dev was taking notes. How were we going to remember all the ideas and organize ourselves?

As a researcher, one of the basic rules of my job is to always observe and always take notes.

I could be useful! I whipped out my handy iPad with keyboard case and typed away. But some of the ideas didn’t make sense to me, and for the good of the team, I realized I also should be voicing my questions and opinions, not just act as the scribe.

So, I asked questions. It was scary. I was worried they would tease me for not knowing the back-end stuff they were talking about, or for speaking about ideas in terms of users’ needs, instead of the system constraints or technology features.

But the team listened to me. They even agreed with me. Okay, they also disagreed with me sometimes. But they treated me with the same respect they treated each other.

Day of the challenge – final code check-in: Honestly, the whole coding challenge experience is a blur. As a researcher, I’m trained not just to always take notes, but also to take photos whenever possible to retain key details that could be otherwise forgotten.

I got so wrapped up in our project, that I didn’t take a single photo of our group. I did take several pictures of our competition though.

Luckily Kathy Miedema dropped by to wish us luck and also snapped a picture.

Mail Attachment

Photo by Kathy Miedema, used with permission

As for the experience itself, I can only attempt to describe it by painting a picture in words.

We are all seated in the AUX Team’s little Design Room. Although all the chairs are occupied, silence reigns, interrupted only by the soft clicking of keyboards, and the occasional low conversation.

Usually, the mental image of collaboration is of a group of people talking together in a group. But in this case, even though it looked like we were all doing our own separate thing, it was intensely collaborative.

Each of our parts would need to come together by the deadline, so we did constant, impromptu, little check-ins to make sure the pieces we were building would integrate quickly.

I checked-in constantly as well, seeking confirmation that, of the many research methodologies I could use, the ones I chose gave the team the data they needed, i.e. user interviews to capture wants, needs and task flows of the current processes and feedback sessions with key stakeholders.

By the way, if you are interested in learning more about research methodology, you can find more info at UX Direct.

So, back to Anthony and me, standing in front of a crowd, about to launch into our demo.

It was crazy; we didn’t have time to do a run-through before; we had some weird display lags using the projector and the Samsung Gear Live smartwatch; the script was too long, and we ran out of time.

Believe me, I have a list of things that we can improve upon for the next challenge, but our idea was good.

Technically, it was solid, because of the deep expertise of the team, which aggregated probably comes close to 100 years of total development experience, and it was based on real users’ needs because of my research.

Happily, we won 2nd place, and $600. Next year, we’ll be gunning for 1st and the cool $1000 prize, which would net $142.86 for each of us.

All kidding aside, it’s not about the prize money or the recognition. It’s about people using their unique skill sets to build something better than any of them could have built on their own.

I will close with a text exchange between Anthony and me, post-challenge:

Me: Thx for letting me participate. I enjoyed seeing “your world” aka development.
Anthony: Uh oh. We are a test species to you.
Me: Don’t worry. A good researcher observes to understand, not to pass judgment.

And later, when I was fretting that I cost our team the win by not contributing any code, Anthony wrote to me:

Contributing code does not mean contributing; contributing does not mean contributing code.

Editor again: Joyce thought the post needing a closing. Thanks to Joyce, Rafa and our guys, Anthony, Luis, Osvaldo, Raymond and Tony for all their hard work. Consider the post closed. Oh, and find the comments.

10 comments

  1. The presentation glitches magnify for you when you are under the spotlight, but I think the presentation was very well done and seemingly flawless.

  2. Thank you T.O. I’m on my phone and there doesn’t seem to be a way to see a profile for you. Were you a fellow hackathoner?

  3. Thanks for the great post from a non-developer perspective! I agree wholeheartedly with Anthony’s comments. In the past 2 hackathons we’ve run, teams that had design input ranked very high. It’s asking those “dumb” questions and helping to focus on a user story that really helps to make a very compelling entry. Well done, AppsLab (and friends) team!
    If other readers are looking for more details on the Oracle iBeacons hackathon or Beacons, in general, stay tuned. We’ll be publishing some articles in the near future and I’ll send over to the AppsLab editor (aka Jake).

  4. @Laurie: As a kid, I was taught that the only dumb question is the unasked one. 🙂 Has served me well as a researcher. Also, being a good listener. I guess those childhood lessons do come in handy!

  5. I’m disappointed the spam got removed. I thought that maybe if enough accumulated, it would then reveal itself as a message from the universe.

    I do like the ease with which comments are posted though. Freedom of speech for the masses and all that.

  6. Bill should do a context engine analysis on spam to decode the secret messages.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.