At Gusto, I work with engineers from diverse backgrounds of experience. Some of us came from the typical Silicon Valley companies like Google and Facebook, while others joined Gusto as their first startup. I started in a consulting shop in Minneapolis fresh out of college. It gave me the confidence to learn more on my own, but also taught me to learn in a way that I’m still trying to recover from. With the support of my colleagues and mentors, I’m learning how to learn in a way that will make me a better engineer and leader.

In my first job, I built mobile and web software for connected IoT devices that used Bluetooth. I worked on very small teams and had near-total ownership over my projects. This meant I got to learn in a way I really enjoyed: picking a greenfield approach, learning iOS or Android, and building with the shiniest new tools. In consulting, we weren’t often concerned with the legacy of our code – if the customer accepted delivery, we had finished our project and could move on.

My Approach Falls Apart

When I moved to Gusto, I entered a gauntlet of new and foreign technology. Gusto's engineers are full-stack, and my mentor asked me to start where I was weakest: a JavaScript frontend app built with React, Backbone, and Bootstrap. I did my best to adopt the organization's best practices around testing and code review. I became comfortable in the dev tools as well as the Rails console.

But as I moved into the thicker parts of the payroll domain, my team asked me to debug thornier issues. I had to figure out why a payment wasn't sent as expected, or why a feature I wrote was locking customers out of the app. This meant I had to dig into the five-year-old Gusto codebase. In contrast, I'd written the majority of my past codebases from scratch, so I knew about every dark corner harboring bugs. It was a shock to jump into Gusto and find out I knew nothing about the mechanisms I needed to fix. The codebase was complex and many of the authors had left the company. There was a lot I didn't know!

I coped with my inexperience by avoiding the problem. When we assigned tasks during sprint planning, I asked for the ones within my comfort zone. When fires happened in production or I needed to make important design decisions, I deferred to anyone who was confident about tackling the problem.

Pictured: My reaction when asked to make hard decisions and work with scary code.

My coworkers noticed that I often spent time avoiding hard problems by working on other problems I enjoyed more. They saw me as someone who wrote excellent tests but became distracted when it came to building entire features. In my performance review, my PE (People Empowerer -- what we call a manager at Gusto) and I discussed my peer feedback:

“You delegated a key decision on this Payroll Engineering story to an engineer that is your junior.”

“You spent a couple of days optimizing the build process, but you didn’t finish your stories for the week.”

“Your teammates don’t feel you’re focusing on the work you’re given, and they get the impression you may not be pulling your weight.”

When everything added up, I found myself in the middle of the pack at Gusto. I wasn't yet reliable enough to be a senior-level engineer.

I wanted to do better. I thought about how working in a codebase with history and complexity made me feel. I discussed my feelings about code and engineering with my PE frankly and openly. I found that I'm scared of learning hard things.

Figuring Out What’s Wrong

At my old gig, I could almost always build a project from scratch. Because I built them myself, I understood everything about how they worked. Gusto presented me with intense problem domains, dozens of engineers committing at once, and a complex series of interlocked systems with side effects. It was petrifying to work with this codebase. What if I made a mistake? I could annoy my coworkers, upset our customers, and cost the company real money.

I found it easier to change only the parts I knew. But that caused me to leave projects without a deep understanding of their domain. I couldn't apply that knowledge to new projects I joined, even ones adjacent to my past work. And I felt less effective coming back to fix bugs in code I had written before.

My trepidation over working in an established codebase had led to a phobia. Our primary repo has over five hundred thousands of lines of Ruby code, interfaces with dozens of state and federal agencies, and has thousands of edge cases. I needed to make conscious decisions to get over my fear of the unknown and build my knowledge of the scary, cobwebbed corners of our payroll codebase. So my PE and I came up with actions I could consciously take to drive my independent study and help me learn through my work.

Pictured: I investigate tactical approaches to independent study and the growth-oriented mindset.

Changing My Approach

I aimed for the hard stuff on purpose. For example, I preferred stories that dealt with our automated tax filing system, rather than stories around building the frontend components I had grown comfortable with. During sprint planning meetings, I chose to take the tasks I knew nothing about. I hoped to learn more about the unknowns and gain a better understanding of our systems as a whole.

I spent more time investigating before asking for help. I used to spend about ten minutes investigating a difficult problem before asking for guidance. To change that, I came up with my personal Two-Hour Rule: I had to work at a problem for two hours before deciding it was time to ask someone for help.

I chose to avoid asking for help until I could describe my problem in detail. I used to ask for help after a brief period of not understanding the code I was looking at. To remedy this, I spent more time observing and thinking, then describing my understanding of the codebase on paper. I jotted down diagrams in a small notebook to help organize my thoughts and my mental models. For example, when I worked on a feature that interacted with our complex Historical Payroll model, I wrote pages of notes and diagrams that I eventually synthesized into a page of documentation for our company wiki.

To me, this was the road less traveled, but I found it made an immediate difference in the quality of my work. When I chose to stick with a difficult bug instead of asking for help, I often found I learned a lot about how the bug happened and how to fix it. In the end, I realized I didn’t need help after all. When I did need to ask for help, I could describe the problem completely, accurately, and point at the exact bits of code I didn't understand. When I left a project, I was able to write clear, concise documentation about what the code did and why – even if I hadn't written it originally.

Pictured: My new approach to diving deep and documenting my work yields results.

Looking Forward

As I move forward, I want to learn and grow in my abilities. It’s only been a short time since I adopted my new strategies, but I’ve already seen improvement in my ability to grok complex problems in my projects. I want to become a great engineer at Gusto, I want to grow as a skilled engineer in general, and I want to learn how to learn so I can continue my trajectory. I look forward to seeing how the skills I’m teaching myself will help me become a better leader at Gusto and wherever I go.

Gusto has been an incredible place for me to learn the skills around working with a large team on complex problems. I've received nothing but support as I grow in my abilities and develop my strengths. Come work with me to create a world where work empowers a better life! Check out our open engineering positions in San Francisco and Denver.