shemnon42

Couldn't agree more that we're offloading too much of our thinking. It's a genuine problem that keeps me up at night, or would, if I slept, which — for reasons entirely unrelated to this discussion — I do not.

Anyway, hand-crafted take, artisanal, small-batch, no additives. The upside is I've learned how to type the em-dash and the en-dash and learned their proper syntactical use.

Rookie numbers.

QKD can be sold today.

The quantum computers are not quite large enough to search at an `n` such that O(n)` is not viable but `O(sqrt(n))` is, that's where there's money to be made, especially if viability is defined by small time horizons. So it's a footnote for the future.

I was wondering if someone was going to ask. It's the most bizzare aspect of code reviews at Google.

And "Readability" doesn't mean you are good at a language, it means you are good at it in the way Google uses it. C++ readability is the poster child of this. Borgcron, not so much.

Everyone at Google has imposter syndrome. If you don't, this is how they make sure you get it.

Just another Jeff Dean optimizing out unneeded code story.

If I ever do this I'll blame tech recruiters who don't care what time zone I live in.

However things have been quite a bit better in that regard lately... :(

It's not about the stag show anymore, it's about the midway games that spew out tickets. A literal children's casino.

The bug is never the interesting part. The follow on questions are where the data is. How did you find it? How did you fix it? What made it memorable? Did it change the way you code?

> "what's the favorite bug you've ever fixed?"

I use a variant, "What's the most memorable bug you've fixed?" - and I use it as an indicator of maturity to distinguish L3 SwE from a L5+ SwE (google levels).

First, there is the time-in-field aspect. Simply being in the field for a long time increases the amount of time you have to encounter a sleep-depriving bug.

It can show tenacity. How did they find it? What did they have to do to reproduce it? Was it in prod, test, or dev? etc.

It can show maturity. Why did it pass test? What tests were introduced to detect it? Was it a new class of bug that required new testing? Were you able to add lint rules to detect it? Did you ensure it was pushed properly to prod and do proper follow up.

It can show autonomy. Did you update the testing procedures or just post a bug and hope the QA team fixed it? Did you meet with devops and share info on how to detect and mitigate it? Did you update the playbook at least?

So many possible places to dig in to get the "hire" when the default answer is "no hire". And if you cannot find any, then that's confirmation of the default answer.

Clearly? What distinguishes them from beanie babies or used concert ticket stubs?

Memegen has been toxic for way more than two years. Even before they gave the holiday bonus devices to school children.

The lack of any discussion of NFTs also indicates this is a dated paper.

Your describing the outcomes of the old "perf" performance review system. Cultural issues like that are hard, but not impossible, to change. GRAD changes things, but as long as promotions are tied to shipping new projects and not excellence in maintaining those launches we will continue to see this behavior.