It tends to be pretty easy to speed up readable+simple code when you need to do so, but fixing broken fast+clever code is much more difficult.

This was my second phone screen at Google, for what it's worth.

The language is a bit odd, and attempts to "read like English", but it provides so much scaffolding I feel like it's worth it.

You can [at least internally] define custom rules to handle pretty much anything, in almost-but-not-quite-python.

  >>> import re
  >>> route = re.compile(r'(?P^/foo/bar$)|(?P^/foo/bar/\d+$)')
  >>> route.match('/foo/bar').groupdict()
  {'fb': '/foo/bar', 'fbd': None}
  >>> route.match('/foo/bar/1').groupdict()
  {'fb': None, 'fbd': '/foo/bar/1'}

Isn't that the reason for comments in the first place?

"At" is the wrong word. The browser is requesting content. If it's requesting content from awesomestuff.com that only newyorker.com has permission to copy, that's a copyright problem.

This is a very odd metaphor for a journalist to mistake. It's as if any reference they make in a piece is violating the copyright of the referenced item. Is reference that difficult of a concept to grasp?

"All these areas would require an enormous amount of research either to validate or refute the theory, research that is unlikely to be undertaken by anyone not interested in rewriting the timeline."

* Merchants selling digital goods may transition to Google Wallet for digital goods

* Merchants selling through Google-hosted marketplaces (e.g. Google Play) will be unaffected

* Merchants selling physical goods will need to switch to third-party alternatives (see below)

-- https://support.google.com/checkout/sell/answer/3080449

There is a reason such jobs turn people into curmudgeons. It's not like they all started that way. You attempt to give a simple explanation as to what you're doing, but as soon as you say anything about their computer, they assume it's technical and tune out.

There are definitely people that would come into the office and learn how you fixed things, and those people were wonderful. Few and far between, though.

I think that's a really interesting comment! Perhaps it's because the UX is more social network-y (FB/Twitter), which are historically public, and less email-y+historically private?

if x == nil { x.doSomethingCrazy(); // Runtime error? } else { ... }

"Boolean blindness" (bah) is that either the type system should catch this at compile time (because we know x is nil), or the language should make it impossible to phrase (pattern matching to pull the information out, such as with the Maybe type).

Go has many type system oddities (reflection instead of generics, for instance), but the things they _have_ done (auto-implementation of interfaces, for example) are pretty cool.

I read this differently: an audience can get the most out of a presentation by paying attention.

If you're consciously communicating while attending a presentation, you're probably not getting anything out of what's being immediately said. In an information-dense presentation, that means you're not getting the most out of the presentation: unfortunate at best, and making the rest of the presentation hard to understand at worst.

Perhaps it's more useful read as an "attendee tip" than a "presenter request?"