I started coding the first day I joined the team. My first task was meant to be an introduction to our code base and regular workflow: The task was simple enough so that I didn’t get overwhelmed, yet at the same time complex enough to give me a taste of how it’s like working with our code base. After the “appetizer”, I started to implement a bigger feature that touched our full stack.

We are big fans of pair programming. Throughout my onboarding, I paired with a lot of different engineers. I had at least five pairing sessions per week for the first two weeks. Sometimes we worked on my task, sometimes we worked on theirs. Working with more seasoned engineers not only got me familiar with our tech stack quickly, but also gave me the opportunity to learn about each engineer as a person.

Throughout my 6-week onboarding, a series of classes were scheduled. There were classes focused on high-level engineering concepts, from how we move money around through ACH to our overall architecture. There were also more practical classes that went over our tech stack, from Rails basics, security, asynchronous services, and maintenance, to hands-on frontend labs on React.js and Flux.

At Gusto, each engineer takes turns to be a Viking Master. Surprisingly, I enjoyed being a Viking Master a lot. I’ve heard some horror stories about being on-call, mostly involving pagers and being woken up in the middle of the night. Luckily, not many people run payroll at 3 in the morning, and we don’t carry pagers around. Being a payroll Viking Master is more like being a detective. For each ticket, I would try to reproduce the error, locate related source code, and fix it. It was a lot of fun because you never know what you would learn along the way. I picked up some nuances of Rails which I might have never encountered otherwise. Being a Viking Master also pushes you out of your comfort zone: Each JIRA ticket is like a train ticket that takes you to a part of the code base that you might not have even noticed before. You are forced to familiarize yourself with the new code as fast as possible in order to resolve it in an efficient manner.

While tracing a bug through the code base is quite fun in itself, what’s even more exciting is pairing with the author who wrote the code and fixing the bug together. Most of the time, after spotting the part of the code that causes errors and getting a sense of the underlying problems, pinning the author and pairing with him/her is the most effective approach.

Last but not least, reading through JIRA and Zendesk tickets definitely brought me closer to our customers, which not only gave me more empathy towards them and provided insights of how our users interact with our app but also motivated me to make our service better.

Gears for VMs.

At Gusto, everyone is empowered to do the best work of their lives. Although each engineer has a pre-assigned team, we all spend two weeks rotating to one or two other teams in order to gain a more holistic view of different parts of our technology and product. I initially joined the HR Engineering team and chose to rotate to the Core Payroll team and the Payments Platform team, each for a week. I picked these two teams because Payroll was the cornerstone of our business, and engineering the system that moves tens of millions of dollars per day sounded fun. The rotation was very beneficial: It helped me to gain a better picture of the engineering team as a whole and also laid out some foundation for cross-team tasks I encountered later.

Every Gustie has to shadow customer phone calls during onboarding. I was really excited about that. Knowing that our customers — people who believe in our product and use it — were on the other side of the phone made my heart skip a beat. “What a great way to start my work!”, I thought to myself. Yet I was half wrong: Serving our customers wasn’t just the beginning of my career at Gusto, it was the main theme around which all of our daily work revolves.

For a company of our size, we specialize into different teams and focus on different kinds of tasks like redesigning landing pages, answering customer phone calls, writing help center articles, or building out a new feature. At the end of the day, it’s all about serving our customers through improving our product and service, and sometimes through serving each other.

Cross-functional work happens a lot at the office. Every now and then, folks from the Customer Care team will pull up a chair and sit next to an engineer or a product manager to discuss what they learned from recent customer calls, many of which involve tuning behaviors in the app. Many conversations happen during lunch. A few months ago, while I was sharing a table with folks from our Partner team, they shared that our accountants comprised a significant portion of our users and that this segment could benefit significantly from a better product experience. Their voice was heard and a new EPD (engineering, product, and design) team was developed specifically for that purpose. We also have quarterly help-a-thons where everyone submits ideas about the tools they think could help them to perform their work more efficiently, and engineers will get together to build out some of them.

It feels quite amazing to be on the same team with everyone else in the company and working towards the same goal together. Much like playing a team sport, it is very motivating and fulfilling.

While implementing tracking and data visualization for the employee directory was not the most interesting task for me as an engineer, what motivated me was knowing that this data would really help product managers to gain more insights and make decisions to better serve our customers.

There are no managers at Gusto. Instead, we have PEs: people empowerers. My PE, Nick, showed me what it means to be empowered. Our 1-on-1s are meetings about me, meetings set to empower me to perform better and grow. In our 1-on-1s, I don’t report to Nick what I accomplished. Rather, I talk about problems I encountered and seek advice and guidance from Nick.

A few months in, besides regular tactical 1-on-1s, we started to do monthly introspective 1-on-1s which focus on my personal career growth. In the first introspective 1-on-1, I wrote down my goals for the next two years. For each of the following introspective 1-on-1, Nick and I will first separately write down areas I have improved in the past month and areas of improvements for the following month. During the meeting, we compare what we each wrote down and come up with action items for the next month. For example, we agreed that my past couple projects were heavy in frontend related work and I needed to gain more backend experience. So we came up with action items which included: For Nick, to keep an eye out and allocate more backend related projects to me; and for me, to dig into Rails in order to be prepared for upcoming backend projects.

I also felt empowered each time I sought help from my teammates. Every single time I asked a question, instead of getting annoyed by the interruption, they always went beyond simply answering my question and provided extra context to help me better understand the reasoning behind different design decisions. My teammates don’t see my questions as interruptions that slow them down, they treat it as opportunities to help me grow, so we as a team can grow better and stronger for the long run.

We believe introspection helps us to stay on track and be proactive instead of reactive. Three times a year, we have company-wide GustoFIED, which is our performance review that stands for Feedback, Impact, Engagement, and Development. There’s also the company-wide annual retreat: Gustaway. This year, we went to Camp Navarro for two days and a night where we relaxed, bonded, and reflected on our values. On each Gustie’s anniversary, he/she will also get a golden ticket to take a vacation anywhere in the world.

Ownership mentality follows naturally when everyone in the company is empowered to work towards the same goal. At Gusto, I witnessed how engineers act as owners of the business.

Coming across others’ code is common when working with a code base contributed by ~60 engineers. There is code written five years ago, and as a startup, the way we write code and the tech we use are evolving quickly. I notice engineers at Gusto don’t have the concept of each owning separate parts of the code. We all own the whole codebase together. When engineers see parts that can use some refactoring, they won’t forget about it and do nothing. Instead, they either go ahead and refactor them or pair with the engineer who wrote the code.

Engineers often take initiative and claim things to work on. As owners of the code base, we know it the best and feel responsible to keep it healthy: Even if it sometimes means telling product managers we need to deliberately set aside time for the sprint to tackle tech debt.

When you are an owner of the business, you are expected to speak up. When I first joined, I had trouble coming up with items during our bi-weekly retrospectives, yet I noticed everyone else in the team had feedback to offer. As part of the team, I felt responsible to provide feedback and help keep the team stays healthy. It was only after the ownership mentality replaced the default idea of “I’m just here to get my job done and go home” that I started to be more sensitive about how things were going and what we should watch out for. Since then, I noticed how everyone in the company spoke up and raised their concerns whenever they spotted something that could be improved. We don’t care much about format or timing for giving feedback, it is always welcome and valued.The power of culture really shows in this case. Surrounded by people who care about the business and speak up constantly, I feel motivated to do the same thing.

The HR Engineering team was formed right before I joined. Before then, it was the Payroll Experience team. A few months in, a new team, the Partners team, was built within the HR team. Not long ago, the Developer Experience team came to life with the focus of adopting new tools and improving existing tools so engineers can work efficiently and happily. Around the same time, the Engineering Excellence Committee was formed because as we are constantly building out new features, our tech stack evolved and we agreed that we should pay more attention to tech debt.

Working in a rapidly growing and changing environment is very exciting. As the team grows, new challenges come along and push us to become better and more mature. You are also expected to grow along with the team. Being able to adapt to changes quickly, take initiative and bigger responsibilities happen all the time. It’s very much like playing a video game: Once you start to get a bit comfortable, a new level of challenges are unlocked.

In the last part of the series, I reflect on what I learned during the past 6 months. Most of the lessons were engineering-related and most applicable to fresh college grads without much industry experience.

It’s only after being at Gusto for couple months, I began to realize how lucky I was and felt extremely grateful for being able to work at a company with great culture and surrounded by extraordinary people. It’s a place people come to help each other grow and get things done.

Fellow college friends: Take company culture into account when you weighing different offers. It matters a lot. It directly affects how you are going to spend your time at work. You want to be productive and grow rapidly. Surrounding yourself with people who share the same values as yours and who you could look up to is a privilege you should seek. One of the things that nudged me to join Gusto was after a full-day office visit and many conversations with Gusties, instead of feeling exhausted, I felt refreshed and even felt I somehow became a bit nicer than usual. It was because everyone I met at the office was extremely friendly, genuine, and passionate.

Never hesitate to ask questions is one of the most valuable lessons I learned, and I still constantly remind myself about it. I still get surprised by how much you can learn from a simple question. It helps me to get the right things done the right way. A lot of times, before asking a question, I thought the answer would be a simple yes, no, or a line of code. Instead of getting the answer I originally looked for, a dialog was opened and the question changed from “how can I do this?” to “why I am doing it this way?”, “is this the right place to do this?”, or even “is this method/component really needed in the first place?”. When I bring a question to a senior colleague, it often gets escalated to a bigger context and a higher level. Instead of getting a simple yes or no, I often receive something much better: A better practice I should consider, a pitfall to watch out for, or an existing method/component that lives somewhere in the code base and does exactly what I want. Avoiding unnecessary work and getting things done the right way is much better than making things work and refactoring them later.

Asking clarification question is crucial, especially when a task first gets assigned. I learned this lesson the hard way. When I was implementing data tracking for a couple features, our product managers said they needed A, B, and C, which at first seemed to be clear and made sense. Then I went out and implemented what I thought they meant. Only after it was implemented, we realized A, B, and C, meant different things to me versus them Yes, we all speak English. But for the same words, we might have completely different contexts and assumptions in our head.

I learned to ask a lot of questions, not only about what exactly should be done but also why we need it and how we are going to use it. For example, I was asked to track the number of clicking for each tab on a page. Only after I asked how were these numbers would be used, I figured the purpose was to see if users click around and play with the page. Tracking clicks for each tab individually is a very different work from tracking if tabs are clicked in general. Asking clarification questions upfront offers an opportunity to examine assumptions from both sides. Ask, and you will always thank yourself later for asking.

I took over the survey project from Darin, an Engineer from the growth team who started the project during his two-week rotation to the HR team. Functionality for sending out survey emails was mostly ready, and I started to work on in-app functionality right away. I noticed a couple TODOs left in the code related to sending survey emails. And I did nothing about it because I was too excited about building the next part and simply assumed our product manager was aware of the TODOs. Thankfully, our product manager caught the missing behavior right before launching. Only until then, I recognized the false assumptions in my head and realized what a code monkey I had been. Assumptions can be our biggest enemy, and you need to be especially careful when a project is transitioning from one engineer to another. Always make sure that everyone — product managers, engineers, and designers — are on the same page before starting.

Rushing into coding does more harm than good. Just DON’T do that.

It’s true when people say you should multiply your original time estimation by a factor of 2.5. If you think you can complete a task in a week, say two weeks and a half. Only after working for almost a half year, I started to see how necessary it is to follow this advice. Writing software is something that should not be rushed. The more pressure you have and the less time you get, the less enjoyable the process becomes and the more error-prone your code will be. Do yourself and your teammates a favor, follow the advice. And don’t be afraid to let product managers know you don’t think the given timeline is realistic.

Silly bugs or even typos being spotted during code reviews was one of the moments I felt ashamed of myself. Those errors could be easily spotted if I took a through a final look at my changes before requesting a code review. I have to admit I don’t always like to look through my own code. Sometimes it’s because I got tired from continuously coding for a long time but still wanted to get the code landed on time.

It’s not only embarrassing to ask people to review your code when it contains obvious bugs, but also rude: The same way you leave a messy kitchen to your roommates. It’s a waste of time for both sides.

It’s very easy for junior developers to think they can completely rely on senior engineers. At least that’s what I first thought: If the code review passed, the code must be good to go and safe to land. The truth is: none of us are perfect. No one is responsible to think through all different edge cases for your code but yourself. Leaving that burden to your code reviewer is irresponsible.