Blue Apron is a meal-kit delivery company. The engineering organization had fewer than 100 employees when I joined as a Backend Engineer. I joined the Delight squad but the team was later rolled into the Engagement squad. Delight’s priorities were a subset of Engagement’s; the former focused on customer retention while the latter prioritized it alongside monetization.

One of the biggest challenges at Blue Apron was in maintaining the written-from-scratch e-commerce engine. The custom-built nature of the engine allowed the storefront to be deeply integrated with fulfillment on the backend, but it came at the cost of quality-of-life features. With this in mind, I took ownership over Address Management since it had been historically overlooked or de-prioritized. I worked on:

• Leading the implementation of Temporary Address Change for deliveries.
• Fixing design issues and bugs that had been the cause of frequent meal-kit mis-deliveries.

Temporary Address Change was a conceptually simple feature, it allowed customers to change the delivery address of a single order. I implemented the backend of the feature and I was also the tech lead for the Web, iOS, and Android frontend implementations.

Aside from Address Management, I acted as a technical leader by:

• Refactoring trickier parts of the codebase that were not well-understood.
• Actively reviewing code to unblock my peers, regardless of their team.
• Documenting older parts of the codebase that were not well-known.
• Mentoring junior engineers.

My experience at Blue Apron was chaotic since I joined in-between two rounds of layoffs. I shifted between several projects that started and stopped as the company’s priorities changed, so I did not have the opportunity to complete some of the projects that I worked on.

Lob is a startup that had less than 20 employees when I joined; I was one of 4 engineers on the team. The company offers a SAAS product in the form of RESTful APIs for sending physical mail and validating addresses. The Print & Mail API handled several million requests per month.

The engineering team was small and without defined roles so we self-assigned responsibilities based on interest and capability. I had more experience with cloud infrastructure, so I took DevOps responsibilities.

One of the first projects I worked on was to setup auto-scaling for the Print & Mail API infrastructure. This turned out to be a larger than expected task given that everything was manually managed through the AWS web interface. My approach was to:

• Introduce Terraform to get a handle on the critical infrastructure.
• Dockerize the application to automate provisioning.
• Setup a parallel set of infrastructure to use AWS ECS for scheduling containers.
• Cut-over from the old infrastructure to the new infrastructure.

The migration completed without any issues and we were able to leverage AWS features to manage auto-scaling with almost no custom code. There were other benefits and improvements from this approach, including:

• Codified infrastructure.
• Explicit, documented provisioning.
• Automated deployments with immediate rollbacks.

Aside from leading DevOps initiatives, I also became the team lead for the Partner Operations team. The Partner Operations team was responsible for optimally routing requests on the backend to the Partners that fulfilled them. Geographic proximity, capability, and available capacity were some of the factors considered when routing to a Partner.

My role on the Partner Operations team was to increase throughput and reduce failure rates. This involved:

• Handling and resolving routing failures as part of an on-call schedule.
• Identifying and reducing bottlenecks in the codebase, infrastructure, and manual procedures.
• Researching, designing, and prototyping a V2 of the backend architecture.

This was a difficult role since the on-call burden was high. I departed the company before I could deliver the V2 of the backend, but I left the team with my blueprints and I had already exhausted the optimizations to the existing code and infrastructure.

@WalmartLabs was the largest organization that I have worked for. I joined the SEO team as a frontend engineer, but what I actually did was full-stack web development. The majority of my teammates were data engineers, so I learned that frontend was a relative term.

The SEO team had several responsibilities, but most of the work centered around support for the Topic Page platform. Topic Pages were a large set of product listing pages on walmart.com that were automatically generated based on data about frequently searched keywords.

Topic Pages were too narrow and too great in number to fit into the site’s category-based navigation, but they ranked highly in organic search engine results. They drove hundreds of thousands of visits in traffic and hundreds of thousands of dollars in revenue to walmart.com every day.

The Topic Page platform consisted of dozens of services, so every member of the team acted as a custodian of at least one service. One of the services I maintained was an internal application known as Mason, a CMS-like tool for Topic Pages.

Mason was on maintenance mode when I first started working on it. The app was buggy, hard to use, and almost no one understood its purpose or its capabilities. The SEO team mainly used it as a manual override for when there were issues with the generation of certain Topic Pages.

When the SEO team started to port the Topic Page platform to support samsclub.com it became clear that Mason would need significant rework. As part of the porting effort, I:

• Cleared the backlog of reported and unreported bugs.
• Simplified the UI/UX to improve usability.
• Handled support requests.
• Created user documentation to reduce the rate of support requests.
• Demoed features to the Site Merchandising team to grow usage.
• Migrated from pet servers to automated, internal cloud hosting.

I was able to make Mason multi-tenant to support Sam’s Club while simultaneously increasing usage among the Site Merchandising team on the Walmart side. Mason became a go-to tool for setting up campaigns in partnership with large brands; a new use case and source of revenue that became possible as a direct result of my efforts.

Aside from Mason, I was also contributor to the customer-facing frontend of Topic Pages on walmart.com and the backing web services.

Sendicate was a startup with a team consisting of just the two co-founders and myself. The company’s main product was a competitor to Mailchimp, but I joined to work on a new product called Sellout. Sellout was an automated email marketing app for Shopify and Bigcommerce stores.

The headline feature I delivered was Manual Emails. I built a WYSIWYG editor that could design emails using a set of predefined content blocks; essentially a CMS for email campaigns.

The CTO built the backend but gave me total freedom to build the frontend since I had more experience. With this project, I:

• Selected a minimal, conceptually simple set of dependencies.
• Made my first contribution to the OSS community via an improvement to one of the Bootstrap framework’s interactive components.

This was my first large JavaScript project, but I was able to ship and the feature launch was a success.

Afterwards, I paired with the CTO to add subscription billing and I learned about the backend. The CTO later left for another company, but I continued to work on Sellout for a period of time. During that time, I:

• Added caching to the product recommendations engine to improve response times.
• Migrated the infrastructure to another platform to cut costs.
• Fixed bugs and fielded technical customer support.

I didn’t ship any new features, but I learned a great deal about operating a SAAS product while I was on my own.

CompuWeigh is a small, though mature, company that specializes in integrated hardware and software for the grain industry. Their products are for industrial automation or logistics management.

Given that this was my first job as a software engineer, this role was more of a learning opportunity for me. My contributions were small but I gained a solid foundation in TDD and BDD because of the rigorous culture around testing.

In one of my last projects I was able to tinker with creating a web service for a .NET Micro Framework device (akin to MicroPython or Arduino), which served as my introduction to web development.