Monthly Archives: January 2012

Quips: Hackathon #2 Recap

It’s been a while since our last hackathon, so we were excited to do another to end the year 2011 at Miso. In the 6 months since our last hackathon, the team at Miso has grown significantly and that has allowed us the option to split into two different teams to work out on separate ideas. I got placed on the Quips team, so that’s what I’ll be talking about today.

What is Quips?

Have you ever hung out with friends, and someone said something so hilarious you wanted to quote them on your social network of choice? That’s the moment we wanted to capture. Drawing inspiration from quote cards from Miso sideshows, we came up with an idea for an iPhone app that let’s you take a picture, slap a quote over it and share it over Twitter! Of course, what’s a photo sharing app without filters a la Instagram? We got that covered too. Our tag line? Appropriately: “Because your friends are hilarious”.

The Journey

The app took 5 of us just 3 days to complete. The team consisted of 2 shared designers (we had two teams), two engineers on iOS and one more on the backend server. Although a relatively simple app, from design and planning to execution, the whole process reminded me of those sleepless nights finishing senior design projects. The difference was that I had a lot of fun doing it, and the only thing that was on the line was my pride in being to do this in the short amount of time we had. At the end, we finished everything within 3 days, and submitted to the app store the day after. Overall it was a success and everyone in the office loved playing with the app.

Lessons Learned

Since it was the second hackathon I’ve participated in, a few mistakes were learned in the past and some news ones were made this time around. I thought it’d be helpful to share a few tips for those attempting a hackathon themselves.

Small and focused – Google wasn’t built in a day, so don’t expect that of yourselves. Avoid ideas where it involves hundreds and thousands of users for it to be worthwhile. Focus on a small idea, and make it awesome. The result will likely be more compelling.

Plan for the worst - I think it’s fair to say that most software engineers are terrible at estimating. Being one, I’m absolutely in love with the idea of building anything in the most ideal time frame. In reality, everything that can go wrong will go wrong when it comes to coding. Though we did a better job this time when it came to coming up with a reasonable design, we still ended up stripping out some parts to cross the finish line.

The devil’s in the details - It took us the first two days to have something somewhat functional, but another whole day to polish and make everything look good and work solid.

Have fun – It will be intense, but don’t let that stop you from exploring new ideas and learning new tools. We liked the Facebook/Path menu, but we didn’t know how it worked so we invested time into building it just for this. Sure it would have been faster going with UI elements we’re familiar with, but what’s the fun in that?

Quip it!

Funny story, we had to resubmit Quips to the app store due to a screenshot having the word “badass” on it. Apple likes to keep everything PG-13 apparently. The app is available in the app store. Go grab it and let us know how you like it!

Miso Engineering Culture, Part I: we believe in sharing

Within Miso as a company, communication is key

Before talking about how the engineering team works, it might be useful to mention Miso is a small team and that we try to communicate efficiently between each other and to be aware of the work others are doing.  Still, we don’t want to waste time by attending meetings which aren’t productive for us.

That’s why we use several channels of communication at work:

  • Yammer,  we use it to post about the status of our work or to share a link for everyone
  • Emails, like everyone else for targeted questions, long updates or event invites
  • Campfire, it’s by far my favorite. We have several topic rooms (Engineering, Support, Design, Product, Marketing). There is always a discussion with those topics, and everyone doesn’t have to be involved in every discussion but we want to be aware of it, campfire is a great tool for that purpose.
  • Meetings, informal discussions, sometimes we chat in-person after all we work in the same open space
  • Gtalk, when we’re too lazy to get up and talk to the person face to face.

Being active in Ruby community: attend meetups, blogging, create open source projects

Ruby community is active, especially in San Francisco, every week we can find a lot of meetups around Ruby/Rails. We try attend meetups weekly or just simply provide a venue for ruby workshops, more generally we try to be involved in the community.

There are 2 goals behind this, promoting what we’re doing and also promoting Ruby. Most of all it’s about sharing and improving our culture. You could learn for example what’s the best practices in hot new startups just by making a connection. This gives you some insight on what you’re doing. It’s a win-win situation to be involved outside of the narrow focus of your company.

Same thing in open source community, we’ve open sourced several projects: like rabl or yaml_record, or recently Gitdocs. By doing so we’ve got a lot of outside contribution Rabl, for instance, has 818 watchers on github and has 13 contributors, that keep improving our gem. Beyond it’s also a way to promote ourself with great codes that will attract new talent.

Blogging is really a good practice to take time to stand back and write down about a technical challenge we’ve been faced with or how we built our last cool feature, and also share with everyone our thoughts. As I keep repeating myself, blogging is also about being communal and have feedbacks from our readers and create a connection with them. The great example I want to share, it’s we found out earlier this week that one of our blog post has been an inspiration for VendorKit.

Sharing is definitely one of our core values that we believe in, because by sharing you receive important feedback, and with feedback you’re going to learn something and build something better. At the end of the day, you’ll become a better software engineer.