4 ms·

When I was there (2005-2006, so, ancient history maybe), Google had a cultural problem with languages like Javascript. All their coding standards were developed

by neilk 17y ago

When I was there (2005-2006, so, ancient history maybe), Google had a cultural problem with languages like Javascript. All their coding standards were developed for languages like C++ and Java and the typical Google engineer had the most experience in such languages. Projects that promised to relieve the programmer from having to write in nasty Javascript (such as GWT) had a lot of support. There are islands of Javascripters in Google, but many of them are working on the browser initiatives. That said, the article is right about the importance of peer review at Google, although the headline is typical journalistic bait. Google's culture isn't so much engineering as it is science. Business is understood as an ongoing experiment. Opinions are worthless, only data counts. The results are stunning and many cowboy developers have become converts. There are many parts of Google's codebase that are so beautiful they almost brought tears to my eyes. You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. The same conventions are used everywhere, "tricky" parts are at an absolute minimum, and good documentation is usually a given. If there's one thing about Google culture that is worth preserving in all the startups now budding off, it's the peer review.

gruseom 17y ago
Both this and the parent (and even the OP, controlling for Cringely) give a fascinating perspective on Google's culture of peer review. Just out of curiosity, can you give some examples of how coding standards developed for C++ and Java wouldn't translate well to JS? (I'm a little surprised to hear about an anti-JS bias there, actually, though it does explain GWT.)
- curtis 17y ago
  A classic case I can think of involved a JavaScript class (or "class" for the purists out there) that was just used for data interchange. Basically it was just a collection of properties. However, for each property "foo", there was a trivial accessor method called "getFoo()". And because the coding standards said that everything must be JsDoc'd (JavaDoc for JavaScript, basically), the property initialization in the constructor had a JsDoc comment, something to the effect of "This is the Foo.". Then the accessor function, getFoo() had a JsDoc comment to the effect "Gets the Foo". Now in all fairness, the JsDoc comments were used to pass type annotations to the JavaScript compiler/compressor/obfuscator. But still, what the hell is the point of not just writing useless comments, but writing them twice? Not to mention the fact that accessor functions aren't all that useful in JavaScript, and they're especially not useful for objects that are just a big bag of properties.
- neilk 17y ago
  Well, to be fair to GWT -- I know the guys who developed GWT, and they are really smart people who just didn't like having the client/server language distinction, and who believed that type-unsafe languages suck for programming, and who wanted to use Java IDE tools to debug client-side issues, etc. etc. They were and are very smart JS developers, for obvious reasons -- they write the infrastructure that supports GWT in raw JS, at least initially. However, internally, at least at my project, they liked GWT because they thought it would liberate them from Javascript. Slightly different focus there.
- nradov 17y ago
  Here is the most commonly accepted coding standard for JavaScript. http://javascript.crockford.com/code.html http://javascript.crockford.com/code.html If you're familiar with C++ and Java coding standards you can see the JS one is substantially different.
lucifer 17y ago
> You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. Sounds like they have an inefficient meat-machine based code generator. Why not just use their considerable resources and automate that process?
curtis 17y ago
> You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. I disagree with this statement. I think having uniformly good code is, indeed, a good thing. On the other hand, I don't believe that means you should take it so far that you can't tell who wrote the code. Good developers can, in fact, differ about how to write good code. In fact my major general purpose complaint about Google is that they'd take a good idea and then take it way too far.
- pyre 17y ago
  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.
  - curtis 17y ago
    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.
- neilk 17y ago
  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.
omouse 17y ago
Do you mind if I ask which part of Google you worked with? I mean, particular products? Or are you still NDA'd? :S

by neilk 17y ago

gruseom 17y ago

Both this and the parent (and even the OP, controlling for Cringely) give a fascinating perspective on Google's culture of peer review. Just out of curiosity, can you give some examples of how coding standards developed for C++ and Java wouldn't translate well to JS? (I'm a little surprised to hear about an anti-JS bias there, actually, though it does explain GWT.)

curtis 17y ago
A classic case I can think of involved a JavaScript class (or "class" for the purists out there) that was just used for data interchange. Basically it was just a collection of properties. However, for each property "foo", there was a trivial accessor method called "getFoo()". And because the coding standards said that everything must be JsDoc'd (JavaDoc for JavaScript, basically), the property initialization in the constructor had a JsDoc comment, something to the effect of "This is the Foo.". Then the accessor function, getFoo() had a JsDoc comment to the effect "Gets the Foo". Now in all fairness, the JsDoc comments were used to pass type annotations to the JavaScript compiler/compressor/obfuscator. But still, what the hell is the point of not just writing useless comments, but writing them twice? Not to mention the fact that accessor functions aren't all that useful in JavaScript, and they're especially not useful for objects that are just a big bag of properties.
neilk 17y ago
Well, to be fair to GWT -- I know the guys who developed GWT, and they are really smart people who just didn't like having the client/server language distinction, and who believed that type-unsafe languages suck for programming, and who wanted to use Java IDE tools to debug client-side issues, etc. etc. They were and are very smart JS developers, for obvious reasons -- they write the infrastructure that supports GWT in raw JS, at least initially. However, internally, at least at my project, they liked GWT because they thought it would liberate them from Javascript. Slightly different focus there.
nradov 17y ago
Here is the most commonly accepted coding standard for JavaScript. http://javascript.crockford.com/code.html http://javascript.crockford.com/code.html If you're familiar with C++ and Java coding standards you can see the JS one is substantially different.

lucifer 17y ago

> You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. Sounds like they have an inefficient meat-machine based code generator. Why not just use their considerable resources and automate that process?

curtis 17y ago

> You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. I disagree with this statement. I think having uniformly good code is, indeed, a good thing. On the other hand, I don't believe that means you should take it so far that you can't tell who wrote the code. Good developers can, in fact, differ about how to write good code. In fact my major general purpose complaint about Google is that they'd take a good idea and then take it way too far.

pyre 17y ago
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.
- curtis 17y ago
  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.
neilk 17y ago
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.

omouse 17y ago

Do you mind if I ask which part of Google you worked with? I mean, particular products? Or are you still NDA'd? :S