My journey to joining Flexport as a software engineer hasn’t exactly been typical: I don’t have a degree of any kind, didn’t do any internships/apprenticeships, and didn’t attend a bootcamp. For 8 years I learned and built on my own, from simple Win32 console applications to a complex browser-based multiplayer role-playing game that turned into my full-time job. (Also, I’m not the only one at Flexport with an unconventional path! Another great example is Helen Stockman’s journey From Data Entry to Software Engineering)

Working on my own has taught me a lot about taking on big projects, learning by myself, owning something end to end, and many other things. But there’s only so much one can really progress without being regularly challenged to improve by other people, so in May 2019 I made the decision to join Flexport. The time since then has been eye-opening, challenging, and fulfilling, pushing me head-first into my next phase of growth as a software engineer. To better explain how I got here and what I’ve learned along the way, let’s travel a few years back in time.

Discovering Code

The year is 2008 — Katy Perry’s “I Kissed a Girl” is on the radio, the iPhone just came out, and I’m a student at Diablo Valley College fully intending to become a firefighter. I took a computer science class out of curiosity, and everything changed from there. I fell in love with making interactive programs, especially games, that took on a life of their own. Here’s what an early Win32 console game I made looked like:

Making it was fun, but the hard part was sharing it with friends — Email services don’t like people sending .exe files, not everyone had the right DLLs or Visual C++ redistributable installed, etc…

Enter Web Development

To solve those distribution problems, I turned to web development — on the web people don’t have to deal with downloading and installing an application, it works regardless of what operating system or browser they run (for the most part), and all it takes is 1–2 minutes for users to create an account and they can start enjoying it. However DVC didn’t have any web development classes outside of basic HTML, so I decided to learn web development on my own.

Learning on My Own

So how does one go from basic computer science classes to creating a complex multiplayer role-playing game?

With no teachers to consult for answers, I turned to a combination of books and the internet. I worked my way through 800 pages of a PHP + MySQL book, scoured API documentation to see if there was a function that did what I needed, searched Google to see if anyone else had run into similar problems, and tried over and over again until I got things to work.

Fearlessness through Problem Solving

I learned an important lesson along the way: Getting really good at the core skill of defining and breaking down problems to solve them allowed me to build hugely complex things I initially didn’t even know how to approach, and in the process of building them I learned an incredible amount. Spending a lot of time defining/understanding in great detail what the problems I was trying to solve were paid dividends in finding the right solution, and circling back to the root problems whenever I lost direction kept me moving forward.

You don’t know what you don’t know

Growing as an engineer and becoming capable and confident of building almost any feature I could dream up, I slowly realized one shortcoming in my approach to learning: Searching for answers to specific problems could leave me blind to things I didn’t know to think about.

I wanted to do something about this, so I started regularly consuming two new channels of information:

1. Twitter — Following engineers like @dan_abramov, @sarah_edo, @kentcdodds, @sophiebits, and @ryanflorence has exposed me to so many new ideas about testing, accessibility, best practices around client-side state management in React, code organization, etc etc etc
2. Watching conference talks — These were critical to understanding the reasons for using React, css-in-js, React Hooks, etc. There’s so much curated information in them presented in a concise, well-thought manner that it’s hard to find elsewhere.

Joining Flexport

After spending 4 years full time working for myself building games, I took time to take stock of what my personal and professional goals were. Making games was a lot of fun, but also hard work, long hours, not very financially stable, and opportunities to work with other smart and driven people who could challenge and push me to improve were limited due to lack of budget.

Flexport offered great work/life balance, an opportunity to learn from capable teammates not just in engineering and design but across disciplines: business, air freight, ocean freight, trucking, customs, international supply chain management, you name it. Every employee’s first week at Flexport is spent in Flexport Academy with other new hires from every discipline and level in the company just learning about the global freight industry, Flexport’s role in it, and how each part of the company works.

Initial Transition

There were so many things I didn’t know about working on an engineering team when I joined. I’d never really had to work with git branches, JIRA, agile sprints, story points, etc. Thankfully at Flexport every engineer is assigned an onboarding buddy to answer questions and help you get up to speed, so I spent my first three weeks bombarding him with questions.

What really struck me during this was — not once did anyone ever try to make me feel stupid for asking what I know must have seemed like very simple questions. And on my team, even the senior-level engineers didn’t hesitate to ask questions about how to do certain things from junior-level engineers. Levels at Flexport aren’t treated like a measure of someone’s competence, just a measure of responsibilities. Everyone’s input is valued, from the interns to the staff engineers.

Applying Lessons Learned to a New Environment

Building and running my own game involved many different types of work. Engineering was a large portion of it, but I also did everything from customer support to user research, product management, product design, devops, QA, marketing, accounting, people management, and more.

Coming from a position where everything was either directly or indirectly my job and I was responsible for the experience of every second users had, I’m used to feeling a high degree of ownership over every aspect of the product and business. This has proven particularly useful at Flexport in keeping a product mindset and business mindset .

Product Mindset

Working on my own projects, I handled every step of the product development cycle:

- Talking to users and handling support tickets to understand their desires and pain points
- Brainstorming solutions to address those needs
- Prototyping and validating concepts
- Developing and testing the code
- Documenting and releasing the new features
- Collecting feedback and assessing metrics

I spend a much larger portion of my time on the development and testing portion of that process now, but I’m always keeping the other parts in mind. Taking part in research sessions with our customers is one of the highlights of my job. I love hearing and seeing first-hand accounts of how they use our platform to really get inside their mindset. The benefits of this manifest in different ways:

• By understanding both the user need and the technical implications, it’s often possible to propose a different solution that achieves the desired effect while being quicker to develop.
• When building features, I can think beyond the spec and design to understand how users will use it, anticipating problems before they occur and being more accurate in my testing of the interactions, thus saving product -> eng -> product cycles

Striving to bridge and close the gaps between product and engineering by understanding both sides makes our development cycles more efficient and ultimately leads to better products delivered faster, compared to if we let ourselves be too siloed.

Business Focus

Caring about the company’s success means thinking about more than completing a feature on time and according to spec. I think about — How does my work affect and interact with my manager, his manager, and other people in the company? What information do they need from individual engineers that they might not always know to ask for? What metrics are they currently looking at that might not be as relevant to our day-to-day work as they seem? How do the questions our peer review process asks influence the answers other engineers and I give, and how could we improve them to get better signal for management and increased growth for engineers?

We could certainly have a lot of team meetings to discuss these things in depth, but meetings are rarely the most efficient form of gathering information from a substantial group of people whose time has a large opportunity cost. As an engineer constantly exposed to the nitty-gritty details of team work and operations, I can proactively bring these issues up and discuss my perspective directly with the relevant people, without taking up the entire team’s time.

It’s been awesome to have a management chain at Flexport that’s very receptive questions both about their process and also ideas on how we can improve as a team and an organization — Having an impact beyond just the code I write that can affect my whole team or even the broader organization is very fulfilling.

Adapting to New Challenges

When I joined Flexport, two things were particularly hard to get used to after being a solo engineer for several years: Not being able to know the whole codebase, and the reduced individual output when you have a large application and hundreds of engineers working together.

Relying on Others

There’s no way I’m ever going to know the entirety or even the majority of Flexport’s code. Flexport’s codebase is more lines than I can count, we have in the vicinity of 700 data models (my teammate Bartek wrote a post on interactively visualizing them), and the repository size is over a gigabyte. The reality I had to get used to when I joined is that I would probably never be very familiar with more than 5 or 10% of the code at any given time. As much as we strive to write understandable code, there’s always going to be context the person who wrote it had that the next person looking at it doesn’t, and even the process of fully understanding a feature’s implementation can take hours to days depending on the complexity.

I was used to knowing the codebase, seeing a feature on the front end and knowing exactly where it lives, where on the backend it hooks into, and the surrounding systems it belongs to. Now, in order to be efficient with my time, I often have to rely on others for context. If it’s going to take me a couple hours to understand the full scope of a feature by exploring the code, it’s probably better to find someone already familiar with it and get pointed in the right direction in 20 minutes.

This was a big shift in mindset for me — Constantly asking for help can sometimes feel like burdening others, and I had to accept that this is sometimes simply the most efficient way to operate. In return, I need to make myself available as a resource for others too, so that together we can move faster.

Individual vs Team Output

In my game, the time it would take from hearing about a small but important issue, to the fix being live in production was minutes. And knowing the entire codebase like the back of my hand, I could pump out an entire new gameplay system in a month or less, while continuously refactoring and improving the quality of the code.

When working on a large team, developing even a limited scope feature can require an investigation into the existing code to figure out how it works, potentially finding someone with context on that area to assist, getting buy in from other engineers on the approach, design feedback reviews, hours to days to complete the code review process depending on if changes are requested or not, waiting for tests and builds to run, and once everything is all buttoned up waiting for it to merge into production.

Go alone to go fast, go together to go far

I’m always striving to get back to the world where writing code feels like a professional chef assembling a meal — Swiftly chopping up the ingredients, processing, and assembling them in the perfect arrangement to make a beautiful and amazing finished product, without a single wasted motion.

But while each individual’s output may be lower, there are huge benefits to working as a team. We have so much more impact together than I ever could solo, and the finished product quality is far better than what I could create on my own on many levels — Design, UX, robustness, you name it. I write better quality code because my teammates constantly challenge me and keep me honest, and I’m always learning new things about design, our industry, and how to achieve the best results as a group.

Conclusion — Looking to the Future

Moving from being my own boss and sole engineer to working on a team at a 200+ engineer company is one of the biggest decisions I’ve made, and so far it’s been absolutely worth it. It’s rewarding to apply the problem solving, information sourcing, product, and business skills learned over years building and running my own project to a vast and totally new environment and see the results it can bring. And I’m constantly learning new things from knowing when to lean on others, to optimizing for productivity of the broader team and company over purely individual results, to the complexities of managing international supply chains for major companies, and the power of a concise, compelling vision that permeates down throughout a company.

I’ve grown so much already in 8 months and look forward to seeing how much further the next few years take me — Whether into a more senior IC role, switching over to management, or delving back into running my own company, joining Flexport has been an invaluable source of learning and personal development that opens new opportunities and exciting challenges for me, and I know I made the right choice.

Thanks to my onboarding buddy Justin and my teammate Sean who’ve faced more of my endless questions than anyone (and did so without batting an eye), to Max Heinritz for some excellent advice that made this post more focused, structured, and readable, and to all my other teammates and coworkers who make coming in to work every day something I look forward to.