An offer of a Voluntary Exit from Google HR landed in my mailbox right around my ten-year anniversary with the company, give or take. We'd had a couple of packages like this at Google before (news), basically the same deal you'd get if you got laid off. But this was the first one put in front of those of us working in one of the revenue engines of the company — I worked on Search.

I wasn't aiming to leave. I liked the work, I had a good team and boss. But the package was enough to kickstart a discussion, "why not now?". My wife and I ran numbers and discussed our futures. I clicked the button. My last day as a Googler was earlier this week, October 4th.

I have good feelings about my time at Google. It was nice that I saw a some different parts of the business: some consumer (three years at YouTube, four years at Search) and some enterprise (three years at Cloud). I got to play with big infrastructure and solve some hard problems. I saw behind the curtain. But the best part was the smart and interesting people I got to work with. I know it's a cliche, but it's the truth.

Not everything was great. I've decided to not use this space for dishy stories about how Google isn't all it claims to be. But I sure do love reminiscing and grousing as much as any engineer. If you want to share war stories over a beer, I'm always up for that.

What's next? I haven't decided if this is retirement, or a sabbatical, or something else. I've been off work for extended stretches twice before, once by choice and once not. Those two times taught me that the difference between a wonderful, mind-expanding time and a stress-fest is my own mindset. And now that I haven't been really working for six weeks now, I can confidently say that my mindset is positive and good.

I'm excited about the next phase. I feel fortunate to have some time to focus on what's important.

I liked the question that I got when interviewing at YouTube in 2015. At Google then we'd have an interview panel of four or five people, each assigned to cover a different area. Billy Biggs was the TL on my panel asked to evaluate "architecture." For a manager candidate that mostly meant evaluating technical cluefulness (someone else had me do some simple programming).

Billy's question: Discuss what would cause a Python interpreter to crash. Not a program written in Python, but the interpreter itself.

I remember this leading to a fun, rambling, back-and-forth discussion of the ways computers can fail. There are so many! Every level of the stack can fail in interesting ways: storage, RAM, memory management, networking. How would a bit flip in a TLB manifest? How does TCP/IP detect and handle ordering? collisions?

We also covered a bunch of engineering and process questions. How is the interpreter itself implemented, in what language and by whom? What would the quality processes be like for a product like that, especially given Python is presumably a really large open source project? How would you manage this? How important to quality is the role of the BDFL?

And then that lead to a some more interesting higher-level discussions about the actual costs and benefits of addressing failures like these in the field. When should programs hard-fail versus detect and recover? How would you staff an engineering team to find and chase down errors? What's the user impact to a failure like this?

One of my favorite things about this question is most likely it was something they'd actually seen right in their backyard. In 2015 significant parts of YouTube was written in Python (that's likely not the case anymore, I don't know). Crashes like these must have come up in the field. Not only are real-world problems relatively easy to ask, but they have the added benefit of showing the candidate the kinds of issues that the team actually deals with. It's also a well-shaped question: open ended, no right/wrong answers.

I got the job.

This is a story about how hard it is to come up with a good name.

This was in 2013. I was part of a team building a system for online education at Stanford. We launched a nice little site, Class2Go, with a small team in a few months. It worked well and supported the basic features of an online course: videos, assessments, auth, reporting. We decided to keep it going and worked on it for another year, expanding the covered use cases and taking on more classes.

But even from the beginning the name Class2Go felt a bit off. Our original aim was to enable offline MOOC students, people trying to take classes offline or in poorly-connected places But we ended up pivoting away from the offline use case to more standard hosted-course features. It became a little multi-tenant CMS with a small database for auth, assessment results, and some basic analytics.

We decided to rebrand. Someone knew a naming consultant, presumably an alum, and soon enough we had an expert on board. They were really interesting to work with. After understanding the platform's goals and features, they generated hundreds of candidate names. Each was vetting for domain name availability and copyright conflicts. The consultant was good at their job, bringing us something like a hundred candidate names (I wish I still had that list).

One name caught everyone's attention: Tindra. It's a Swedish word that means "sparkle" or "twinkle." It's evocative and easy to say. It also happens to be a woman's name, but not a particularly common one we were told.

Surprisingly, tindra.com was available! In 2013 short and catchy domain names were getting hard to come The new gTLD program had only just been approved in 2012, and .com and .org were pretty crowded.

The problem was that if you Googled "tindra," the top result was a Swedish adult film actress! Not good. Maybe with enough SEO juice, over time, we would have overtaken that. But on launch day, that's not the association you want to have.

We ended up punting on the problem and going with a generic name, Stanford Online. It got the job done, but felt like a missed opportunity. We later merged with edX and I found another job. Eventually the team re-branded the site with the name Lagunita, the name of the lake on campus, which they're still using today. I like it.

I admit I still have a thing for Tindra though. The name, not the actress.

Postscript: tindra.com still doesn't seem to be used for anything today. It looks to just be parked by a German domain registrar. Google results don't seem to be a problem. Maybe it's available for something interesting?

Thanks to Jane Manning for her review, she was there too.

What's the value of an experiment or a prototype?

There are all kinds of ways to have impact. A feature can improve user experience; a hardening project can reduce risk of a production outage; refactoring or test coverage can improve velocity or make software easier and safer to maintain. And good engineers care a lot about impact. While it's not the only thing that matters (the "how" is important too), if you start with impact, you'll generally do well.

An engineer's job to put ideas into practice, to make things. But sometimes we're not sure what to make. Or we think we know, but aren't sure it'll work. The best way to figure that out is often running a set of experiments, or maybe building a prototype (an n=1 experiment).

But crucially, an experiment doesn't have value itself. An experiment is successful only if we've learned something. The intent of the test rig or prototype isn't to live on. Indeed, knowing that we plan to throw it away is part of what makes it fast and cheap to build, and it shouldn't have all the trappings of production-quality software, like test coverage and code reviews.

So how do we ensure that value gets delivered? When you work in a team or a company people turn over. It's not just enough to do the experiment, you need to write it up and share your results. To produce a good writeup, you should:

1. Figure out the hypothesis(es) you're testing. Often this is in the form of one or more questions. For prototypes, it might be a boolean, i.e. we can build X that will work. But even then, consider what "done" means. Stating your hypothesis in terms of a metric is often easiest. NB I find the goal/driver/guardrail framework from Thanks Diane's book helpful, Trustworthy Online Controlled Experiments.

2. State your assumptions and method. This is where you usually get the most feedback. Note that this usually isn't a project plan, as your reviewers usually don't care how long it takes or what happens when.

3. Seek feedback from your peers. Publish the doc stating the method to have smart people poke holes in your plan and make sure what you're measuring will actually address the hypothesis. And then when the experiment is done, get it reviewed by someone senior to ensure that your work supports your conclusion. This also spreads knowledge about this work (both that you're doing it, and the results) so the overall organization benefits.

The artifact produced has many benefits. It's useful for you as you discuss follow-on work; it's useful come performance evaluation time. But most importantly, it benefits the organization. Contemporary and future peers can learn from this work.

You'll benefit from taking the time to write it up, the reviewers learn from reading, and it'll live on past your time with the team.

Sponsorship is using your position and influence to help someone get ahead. It's similar in many ways to mentorship, the topic of my last post. But sponsorship is a bit tricker. Most people understand mentorship and have good feelings about it. Sponsorship is a bit less familiar and might even feel a bit unseemly — at least it used to feel that way to me.

Although I'd heard the concept before, a talk Carla Harris gave at Google in 2022 made an impression on me and brought it to the forefront. (She has a 2019 TED Talk that hits a lot of the same points). She spoke about the value of sponsorship, both on the receiving end early in her career and now as a sponsor herself. More than just her description, what I most appreciated was her candor. It gave me a permission structure to use this concept myself. I started using it with junior engineers when thinking about their careers; I thought about it myself when debugging how some decision played out. It also helped me to think of it less judgmentally. Now I see it as being thoughtful and pragmatic about how decisions are made.

So what it it? Sponsoring is similar to mentoring in that it's an investment in someone, but the mechanism is different. Mentoring is a commitment to problem-solve issues as they come up, teach skills, and serve as a sounding board, amongst other things. Sponsoring is more strategic. The sponsor is committing to understand the sponsored's goals and strengths, and (here's the important part) help them get ahead. The time commitment isn't as large, but the actual commitment is greater. Assuming they see eye-to-eye, the sponsor commits to putting their reputation on the line to help the their person achieve their goals. Some examples would be vouching for the sponsored during a staffing conversations or seeking out and advocating for them when opportunities comes up.

In some ways, sponsorship acknowledges and even co-opts the "you have to know somebody" way that the world actually works. Underrepresented groups can benefit from sponsorship as a way to wedge into existing power structures. If that describes you, consider asking for someone to explicitly sponsor you; if you're in a traditionally privileged group, consider sponsoring someone who isn't so much. My Google peer Rachel observed: "women are often over-mentored and under-sponsored."

Maybe You're Going Up For Promotion

With this in mind, let's apply this to promotions.

Try as we might to bring rigor and de-bias these decisions, they are complicated and are made by real-world humans. Organizations rely on their senior people to bring their experience, knowledge, and judgment to bear.

Consider how the promotion decision will be made for your case. One key question is who'll be in the room? This isn't just who is invited and who will attend, but more who will be influential in the discussion and decision making process, and for what kinds of questions. Not everyone has an equal voice.

Say you're an engineer going up for promotion to senior engineer. Then likely a senior tech lead (not necessarily your tech lead!) will be asked to speak to the quality of your work (e.g. good code, considered alternatives, future-proofing). A senior manager will likely be asked to assess how well you worked with others and made good decisions. And these are just two of the factors — there will be many others depending on your role and level. You need to work down the rubric and think through who'll be asked to attest to each area as it comes up. Who will be asked to speak to concerns when they're raised ("was that really that hard?")?

Sometimes you might know who the key person will be, but often you won't. Enlist your manager or other senior leaders to think it through with you. Game plan the decision out.

And then assess their level of support. This may be something you can do yourself (if you have a relationship already) or maybe you'll need your manager's help. But somehow you need to ask them, as candidly as you can, "If asked about X, what will you say?" It can sometimes be hard to get an honest answer, so you may need to push a little. Reassure them you'd much rather know now if you have their support or not and you're not going to hold it against them.

If you don't have their support yet, that's OK. Think about work you can do to change that over time.

Day-To-Day Decisions

Not all decisions are as high-stakes as promotions. Leaders make decisions all the time, like whom to trust to lead a project or run a meeting. I like to think about these small-but-important decisions too in the context of sponsorship. Is your manager your sponsor? What about your TL?

Thanks to Josh Loftus, Maren Stever, Jane Manning, and Rachel Grey for their reviews.

So you're looking for a mentor, that's great! I've benefitted a lot from mentors in my career. It'll be a valuable experience for both you and your mentor. This post has my tips for finding a good mentor, asking them, and maintaining a good ongoing relationship.

Choosing

These are my three go-to rules for finding a mentor. They've held up across many companies and years.

1. Your mentor should be someone you admire. The best choice is usually someone the same career path as you, but further along by some years. They don't have to be so much more senior, it could just be the next step, but they've shown that they're willing and able to take on more responsibility and how to do it at your company. Ideally they're someone interesting, inspirational, and relateable.

Another type of mentoring relationship is when you're looking to make a change — say from Engineer to Engineering Manager, or Engineering Manager to Product Manager. Then you're looking for someone who made the switch. I find they're often the most eager to talk about how and why they did it.

2. Organizationally close-by is OK, but they shouldn't be one of your leaders. I've gotten the most out of mentors outside my chain of command. That way, I never had to worry about choosing my words (or topics) carefully. I could problem solve or just vent. Sometimes the person you need to discuss is your own boss.

3. Rapport is super important. Maybe the most important thing of all. Your meetings can't feel like a chore for either of you. Even if you've gotten along fine in the past, maybe you'll hit it off in this new relationship, maybe now.

How can you find the right person if it's not obvious who to ask? Use your network, talk to people, ask for referrals. Big companies often have mentoring programs for matchmaking.

Asking

While your mentor will benefit a bit, you'll be the one getting the most out of this deal. So it's up to you to ask. Understand that they're likely busy, so say how much you'd appreciate some of their time. Make sure they know it's OK to say no.

I recommend asking for a trial run to start with: "Let's do three or four meetings and then re-evaluate." That way you can make sure that it's clicking, see the "rapport" criteria above. If it's not feeling great on both sides then it's best to try again with someone else, no harm no foul.

Being A Good Mentee

So you've found someone, great. Here's some things you should do during probation and onward.

1. Respect their time. Be prompt. Work around their schedule and in a way that works best for them (30 min? over a meal?).

2. Come prepared with a topic or two, keep a backlog. It can be something specific, like problem solving a particular situation or relationship. Or it could be getting just-in-time feedback on a draft email or document. Or it could be open-ended, e.g. "if you could advise your former self 10 years ago, what would you have said?"

3. Check in from time to time. Make sure this is still working out for them: the style of meeting, duration, etc.

4. Find an appropriate way to thank them. Nothing big but it's important to show that you appreciate their time. For example at my current employer (Google) we have a system to give shout-outs to peers that come up at performance review time.

Finally, find a way to pay it forward. Introduce mentors and mentees; volunteer in your company's matchmaking service; find people who appear to stranded and offer to help them out. Sending this post might be a fine icebreaker.

I was so disappointed in Oppenheimer. It wasn't terrible, but what a missed opportunity.

Mystifying. Part of the job of a biopic is to give you insight into what a person is thinking and feeling. Especially for this movie, which is basically about this question: what would it be like to be the person who made these terrible weapons? I understand he's complicated, and it's complicated. But instead of dialog, or even some outright explaining, this movie leans on of Cillian Murphy staring into the distance or adjusting his hat.

Women. There were plenty of interesting women they could have brought in, either contemporaries, or from academia, or the Manhattan project itself. There are only two women in the movie: one is a sex object with mental health issues (Pugh); the other is a mother/lush with a surprisingly sharp wit, but only for a minute (Blunt). The sex scene, oddly using Oppenheimer's most famous line, was gratuitous and super weird.

Strauss. I'm not invested at all in the conflict with Admiral Strauss. Paraphrasing the good folks at The Incomparable, "I don't care if some guy becomes Commerce Secretary in the Eisenhower Cabinet."

Given how much I like the history and the science of this period, I was really pulling for this movie. Dang.

I did a data cleanup over the weekend. I doubt this is interesting for anyone else, I just wanted to capture my own notes.

Our family photos are stored up in Google Photos. We have about 100k photos and short movies that take up 0.5TB. I wanted to back up to local storage, but also I liked the idea of trying the mdisc format for long-term storage.

I ran Takeout and unzipped everything. I was surprised to see so many duplicates. Some are copies in the same folders with suffixes like "(1)", most are multiple copies in different folders. Takeout seems to just store a copy for each album a photo is in.

Some poking at the data shows 88% of 302,755 files / 72% of the bytes were unique (histogram at the bottom of the post). Removing dups can save 200+GB. Sure not really worth the trouble but why not.

Steps

1. On the NAS, gather file checksums (md5sum) and sizes for all the files under Takeout/Google Files. Mostly variations on of find -print0 | xargs -0.

2. Data cleanup to get into nice file paths and clean delimiters, mostly interactively with vi.

3. Insert into sqlite using .separator and .import.

Here's what the database ended up looking like: Photos and Sizes are inputs, HashCounts, Duplicates, and Candidates are outputs.

CREATE TABLE Photos(hash TEXT,path TEXT);
CREATE TABLE Sizes(size INT,path TEXT);
CREATE TABLE HashCounts(hash TEXT,found INT);
CREATE TABLE Duplicates(path STRING,hash STRING,found INT,size INT);
CREATE TABLE Candidates(path STRING,hash STRING,size INT,pos INT);

4. Find the dups. I'm surprised to find some with 50 or more copies, but it out some family favorites end up in lots of albums.

insert into HashCounts
select hash, sum(1) as found from Photos group by hash;

5. Figure out candidates for deletion

insert into Duplicates
select Photos.path, Photos.hash, HashCounts.found, Sizes.size
from Photos, HashCounts, Sizes
where HashCounts.hash=Photos.hash and Photos.path=Sizes.path
and HashCounts.found > 1;

The first of each set is the one we'll keep.

insert into Candidates
select *
from (select path, hash, size, row_number() over (partition by hash) as row_number
    from (select * from Duplicates order by hash, path desc)
) where row_number > 1;

I was surprised that sqlplus supports window functions, nice.

The inner reverse-alpha sort on "path" takes care of two cases. I tend to prefer keeping photos with names that start with years, and Those come first alphabetically (nice). Also within folders often there are many copies with "(1)" and "(2)" suffixes that are generally cruft and most worthy of removing, and those also sort last alphabetically (nice).

5. Dump out the "Candidates" using .output. Copy back to the NAS. Do lots of spot checks. Convert to a bash script of rm commands, run very carefully.

Tools

Sqlite is my go-to tool for ad-hoc work like this. It's fast and simple, but only for small jobs -- this one is MB-scale.

select name, sum(pgsize) from dbstat group by name;
name           sum(pgsize)
-------------  -----------
Candidates     3006464
Duplicates     5541888
HashCounts     11051008
Photos         23240704
Sizes          13807616
sqlite_schema  4096

My Synology is a pretty good place for storage with ability to ssh in and run local commands. But if I had to do this again, though, I should have just bought a large locally-connected SSD. All the transfers to-from the NAS were a hassle. Looking now I'm stunned that you can get a 4 TB external SSD for under $300.

Some private notes here.

(source)