41–50 of 116 posts
http://www.quora.com/Facebook-Engineering/How-accurate-is-th...
What a crock of shit: after boot camp, all engineers get access to live DB I can understand on a startup or small org but an organisation of that size, there should be very tight access control. Despite what anyone says, the probability that someone does something bad increases in larger groups. Security should be on a simple need-to-know basis and nothing else. I build BIG financial software and we have certain audi…
>I build BIG financial software and we have certain audit requirements, access control requirements, data protection requirements etc and that is exactly how it should be. Funny, I had the same argument with a colleague today. Since FB is listed and their business model is based on customer data they should follow the same legal requirements as customer finance companies.
Perhaps. But they certainly do not have the restrictions of financial audit requirements and things like Dodd Frank etc. which is overwhelming all the major banks right now and is a big way to earn money for consultants if they know ABC of audit/compliance in 2012. Anyway, the point is that fb even though not ideal in how they store/use user data (which I personally am not a fan of as well), it does not matter as much as it matters to a bank/financial institution. I say this while I work for clients that are major banks.
Earlier quoted context omitted.
You finance and billing guys will never understand. These are rockstars . They work for facebook. They would never ever type UPDATE users SET email = username || '@facebook.com'; WHERE username == 'john.smith';
Of course not. Much faster to type UPDATE users SET email = username || '@facebook.com'; Then let the users sort out the exceptions.
I really like seeing this approach listed: "resourcing for projects is purely voluntary. A PM lobbies group of engineers, tries to get them excited about their ideas. Engineers decide which ones sound interesting to work on." That sounds exactly the same as how Github's engineers work. It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. And if you can't get anyone interest…
> It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. Eventually people lose interest. It's only human. But The System has been written, it is in production, and it has accrued a healthy stock of user data. One day, The System breaks. "Only" tens of millions of users -- less than a percent of all Facebook users -- rely on the The System. But they rely on it utterly. Who wi…
Good software should be written on the assumption that someone else is going to be editing your code at a later date anyway. If it's highly readable, then being unable to grab the original developer is less of an issue.
This is one of the reasons for the peer code reviews during the original development.
I doubt it's really that hard to find developers to work on issues like this. I've always thought the idea that their work impacts millions of people, even though that is a tiny percentage of the total userbase like you said, was one of the big attractions of working at Facebook. If I knew of an issue impacting that many people, I'd be delighted to have solved it.
Earlier quoted context omitted.
Thou who uses unit tests, UI tests, precondition, postcondition checks, heavy logging, knows the language and toolchain and knows arse from elbow NEVER debugs in production out of necessity or desire. It just works. In the last 5 years, we've never hooked a debugger to production instance or given access to a developer. In that time, we've pushed approximately 912 billion SQL transactions through the system and 24 bi…
No please tell me, how did you learn to write unit test which cover all the crazy data configurations users are able to come with.
My whole mantra is don't manage complexity: avoid it.
Earlier quoted context omitted.
Of course not. Much faster to type UPDATE users SET email = username || '@facebook.com'; Then let the users sort out the exceptions.
I think he was being sarcastic - you can see the semicolon in the middle of the command which looks like pretty much what they did with the whole e-mail debacle. You simply removed the second incomplete statement.
Earlier quoted context omitted.
Thou who uses unit tests, UI tests, precondition, postcondition checks, heavy logging, knows the language and toolchain and knows arse from elbow NEVER debugs in production out of necessity or desire. It just works. In the last 5 years, we've never hooked a debugger to production instance or given access to a developer. In that time, we've pushed approximately 912 billion SQL transactions through the system and 24 bi…
No please tell me, how did you learn to write unit test which cover all the crazy data configurations users are able to come with.
There are heaps of techniques one can use to identify which data points and combinations are useful to test. Some of these techniques even take a peek at your code to highlight the possible pain points.
This is the real Facebook secret sauce in convenient flowchart form: What's the most evil thing we can think of doing? V Candidate ------->^ V (yes) ^ Is it legal? ^ V (yes/no) ^ Can we get away with it? (abs. not)--->^ V (yes/maybe/prob. not) ^ Keep shipping! ^ V ^ Did we get in trouble for it? (no) ^ V (yes) V ^ Claim it was a mistake! V ^ V V ^ Still in trouble? (no)-> Keep feature->^ V (kind of) ^ Being sued for…
Earlier quoted context omitted.
I wouldn't lump Google in there with Facebook. We have very strict controls on access to user data (we can't even see email addresses in logs), and we have not adopted the motto "move fast and break things". We do extensive automated testing and have release processes that are designed to minimize problems in the event of a bad push. Yes, bugs happen from time to time, but it's software -- there is no known practical…
I'm not arguing for unrealistic quality levels, and I will acknowledge immediately that my experience could be atypical. However, in fairness, if I look at all of the software that I use regularly in a professional capacity today, then it is clearly Google products that are the most buggy, and by a very wide margin. For example, I have a client who uses Google Docs/Drive. We have rarely managed to hold a meeting with…