4 ms·

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do

by pgroves 12y ago

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get 'funded'?

nbm 12y ago
That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the weekend - unless they like to structure their time like that, I guess. It may or may not be a full-time job, but the job whatever it is isn't some search for abstract perfection, it is again to solve real problems encountered by others in the company. Often it is a part-time component built as part of trying to solve some more direct goal - like fighting spam, or serving bits, or whatever. Often it is something the engineers just do - it makes sense to break things up into libraries, or services, or whatever, and they do that, and then that library or service is usable/useful elsewhere, and that's it. Other times they may suggest and motivate it as a goal-in-itself in a team goal setting situation. I doubt that's a particularly useful answer, but maybe with further questions I can make it more useful to you?
- logicalmind 12y ago
  I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help the competition. It does raise the interesting question of whether facebook employees are doing this work just to avoid the work that is the "core competency" of the company. Especially given the fact they don't gain a competitive advantage from releasing the work that facebook paid for into the wild. By this I mean, the company benefit would seem to be attract other talent. And the personal benefit for the devs is to get their name out there are something cool and interesting. Certainly, working on the best way to advertise to users is a lot less exciting/sexy than working on static type checking for javascript.
  - nbm 12y ago
    Different people find different things exciting/sexy to differing degrees. Some people like building stuff that others can see. Some people like building stuff that others will use. Some people like building stuff that makes other people build stuff faster. Some people like building stuff that is highly reliable, really fast, really scalable, or really efficient. Some people even find improving advertising really exciting - they expound on how ads can be win-win, and even that they can only find their full effectiveness when they are, or something like that. I don't think anyone is "avoiding" any work - there's just tons of work that needs to get done, and people mostly choose to work on that stuff that interests them. One could say that product engineers "avoid" infrastructure work and infrastructure engineers "avoid" product, but I think that would be inaccurate in most cases.
    - logicalmind 12y ago
      It is a great luxury to be able to work on what you like, especially as a dev. Unless you're a well-known person, I don't think it's that easy to work on what you like, even at google. At least not anymore. Hopefully you guys at facebook can keep the MBA's off your backs long enough to do more cool stuff!
- pgroves 12y ago
  It sounds like there is enough slack in the schedule that teams can decide they want to spend non-trivial amounts of time on these projects. It's surprising to hear that anyone, even the companies with big budgets, are able to hire enough people to do this without the projects getting an official seal of approval and budget. Even just taking the time to document, package, and publish is non-trivial. It seems like the vast majority of companies are not far enough out in front of their production issues and requests from the business side that engineers could do this sort of thing. So I guess it's impressive that Facebook (and probably Google) are in that position.
  - nbm 12y ago
    There is a degree to which scale makes it necessary to develop these sorts of projects. Losing 1% of productivity in a engineering group of 10 people might not be a big thing, but at 1000 people that's 10 full-time people worth of productivity you're losing. Dedicating 1-10 people for a few months or a year (or even two years) to remove that 1% productivity loss is clearly worth it. Documentation costs productivity to write, but when there are many people who would be made more productive from it, it makes sense to do it. I think "slack" is the right way to think about it. It isn't a free-for-all - the business still needs to run - but there's enough space to explore, to rewrite, to document, to polish, and so forth. That's where the magic happens - the unplanned and the unexpected things around that which you thought you were going to do.
avik 12y ago
We actually built this because we write a lot of JavaScript at Facebook, and we need a tool like Flow. So yes, we worked on it full-time, with "funding": our developers like to move fast, Flow helps them do that. (It's a different matter that we would have done this on our free time anyway, because it's so much fun!)

by pgroves 12y ago

nbm 12y ago

That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the weekend - unless they like to structure their time like that, I guess. It may or may not be a full-time job, but the job whatever it is isn't some search for abstract perfection, it is again to solve real problems encountered by others in the company. Often it is a part-time component built as part of trying to solve some more direct goal - like fighting spam, or serving bits, or whatever. Often it is something the engineers just do - it makes sense to break things up into libraries, or services, or whatever, and they do that, and then that library or service is usable/useful elsewhere, and that's it. Other times they may suggest and motivate it as a goal-in-itself in a team goal setting situation. I doubt that's a particularly useful answer, but maybe with further questions I can make it more useful to you?

logicalmind 12y ago
I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help the competition. It does raise the interesting question of whether facebook employees are doing this work just to avoid the work that is the "core competency" of the company. Especially given the fact they don't gain a competitive advantage from releasing the work that facebook paid for into the wild. By this I mean, the company benefit would seem to be attract other talent. And the personal benefit for the devs is to get their name out there are something cool and interesting. Certainly, working on the best way to advertise to users is a lot less exciting/sexy than working on static type checking for javascript.
- nbm 12y ago
  Different people find different things exciting/sexy to differing degrees. Some people like building stuff that others can see. Some people like building stuff that others will use. Some people like building stuff that makes other people build stuff faster. Some people like building stuff that is highly reliable, really fast, really scalable, or really efficient. Some people even find improving advertising really exciting - they expound on how ads can be win-win, and even that they can only find their full effectiveness when they are, or something like that. I don't think anyone is "avoiding" any work - there's just tons of work that needs to get done, and people mostly choose to work on that stuff that interests them. One could say that product engineers "avoid" infrastructure work and infrastructure engineers "avoid" product, but I think that would be inaccurate in most cases.
  - logicalmind 12y ago
    It is a great luxury to be able to work on what you like, especially as a dev. Unless you're a well-known person, I don't think it's that easy to work on what you like, even at google. At least not anymore. Hopefully you guys at facebook can keep the MBA's off your backs long enough to do more cool stuff!
pgroves 12y ago
It sounds like there is enough slack in the schedule that teams can decide they want to spend non-trivial amounts of time on these projects. It's surprising to hear that anyone, even the companies with big budgets, are able to hire enough people to do this without the projects getting an official seal of approval and budget. Even just taking the time to document, package, and publish is non-trivial. It seems like the vast majority of companies are not far enough out in front of their production issues and requests from the business side that engineers could do this sort of thing. So I guess it's impressive that Facebook (and probably Google) are in that position.
- nbm 12y ago
  There is a degree to which scale makes it necessary to develop these sorts of projects. Losing 1% of productivity in a engineering group of 10 people might not be a big thing, but at 1000 people that's 10 full-time people worth of productivity you're losing. Dedicating 1-10 people for a few months or a year (or even two years) to remove that 1% productivity loss is clearly worth it. Documentation costs productivity to write, but when there are many people who would be made more productive from it, it makes sense to do it. I think "slack" is the right way to think about it. It isn't a free-for-all - the business still needs to run - but there's enough space to explore, to rewrite, to document, to polish, and so forth. That's where the magic happens - the unplanned and the unexpected things around that which you thought you were going to do.

avik 12y ago

We actually built this because we write a lot of JavaScript at Facebook, and we need a tool like Flow. So yes, we worked on it full-time, with "funding": our developers like to move fast, Flow helps them do that. (It's a different matter that we would have done this on our free time anyway, because it's so much fun!)