On the subject of GitHub work for hiring: thinking about it as strictly positive or uselessly noisy probably means you have an overly simplistic model for evaluating candidates.

I'll share a model that's worked for me in the past. Before you even write the job description, define the 3-7 traits you need to hire against. These can be as fuzzy as "gets shit done" or as specific as "5+ years marketing SaaS to $100k+ accounts" or "is effective at resolving incidents while on-call."

I did some reading on @EnvoyProx's locality, and it is SO much more powerful than I had previously thought. It's crucial to implementing a service mesh with dynamic config, and it even has implications for how load balancing works.

Let's have a thread! First, wtf is locality?

Locality is just a struct that Envoy defines about itself. Each proxy instance can be configured to know about which zone it lives in (e.g. datacenter), which cluster it typically serves (e.g. ServiceFoo), and some other opaque metadata (e.g. AZ-VA-12).

I think I figured out why arguments like "an engineers should be on-call" or "all engineers should be deeply involved with production/ops" bother me.

It's not that I disagree, but it sometimes implies an untenable expansion of what a person's job is. Good version: when your branch is merged, you're expected to be available for 60 minutes afterwards if errors crop up in production. No clicking Merge at 5:30pm on Friday and hopping in a car to go camping.

You were expected to write a feature. This is part of it.