How I found my career path at Flexport

Starting at Flexport, the Freight Forwarder

After college, I was working as the office manager at a company on the floor below Flexport’s office. I became friends with the Flexport office manager after meeting via an email thread with the building manager. I would visit her upstairs to commiserate about building management or ask if they could please stop playing basketball in their kitchen! As I got to know more Flexporters who taught me more about the company, I realized I wanted in.

My first undergraduate degree was in Marine Affairs, so I was interested in Flexport as a freight forwarder. Freight forwarders facilitate the bulk movement of manufactured goods around the world. This involves seaports, cargo ships, and a byzantine network of international trade regulations. I knew a little bit about it from school, and I was excited to finally be able to use my degree.

I knew that Flexport sponsored employees getting their customs brokerage licenses, and I’d heard through the grapevine that the compliance department was expanding. I figured I would get my foot in the door via a data entry position that was open at the time, and then try to wedge myself into compliance — maybe try for a customs license.

Intro to Programming: Automating My Workload

I started at Flexport in a data entry position. The work wasn’t challenging, but the volume was overwhelming — we were in our ‘scrappy start-up’ phase. For several weeks, I was the only full-time employee in a department with a growing backlog.

One of my tasks was to clean up rate sheets and make them compatible with our system. The rate sheets described the price of putting a container of goods on a cargo ship. There are several companies that own ships, and each has their own rate sheets, schedules, and formats. Rates are determined by the origin and destination ports, container size, commodity being shipped, etc., so a sheet can have over a thousand rates.

It took me about 10 hours a week to clean up and import the sheets, and the time it took me to process each sheet was time our operations staff was unable to create accurate quotes for our clients. One of the first things I did was to write up a process document for myself. Moving through the checklist ensured I never missed a step (for more details, see The Checklist Manifesto). It was pretty much a program for myself:

1| Ctrl + F for ‘Yantian’2|   replace with ‘Shenzhen’3| Scroll through Column C4|  if any cell is x5|   and Column F for that row is y6|     change Column H to z7|  ...

I had done some free online programming tutorials before. The kind where you make a Dog class and a Cat class that both inherit from an Animal class. They weren’t enough to keep me interested in programming, but they were enough that I had a sense of what computers could do. The rate sheets were all in excel, so I spent a couple evenings tinkering with Visual Basic. I ended up with a macro that reduced my 10 hours a week of data munging to 5 minutes. It was an incredible feeling, mixing creativity and problem solving to create tangible value. Since Flexport was still small, I got a good amount of recognition from the higher ups in the company, which felt great too.

There is More to Software Engineering Than Visual Basic

Writing that first script opened my eyes to what programming could be like, but the rest of my work would be a lot harder to automate. I knew I needed a significant level up in skills before I could be paid to program. I looked into university courses and coding boot camps and ended up applying for the Oregon State University Computer Science Online Post Bacc. A post-bacc (short for post baccalaureate) is a program for people who already have a bachelor’s degree. Your first degree meets all of the gen ed requirements, so you can skip right to the required courses to earn an additional major. The OSU post-bacc requires 60 credits for a B.S. in Computer Science.

I chose the post-bacc over a boot camp for a few reasons. At the time, Flexport was only hiring CS majors, and the legitimacy of bootcamps was still in question. A lot of the engineers I knew emphasized that a CS foundation pays dividends later in their career. I was also worried about imposter syndrome and being taken seriously, so I wanted a real degree to fall back on. The program is also completely online, unlike many bootcamps, and that flexibility was appealing.

Discovering Flexport, the Tech Company

I started the post-bacc taking one class each quarter and working full time. Towards the end of my first quarter, I realized that I learn best by immersion and that I needed to commit more time to the program. At the same time, my manager, Phoebe Ford, called a meeting to talk about promoting me into the operations org. I told her about the post-bacc and asked if I could stay in data entry and work part time so I could take more classes, which she immediately agreed to. We designed a role in data entry where I could work less hours, keep my health insurance, keep paying rent, and spend some time at work developing scripts. Over the next two years I got a lot of support from Flexport, but this moment was pivotal.

As the data entry department grew, we got a new manager, Will Stoeckle. Data entry is generally a new grad position and Will was committed to helping us grow our careers. He worked with the engineering department to get me access to the code base, and he helped me enlist Alex Stark, a Flexport engineer, for weekly mentoring sessions. Stark’s mentorship was invaluable. One advantage of a bootcamp over a CS degree is the focus on industry relevant skills. In my post-bacc, I was learning a lot of foundational skills — assembly code, networks, operating systems, discrete structures, etc. Pair programming with Stark exposed me to the modern languages and tools — ruby, rails, javascript, react, and git — that we use at Flexport. It also exposed me to my biggest challenge — working on a large, active codebase.

The programming assignments in school were all greenfield. Greenfield code is easy to write:

1. You are given the parameters of a task
2. You open a blank terminal
3. You write the code to complete the task

Writing code on an active codebase is not easy. It looks more like this:

1. Someone tells you about a bug
2. You search through thousands of nested files to find the code relevant to the feature. You’ve never seen most this code before, you probably didn’t write any of it, and if you did someone probably changed it while you weren’t looking.
3. You identify the bug
4. You fix the bug
5. You make sure that in the time it took you to write your fix, no one changed the code you were working on
6. If there were changes, update your fix to work with them and then repeat step 5
7. If there weren’t changes, pray there weren’t any added while you were checking for them and merge your code

One of the first tickets I paired on with Stark involved adding a new validation to our data model. We model a concept of the modes of transportation that a container can be on (truck, train, or ship). We also model a concept of partially filled containers. (Partial containers are cool so I’m going to give more context than necessary. If a client only has enough goods to fill up half of a container that need to go from China to the US, they can pay for half of a container. Then we find another client with a half container of goods that need to travel a similar route. These two clients can share the cost of shipping one container across the Pacific. Then we deconsolidate their goods at the port, put half on a train to Topeka, and the other half on a truck to Portland (for example). It’s like giving the traveling salesman a knapsack. The freight industry is awesome and you’ll never convince me otherwise.)

So my validation was to ensure our partial container flags stayed in sync with our transportation mode flags. The problem is that shipments, containers, and transportation modes are heavily used aspects of our data model. As I was writing this validation, other engineers were adding new code that violated it. Each time that happened I had to do something called a rebase. I added their changes to the copy of the codebase I was working on and applied my new validation on top of everything. Then I could identify where the new code violated my validation and fix it. It took 21 commits to write the validation, adjust for new code, and adjust for the code added during the last adjustment (this was exacerbated by the fact that I could only work on the code a few hours a day between my primary work responsibilities). I also made every mistake it’s possible to make when running a rebase.

The code to write the validation was simple. The real challenge was the process of shipping it into production. The challenges of working in a large, active codebase aren’t taught in schools. Most engineers learn the skills to handle it in internships or their first job. Being able to work on real tickets and having Stark to guide me through the process set me up for an easier transition into engineering.

Working up to Engineering

I spent a year working in the data entry org, pairing on engineering tickets, and working on my post-bacc. My end goal was to work my way into engineering, so when an opportunity came up to work on the tech side of the org, I took it. The role was to liaise between the users and engineering on bug reports. Since I had some experience with our code base already, I was able to read through the code to better diagnose tickets for the engineers. I could also write some small fixes myself. I was in this role for another year before I completed the post-bacc and earned a B.S. in Computer Science. At this point I’d written a good amount of code, but with a lot of help and hand holding. So I transitioned into a role as a Software Engineering Intern, on the same team as my mentor.

As an engineering intern, I could finally write code full time. I felt like I’d written a lot of code in the last two years, but it was nothing compared to being able to dedicate a full day without context-switching between my primary work responsibilities or school. I designed and executed my own project, refactoring one of our core models and integrating with a third party data source. After four months as an intern, I was promoted to Software Engineer I.

Pair programming an ocean team bug — we’re laughing because coding photo shoots are awkward

Final Reflections

I’ve been a full time Software Engineer at Flexport for about six months, working on the ocean team. I spend most of my time automating work for our operations staff in Asia. I’m learning a lot about ocean freight, and even more about engineering.

Being an engineer is exactly as awesome as I thought it would be. But it doesn’t feel like I’m ‘done’. For almost three years my driving goal was to ‘become a Flexport engineer’. And I did. But now that I’m here the learning hasn’t stopped or slowed down. Right now I’m devoting my energy to becoming a better engineer. After that, hopefully I’ll be able to become a mentor for others.