4 ms·

Some inaccuracies pointed out by another FB engineer http://www.reddit.com/r/programming/comments/f3u0n/how_facebook_ships_code/ http://www.reddit.com/r/program

Some inaccuracies pointed out by another FB engineer http://www.reddit.com/r/programming/comments/f3u0n/how_facebook_ships_code/ http://www.reddit.com/r/programming/comments/f3u0n/how_faceb...

neilk 16y ago
Copying the main points here, from Reddit user "epriest": The article is has a few inaccuracies: There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn't look at every change personally. People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren't around to support them in case something goes wrong (and haven't found someone to cover for you). Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature. We have automated testing, including "push-blocking" tests which must pass before the release goes out. We absolutely do not believe "most engineers are capable of writing bug-free code", much less that this is a reasonable notion to base a business upon. If this is a real quote, it comes from a very junior engineer. It is empirically untrue. The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc.
- pak 16y ago
  OK, so according to him there's code review and some automated tests. But that still doesn't address wide open access to the live DB by brand-new devs, and the complete disregard for having a dedicated QA team. Why QA? I would think FB engineers are more busy doing real work at work than fooling around on their own site (heh, the irony) and finding out that Junior Dev 39's change to the thingamabob broke chat for the umpteenth time in IE7. And as many people have pointed out here, they are a platform for many other businesses now--there's no dogfooding that--and the API stinks in terms of stability and documentation.
  - aamar 16y ago
    It's easy to dogfood an API. Not saying that FB does, but it's easy to.
    - pak 16y ago
      It depends. If your API was built underneath your own site, then it's easy. FB's API doesn't seem to actually support anything on the main site, e.g., I doubt their own "apps" actually run on the FB Apps API. And there's no incentive for any of the engineers to build them like that, because they have such lateral access to internal code and data.

Some inaccuracies pointed out by another FB engineer http://www.reddit.com/r/programming/comments/f3u0n/how_facebook_ships_code/ http://www.reddit.com/r/programming/comments/f3u0n/how_faceb...

neilk 16y ago

Copying the main points here, from Reddit user "epriest": The article is has a few inaccuracies: There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn't look at every change personally. People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren't around to support them in case something goes wrong (and haven't found someone to cover for you). Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature. We have automated testing, including "push-blocking" tests which must pass before the release goes out. We absolutely do not believe "most engineers are capable of writing bug-free code", much less that this is a reasonable notion to base a business upon. If this is a real quote, it comes from a very junior engineer. It is empirically untrue. The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc.

pak 16y ago
OK, so according to him there's code review and some automated tests. But that still doesn't address wide open access to the live DB by brand-new devs, and the complete disregard for having a dedicated QA team. Why QA? I would think FB engineers are more busy doing real work at work than fooling around on their own site (heh, the irony) and finding out that Junior Dev 39's change to the thingamabob broke chat for the umpteenth time in IE7. And as many people have pointed out here, they are a platform for many other businesses now--there's no dogfooding that--and the API stinks in terms of stability and documentation.
- aamar 16y ago
  It's easy to dogfood an API. Not saying that FB does, but it's easy to.
  - pak 16y ago
    It depends. If your API was built underneath your own site, then it's easy. FB's API doesn't seem to actually support anything on the main site, e.g., I doubt their own "apps" actually run on the FB Apps API. And there's no incentive for any of the engineers to build them like that, because they have such lateral access to internal code and data.