I turned off comments on this site today. The good people at Disqus had provided me with a free service for commenting that had worked for ten-plus years. But they appear to have gone down the enshittification path and started running a bunch of link-spam right above the comment box on all my pages. Of course they did. I captured a screenshot if you want to see. Boo.

Shame on me for entrusting a company to handle content for my personal site in the first place. Isn't controlling things the whole point of this old-school blog business? Not a big loss, nobody had posted a comment in a long time. But still.

I've been off work for about three months now. It's a good occasion to take stock of how that's going. In a word, it's been great.

• I'm surprised how much lighter my mood is. It feels like a weight that I've been carrying around for some time is no longer there. It's different than being on vacation, better actually. I didn't appreciate how stressful tech management has been all these years.

• I'm taking a ton of pleasure in simple things. I go grocery shopping almost every day, I'm doing a ton of cooking.

• It feels good to get healthier. I had knee surgery and am recovering from that just fine. I exercise nearly every day. On days that I don't go to the gym I do thirty minutes on the bike.

• It's great to have flexibility. I hadn't planned to see my Dad on his 80th birthday because we'd on a bigger group thing later. But on a whim I drove down and took him out for breakfast on his actual birthday, because why not.

• If I didn't want to do it before, I still don't want to do it. The closet hasn't gotten cleaned out; neither has the garage.

My friend Rachel Grey has a three month head start leaving Google. Her writing this resonates with me. Especially this from recent LinkedIn post (private, sorry): "one month off per year of service is a good rule of thumb; after six of them, I'm still feeling like a sailor who just barely managed to swim to shore." Maybe that's still where I'm at too.

So what have I been doing? I'm prioritizing friends and family — I'm lucky to have a lot of people I care about. I'm embarrassed that I haven't always been good about staying in touch, but I can fix that now. And fun stuff like bridge lessons.

Beyond that, I'm getting involved with a couple of small projects but nothing serious yet. When I find something interesting, I'll write about it here.

I believe good data about our world -- nature, people, economies, etc. -- is a public good. I believe that in my bones. Which is why it's so troubling to me when I hear

Homeland Infrastructure Foundation-Level Data (HIFLD) NASA

https://www.reddit.com/r/gis/comments/1lkol3s/sad_news_hifld_open_to_be_discontinued_by_sept_30/ https://projectgeospatial.org/geospatial-frontiers/the-rise-power-and-uncertain-future-of-americas-open-infrastructure-data

Values are useful. thirty years as an engineering manager has been in big companies, trying to get people to do things, and I've used values one of the quickest ways to do that. It gets peoples attention; it can bring an unruly or noncommital peer to heel.

Example At A Big Company -- Google

An Example -- Groups.IO

I'm writing to recommend a good vendor, Groups.IO. They are a mailing list company. If you have a group of people that you want to to keep in touch with, they can provide basic mailing list features. The free tier is pretty reasonable, up to 100 subscribers and only basic features. Then if you need bigger lists, or fancy features, they'll upsell a premium offer.

Why not just Google Groups? I basically believe their claim that Google Groups has gone long in the tooth. It works but it's been a long time since it's gotten improvements. '

For me the main driver was that it wasn't Google. The need to create a Google ID is a pretty big barrier for some people, either for philosophical or technical reasons. Amongst the group of people I was hoping to reach, a not-small number has some trouble with their Google account before, and having to sort that out was a big barrier.

There are two things in particular that cause me to write a special post.

1. Do One Thing Well

They offer this basic mailing list service and do it really well. Their service is fast, featureful, robust. Because it's the most important thing the company does, they take it seriously and it shows.

Now they do have a bunch of higher-value things like calendars and shared databases. I confess I didn't try those, and I don't begrudge them for expanding up the stack. But you don't have to use those, and the upsell isn't too pesky.

2. The Premium Trial is Well Behaved

This is really the unique thing that motivated this post. I wasn't sure that I needed the premium service, so I signed up for a free trial. The thing that was a pleasant surprise was when the trial period ended, it fell back to the standard. The email I got from them is included below, with the key sentence highlighted in yellow.

When was the last time you saw a service do this at then end of the free trial? I can't remember one. It's great.

What's so great about this is that it sends strong signal that this company puts the user first. I can imagine the pitch from the person at the company responsible for

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.