8 months of Software Engineering in San Francisco
For all of you who read about my first month at my new job, here’s a surprise: I’ve just passed my 8-month mark! I wanted to put together a reflection for myself and also update those who are curious what it’s been like to live and work in San Francisco as a software engineer at a growth-stage tech company. Work has been a huge grind, but at the end of the day, life is good. I’m grateful because I’ve been able to balance my time so I am maximizing my learning and my contributions to my team, while still spending time with friends and family.
So what have I been up to? Building things with Samsara!
What is Samsara?
We are a company building a platform for connected sensors. Think Alexa or Google Home, except instead of a little box sitting next to my bed that I can use to turn the lights on with my voice, it’s hundreds of thousands of similarly-sized boxes plugged into vehicles and factory production lines to help the world run more smoothly. From GPS, accelerometer, and thermometer to computer vision, microphones, infrared, and vibration sensors — you name it. We pack these sensors into portable boxes and then build a data platform on top. As a result, our customers can measure and record real-world data and even issue commands so that whatever they’ve been creating or moving around the world, they can do it faster, cheaper, and just better all-around.
Way cooler than Alexa. Although to be fair — Alexa helps me play jazz playlists at dinner parties and that’s something our Samsara devices don’t do… yet…
My team
Ever since I started last July, I’ve been working on an awesome team: Compliance.
As a whole, Compliance at Samsara is responsible for building tools to help our fleet customers meet government regulations, particularly the ELD Mandate. This mandate was set up to help keep drivers safe on the road, and basically defines how long drivers can work for and under what situations certain exceptions can be made. Companies that fail to stay compliant may be fined or lose their right to operate.
At Samsara, we split our compliance work into two teams. Compliance Foundations builds systems to record compliance-related sensor data in a scalable and accurate way. Compliance Features (the team I’m on) works on features to retrieve and perform calculations on the stored data so that our customers can easily prove that they’re compliant.
We also have other product-engineering groups as well as infrastructure teams. I work a lot with other teams in the Core Fleet vertical, and I work a bit with the infrastructure teams, but it’s rare for me to work with engineers from the other product-engineering verticals. So far, this engineering org structure has worked well for us because we can keep our teams small and focused.
Everyone on my team sits close to each other so it’s easy to have impromptu meetings when we need to gain some context on a project that we overlap on:
But we also know how to relax and have fun when we need a break:
Customer Focus
In terms of the work I do, if you’re not a truck driver, a fleet manager, or a FMCSA regulator, it might be hard to empathize with my team’s products from the user’s perspective. That’s how I felt when I started. But one of the awesome things I love about Samsara is that it’s really easy to get some face time with actual customers. We have a great design team and product operations team that organizes visits to actual truck yards so that we can meet with the owners of these companies and listen to their feedback. I took advantage of one of these opportunities to visit a customer up in Stockton recently, and I was able to see how valuable my work was to them.
For this customer visit, I learned a lot by just asking fleet managers how they operate throughout the day, and how they leverage Samsara’s platform to perform important tasks. We validated a number of pain points that we had theories about, and we even solved some of their problems on the spot by teaching them about new features. Overall, a very fun and valuable experience.
Interesting Engineering Work
Engineering-wise, the compliance team builds and maintains features surrounding some interesting data structures and architecture.
For example, there’s a state-machine system we call the “Rules Engine” that we use to model all the rules that the government has set for Electronic Logging Device (ELD) users, so that we can help drivers stay compliant. Zach and Casey have continuously iterated on the Rules Engine to provide violation information to our customers across hundreds of thousands of devices. The Compliance Foundations team spun up a new micro service to handle events recorded by the ELD and the Features team has added new algorithms and features to that service over time. Ian has worked on many front-end features and re-designs in order to make our UI as intuitive and painless as possible. I’ve also built out some new API endpoints for exporting compliance data, ultimately contributing to Samsara’s developer ecosystem.
All of these projects are built using our tech stack of Golang on the backend and Typescript on the frontend. We deploy new features based on a feature-flagged approach and track metrics on Datadog and AWS Cloudwatch.
Lessons Learned
Giving Estimates
Over the past few months, one of the best lessons I’ve learned about being a good software engineer is on how to give better estimates. Starting the job, I would give really rough estimates that would often be too aggressive because 1) I didn’t scope out the relevant code sites enough, and 2) I made assumptions on how many hours per week I’d actually get to code and think about coding.
To address better scoping as an organization, the engineering team has recently started to adopt a more structured Request for Comments (RFC) implementation spec document. We’d all use this doc when starting a new project so that different stakeholders could provide design input in the early stages of the project.
In terms of time-bounding my actual rate of work, I’ve started using “engineering weeks”, as defined by 2–3 days per week of actual coding time. Tuesdays are full of team and product-related meetings, while Mondays and Fridays are often occupied with candidate interviews and other interruptions. We try to keep Wednesdays and Thursdays as no-meeting days, but inevitably some extra engagements get sprinkled in throughout the week, and so we arrive at the 2–3 days of actual coding work per week. At first when Zach, my engineering team lead, taught me to estimate this way, it sounded a little strange that only about half of my week was spent on actual coding, but after experiencing the true flow of a project, it started to make a lot of sense. The meeting time that we don’t count as “coding” time contributes a lot to the success of a project by making sure that it’s designed well and that we’re not doing throwaway work.
The Power of Clean, Reusable Code
One of the favorite things I worked on was creating an internal library in Typescript that provides a variety of tested functions to make it easy to work with time range data structures. We emphasize commenting and documenting our code, so each of these library functions has comments to describe how to properly invoke each function. I had to take a couple days worth of detour from my project at the time to create this library, but it’s since saved a good amount of time for other people on the team, which is awesome. I’m looking forward to creating more reusable and useful tools like this for my team to help us scale!
Share Work Interests With Your Manager
First of all, you have to think about and formulate your interests so that you even have something to share, but once you do, talking about them with your manager will help you progress in your career. I’m thankful for the great managers at Samsara who are helping keep the team focused so that we can deliver quickly on key features, but also allowing each individual the opportunity to work on things that interest them.
For example, after working on an API project, I realized I really wanted to work more on the future of Samsara’s developer ecosystem. My manager, Derrek, talked through ideas with me and has been a great sounding board for identifying high-impact work that I can take on in this direction.
More pics
All of these pictures were taken during social gatherings at Samsara. Some of them were fun networking events, others were self-organized club hang outs, and the last picture was taken during one of our quarterly hackathons.
Taking a step back
- Samsara is adding 200,000 new devices to the platform every year.
- We now have 5,000+ customers worldwide.
- We’re collecting 100 billion sensor data points every year.
- The company’s valuation has tripled to $3.6 billion since I’ve joined.
- We’re expanding our offices in San Jose, Atlanta, and the UK.
What’s next?
- I’ll be moving to Atlanta for a few months to help hire and onboard new engineers!
- The compliance features team is growing! (Hi Nathan.)
- I’m helping lay groundwork to help our new app marketplace flourish in the future :)
Last but not least, shoutout to my roommates, my homies, and my amazing girlfriend for keeping life outside of work fun, healthy, and beautiful.
******************************************************************
If you’re looking for a software engineering job (and even if you’re not interested in Samsara specifically), hit me up because I’d love to help you with studying tips, interviewing tips, and networking!
Check out some of our open engineering roles:
- (SF) Software Engineer, Full-Stack
- (SF) Senior Software Engineer, Full-Stack
- (SF) Engineering Manager
- (ATL) Software Engineer
- (ATL) Senior Software Engineer
- (ATL) Engineering Manager
Feel free to connect with me on LinkedIn.
*****************************************************************
Special thanks Advith, Alex, Zach, Casey, Derrek, Ryan, Priscilla, Sarah, Sujay, and Elisha for helping with edits!
