Device and Browser Usage on LivingSocial’s Website (Q1 2016 Edition)

I could make a list of the benefits of working for a product company, but let’s cut to the chase: access to data over time tops my list. Data—once analyzed and interpreted—can inform decision-making at all levels of the organization: strategy, marketing, design, development. In my experience, it’s been a rare occasion where I’ve had access to this sort of data in a client services setting.

Twice in the last three months I’ve spent an afternoon digging into our traffic data collected with Google Analytics (GA), specifically looking at devices, operating systems, and browsers. I set out to gain a better understanding of the technology our customers use and, in turn, use the data to make some decisions about how we design and build our products.

Let’s first take a look at some stats from the end of last year.

Camaraderie vs. Morale

A few weeks ago I was in a meeting and someone asked a common question, “How’s morale?” My colleague Dave Bock responded, “Well, morale is low. Camaraderie is high.”

The distinction blew my mind and it’s something I’ve given a lot of thought to in recent weeks.

Whether it’s because a new feature launched and isn’t going as well as expected, sales took a hit, a decision is being made, or maybe it’s just a boring Tuesday, we’ve all asked – and been asked – “How is morale?” It’s one of the key ways we judge how everyone is feeling, and its answer has vast implications.

So what exactly is someone asking when they ask about morale? To me, it encompasses a generic sense of how everyone in a group is feeling towards something. In our industry it is often aligned with how everyone is feeling about the company, which often results in a generalized definition based on relative responses. (Specific instances could be how everyone feels about the company’s product choices, status, direction, and so on.)

With or Without You


It’s So Hard To Say Goodbye To Yesterday

Attrition. Forced or voluntary it’s never fun. (Unless we’re talking about Johnny down in Accounting. In which case – good! They’re not your cookies, Johnny!) At LivingSocial our coworkers are a major reason why we work here. They are a fun, energetic, and brilliant bunch. You know what I’m talking about, I’m sure your company is the same way. So when a beloved member of the team leaves it can send you on an emotional rollercoaster where you’re happy they are getting this new opportunity but they did all that work, how will you ever replace them! And they were so funny, you’re just going to miss them so much! Trust me, I understand. But being able to work without someone is just as important as being able to work with them.

On the business side make sure you know what they do. You may think you know but verify. You could discover they were manually running an important script everyday. Or handling a business relationship you knew nothing about. Maybe they have the only login to your AWS account. You don’t want to find out about these things after they are gone. Also, don’t be scared that you’ll suddenly be doing twice the work. While it’s possible sometimes you can decide to just do less with less.

Collaborate and listen.

Champion good ideas.

It’s one of LivingSocial’s company values and it’s what I’m here to do today. The idea? Creating the kind of environment where your team is comfortable asking questions & thinking out loud.

I can hear you asking: but what does that mean!?

For us in Engineering it means we try really hard to acknowledge and answer questions and not let them go unanswered.

It also means we try to contribute to the collective intelligence by thinking aloud (i.e. discussing bugs, issues, etc. in our public Slack channels), as well as summarizing relevant conversations that might’ve happened in DMs or in hallways.

And finally it means we don’t make fun when someone asks a question.

It means a little more work, but collaborative & encouraging cultures don’t happen in a vaccuum. So we do the work!

Michael Evans is a Google Developer Expert

We’re proud to announce that our very own Michael Evans has been selected to be a Google Developer Expert! What does this mean exactly? From Google:

Google Experts are a global network of experienced product strategists, designers, developers and marketing professionals actively supporting developers, startups and companies changing the world through web and mobile applications.

Google Experts are experienced, recognized developers of Google technologies as well as outstanding professionals in product strategy, UX/UI, marketing, growth hacking and monetization. They distinguish themselves through frequently speaking at conferences, share their passion and experience by publishing videos and tutorials, writing code samples, mentoring developers and startups and much more. Thanks to their support, developers, high-potential startups and technical communities around the world build and launch highly innovative apps.

Check out his GDE profile, and feel free to reach out if you have any questions about Android Development. Congratulations, Mike!

Maintenance, Operational Concerns, and Cost

So much of our time as software developers is spent maintaining existing applications and services. I’ve always taken this as a given and treated it as an annoyance as opposed to “real work”. I don’t want to maintain someone else’s old and crappy code! I want to build new things and “do them the right way”. Looking at code that’s as old as the company and trying to make sense of it all is depressing and a total time sink.

Throughout the past few years, my views on software maintenance have changed pretty dramatically. I’ve realized that successful applications in an “Enterprise” environment spend far more time in maintenance mode then they do being actively developed. Consumers of your application don’t care that you used some cutting edge framework or state-of-the-art architectural patterns. They just care that it works and continues to work well.

Sure, these new techniques can be great and I will never discourage developers from trying to optimize the application development process, but operational standards also need to be taken into consideration. Have you given any thought to how your application will look 6 months from now? 1 year from now? 5 years from now? Years after you and your entire team have left the company?

It’s a pretty intimidating task and one far too many choose to simply ignore. Software maintenance is an expensive and time consuming process. Many organizations spend non-trivial amounts of time and energy trying to figure out how to reduce overall maintenance costs. Having to ask these kinds of questions are a pretty solid sign of both technical and process debt. Sounds like its time to make a large payment with interest!

Replace While Loop With Enumerator

Sometimes, it looks like it is not possible to avoid using an accumulating array, a pattern that feels unnatural in Ruby.

Recently, I’ve needed to chase down and unroll pagination links over a JSON / REST api. I don’t know how many pages there will be, and it’s probable (but not guaranteed) that I need to retrieve and use all of the content. Since each page is dependent on results from the previous page, there is no obvious Enumerable parallel. Here, I’ll demonstrate a quick refactoring that will provide in a clean, lazy enumerable object.

This being a HATEOAS API, the next page link is embedded in the response JSON, tucked under a [“links”][“next”] key. To fetch all of the data, I end up with code that looks something like:

def retrieve_all_pages(url)
  widgets = []

  while url
    response = connection.get url
    json     = JSON.parse response.body

    url      = json["links"]["next"]

    widgets.concat json["widgets"]


As ruby goes, this is pretty ugly. When there’s something distinct to enumerate over, it’s recommend to replace the accumulating widgets array with a #map call, or working with some other Enumerable method. Unfortunately, there isn’t a clear parallel for this case.

Inline SVG with PNG Fallback

In response to my recent article on SVG icon sprites, Russell asks:

But my real question is how do you provide fallback support for SVG icons if the browser doesn’t support SVG?

Russell asks an excellent question that I’m sure many front-end developers fret over as we strive to support the capabilities of all of our users’ browsers and devices. Luckily, the state of SVG support in modern browsers is strong. But… there’s still potential for users running older browsers to have a less-than-ideal experience.

So then how can we give the best experience to users with modern browsers and devices without leaving other users out in the cold? Allow me to bang on that old drum we call progressive enhancement