How Facebook Ships Code
framethink.wordpress.com
How Facebook Ships Code
1–10 of 116 posts
Re: How Facebook Ships Code
#2What 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 audit requirements, access control requirements, data protection requirements etc and that is exactly how it should be.
I'd never put my data near FB. They are simply irresponsible.
Re: How Facebook Ships Code
#3I 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 interested in working on the project, then it's a good indicator it may not be a project worth completing for the company anyway.
I'm sure there are times when someone has to say "We need someone to do this", but I'd be curious to hear from someone who works in one of these environments how common an issue that really is.
Re: How Facebook Ships Code
#4What 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…
It's a little irresponsible, but how else do you expect them to debug live code?
Re: How Facebook Ships Code
#5I 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…
I'm curious - what happens when an engineer wants to propose an idea? Do they need to get a PM on-board to lead the project? Who decides if the idea is good?
The PM/engineer divide feels uncomfortable to me, but I have limited experience with these roles, so it's likely simply for lack of knowledge. I hope someone can clarify this for me.
Re: How Facebook Ships Code
#6I 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…
I'm curious - what happens when an engineer wants to propose an idea? Do they need to get a PM on-board to lead the project? Who decides if the idea is good? The PM/engineer divide feels uncomfortable to me, but I have limited experience with these roles, so it's likely simply for lack of knowledge. I hope someone can clarify this for me.
From the article at least, it seems like there aren't a whole lot of PMs at Facebook.
If an engineer has an idea, they seem to be more encouraged to just find some people to work with, build it, and then roll it out to a very small section of Facebook's users and see how they react to it. Good ideas might then be taken further, but bad ones (Or I guess, ones people just don't care about) won't be.
(I don't work there though, so I have no way of knowing if that's right or not, sorry!)
Re: How Facebook Ships Code
#7What 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…
Note that it doesn't say whether they all have write access, or whether all the data they have access to is encrypted in some way.
And any of those statements should be interpreted as one response he got from talking to lots of different people, and be subject to some amount of skepticism.
Re: How Facebook Ships Code
#8Previously on HN: http://news.ycombinator.com/item?id=2594083
↪ How Facebook _actually_ pushes updates to the site
I came across this originally on the Etsy dev blog, rather than HN, and that particular post had some good other stuff about Flickr and Etsy:
http://codeascraft.etsy.com/2011/06/01/pushing-facebook-flic...
Re: How Facebook Ships Code
#9What 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…
It's a little irresponsible, but how else do you expect them to debug live code?
You don't. Reproduce the issue on a development instance.
Re: How Facebook Ships Code
#10Am I the only person who thinks this whole approach is broken?
We have seen the rise of "devops" recently, and big name web companies like Facebook and Google seem to be very proud of how engineer-led they are, how empowered their developers are, how their product managers don't have much real authority, how they push code to production ten minutes before it's even written, and so on.
From the outside, I see systems that are always changing, so users can never rely on anything working the same way from one visit to the next. I see organisations with access to sensitive personal data being cavalier at best about how they handle it. I see a major blunder every few weeks that at best causes serious irritation to users and at worst risks significant loss of business and/or legal/regulatory consequences.
And I see huge brands whose egotistical staff don't realise that they are successful despite evidently not bothering with either real product management or robust testing, not because of these things, and who don't seem to notice that they are still relying almost entirely on momentum from one or two really big successes from early on to maintain their user base and revenues.