Reef Loretto joined the Privy engineering team in August. We ask for a new engineer’s observations as part of their onboarding process, and Reef submitted his in essay format, so we decided to post it here. It has been lightly edited for the audience.
This week I started a new job at Privy. Already, there are lots of things I’ve noticed which make me incredibly excited to work, learn, and grow with the team. First among these is the clear and visible value placed upon a smooth and enjoyable onboarding process. On day one, I came to my desk and was able to go from “zero” to “functional dev environment” before lunch. The team maintains carefully-written onboarding documentation, which includes a very useful bash script to get a docker environment up and running. The script ran with no issues, and then all it took was a simple
docker-compose up to get the entire application running locally. I learned immediately that the docker configuration greatly reduces the pains of trying to create a local environment resembling those of staging and deployment (which was a significant cause of stress in previous projects/teams).
On my last co-op, which is the only other professional engineering experience I’ve had until this point, this same process of getting “up and running” was prolonged unnecessarily: I didn’t initially have admin privileges on my machine (and as a result couldn’t install anything properly); there was a process of “purchasing” software through an internal sales portal that required a sequence of approvals (any one of which could turn into a multi-day bottleneck); and similar things which I presume were the result of scale and company maturity. Thankfully, I am not faced with such issues currently.
I got code pushed to
master on day one. Yes, it was just one line, but the emphasis placed on jumping right into the team’s development flow is great; and getting a really trivial PR in on day one is almost like a greeting (“helloooo everyone I made it ?”) to the rest of the engineering team. It’s a good idea.
The rest of the week has been a gradual process of getting ramped up in the company’s codebase. The head engineer tagged a couple
starter stories for me to work on, which have sort of been a compass for me to use while navigating through the massive number of classes, tests, configuration files, etc. which make up the core product.
The low point of this week occurred on Thursday when I learned about some internal changes that had occurred since I signed my offer letter in March. The changes themselves weren’t negative per se, but they represented another set of “new things” I had to deal with in parallel to everything else. I experienced a minor shock but got over it pretty quickly.
There have been other good things, but I want to get to something else that’s been on my mind. In my one-on-one discussion yesterday with the head engineer, I realized that I may have been overly concerned about trying to make my first week as productive as possible. This meant that I didn’t spend as much time with the recommended resources on Ruby, Rails, and other guides which are intended to help developers new to the language/framework write good code. In week two, I intend to focus both on development work as well as tasks that optimize for long-term productivity, which at this point means learning as much as possible about the company, its team, and the technologies I’ll be using both now and in the future.