Meet a zulily developer: Beryl


Who are you, and what do you do at zulily?

I am Beryl, a Software Engineer on the EMS (Event Management Systems) Team. I work on the internal tools that help other zulily teams set up and manage sales.

When did you join zulily?

I started at the end of July, 2013 — almost a year and a half ago.

What’s a typical day like for you?

Every day I am usually spending some time working on my assigned projects, reviewing designs or code from other members of my team and supporting users. The work I do on projects depends on the project I am working on as well as at what stage that project is at. Various things I might do for project work include drawing up user interface designs, attending meetings with our users, coding and testing.

What is one of your favorite projects you finished and launched to production?

My favorite would have to be a rewrite of a page that provided an audit for what we sell. The page had become extremely slow, the data source had been deprecated and was often inaccurate and it was not tailored to what our internal users needed to do. When we realized this was taking up a huge amount of time for our users, I was able to talk to them to figure out their intended workflow and propose a new design. Within a fairly short period of time we had a new page up and running that everyone was happier with and that provided accurate data.

What was it like in the early days?  Tell us a crazy story.

When I first joined, I spent some time looking around the application I work on. It was very surprising when I came across a couple of error/info messages that included pictures of my coworkers for humorous effect. Some still exist, but I think they’re slowly starting to disappear…

What gets you excited about working for zulily?

The sense of community I get from other employees. As a developer on internal tools, I get a lot of opportunity to meet with employees from a bunch of different parts of the company. Additionally, I am enjoying getting to know engineers across all tech teams through our small, but growing, women-in-tech community. Even though the company has grown so much since I first started, it still manages to feel just as small!

Meet a zulily Developer: Trevor

Processed with VSCOcamEach month zulily will talk with a developer and learn about a day in the life of a zulily engineer.

Who are you, and what do you do at zulily?

I’m Trevor, a developer on the Relevancy team. Prior to that, I worked on our fulfillment and warehouse management systems.

When did you join zulily?

I started in August of 2010, so it’s been 4 years now.

What was it like in the early days? Tell us a crazy story.

Oh man, where to start….

  • My first desk was the classic startup cliché: a door blank on top of two filing cabinets. (We have proper desks now.)
  • My second day on the job, the director in charge of the Supply Chain team stopped by my desk and introduced herself like so: “Hi, I’m Lys. I hear you’re traveling with me to our vendor site next week?” At that point my manager leaned over and said, “Oh, uh, heh, I meant to ask you: can you go to our vendor next week?”
  • The following week consisted of Lys and me in a conference room with 10 folks in suits from the supply chain logistics company with whom we were gearing up to integrate. I had never worked on anything remotely related to supply chain logistics before, and couldn’t have told you what “GOH” stood for if my life depended on it (“garment on hanger”, if you’re curious). I spent most of that week furiously scribbling notes and wondering what in the world I’d gotten myself into.
  • About a year later, we needed to build our own fulfillment center in Reno. My understanding at the time was that a typical FC startup project took 6 to 9 months. We had 10 weeks to go from an empty building to shipping packages — and we got it done. To me that was a testament to what a small, tightly focused, extremely motivated group of people can do. It was a lot of work, with not a lot of sleep, but in the end it was worth it.

How is that different from now?

Things are much, much less hectic nowadays. We still move fast and set aggressive goals, but we don’t have to burn ourselves out to achieve them. The team is also bigger now, so there are a lot more hands to help carry the load.

What’s a typical day like for you?

I usually get into the office at around 10 am. First off, I usually grab a cup of coffee and check email. Then I give our API monitoring charts a look to make sure everything’s healthy.

99% of the code I work on nowadays is in Java, so once I’ve confirmed that everything’s humming along I’ll fire up IntelliJ and get to coding. Somewhere between 11 a.m and 1 p.m. I’ll take a break for lunch, then back to coding for a few more hours before our daily afternoon standup meeting. After that, more coding, till around 7 p.m. when I head home.

We’re definitely fans of the “ship early, ship often” mantra. It’s not at all unusual for me to push 3 or 4 different builds to production over the course of a day. Of course, there are also plenty of days where I’m heads-down working on larger changes, but we try to keep our changes small enough, and the barrier to releasing new code low enough, that we don’t go dark for long stretches of time.

What gets you excited about working at zulily?

There are so many things:

  • The team is absolutely top-notch. I’m surrounded by smart, talented people, both on my immediate team and across the entire organization. I learn something new from my coworkers every day.
  • We move fast and try new things. Sometimes they work, sometimes they don’t, but every time we learn something new.
  • The Relevancy team’s mandate is to figure out how to quickly and accurately surface the most engaging content for our members. We’re continually searching for ways to improve our systems, either by trying new and novel recommendation algorithms, or by increasing our capacity and reducing the time it takes our recommendations to update in response to user behavior. It’s a fascinating space that combines machine learning with hard-core engineering for scale. I love it.
  • I’ve worked at places building packaged software with 9-to-12-month release cycles. It’s disheartening to put that much effort into a project, just to see it languish on a shelf somewhere because the customer can’t (or won’t) deploy it. Our team is the polar opposite of that-we push new code to production several times a day. This creates an incredible virtuous cycle. The barrier to pushing code live is low, which means you do it more often, which means each change is small, which means it’s both easy to verify and easy to roll back if something goes sideways. With such low friction, we’re constantly pushing forward, constantly improving our service, creating a much richer, more engaging experience for our members.