Analysis Paralysis

     I was unaware of this phrase until a friend and colleague mentioned it to me but I was well aware of the symptom.  So many options and choices where do I start?  I suppose I'll come back to it later or even start on a different project with a more obvious starting line.  I believe everyone at one time or another has come across this syndrome and it might have even hindered their production. 

     Personally, I get through this barrier using some other idioms.  I 'jump right in with both feet', 'throw everything at it and see what sticks' and 'move fast and break things'.  Hesitation only makes me think more and when beginning something, that might not be the best way.  Sure, a well thought out plan is great but rarely does anything in my experience end up exactly the way it was planned.

     I believe just knowing the phrase 'Analysis Paralysis' is the first step in conquering the problem.  At least now I have something to search for while I am avoiding what I really need to do...


@RTR_tech

As I write this, today is beach day @RenttheRunway (July 31, 2014).

What does that mean? It means our CEO Jenn Hyman (@Jenn_RTR), decided that the whole team deserved a day of “Mandatory Fun” at an awesome beach with tennis courts and a pool and the whole nine yards, on the company's dime.

A few days before that Jenn spontaneously ordered an ice cream truck to come to the office and give everyone free ice cream. We're not talking 10 people here - we’re talking about the whole, enough-to-fill-multiple-busses, RTR office.

A few days before that there was a Hawaiian style BBQ/Luau at our Dream Fulfillment Center in Jersey (where your dresses are shipped from).

You get the idea.

But lots of startups have occasional crazy fun surprises like that (right?). What's really telling about a company is the day-to-day. This blog is about life @RTR_tech, not RTR in general. Make no mistake: this is a tech organization and it’s an awesome one.

Let me tell you a story. It's going to be a bit scattered, and probably long-winded, but I think you'll like it.

I promise I'll mention some tech along the way.

A little more than a year ago, I was living with my family in Ann Arbor, MI where I had worked for about 13 years. Ann Arbor is an awesome little college town, but my wife wanted to move back to NY where she grew up. As a prerequisite, I wanted to make sure I found a job in NYC where I could truly be happy. This was more difficult than you might imagine.

I was looking for a small-ish, startup-ish, flexible, open-minded tech company with outstanding people.

I eventually discovered a large list of NYC companies of this ilk. Cruising down the list in alphabetical order, I eventually came to Rent the Runway.

"A fashion/e-commerce company?," I thought, "meh."  I passed right over it.

Fortunately, it didn't end there. The CTO of another company (whose selfless kindness I should have repaid long ago) reconnected me with RTR_tech via CTO Camille Fournier (@skamille) I had a phone call with her and was extremely impressed. The rest is history. I also spoke to Vijay (@vjsubr), head of Analytics, Jenn Hyman and various awesome members of the tech team and I was convinced.

One year later, I can tell you that this company is far from just a "fashion/e-commerce company" and is anything but "meh."

These people are awesome and humble. They learn from their mistakes and they learn fast. They actively seek feedback. They listen deeply. They really, honestly care about their teammates. They have created a culture of openness, idea sharing, risk-taking, fun, friendliness, honesty, continuous improvement, teaching and in-the-end, success. And they pay me to hang out with them all day!

What follows is just some of the awesome stuff I’ve had the pleasure of living with @RTR_tech.

First off, we use modern technology tempered with a good bit of wisdom that the “Shiny New Thing” is not always as awesome as it seems. The grass is not always greener on the other side. We’ve adopted a lean-and-mean, modern Java web service framework called Dropwizard. Not Node. Not Scala. Not Python. They're all cool, don't get me wrong, but Java is tried and true and way cooler than you might think if you just take the time to get to know it. :) Plus: Java 8! And cool stuff like @AutoValue. We're working hard to move our front end code to Backbone. There's some Ruby in the mix for good measure. Plus, have you seen what renttherunway.com looks like? It's freaking beautiful! We work with awesome designers and we really care about making it not just work right, but also look great.

We have regular, weekly one-on-one meetings with managers, team leads and peers. These are not perfunctory tech status updates. In these meetings we talk openly about what's bugging us. We refine our goals and take steps towards achieving them. We work to carve out time for people to work on that open source contribution they've had in mind (making @AutoValue work with Hibernate perhaps). As a manager, one of my personal rules of thumb is that performance reviews should not contain any negative surprises (or only good surprises). I've learned to use this one-on-one time to make sure that's the case and that I'm guiding/teaching (and learning from!) my reports to avoid those negative surprises. Just a few days ago I was writing a performance review. When I really got into the meat of it, I realized that I had some new suggestions around goals the person could set, but that we hadn't talked about yet. Before I wrote those things into the review, I grabbed the person and talked through the suggestions. The next day, we had the Important Official Mid-Year Review meeting. I delivered my write-up, and watched the pride swell up in the individual. This is not to say there was no constructive feedback, but that that feedback had already been well established and internalized. That's how you do performance reviews. We do that here @RTR_tech. If you're on my team, you'll get a performance review like that. I really care - we really care - about our teammates as people. In the end, that's all we have. Java code is easy. People are hard. Help them refine and follow their goals. Help them thrive. Help them learn. Help us learn.

@RTR_tech we are a learning organization from top to bottom. As such we’re encouraged (by @skamille and others) to attend technical conferences. RTR_tech will send you to speak or just attend. And of course, @skamille, @markwunsch, and @OMGannaks held a panel discussion @RTR_teach - oops, @RTR_tech - about how to write successful conference presentation proposals, because… they're awesome.

Similarly, we do Drinks and Demos every Friday. This is our chance to share essentially whatever we want as engineers. Maybe it's @timx showing off the new RTR Unlimited product/feature his team just released or @ericqweinstein teaching us some new stuff about "The Rubies." It could be @CarloBarbara doing a case study of how to systematically debug a tough OutOfMemoryError, because, as @skamille says, "don't flail."

Speaking of "don't flail:" you can learn that and so much more by going to @skamille's weekly office hours and having a great discussion with her. I'm not exaggerating that every time you sit down to talk with her, you'll walk away having learned something or with a new perspective on something. She maintains these office hours as a way to remain accessible and keep the communication lines open despite the fact that our tech team is quite large and growing rapidly. How accessible? Our awesome intern Maude (@QcMaude - A Post Internship Look at RTR) has mentioned to me how great it is that she is able to openly talk to Camille as she would any other peer.

There are lots of big brains out there in the world though, and we can't send the entire tech team to the next “Edgy Tech Conference.” In order to fill that gap we bring in guest speakers from time to time. We’ve invited people like the creator of Backbone (@jashkenas) and (@mrb_bk), an engineer from Code Climate (which we use for JS/Ruby static analysis).

"What if," you say, "I get a crazy idea that I just want to try and I never have time to build it?" You'll have your chance! In the year I've been here, we've had a hack day, a (3-day) hack “week” and a full, five-day hack week the last week of August. On hack week you get to work on (more or less) whatever you want as long as it’s vaguely related to making RTR more awesome. Best of all, these hack week projects often turn into real, even huge, projects that alter the roadmap of the company! For example, on renttherunway.com we have a feature where users can upload their own photos. Unfortunately, the quality of these photos varies wildly. What if we had a way to automatically give each photo a quality score so that we could show the higher quality photos more prominently? I happen to have a background in machine vision. For my first hack day project, I built a first cut of such an image quality metric. It was simple, but actually showed visible improvements. (In a nutshell, the metric gave preference to images with 1 or 2 faces and images that are overall brighter.) Another example? Our huge new feature, a whole new subscription-based rental model called RTR Unlimited, started life as a hack week project.

But wait! There's more! A recent new hire asked me if RTR_tech does anything with open source. Indeed, we do! For starters, we are committers and some of the main promoters of the aforementioned Dropwizard. We also have more than one OSS project that we produced internally: Alchemy for A/B testing and Conduit for simplifying the use of message queues. I'm certain these projects are just the beginning. In fact, it's worth noting that our internal software development process is modeled to a degree on open source development. We use pull requests for everything, no matter how small, and naturally, have awesome unit test coverage. This is a great way to develop and combines the best of OSS development with the benefits of being in an office right next to your teammates. For one thing, I have found pervasive code reviews to be an excellent way to spin up new people on company standards or languages that are entirely new to them. It really works and has allowed me to remove one worry from my list of "oh man, new person, so much to cover."

All of this sounds fantastic, but we’re a startup so we must be working like dogs, right?

Well...

We have unlimited vacation. Now I admit to being a bit (a lot) cynical. On joining RTR_tech, I assumed that "unlimited vacation" was code for "guilt-based vacation." I was wrong. This is simply not the case. People take lots of time off, myself included, and I haven't seen any guilt-tripping at all. Remember, we're talking about real people here. Awesome people. It turns out, we respect each others’ need for time off. When @MichelleWernick goes to Paris, we all get excited for her and people step up to help fill the gap in QA. When @skamille goes to Hawaii, we don't flood her inbox; we step up and exercise our latent CTO superpowers. When she gets back, there's Hawaiian candy on the kitchen counter and funny stories about emergency room visits.

In fact, it doesn't end with unlimited vacation. We have stellar work/life balance in general. @RTR_tech we understand that the trick is to anticipate, plan, and course-correct a project early. We work hard to avoid feature creep and instead focus on quality. We work smarter, not harder. In this way, we deliver awesome software without people freaking out at the last minute, having to put out fires, and working 12-hour days. Sure, we're not perfect at it, but we've had major successes and we believe in it. We're continuously improving. (How about a Drinks and Demos presentation about what went right and what went wrong in that last big project release? OK!) We embody this in other ways too: Unlimited vacation begets unlimited maternity leave. (I've seen it more than once! It happens! It works! All companies should do it!) And after your maternity leave, maybe you want to have your newborn brought by the office every day so you can take time to feed it. Of course! Who wouldn't allow that? I have a son and a wife. I get to go home and eat dinner with them and when I return to the office the next day, renttherunway.com is still there and I get to do more cool work on it with my fantastic team! I'm more loyal for the stability it provides. I take the time to write a blog entry because of it, and I spend that much more energy recruiting the next awesome teammate because I love telling them about it! What if you don't have a family? What if you're young and unattached? RTR is in NYC! Go enjoy living in New York Effing City!

Did I mention we're encouraged to write articles for our tech blog? Perhaps you've seen said blog? These kind of things are literally listed in our quarterly tech team goals. "1) Ship feature X so we can rent some more dresses. 2) Post 6 tech blog entries."

OK, I promise I'm almost done gushing, but stick with me a bit longer. There's so many more cool things to tell you.

I had a new junior engineer start recently. I gave him a week or two to settle in before I gave him his first major task. Let me set the stage: we're nearing completion of some initial research that uses Python to do Markov Chain Monte Carlo simulation for parameter inference on a Bayesian Network. (To predict the future. NBD.) I asked New Guy to determine if it's viable for us to port that to Java for production use. (The answer, two weeks later, appears to be yes, if a bit inelegantly, via Yadas (Yada Yada Yadas). So that's a thing we do @RTR_tech. Rad, right?

Our interview process is an area we've recently been working to improve (because we're doing lots of it). So how are we doing? Yesterday, I got overwhelmingly positive feedback from a new hire. He thought that it was fantastic to have an RTR_tech engineer guiding him through the whole interview process, answering his questions, being open, honest and enthusiastic. Shortly thereafter, he took the gig. Sounds like it's working!

Did you notice that I used one or two (or forty-two) Twitter handles here? That's because I'd love for you to join our conversation! I want to hear from you! What are we missing? What more can we do? To my fellow RTR_tech-ers (is that a thing?): what is life @RTR_tech to you? Follow us on Twitter @RTR_tech! But don't stop there! Connect with these awesome people about awesome stuff: @skamille, @ericqweinstein, @markwunsch, @bhsdrew, @CarloBarbara, @timx, and many more (use transitive closure to find everyone!)….

This is life @RTR_tech.

P.S. - I really wanted to figure out how I could work in a joke about Talk Like A Pirate Day being a big deal at RTR, but, as any good engineer knows, sometimes you have to kill your little darlings.


Teams That Fight... to Win!

I joined the company and my current team about two and a half months ago. Very shortly after I started, I learned or started hearing a couple of things: One really loved backend eng was leaving the company. My eng/tech lead partner actually didn’t want/ask for a PM (me) on the backend team. Once the frontend team was done with their recent launch, that team was going to be combined with the backend team. Two new backend engs are coming on. And the frontend team already has a PM…

So I thought, “Whoa! ‘The team’ is becoming a completely new team. This could get interesting.” ...And it has been interesting in the best possible way!

You know those times when you ask your girlfriend or boyfriend if it’s okay for you to grab a quick drink with your ex, and they say, “Sure. That’s fine.” Then, of course, you go ahead and grab that drink only to later find out that it actually wasn’t fine.

...That’s somewhat like where our team started from: not fully trusting each other; going along with things; and avoiding conflicts even when there was disagreement.

Now you hear discussion and debate over what’s important, how should we approach a change, is there confidence with this release, etc. Beyond the work itself, we also openly talk about each other’s preferences and what works/doesn’t for how we can work better together.

We won’t always get everything right, and we’ll need to keep working hard to keep getting better. But I love where we are and where we’re headed.
 

                                     The pyramid model from Patrick Lencioni’s The Five Dysfunctions of a Team.

If you’re familiar with The Five Dysfunctions of a Team, which coincidentally the product and design team read just as our Pillar/dev team was coming together, you’ll appreciate some of the specific changes we’ve seen moving up the pyramid:

There’s more openness around when help is needed, which has led to stronger trust in each other, which in turn has led to more healthy conflict--good fights ;) --where we challenge each other as a team… as partners in crime, with the goal to make the right calls and get the best results.


A Post-Internship Look at RTR

This post was written by our awesome colleague, Maude "It's pronounced 'Mode'" Lemaire, whom we can't wait to welcome back after she finishes school.


I left New York City a few hours ago with every intent to return. Yesterday marked my final day as a tech intern for Rent the Runway but I still feel as though I'll be back on Tuesday, grabbing myself an ice coffee from the kitchen and tackling some new bugs. Needless to say it'll be strange heading to class bright and early and hitting the books once more.

I spent thirteen weeks working alongside some of the most insightful engineers at Rent the Runway's SoHo offices. Within just three months, I learned more than in a single semester of university. Pat (Newell) & John (Holdun) have taught me about writing efficient JavaScript, best CSS practices, and using Backbone to solve just about every problem. After a few weeks, I developed a decent understanding of Ruby where I had none whatsoever previously.

From my experience this summer, I learned most from the code review process. At Rent the Runway, when you're working on a new feature or fixing a bug, you start on a local branch. When you think it's all good, you make a pull request to merge your changes onto the master branch. At that point, your peers will review your code. They'll make comments about syntax, a block of code you can reduce to a single line (sometimes), and the bigger picture of your solution; sometimes it turns into a big discussion about how your code will scale and evolve with future features on the horizon. Although it might seem harsh at first, you have to go into the code review process with an open mind and hope to come out of every pull request a better programmer than you were before.

Everyone's constantly talking about building a scalable, maintainable system. There are discussions about the best practices everywhere you turn in the office. Don't know how a system works? Open up your chat and ask someone you think might know. Don't know the specifics of Ruby syntax? Just turn around and ask someone! You'll find experts in a bunch of niches and it's an environment that makes it incredibly easy to learn a ton of new things. As an intern, it's a perfect opportunity to turn to your neighbor and ask them a million questions about what they know! I was able to learn about product, business strategy, marketing and buying in addition to tech just by having coffee chats with coworkers. In terms of work experience diversity, you truly can't beat the Rent the Runway team.

The amount of women in tech at Rent the Runway is surprising. I wasn’t prepared to see so many, coming from a university program where barely 9% of us are women and having worked an internship the previous summer where I was the only woman on my team. It was great to see that no matter what background any programmer was coming from, everyone was open to their ideas. No need to prove yourself (which I've had to do in certain cases) – you're instantly an important part of this dynamic group of hardworking engineers. Even though I was "just an intern," I found that I was the only one ever saying anything of the sort. To my team, I wasn't "just an intern;" by the end of the summer, I was given just as much work as my coworkers and writing as much production code. There were certainly times when I seriously screwed up a pull request with a million rebasing related commits and caused a fair share of JavaScript errors but I'm happy to say I fixed more problems than I caused.

About a month before my original end date of August 22nd, I was sitting down with Jade, the team lead on our current project, when he asked when I'd be heading back to Montreal. At the time, I'd heard about Hack Week during the last week of August – a full five days of working on anything you wanted (so long as it made Rent the Runway better) and I desperately wanted to stay the extra week. With his support, my internship was extended by a week and I was able to stay and participate in the festivities. To top it all off, a few weeks later I was given a full-time offer! Beyond the perks of free rentals, unlimited vacation, and living in NYC, it's an opportunity I simply cannot pass up. Between the people in tech at RTR and the opportunity for fast-paced growth, Rent the Runway is a really (really) great place to work and you can count on me coming back after graduation.


How to Track Tracking Numbers and Why it Matters

We do a lot of shipping - tens of thousands of pieces a day - so our team has developed a niche expertise around automating the process. Tracking packages is important to us, sometimes in unexpected ways.

Why are tracking numbers important?

From an accounting perspective, we aren’t allowed to recognize revenue until a package has been delivered to the customer - often several days after we have shipped it. A difference of four days may not seem like a big deal, but it’s important for us (and the government!) to paint an accurate financial picture. This is true, incidentally, for anything you order online: although your credit card is charged immediately, the books aren’t balanced until the item arrives at your doorstep.

We send various emails around a package's shipment status: a survey after your dress has arrived, or a friendly reminder to return an overdue dress.

We try to be smart about scheduling when we ship a dress. Knowing exactly how long it will take to arrive back to our warehouse, and its current transit status, is important for maintaining inventory.

And underneath all of this is a goal to decrease our costs: for example, shipping via a truck rather than airplane.

How to track UPS packages with cURL

If you try to search Google for how to use the UPS API you don’t get much more than a link to the UPS. There’s a cottage industry around understanding and wrapping shipping APIs. I think most developers don’t bother to try because they seem intimidating and arcane.

In practice, we’ve found it’s really not so intimidating (though it is a bit arcane). Here’s the minimum you need to use `curl` and start fetching tracking information directly from the UPS!

Create a UPS account

This is by far the least intuitive step of the process. You have to both create the UPS account, and then fill out another online form (instructions here) to request API access. I had initially thought there would be a delay, but in fact they give you API credentials immediately after registering.

Take note of your Access Key, which they also email you after requesting API access.

(If you’re already doing UPS shipping, you probably already have a UPS account and just need the API Access Key.)

Download the documentation

Once you’ve logged in, you can access the documentation for all UPS APIs. Their APIs are all XML-based. You can choose between a SOAP interface or a simplified XML. I'm partial to their basic XML interface. Oddly, if you know the direct link you can download the documentation. Specifically, we will be looking at the tracking API.

The documentation contains sample SOAP and XML requests, WSDL files, XML schemas, and detailed documentation on all of the input and output fields. Their API is surprisingly robust and well-documented.

Create the request XML

The UPS API has a strange format: you literally concatenate two XML files, and then POST the result to a URL.

The first part has your credentials, and the second is the actual tracking request.

<?xml version="1.0" ?>
<AccessRequest xml:lang='en-US'>
<AccessLicenseNumber>ACCESS_LICENSE_NUMBER</AccessLicenseNumber>
<UserId>username</UserId>
<Password>password</Password>
</AccessRequest>

<?xml version="1.0" ?>
<TrackRequest>
<Request>
<RequestAction>Track</RequestAction>
</Request>
<TrackingNumber>1Z0020421361795425</TrackingNumber>
</TrackRequest>

curl away!

url -X POST -d @ups.xml https://wwwcie.ups.com/ups.app/xml/Track

The output XML has all of the information you would expect to find on the website: tracking status, package weight, shipping method, etc. The document is well-formed and easy to parse.

For Python programmers…

I implemented package tracking, along with other API features, in a most-excellent library called ClassicUPS. Feel free to make a pull request!

Conclusion

As customers, we refresh the UPS website to see when our package will be delivered. But that status information is used by merchants, auditors, accountants, marketers, and lawyers to provide accountability for transactions between buyers and sellers. There is a lot of opportunity for businesses to use tracking status in clever ways, and from an engineering perspective, it is surprisingly easy to fetch and work with this information directly from the UPS.

Happy hacking!