What I did, experienced, and learned during my first 6 months at Gusto
After sharing what I did and experienced during my first 6 months at Gusto, it’s time to reflect on my learnings. The following are lessons I learned based on my own personal experiences. While I hope my college fellows will find one or two points helpful, one should keep in mind that I’m still an apprentice myself.
What I learned
- Culture matters a lot.
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.
- Ask. Ask. Ask.
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[^1]. But for the same words, we might have completely different contexts and assumptions in our head.
I learn 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.
- Communication when transitioning projects between people is critical.
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. Alway make sure that everyone — product managers, engineers, and designers — are on the same page before starting.
- Don’t rush into coding, think like an engineer before putting your hands on a keyboard.
Rushing into coding does more harm than good. Just DON’T do that.
- Timeline estimation is hard.
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.
- Review your (damn) code first.
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 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.
- Don’t rely on anyone else, own your own code.
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.
As this series of posts comes to its end, a story comes to my mind:
A man came upon a construction site where three people were working. He asked the first, “What are you doing?” and the man replied: “I am laying bricks.” He asked the second, “What are you doing?” and the man replied: “I am building a wall.” As he approached the third, he heard him humming a tune as he worked, and asked, “What are you doing?” The man stood, looked up at the sky, and smiled, “I am building a cathedral!”
The past six months was the beginning of my journey at Gusto. As much as I’m excited about continuing to grow and sharpen my skills, I also can’t wait to see the Cathedral we have in mind comes to life bit by bit.
Originally published at sihui.io.