Unfortunately, the part they didn't tell you was that you should put more users first before putting fewer users first. (This is what "impact" means on the job ladder.)
Given two otherwise equal tasks, if one helps 60M users and another helps 12M users, you are usually expected to work on the one that helps more users. And if a product develops too many bugs of the latter type (affects too few users to ever be prioritized above other work), it will usually get shut down.
Fixing bugs for one or two or even a hundred users doesn't scale, and Google wants to scale so it can live up to its "potential to improve the lives of millions of people". (If you ever work at or start an early-stage start-up, you want to be the opposite of this because Google can't; see Paul Graham's "Do Things That Don't Scale" essay.)
If you come back (for another internship or full-time), the Intern Host, Product Manager, Director, and/or VP Engineering in your management chain can provide more context on how to apply "put the users first" in your specific context.
There are times where I was expected to put IE 9/Win XP above Firefox because that would help more users. And yes, that sucks, both for me, and for Firefox users.
The issue with this, that you have to focus on the largest group of users so you can "improve the lives of millions of people" is that it doesn't make sense: Google has hundreds of billions of dollars in cash they literally can't decide how to spend.
Clearly, they have enough money to "improve the lives" of more people, so that answer doesn't satisfy. However, the idea that Google is first and foremost a business which makes money at any expense, and it isn't profitable to support a competitor's browser, does.
In my opinion, the engineers that work on Chrome are the saddest about Alphabet products that are Chrome-only, because it makes it harder to cooperate with Firefox, Edge, and Safari engineers on open web standards.
I disagree with the idea that it is unprofitable to not support competing browsers. Just look at United States v. Microsoft Corp.
But, as you say, Google is first and foremost a business. As a business, it has a process where, if you don't have impact, you get fired. There are lots of people who, if forced to choose between "deferring work on Firefox bugs" and "getting fired", would choose the former. I would rather that they didn't have to make that choice in the first place.
When I say profitable, I'm assuming someone factored in antitrust risk (an all-time low given our current policies here in the US, mind you), as well as the lost customer satisfaction, possibly revenue from users of those other browsers, etc. weighed across the cost of man-hours to support other browsers. Obviously, Google supports iOS quite well, because that platform brings with it a massive amount of users, and hence a massive amount of money.
And FWIW, I recognize that the engineers are usually not the same as the businesspeople who make the business decisions. :)
> Google has hundreds of billions of dollars in cash they literally can't decide how to spend.
Those billions of dollars don't code for themselves. You need to hire more folks (yes, overtime is a thing at Google), you need to direct them to do the right things (means: more hiring), and more infrastructure. Besides the cafeterias which boil down to "even more hiring" (and why not, we did that twice in our thought experiment already) those devs need office space (of some kind), equipment and server time for testing their thousands of additional commits every week. And more server time to cover the additional test cases (eg. for additional browsers), so this is super-linear.
Given infinite dollars (or any reasonable approximation of that), the problem really is how to spend them without ending up finishing nothing because you've just invested them in a giant gridlock situation.
You have to look at opportunity cost. There is significant dev time that is spent supporting those configuration mixes that relatively few people will use.
If that dev time could be spent on other features that will be appreciated by more people, then that is a decision you can make while still adhering to the principle of "users-first".
So a multihundred billion dollar web company doesn't have the dev resources to support Firefox? Even though it already works when you spoof the agent string?
Even with all the resources in the world, opportunity cost plays into every decision. To remove that context would be missing my point.
And as always, resources dedicated to a project are finite. The “X billion dollar company can’t do trivial Y thing” isn’t as straightforward as it seems and the argument rarely holds up to scrutiny in my opinion.
We’re missing a ton of internal context here, and to have a real discussion we’d need that context. Otherwise there are tons of valid reasons why the opportunity cost calculation might not have worked out.
At some point you have to stop giving the benefit of the doubt. I draw the line where Google is unable to make a search page (that is making them the "x billion dollar" company in the first place) work with Firefox due to "lack of dev resources". Even though the only thing stopping the page from working in FF is a user agent check.
You are making exactly the same argument that Microsoft proponents were making when IE was bundled into Windows trying to push off other browsers. We don't have all the context, it must be too difficult to separate browser and OS code, etc
I agree. At some point they should stop considering FF users as "well they aren't OUR users" in the cost benefit equation. They have to acknowledge that FF has a big chunk of the market and it should be part of the "Browsers we test on" list.
Considering the features work fine on FF, the actual costs for testing on FF should be minimal.
Well, they’re busy solving that with alternative solutions, by paying devs to secretly install Chrome with their software, and set it as default, and similar shady deals.
This is helpfully decimating the marketshare of anything that isn’t Chrome.
> Even the VLC authors documented how Google tried paying them to ship Chrome as default with their installers:
It doesn't mention when though. If its around the time where MSIE was dominant, well, I (FWIW) got less of a problem with that. Because -even with its profiling- Google Chrome is objectively a far, far better browser than MSIE ever was. And the Google of 2005 or 2010 is a better Google than Microsoft was in 1998 or 2002. Check the Halloween documents on that one.
The only real cost here is processor cycles for increased number of automated tests. You don't even need a part time job to maintain the extra tests (otherwise you'd do something wrong).
> There is significant dev time that is spent supporting those configuration mixes that relatively few people will use.
The issue I have with this is that too many are looking at percentage/share/ratio only. Yes, percentage matters. But absolute values matter just as much.
Or would you call a couple of million people "just a few"?
And nobody answer with "for Google, yes", that's completely besides the point.
I'm a Firefox user working at Google.
A lot of internal tools are Chrome only and when they get released to public they have a lot of technical debt to make it compatible with FF.
The thing is engineer seems to always go for the latest internal library like Polymer which are only supported by Chrome. FF is working on supporting it which would probably improve the situation for a lot of Google product but it's taking time.
Also I've heard that Google is not so good at hiring front end engineer, as they are less likely to have the "inverse a binary tree" background.
Depends how you look at it. Dev time is a finite resource, and spending it on supporting a weird combo of user agent and browser seems likely to lead to less user utility.
Ive been on both sides and used most google ad products. For a solid 1.5 years we had to use Opera to function in DBM due to Angular memory leaks. I live in DFP now and have to reboot my machine after 3-4 hours in their interface using Chrome and Safari. Maybe they are just a really, really unfathomably big company that always see as users do across every team.
Sorry, I've really tried to come up with anything it seems reasonable to share more than:
'Google's ostensible adword assistance team were no more than glorified inside sales and, over the protests of the rank and file, bamboozled management into throwing over a $1 million dollars of good money after bad which helped sink the company'
Xoogler here, worked there for 18 months circa 2015.
> And the first thing they told us at the orientation is that they put the users first.
This is the company line, but the truth is that Google no longer knows itself. The orientation was designed in an era where Google was growing rapidly. The fear was that the early company culture of mutual trust and so on was likely to be diluted by the influx of new hires, so let's administer a proactive cultural injection.
But the reality today (err, 2015) is that the Google culture is no longer monolithic. Even basic day-to-day processes are different between Chrome and Android and Google and X and probably other teams I wasn't exposed to. The orientation has now become counter-productive for a large subset of the engineers, because it sets expectations wrong.
Examples: "Every engineer has access to all the source code." Or "no company code may be stored locally on a laptop." Or "every change must be code reviewed." These were company policies that were routinely violated by individual teams, which I only learned after daring to ask "how the heck are you getting your JOB done?"
Does Google "put the users first?" Depends on the org. In my admittedly brief tenure there, the most important consideration was internal politics, followed by "partner" and "ecosystem" concerns. Users registered but only distantly, mainly because we didn't expect many of them.
I think Modern Google can be best summarized with a company-wide goal of "be the most." Google Search as the most-used search, Android as the most-used OS, Chrome as the most-used browser, etc. If your revenue is based on page-views, and page-views are based on click counts...
"Most" is different from "best."
Edit: I feel obligated to clarify how the "we didn't expect many users" comment meshed with the "be the most" principle. I was a software engineer in a hardware org (think Pixel). The point of high-end hardware like Pixel was not to dominate the market, but instead be a prestige product that moves expectations. By building a MBP-level laptop, Google could demonstrate that ChromeOS is not just for throwaway laptops, and thereby make ChromeOS viable on its partners high-end hardware. Being too successful was an anti-goal, because it risks scaring off Samsung and the like.
The hope was not to single-handedly dominate a la Apple, but rather to foster the "ecosystem." As to users, well...they'd be better served indirectly by a robust ecosystem. Or at least that was the hope.
You'll notice that Google does not build low-end hardware, with the notable exception of Chromecast, which is another story.
Is that a lie then? Because what you said seems to imply Google puts the convenience of the developers first.