diegs

I don't have firsthand knowledge of obtaining such justifications, but a couple things come to mind that seem reasonable to me as an engineer who has to propose any sort of project (and I worked at Google that also makes upstream contributions and was able to glimpse into some of the "contribute to open source" justifications):

- If you're already using gnu/linux, building functionality you need on top of what you have is most likely the easiest and least risky way to go (see also: worse is better[1]). Google and now apparently FB definitely built stuff on top of Linux to meet their specific use cases (Google was a big contributor to the original cgroups IIRC), and it worked out quite well for them.

- I would imagine that the way this might go is that a bright engineer/team identifies an opportunity to make a significant improvement, proposes it, does some back-of-the-envelope calculations of the potential benefits it brings, and convinces management that the risk/reward ratio is satisfactory. This is, generally speaking, a critical skill to possess as an engineer in any organization. But especially at the scale of Google/Facebook, if you can propose something that will save even single-digit percent in CPU/RAM/DISK usage or other operational considerations, that translates to many millions of dollars.

(Side story--and hopefully I'm not violating any NDAs by saying this--when I was at Google Jeff Dean was leading a grassroots effort to identify and remove wasteful code, such as extraneous log statements and unnecessary string formatting, and maintained a document that cataloged how much $/year (hint: often more than most people's salary's) each improvement saved)

- Generally, I feel like most of these projects likely come about incrementally, perhaps with some patches here or there, some ideas that come about based on experience or academic/PhD research from employees, and then eventually that accumulates into something that ends up being cleaned up and upstreamed.

- I also think that generally speaking, a lot of engineers do want to express pride in their work, and open sourcing it is one way to achieve that. Furthermore, there is likely a tradeoff of competitive advantage vs community goodwill and also getting other people outside of your company to maintain, debug, and improve what you made, and I think Google and Facebook have an engineering culture of preferring the latter to the former. At the end of the day, Google is profitable because of its search/ad algorithms and Facebook because of its social graph and ad platform. Their tech stacks are necessary but not sufficient, and furthermore are often don't necessarily provide that much benefit to others who aren't running at the same scale (realistically speaking, you can get a lot of mileage out of a single, relatively modest server running OpenBSD or something)

[1] https://www.jwz.org/doc/worse-is-better.html

I can afford to tip, so I tip. I pay 20% more a year for the privilege of consuming expensive capuccinos and muffins served by people who are being priced out of the city in which I live by my profession.

Whether or not the system is just, the businesses are compensating their employees fairly or not, or my tips are going to one person or the whole group, I feel better about not needing to worry about such things, eliciting a good reaction from the employees I interact with on a regular basis, and putting more of my money into the local economy in which I live and interact with on a daily basis.

I can't solve any of the macro problems, but for a minimal cost to me as a highly paid tech worker, I feel good about my contribution to the micro problems. YMMV.

What Yonatan and the parent are saying is that what Google "looks for in an engineer" applies to what is possible to screen for during hiring, which is only the very start of your career at Google.

In your actual career at Google pure technical ability it is very little of what Google "looks for"; that's necessary but not sufficient at all. Very few engineers are promoted for pure technical prowess; more often it's a combination of technical ability and EQ, or even just EQ.

Mostly it's a function of impact, which requires getting shit done, which requires working well with others. The top engineers at Google (Jeff Dean, Sanjay, Yonatan, etc.) are known for being phenomenal mentors, managers, and leaders--not just phenomenal engineers.

It's easy to be cynical and focus on instances where this is not true, but in my experience I agree with the parent that on the whole Google is quite good at managing its engineering org. In a XX,XXX person engineering org you're going to have some anomalies. And those are the ones that make these sorts of manifestos that are picked up by the media. Remember that Michael O. Church also worked at Google for a while and had a similarly controversial impact during his time there (look it up if you're unfamiliar).

Source: I'm a xoogler.

> Uber isn't a charity.

By that token, their drivers aren't charity workers either. If we put aside the inter-personal aspect of the video (which is contentious to say the least) this, to me, espouses the fundamental flaw in Uber's approach to their business: they have no respect for their workforce.

Unless they can get their self-driving cars working in time (which is another contentious subject), I suspect their eventual failure if it comes will be due to how they treat their drivers. Personally, I use Lyft because (a) in SF Lyft and Uber availability is more or less fungible and (b) I got tired of Uber drivers giving me an earful on how badly Uber treats them. Lyft drivers, in my experience (which is anecodtal, but I take at least 5 Lyfts per week and often 10+) are reasonably happy about their work. After the recent news I went ahead and deleted my Uber account, but that was an easy decision to make since I never use them anyway.