This week, Meetup’s own Rich Hsieh sat down with the folks at Devpost where they talked about culture fit. What exactly is it? And how is it valued at a company like Meetup? Check out the discussion here:
And then check out our awesome Devpost page where you can read more about what it’s like to work at Meetup, and what the interview process here is like. And you can check out all of our openings!
http://devpost.com/teams/meetup
Last week I was fortunate enough to give the keynote at Mobile Week NYC. It was entitled “It’s Time! What to do When Rebuilding Your App?” and is a case study in how Meetup made the exciting (and difficult) decision to rebuild and redesign our apps.
The keynote meant to answer the big question: “Once teams are spun up and start working on a project like this, then what?” Here are a few of the key Android and iOS engineering topics I covered in my talk.
iOS
One of the biggest decisions we had to make around rebuilding our apps was with our iOS app. Some background on our iOS app is that it was originally built in a 3 month extended hackathon type project back in 2009 by two engineers that did an awesome job getting an MVP shipped. The problem was, it was never re-written over the course of 6 years, accumulating a lot of technical debt. We knew the code wasn’t of the quality we wanted and our test coverage was way too low for our current standards.
Also, much of the institutional knowledge from those who had built the app over 6 years was gone, so we hired — in our opinion — the best mobile engineering shop in NYC — Lickability — to do an in-depth analysis of our codebase. Their output was a spreadsheet of every class in the app (almost 500 classes!), a recommendation as to whether or not the class was salvageable, and metrics around the test coverage.
Following such a detailed assessment, we had the data to know that we needed to re-write almost our entire model code. Naturally, in a redesign you have to rewrite the view/UI code as well, so it was a clear decision for us that in order to futurize Meetup, investing more time in a new codebase that met our quality and testing standards was the right decision for us. Futurize is one of our company values and means: “ We like shipping, but we like investing to ship faster in the future even more.”
After making that decision in 2015, it seemed obvious to us that if we’re going to rebuild our app, Swift was the only way to go. Among many other reasons we love Swift, we especially love that it is statically typed so is type safe just like the rest of our Scala/JVM stack.
Once the decision was made to rebuild our iOS app from scratch, the next key decision we had to make was Swift 1 or 2, because Swift 2 was still in beta. We decided on Swift 2 because it both compiles and runs faster, is a great boost to our team’s morale to be able to start off working with and contributing to a the latest open source iOS language, and we saw it as a great way to attract people who wanted to make Meetup now using the future of iOS.
The second decision we made was supporting iOS 9 and above for minimum version support in the new app. We had a lot of data that showed how quickly our member base would upgrade to iOS 9 and how few members would be left on iOS 8. We didn’t like that we’d leave any member behind. But, not only did the data support it, but our engineering assessment was that building for iOS 9 and above would significantly reduce the amount of code we’d need to write — freeing us up to build and ship other features faster. Specifically, supporting iOS 9 allowed us to use the new UIStackView class, providing an easy interface for laying out a collection of views and leveraging Auto Layout for creating UIs that adapt to the device’s screen size and orientation.
Android
The decision making process around building our Android app was very different. The foundation of our Android app was much better, the code quality and test coverage was much higher, and the lead engineer working on the app had already been working on it for several years.
We had the institutional knowledge in house to do an assessment of the codebase and determined that we’d have to refactor and re-write significant things, but that there were parts that would serve us well in the future. During our assessment we identified key areas we needed to address and this is how we handled them.
The biggest change we made was to go all in using RxJava for reactive programming in Android. It really helps us get concurrency under control with little effort because it abstracts everything to far fewer lines of code. This was a big deal for us because we’re loading so much data from the network using multiple API calls and our API has to support many different clients at once (Android, iOS app, Apple Watch, Web). So, it’s hard for the API to always return data to a client app in a single call that’s exactly the way each client app needs it every time.
Our Android team absolutely loves RxJava because they know that they can composite multiple calls on the client (meaning they can easily wait for both to complete, then do something in the app) in just few lines of code. They can do this without adding additional complexity (for example, composing Futures) or having to manage things like if a user tapped away from the screen. It’s been the biggest improvement for us in the new app architecture.
We’ve also loved using OKHTTP from Square as our HTTP client. It helps us load data from the API into the app faster, save bandwidth usage, and really make our app more responsive – it just feels and works awesomely fast.
We use Jackson for data processing and agree with the Jackson Project page that says it’s “the best data processor for Java”. It supports every format you’d want with streaming parsing and data-binding.
Last, but not least, Guava is a set of core libraries from Google that really helped us handle a broad range of things like collections, caching, I/O, and has really reduced the amount of code we’ve needed to write ourselves.
Thanks!
Mobile Week NYC was a great experience and there were a lot of interesting talks there. Thanks to the conference organizers for inviting me to speak and to everyone who attended and participated! I learned a lot and met many passionate, smart people doing great things in mobile.
Our Devpost site contains bios and fun facts about some of our team members, myself included. We’ve also shared data on the ethnicity and gender background for some of our employees, broken down by the company and our engineering team.
There are many factors which go into building an inclusive culture at Meetup and this data represents only one part of the picture. A fuller portrait would include people such as our CTO, Yvette Pasqua, and other women in leadership roles. What this data does is provide a snapshot of team members who self-identify within the parameters of federally required EEO-1 reporting categories and have chosen to share this information. I care deeply about inclusion both within and beyond this. For example, this data doesn’t capture gender information aside from “male” and “female” - a topic which I will be speaking about at PyCon this June.
I think that sharing diversity data is a critical first step towards transparency and accountability. I’m proud to work to help create a company whose makeup reflects the diversity of our Meetup members, and to help create an industry whose makeup reflects the diversity of our world.
Anne DeCusatis is a Core Engineer on Meetup’s Retention team.
Towards the end of the first week of March, on March 4th and March 5th, Meetup put together a small team of engineers who volunteered to attend the 6th annual Northeast Scala Symposium in Philadelphia.
I am an engineer on Meetup’s Member Engagement team, building a system that delivers smart and personalized notifications to members on our platform. I am also a part of Meetup’s Core Engineering team, where we are using Scala a lot in order to build out our platform. Given my work and interest in Scala, I was one of the engineers who participated in the trip, and I’d love to share some of the things I learned during Day 2 of the event!
This was the first language conference I have ever attended and it was even more exciting to me, given that I only started working in Scala since I joined Meetup, almost 2 years ago, straight out of college!
Day 2 was the unconference day and it started with a casual meeting, in which every participant who had something to present would take a timeslot on a spreadsheet, such that at the end of the meeting we had a relative schedule for the day. After this, everyone was free to go to whichever presentation was most appealing to them.
And off I went!
Eager to learn more about Scala and the theoretical background behind it (and being a math nerd), I picked Category Theory as my first presentation to attend. I did not know much about what Categories are in Scala and what kind of rules govern these entities, but I went in excited to learn something new.
The talk started with an abstract definition of Categories as collections of objects and arrows (or maps/morphisms) that define relationships between the objects. These concepts seemed very familiar to me from those of Set Theory.
Rúnar went on into describing Functors (maps between Categories, that preserve their structure) and then explained what Monads, Monoids and Comonads were, while also doing some whiteboard Scala examples of all of this. These topics were necessary background needed in order to answer a question posed by someone in the audience:
Prove that List is a comonad in the monoid category of List
Using the information absorbed up to that point, we were able to follow a simple proof of the statement.
This was my first ever exposure to Category Theory and I loved it! Rúnar’s explanations made me dig more into it after the conference!
The second presentation I went to was also led by Rúnar Bjarnason, but this time it was very hands-on. He introduced us to a small IRC client & server built using scalaz-stream and everyone in the room had to implement a feature of their preference to add to it.
I went on trying to implement the ability to change nicknames while in a chatroom. The process of working with scalaz-stream and, implicitly, with scalaz was relatively new to me since I haven’t written pure functional code using scalaz before, but it was a really good experience to be exposed to both of these Scala libraries.
By the end of the workshop, my implementation ended up being somewhat functional :)
After a couple of other presentations, I got to my last presentation of the day. It was about a known Scala compiler bug and it involved a lot of live coding, type-level programming, category theory (d'oh) and just pure amazement.
The gist of the presentation was a proof of concept of the compiler bug and ways to get around it. It was very well explained and, even though the material got pretty intense towards the end, I enjoyed the deep dive!
I really enjoyed my time at NE Scala and learned a lot of new things, from theoretical aspects of Category Theory, to more applied concepts using pure functional scalaz. I am very excited for the next conference I’m going to attend (or even unconference, since Scala Days 2016 is approaching and will be in NYC :) )!
Interested in working at Meetup? We worked with our friends at DevPost to put together a page about our engineering team. Find out details about dev process and our tech stack, plus check out interviews with our great engineers.
