Recently Increment published an issue about what it is like being a developer at a number of great companies like Fastly, Lyft, and DigitalOcean. We thought it would be fun to create a blog post answering the same questions about what it’s like at Stitch Fix.
Dan Shultz, Principal Software Engineer and Engineering Manager on the Styling Engineering team at Stitch Fix.
What are the most common tools that developers use at Stitch Fix?
On our Engineering teams, we use Git, GitHub, CircleCI, BugSnag, DataDog, Slack, and our in house Ops tooling called Fixops. Interestingly, we rely heavily on Google Docs for collaboration on projects given how great it works for asynchronous communication and how easy it is to include others outside of the engineering teams. For project and bug management each team has their own tooling preferences ranging from GitHub Projects, Pivotal Tracker, and Jira. We also publish a Tech Radar that shows what tools we use and how we use them.
Which languages do developers code in?
We do experiment with new languages and are comfortable being a polyglot team, but we are able to get the most lift from using a core set of languages and libraries. The lift comes from being able to simplify our deployment and monitoring processes as well as keep up with the latest libraries and language releases.
What is the development process like? (the lifecycle of a piece of committed code)
Our engineering team works closely with our business and Data Science team to understand the problem we are working to solve and identify the best way to solve it. Once a solution has been identified, the engineer works cross-functionally to complete the solution which may involve building a new service, updating an existing service, integrating with a new service, and completing necessary UI changes.
As we write the code, we ensure adequate test coverage for the features, and open pull requests on GitHub. After getting necessary feedback, the code is merged, and deployed directly to our production environments after a final test run.
What is code review like?
All changes go through a PR process which is low ceremony. A developer opens up a pull request on GitHub, typically requesting targeted feedback and opening the review up to the team that owns the project. We ask that each person model responsibility by ensuring they know what feedback is needed and that the necessary feedback is provided before their code is merged.
We have a fairly lightweight process that includes a simple deployment checklist to help ensure any potential steps needed before deployment are completed. This includes setting new environment variables, ensuring data migrations are completed before deployment, and completing any communications for the change.
How is testing done, and what kind of tests are run?
As every change to master deploys, we rely heavily on our test suites to ensure smooth deployments and that we do not introduce bugs or regressions. Our teams write both unit and integration tests to ensure a feature is adequately covered for the value that it adds. These tests are run on CircleCI for every push to a branch or PR, and every time a branch is merged to master, prior to deploying to production. We additionally have staging environments which allow teams to look at certain changes in a pre-production environment when necessary.
Some of our teams, including mine, rely on feature flags to allow us to easily test features in production without the risk of introducing breaking changes across the entire system.
How is code deployed?
After all tests pass in CircleCI, a Docker image is created as an artifact, and CircleCI makes an API call to our internal Fixops Service triggering a deployment. As the new containers come online and health checks pass, the new code becomes live.
What is an average day-in-the-life of someone on one of the development teams?
Our development teams each have their own working styles, with just over half of our engineers working remotely across the US and the rest working out of our San Francisco HQ. In addition to shipping code, an average day across our teams involve PR reviews, emails, and chatting on Slack and screen shares. Our week is mixed with meetings to talk through current work and plan future work, complete team stand-ups, talk about new additions to our road map, and general information sharing for our teams. There also may be interviews as everyone has the opportunity and is encouraged to participate in our recruiting process.
We have team wide quiet periods on Wednesdays and a few other times allowing teams to keep clear of meetings to focus on work without interruptions which has been effective across the company.
What makes Stitch Fix a special place to be a developer?
Our company actively values diversity and works very hard to model that. Additionally we have a set of defined company values that are modeled through the organization and allow us to work well together daily. These values include being Bright, Kind, and Goal Oriented. Our engineers at Stitch Fix all get to participate in defining what we work on and what we are building to best serve the business and our clients. I think it’s rare that not only does everyone get a voice in how engineering work is done but also what engineering work is done. We value partnership across the business and the engineers actively help identify how to solve problems faced by our business and present problems that we identify.
Can you tell us a bit about your team and what you are working on?
On the Styling team, we support the needs of our stylists, ensuring that they can easily understand the client and select clothing that will be best for the them. We work very closely with our Data Science team and are currently focusing on making some large scale improvements to how we recommend inventory to our stylists and how those recommendations are done. We’re really excited about how these improvements will allow the stylists to better target clothing that will best serve our clients and most delight them.