What I did, experienced, and learned during my first 6 months at Gusto

Today marks my six-month anniversary at Gusto. As time flies by, I learn more and more about Gusto: its mission, its culture, and most importantly, its people. The more I learn, the more grateful and lucky I feel for being part of it. As I graduated from college and transitioned into a young professional, the past six months have come with a lot of changes. Many of my friends who are still in college ask me about my experience at Gusto and what I have been learning. So I decided to write a three part post to share what I did, experienced, and learned over the past six months at Gusto, from a fresh college grad’s perspective.

What I did

Six-week Engineering Onboarding

1. Implemented features

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.

2. Did a lot of pair programming

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.

3. Attended a series of intro courses taught by Gusto engineers

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 maintenances, to hands-on frontend labs on React.js and Flux.

4. Shadowed a Viking Master, a.k.a. on-call engineer, for a week

At Gusto, each engineer take turns to be a Viking Master[^1]. 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[^2] 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 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[^3] 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.

5. Two weeks of rotation

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.[^4]

Leaving My Fingerprints

After my onboarding, the HR team worked hard to launch a brand new employee directory. I contributed in various areas such as implementing small missing pieces, converting existing Backbone.js components into React.js components, as well as working along side with product managers and the data team for tracking and visualizing usage data of our new features. After the successful launch of employee directory[^5], I started to work on our employee survey feature[^6].

Software development is itself a lot of fun, and the team you develop the software with and how you work together can make it even more enjoyable and fulfilling. I will share what I experienced (Part 2) and learned (Part 3) during my first six months at Gusto, mostly from an engineering perspective.

1:

Gears for VMs to wear

2: One nuance I learned was: the way ActiveRecord saves NestedAttributes by declaring autosave: true might cause some strange behaviors. Say there is a nested numeric field, Hour, for the Payroll model. Calling valid? on a payroll object after changing its nested hour from 7 to 7. will return true. But it shouldn't because 7. is not a valid numeric field. Strangely, if the record is changed from 7 to 8., calling valid? on the payroll object will correctly return false. After digging into the source code, I figured the reason was ActiveRecord didn't think the nested field hour had been changed when a tailing decimal was added. _field_changed? uses type_cast to determine if a file has been changed. And type_cast turns 7. back to 7 which in fact, stops hour from being added to changed_attributes, which is used by changed? to determine if the entity has been changed or not. And changed_for_autosave? uses changed? to determine if a NestedAttribute has changed.

3: Did I mention git blame? 😏

4: We do have engineers jump around teams. Phan, one of the engineers who seems to know every part of the system, has jumped from Payroll, to Benefit, to DevOp, and back to Payroll. It's also not uncommon for engineers to take on projects that doesn't belong to their team.

5: and my 3 week Asia trip

6: The project was started by Darin, an engineer in the growth team, during his two-week rotation to our team.

Originally published at sihui.io.