# So long, and thanks for all the Gophers!


In some ✨personal news✨, I've recently left Google. It was a great ~3 year
ride, and I couldn't have asked for a better place to begin my career.

![Obligatory badge-and-laptop goodbye photo](https://benjamincongdon.me/blog/2022/07/10/So-long-and-thanks-for-all-the-Gophers/badge_and_laptop.jpg)

Whenever I'd interview candidates for Google, a frequent question was "What's
the best part of working there?". Invariably, I'd answer with the well-worn (but
true!) cliche that it's the _people_ who work here which make it special -- not
the free food. 😉 I was lucky to work with a bunch of talented engineers,
several of whom became valuable mentors. (You know who you are; thanks again!)

I also got to write and review a small mountain of Go code at the company at
which that language was created. This was a fun experience that helped me
level-up as a programmer.

So, why leave? It was much more of a "pull" than a "push". Things were going
well! I enjoyed the work I was doing, my impact was increasing over time, and I
was progressively increasing my scope. My team recently shipped something that
was a ~year in the making, and the usage metrics were encouraging.

But out of the corner of my eye, I saw myself approaching a comfortable local
maximum. The pace of my learning was decreasing, and I saw a plateau in the
not-too-distant future.
[From experience](/blog/2018/07/02/Inertia-and-When-to-Break-a-Habit/), I know
myself well enough that once I hit a local maximum I find it challenging to
break out.

<!-- If you'll permit a brief tangent, Charity Major's definition of a Senior
Engineer has stuck with me since I first read
[this piece](https://charity.wtf/2020/11/01/questionable-advice-the-trap-of-the-premature-senior/)
in 2020:

> Think of every job like an escalator — a 50-foot high escalator that takes
> about two years to ride to the top. But once you’ve summited, you stall out.
> You can either stay and wander on that floor, or you can step to the left and
> pick another escalator and ride it up another 50 feet. ... In my mind, someone
> becomes a real senior engineer after they’ve done this about three times. 2-3
> teams, stacks, languages, and roles, over a 5-8 year period, and then they’re
> solidly baked. There are insights you can derive from having seen problems
> solved in a few different ways that you can’t with only a single point of
> reference.

I like the "escalator" metaphor, but I think
[S-curves](https://en.wikipedia.org/wiki/Sigmoid_function) model this a bit
better since skill progression is nonlinear. On an S-curve, once you start to
see deceleration, it's clear that you'll soon reach a plateau. That's not a bad
thing; there's still quite a bit of area-under-the curve once you start
decelerating. But it does mean that you've reached the diminishing returns of
effort. And that's what I was beginning to feel pretty strongly earlier this
year.
-->

So, when an opportunity arose to "reset" to a new stack with a new org and
problem space, it felt like an appropriate time to make the switch.

What's next? I'm joining [Databricks](https://databricks.com/), working to help
build out their platform infrastructure. I've been interested in Databricks'
problem domain since college, and am really looking forward to experiencing what
it's like to work in a smaller, rapidly scaling engineering org.

(Oh, and yes, this was the context behind
[Tools for Making Difficult Decisions](/blog/2022/05/18/Tools-for-Making-Difficult-Decisions/))

