Everything Looks Weird When You’re New
A tale of maps, pull requests, and hitting the ground running at my new job.
I’m nearly 6 months into my job at Stripe, which means it’s the perfect time to write a four-and-a-half-months late post on my first six weeks.
However, I’m not super interested in writing about how I got here. It’s not a particularly exciting story — I was enjoying time off between jobs when Dylan tricked me into interviewing here and I fell in love with the team. Okay, fine, maybe I asked him if they were hiring, and maybe I was sick as a dog during my on-site and, okay, maybe this could make for an interesting post.
But I’m not going to tell it. Instead, I’d like to write about my experience ramping up at my new gig, some things I did that continue to pay off, and how this was all possible.
A Little Map in a Big Codebase
One of the first things new employees see at Stripe is an internal product called “Home.” It’s how we learn each other’s names, search for information across all sorts of platforms, and serves as a source of truth for things happening at the company.
As a remote employee based out of New Jersey, Home was particularly exciting to me as a means of staying up to date with all the things happening at Stripe, and also as a way to get the information I need without needing to bug someone for it.
So you’ll understand how completely and utterly horrified I was to find the following map on my profile.
See, here’s the thing. I was born in New Jersey, went to school in New Jersey, and came crawling back to New Jersey after San Francisco rejected me. New Jersey is an unfortunately large portion of my identity, so for this map to suggest that I live in NEW YORK is disgusting and unacceptable.
Something had to be done.
This issue isn’t a huge deal. Nothing’s broken, and maybe that’s even the intended behavior! Still, (a) it bugged me and (b) it seemed interesting. Those two reasons are more than enough to spend some free time between onboarding sessions at least poking around. What’s the worst that could happen? Maybe an hour of free time lost to the abyss.
I pinged my spin-up buddy David about this gross injustice. He suggested I poke around if I had the time (onboarding is super busy, after all) and offered some links where I could read up on getting Home running locally on my machine.
Following those instructions, I popped open DevTools, and started clicking around without a clue of what I would find.
“Mapboxgl,” hey that seems unique enough to search for!
I then hopped over to our internal livegrep instance (which I had heard about in passing in one of my onboarding classes), and typed a couple letters into the search field.
So we follow map.js down the rabbit hole and eventually find the line of code that’s been tricking everyone into thinking I live in New York.
const tooltipOffset = 0.03;// ...<LocationPopup
source={`/api/people/${person.username}?with_extra_loads=true`}
person={person}
updateLocation={(lat: number, lng: number) => {
tooltip.setLngLat([lng + tooltipOffset, lat]);
map.setCenter([lng, lat]);
}}
/>,
A-ha! Bug successfully tracked down. A little git-blame magic points us to a seemingly inconsequential year-old diff where we appeared to be adding 0.03 to the longitude… just because. (My working hypothesis, for employees who have “San Francisco” as their location,0.03 puts the dot closer to the actual Stripe office instead of the center of SF).
Well, 0.03 put me in New York so 0.03 has got to go.
Code is the Easy Part
This blog post is not one of a debugging triumph. After all, my diff removed three lines of code, and tracking down those three lines was easy enough thanks to Stripe’s tooling.
What comes next is far more interesting — how do I, a nobody who just started at this company, get a fix like this in place? How do I test my change? How do I write up a pull-request? Who do I get to review it? How do I respond to review feedback? How do I land it? How do I deploy it?
These questions were important ones: for nearly all changes to Stripe codebase, both the trivial and significant, follow very similar paths.
Fortunately, I had a network of folks (and a spin-up buddy) to walk me through the process of writing a PR like this (we have a template) and to make sure to tag the right people for review (we have bots that fail the build without them and can also ping them on Slack).
After responding to some comments, fixing my linting setup, and getting this PR re-reviewed and approved, I was then walked through the process of deploying the site. The specifics aren’t important, but a couple of shell commands and a dashboard to watch for any spikes in errors was easy enough with my spin-up buddy next to me.
I got some extra practice on the debugging/review/deploy process with two more diffs while I was going through Stripe’s training for new engineers. These diffs were also for bugs that piqued my curiosity (color contrast, web performance) so I just went for it. Again — what did I have to lose? Maybe an hour or two of my time.
Additionally, these two diffs expanded my comfort zone in that I tagged folks to review them that I had never spoken with. Git-blame, slack logs, and searching documentation suggested that they were equipped to review changes to these tools, so I just went for it. Turns out my coworkers are super friendly and give great feedback.
Head Starts
Was it worth it? This much effort (and all this writing) for some pixel tweaks on internal tools? One could argue that these bugs were known and ignored because, well, they just weren’t important.
It’s easy to fall in such a trap, especially at a company of this size with this many people and processes. Additionally, as a new hire, I had a tension between not knowing anything at all, and having an acute sense for things that were out-of-place.
My pro-tip, and the point of this article, is that you can hop right over this fence if (a) the fix is interesting to you or (b) the cost of not finding and merging a fix is low. In this case, I was a curious new hire who wanted to get a feel for Stripe’s big codebase — and I had lots of free time to play. I may have lacked context and history, but was not burdened by the tunnel vision that leaves your map pointing at the wrong state.
There are some obvious benefits to all of this:
- The product is better off, even if just by a little.
- I can get some extra practice on things like code review, grepping, testing, deploying — the details of Stripe engineering — in a safe, relaxed environment.
- It’s just fun.
Six months into my role, these small changes are still paying dividends, and I’m still making room for a little fun.
If this sounds like fun to you, Stripe is hiring. Thanks for reading.
