Thoughtfully writing a blog post

Blog posts by the Engineering team

Tech Radar Spring 2017 Update

We’ve been trying to use the technology radar concept as a way to document both what technologies we have in use as well as our current thinking on direction. It’s viewed as documentation and not speculation, so our tech radar should never have stuff in it that’s not actually in production.

Not Reinventing the Wheel: Email Validation in Swift

In cycling, a wheel that doesn't wobble is considered to be "true". We're happy with the email validation solution we've found here - it's *also* true, and did not involve re-inventing the wheel.

Continuous Integration and Deployment for iOS

We could not have the luxury of continuous deployment if we didn’t have the discipline of a strong testing process. Tests help us ensure that each new version of the app works well, without having to go through an extensive manual QA process. Tests help us continuously deploy with confidence.

Me and Time Management, Alone in the Thunderdome

Today, I feel pretty comfortable with my relationship to Time. That's a new thing for me to be able to say. Most of my adult life has felt like a Thunderdome style battle to the death with Time.

Remote Pairing with Strangers

Somewhere in a closet in Texas, a desk sits, isolated from the noise of children and clanging dishes. From here, I gather my wits and connect to the outside world. I reach out to other devs.

1:1s | From Meeting to Multiplier

If there’s one thing we probably have in common, it’s that we both have a “1:1”. Some sort of regular check-in meeting with your manager. If you don’t, I urge you to fix that.

Putting the "Erch" in Merchandising

My team at Stitch Fix builds internal tools for our merchandisers, who are responsible for planning and buying inventory that delights our clients. Internally, we are known as the “Erch” team. It’s a funny name with roots deep in Stitch Fix history, but I’ll save that story for another time. Instead, I have a story of my own to share. Prior to joining the Erch Engineering team, I got my start at Stitch Fix on the Merchandising team.

Avoiding Over-Engineering

It’s easy to know if you are under-engineering something, because you produce sloppy work. It’s much harder to know when you’re over-engineering. The root cause of this is expanding the problem at hand so that the solution is much more interesting than the solution to the actual problem.

The Timeless Way of Building Software

In 1977, an important 20th-century architect and prolific author, Christopher Alexander, wrote a book, “A Pattern Language: Towns, Buildings, Construction” followed in 1979 by another book, “The Timeless Way of Building”. These were books about architectural thinking where patterns, a pattern language, and a “way” of building were discussed in depth.

Unsharing the Database

At Stitch Fix, we are currently tackling a pretty common problem among fast-growing startups in the process of scaling. Our applications are overdependent on a shared database, and in order for us to uncouple the various engineering teams from one another and to grow our applications to the next level, we need to unshare it. This blog post will talk about the problems we are trying to solve, and the stepwise approach we are taking to solve them.

Managing Technical Change

One of the biggest challenges to growing an engineering team is dealing with technology choice. Some organizations stop time at the moment they chose their current stack, refusing to add any new technologies. Others allow everyone to use whatever they want, leading to an explosion of unmanageable technologies. Both of these are terrible, but what is the alternative?

The Merchandising Calendar

Since Stitch Fix is a retail company at heart, we operate on the merchandising calendar. The merchandising calendar is used by the retail industry for accounting of sales, inventory and payroll. It originated in the 1930s and became widely adopted by the 1940s. The primary reason for its creation was to guarantee the same number of weekends in comparable months since a large percentage of retail sales occur on weekends. Also the calendar ensures that any end date of a period falls on the same day of the week.

12 Things to consider when deploying HTTP Services

Rather than putting all domain logic into a single application monolith, modern software architectures tend to split functionality into multiple applications and services. There are definitely pros and cons of either design; and it is not the goal of this article to go into the details of what is better and why. However, it is generally agreed upon that one of the detractors of using services is the increased complexity that it brings to the table. Specifically, there are many more points of failure, and building a robust system means expecting that nodes of your system may fail at any given point in time. These failures cannot be ignored and you cannot expect to be able to wait until your nodes are all green to operate normally. In order to address some of the added complexity that services introduce, I’ve compiled a checklist of important elements to consider:

Our Git Branching Model 2016

Way back in 2013, I described Stitch Fix’s git flow, as a reaction to the popular post “A Successful Git Branching Model”. Recently, Jussi Judin posted a reaction using the classic considered harmful tag line. I read the post with enthusiasm, but found the process described still too complex. This felt like a good time to refresh my previous post with how Stitch Fix currently does branching and Git (it’s even simpler than it was in 2013).

Do you know what problem you are trying to solve?

This is a story I will one day tell my grandchildren. But as I have no grandchildren, you, dear reader, will have to do. Now sit down, pop this hard candy in your mouth and look interested.

Thinking Through Heroku's Preboot

Preboot is a feature provided by Heroku that can help you achieve zero downtime deploys. Meaning that when you push a new version of your code, there’s not even a split second that your users experience your app being down.

iOS Code Signing - Part 3

Update (10/31/2016): We’ve written a newer blog post about how we test, integrate and deploy our iOS app. It complements the information here, and includes up-to-date details about our current process.

There Is no Happy Path in Programming

It’s often expedient to discuss the “happy path”, which is the ideal or most simple flow of logic through a system. While it’s a great tool for conversation and identifying requirements, I’ve found it more and more problematic when thinking through actual implementations, especially when there are distributed systems involved. It’s often better to plan and design for all paths from the start.

iOS Code Signing - Part 2

Update (10/31/2016): We’ve written a newer blog post about how we test, integrate and deploy our iOS app. It complements the information here, and includes up-to-date details about our current process.

My Favorite Tech Talks (and Articles) of 2015

I am a tech talk and blog post addict! In the evenings I frequently run on my treadmill and watch at least one tech talk. At our last offsite in San Francisco a few of my co-workers encouraged me to write a post of my favorite tech talks and articles from 2015. Well here they are, in no particular order:

Our iOS Layout Journey

Stitch Fix recently released its first iPhone app! What started as a simple, single-storyboard application is now a complex application with entirely programmatic views. The transformation from storyboard to programmatic views was not straightforward–we experienced the good and the bad of storyboards, .xibs, programmatic views, and in-between hybrids.

Using Consumer Driven Contracts to Reduce the Need for Integration Testing

Here at Stitch Fix, we have many different apps and services. As our infrastructure grows, so does the need to create and define more “micro-services” to centralize and isolate important shared behavior and data. Testing is a very important part of our development process. As we started creating more and more services, we realized that we had to change the way we think about integration tests when services are involved. Here’s a typical workflow that you may be familiar with:

When Bits go Bump in the Night

I think it’s safe to say that on-call week is never something we software engineers eagerly anticipate. I know from past experience, my stress levels tend to uptick, my personal productivity expectations decline, and my eyes are always trained on my email, hoping the dreaded pagerduty alert will not jump from the shadows. But I have to ask myself, what’s driving these negative emotions? And more importantly, are they pointing to possible improvements we as software engineers should implement to make on call duties less of a burden? At Stitch Fix, we’ve acknowledged these concerns and recently implemented strategies to help make on call duties less stressful and more productive.

Interviewing at Stitch Fix

I know it’s trite to say that interviewing for a job is really stressful, but I hope you’ll cut me some slack. The experience is still a little fresh. This summer I dove headfirst into the gauntlet that is Job Hunting for the first time in six years. I’d heard nightmarish stories about what awaited me: riddles and puzzles, trick question whiteboard code exercises, and grueling panel interview sessions. I was, if you’re going to force me to be perfectly honest, scared out of my mind.

Developing New Features With Our Customers

One of the great things about being a software engineer at Stitch Fix is that most of our applications are internal-facing. This means that many of our “customers” are also our co-workers and may even work in the same building as us. For example, I work on our engineering team that supports our merchandising organization - the people who plan, buy, design, and allocate our inventory. Our merchants work with us in our headquarters on Market St. in downtown San Francisco.

iOS Code Signing - Part 1

Update (10/31/2016): We’ve written a newer blog post about how we test, integrate and deploy our iOS app. It complements the information here, and includes up-to-date details about our current process.

Simple Rails APIs with Stitches

We don’t have a single monolithic application—we have lots of special purpose applications. Initially, there were just a few, managed by a few developers, and we used RubyGems to share logic between them. Now, we have over 33 developers, are a much bigger business, and have a lot more code in production. So, we’ve turned to HTTP services. Instead of detailing the virtues of this architecture, I want to talk about how we do this with Rails using a shared gem that’s less than 1,000 lines of code called stitches.

Testing Required, TDD Optional

I’ve been talking to and interviewing quite a few junior software engineers and Rails bootcamp graduates of late. Since testing is so central to our work here at Stitch Fix I usually ask them about it and TDD. Often people respond sheepishly that they don’t really write tests first but they know they should. One person told me that their bootcamp class read the “TDD is dead. Long Live Testing” post by DHH and took away the lesson that testing wasn’t required. I’m pretty much 100% certain that’s not the correct interpretation. Perhaps it points to a problem with TDD in Rails development culture: testing is a requirement and TDD is a choice, but the two are often conflated.

Best Technology Work Culture

Facebook, Uber, Lyft, GitHub, Pandora - an impressive list of companies. And now Stitch Fix, a company devoted to disrupting the retail industry with innovative technology, and where I work as a software engineer, was in direct competition against these organizations.

Anatomy of a Rails Service Object

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects. We’ve thrashed on exactly how these classes should be written, so this post is going to outline what I think is the most successful way to create a service object.

Go for interesting work, not 'interesting' jobs

A couple of years ago a developer friend and I were discussing our ideal engineering jobs. I didn’t have a specific idea of what mine would be but I knew that it would sound boring to most people. Less than a year later I found myself at Stitch Fix doing just that and I could not be happier.

Stitch Fix ❤ UNIX

I ❤ UNIX and using the command line; they help me solve problems at Stitch Fix. I’m not alone. Across the Data Science and Engineering teams, we’re constantly solving problems with UNIX and the command line.

Congratulations on Becoming a Software Engineer

Now you know all about strings and ints and how Hash tables are ordered (or not). You know how to talk to a JSON API and build a Twitter clone in 3 different languages (or maybe 3 different JavaScript frameworks). Your aptitude, technical knowhow and general pluckiness have helped you land your first real Software Development job. Congratulations. This is no easy feat. I know that you put in many hours of study and many more of frustration to get where you are today. By knowing how to write software, you’ve opened up for yourself a whole world of possibilities.

ElasticSearch and Denormalization in Rails

All these JOINs are killing me

Assume the User is Correct

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.

Some Design Up Front

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.

Tip of the Iceberg: In Praise of Internal Apps

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.

Unassuming Apps w/ AngularJS

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™.

Should we use multiple input fields to prevent mistakes by users?

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”.

How We Deal with Failed Resque Jobs

The Grouper Engineering Blog posted a good description of what it’s like to host Resque on Heroku:

The Value of Minimal, Flexible Systems

We call it “Old Admin”. A basic admin interface (similar to Rails’ Active Admin) built by an outside team before the current engineering team arrived. For a time it ran our whole business. One of the first tasks of our original engineers was to replace it with something more sophisticated. However, limited as it was in many ways, it inadvertently taught us some good lessons about designing internal systems.

Resque Brain - a Better resque-web

We use Resque at Stitch Fix…a lot. For background processing or getting work out of the web request/response loop, Resque is our go-to technology.

Rails Application Templates

The ability to quickly create and deploy an application is crucial to avoiding a monolithic architecture. I touched on this in my talk at RubyNation, as well as my post here, but a key part of that ability is to script the actual creation of the application so that it’s ready for your infrastructure and your team. At Stitch Fix, we use Ruby on Rails for most of our applications and, fortunately enough, Rails provides a handy feature called application templates that allows you to script the creation of a new applications with whatever boilerplate you need.

Presenters: Delegation vs Just Making A Struct™

Like most good Rails developers, we use presenters at Stitch Fix. We typically implement them using delegation, but I’ve been finding that the time savings of this approach over just making a struct-like class is negligable, and results in code that’s harder to change and harder to use.

Startup Engineering Team Super Powers

Stitch Fix is the third startup I’ve worked at, and the second where I joined at a fairly early stage. So far, we’ve been able to avoid creating a single monolithic application, and have been consistently delivering and deploying solutions to our users. I believe this is because we’ve developed a set of “super powers” which have been extremely helpful, and I believe these powers will keep our team and technology healthy for years to come.

Our Git Workflow

An old post from Linus Torvalds about using git popped up on Hacker News today, and reminded me of the complex gitflow workflow, as well as Scott Chacon’s post on “Github Flow”, both of which are excellent reads.

Getting OmniAuth with Google Apps to Work on Heroku

At Stitch Fix, we outsource pretty much all of our hosting and technical needs to Heroku or their add-ons. Given where we are now as a company, it makes total sense: we don’t need to hire an admin, we don’t need to adminster actual boxes, and we can easily add/remove/change our technical infrastructure. If you are a small startup and you are messing with Linode slices, you are probably wasting time.

pghrb Lighting Talk

Tonight Jon Dean will be giving a lighting talk at the Pittsburgh Ruby User Group to talk about why business logic in Rails applications should be moved out of the model and into pure Ruby classes. If you’re in the Pittsburgh area be sure to stop by and introduce yourself!

Magma Conf 2013

Jon Dean spoke at Magma Conf 2013 about Inter-Application Communication and RESTful APIs for a Service Oriented Architecture. The talk was intended to provide a basic overview of a few reasons to create a Service Architecture for your platform and some basic starting code for those just beginning to look into it. Take a look here for more information and the slides.