As mentioned previously, a lot of what we do at Stitch Fix is create software to run Stitch Fix. While we have a team dedicated to our (external) customers’ experience, most engineers are working on software for internal users.
In data science, or any related quantitative field, we strive to understand and leverage our data for our objectives. These data will usually be part of a bigger project that we’re working on where the workflow looks something like the following:
For the past half year I’ve been exploring Julia in piecemeal fashion. It’s a language that does not conform to the traditional notions of programming. Julia is a high-level, dynamic language (like Python) and is on par with C and Fortran in performance.
Being a good developer means knowing both what to build and how to build it. At Stitch Fix, we don’t have a dedicated product team, so we spend more time than most figuring out what to build1.
Working on a public-facing website can be a ton of fun. You get to show your work off to friends & family, see it get used by a ton of people, and feel the pride of working on what the world thinks of as your company’s “product”. But this is just the tip of the iceberg.
On my personal blog, I outlined some issues with Rails’ front-end support. A lot of discussion around that post had to do with the notion that Rails isn’t for building “ambitious” apps that are client-side heavy. The thinking further goes that for un-ambitious apps, “The Rails Way” (server-generated JavaScript) and JQuery is Just Fine™.
At Stitch Fix, we’re working on our sign-up flow. During this process, we debated whether we should have a single password field, or, as many sites do, two— the second one being a “password confirmation”.
The process of selecting just the right merchandise for each of our clients is not a simple one; there is much that needs to be taken into account. There are parts of the process that can be broken down and framed as a mathematical model of client utility. Here, the individual preferences for each client can be modeled and validated empirically through machine processing of structured data. However, there are other parts that evade such strict rationality assumptions and tend to be better evaluated emotionally or from information not manifested in structured data. For this, we need to rely on the judgments of expert-humans. Each piece contributes distinct value to the overall selection process and exclusive focus on either one would be incomplete. For this reason, the Stitch Fix styling application has been architected to leverage diverse resources - both machines and expert-humans - in order to exhaust all available information and processing.
I just returned having spent a great day in Los Angeles, CA (at UCLA main campus) where I had the pleasure of giving a talk at the R User 2014 Conference. The conference brought together top users and developers of R. It was a great place to share ideas on how to best apply the R language and its tools to address challenges in data management, processing, analytics and visualization.
