I think the point was that you can't say "Oh! So-and-so wrote this section, because all of the code blocks are like:

  if () {
  }

instead of

  if ()
  {

} "

Or "I know that so-and-so wrote this piece of code because there are goto's everywhere since he started off as a ASM programmer that eventually became a C programmer."

I've maintained a codebase that started in '89, and I'll tell you that there were some messy things in the code and lots of it was unmaintainable (well, 'maintenance' requires either 'major rewrite' or 'dirty dirty dirty hack'). I could go into code and see 3-4 different ways of accessing the database used within the same program. This is the kind of stuff that I'm assuming he's talking about. I've seen code where there are 'layers' like some sort of core-sample that allow you to tell when/who modified the code and what 'era' it was modified in.

That may be what neilk meant, I can't say. It's not what I meant. Even given the same style guide, you could probably tell the difference between my code and someone else's because I tend to write shorter functions, longer function names, and I use temporaries aggressively, especially to avoid linebreaks at inconvenient spots. I also write a lot of one or two-line block comments.

I partially agree with you that authorship is still visible, even when writing to a very strict coding standard. I'm thinking of a colleague who wrote a little mini-templating system to solve a particular issue. That style of solution was very characteristic of him.

But the point is, I could read through it almost at the same speed I could read my own code from a few months ago.

And, when I was modifying someone else's code, I didn't have to make any hard decisions. For example, if my predecessor had named functions inconsistently, I could make some lame attempt to follow what had been done, or try to carve out a chunk of code done "my" way. But at Google I never had that problem. And that's why people at Google can modify each other's codebases all the time.