My employer is a huge AWS user and Google is constantly chasing us with a treasure chest of free credit to migrate over, their prices are significantly cheaper, but everyone agrees it’s worth the premium to stay with AWS simply because they answer the phone.

(If you have never used AWS’s enterprise support, those guys are worth every penny.)

That's enough that someone at Google will acknowledge what you're reporting is a bug on their end, and that they can reproduce it. But it's not enough to get the bug fixed.

The support may be good if you're asking questions they've heard before - or if you need something like an account lock reset, which the support folks have a button for. But if the problem you're encountering requires a code change? Not so much.

(If you're wondering, the bug is "in Google Drive, users with third-party cookies disabled get stuck in a redirect loop when downloading files or viewing videos, as the cross-origin request to googleusercontent.com attempts to redirect to get an auth cookie that never arrives" )

We have a saying here that goes something like "don't buy pizza at a burger joint"... Don't buy services from a advertising / products company.

I will remember this. Thanks.

> That's enough that someone at Google will acknowledge what you're reporting is a bug on their end, and that they can reproduce it. But it's not enough to get the bug fixed.

I will try to remember that the next time I deal with an open-source project, either as a user raising an issue, or as a project contributor helping solve such issues.

Often, we do not realize how lucky we are that contributors to open-source projects help fix the bugs which we report.

Google hold too much control over the internet and the majority of internet users lives, to the point where it's almost authoritarian: They can screw with your personal life and potentially your business without any recourse, causing the effects such as the one I just experienced. I'm not suggesting some large conspiracy against those who oppose Google's affect on the web, and many of us will continue to complain openly and loudly about them because that is our culture. But the effect their position has on freedom of speech is still present, it's a natural instinct, it increases the chances of a large portion of the population to remain silent out of personal fear - and that is concerning.

Once I subscribed to YouTube Music (paid!) family plan, but my wife's account would always say that she is in another country and can not join the plan. I tried everything - the support never even bothered to reply to my emails. I cancelled the plan and since then I keep seeing the same ads for the premium service every time I open the YT mobile app.

(And in fact, what actually happened was they hadn't sorted me out by the time the free trial was up, so I cancelled it and switched to the individual membership. They managed to get things sorted out a week or two after that, but I'm still on the individual membership; my wife just shares my account ID.)

I had to login to both mine and his account in order to complete my support request or they wouldn't help me. When I called them it was like any crappy indian support team which I barely could understand.

Compare that to DigitalOcean for example, there you can actually group resources for an org and their support is actually knowledgeable about their products and can answer questions even about implementation details. Also, you don't need a PhD in order to understand the UI which is a great plus.

I find that extremely difficult to believe without more context. Google support isn’t that bad. I’ve had a mediocre-to-good experience with it over the years.

With that said, while I agree that aws business and enterprise support is worth the hundreds to thousands of dollars a month, so is the five bucks a month for a google workspace account that includes support.

The only item in Google's business playbook...

If, somehow, an antitrust ruling split ads from the rest of Google the non-ads remainder wouldn't last more than a few years.

You are 100% correct in that ads are the ONLY thing propping up google as a business. This is probably a very bold prediction, but I think that when money starts getting more expensive, when rich billionaires are more reluctant to just throw money at inane, borderline speculative bullshit, there will be a massive hemorrhaging of unnecessary business. And maybe this is a little out there but... you know how YouTube doesn't actually make any fucking money?

Interesting things to think about for sure.

https://www.theverge.com/2021/7/27/22596592/google-q2-2021-r...

I think it's projected to earn 20 billion this year.

[1] https://hbr.org/2021/02/what-digital-advertising-gets-wrong

I am locked out of my (10+ years old) account for almost two years, due to "security reasons" (I have valid OTP so I call this BS and my credit card has changed in between so the account is useless for anyone), they want me to call some number in states, but I am not giving my phone number away, which is also the reason why I don't create new account.

I have calculations, in last two years I have bought 4378 EUR online. This could be collected by Amazon - but now it isn't.

I am still waiting when they will come to their senses and figure out that locking out users (especially if they made quite a few purchases) longer than few months is counterproductive.

Meanwhile they are losing money they could earn. Good job.

The team I was on at Amazon every line of code felt purposeful. At Google it's just Java charades. One time we were propping up a new micro service that received data from one data source, transformed it to another data source. That's it. No other API calls, no algorithms, no design patterns, no filtering, just deserialize/serializing/renaming fields between two data formats 1:1. It's literally a few dozen lines of code. I was the project lead and was likely going to be sole person responsible for it, and I proposed it be written in Go. It took to me 2 days to implement it in Go. Our manager wanted it rewritten in Java, because no one on the team knew Go and in his opinion would want to learn Go. The Java rewrite took a month to get to an MVP "Hello World" state, and another month to calibrate the codebase with the rest of our projects. It takes days to learn Go, less than a month to be well-versed in Go's standard library. Its package management is simple but also sane. Years working with Gradle and there is still weird stuff popping up every so often. The microservice depended on some Google "public" client libraries. At least with the Go libraries it's feasible to read the entire source code and flesh out things on the edge of documentation. Go's limitations also means code tends toward being idiomatic and standard. Besides the Maps API and some GCP products that receive attention, most of the APIs/libraries feel half-baked for external consumption. Documentation is a big piece of it. I'm not sure what the state of AWS documentation is nowadays but, on my Amazon team, we were co-developing documentation and code in unison, like how people iterate between test/code.

At Google, documentation feels like an after the fact dread so that a bunch of suits ( dressed in jeans and t-shirt ) can green light the project and sign off on a laundry list of due diligence of "product excellence". The final product is documentation that centers around a Hello World, but after that you're often not sure how to proceed. You're instructed to run a bunch of commands serially without much context, basically the fish, but you didn't really learn how to fish. Beyond this imperative 'Hello World' style documentation is nuanced callouts and notes for some esoteric cases for exhaustive coverage purposes that is just really distracting for 99% of clients. Basically don't sue us, we made sure to mention is in documentation. I've worked extensively with the Google Cloud documentation org, and they are really problematic. Google is usually too nice ( or maybe it's just the game dynamic of everyone having cushy job ) to fire people, whereas Amazon would go in a "different direction". I don't see this documentation problem going away until there is leadership who isn't afraid to fire people, which is also unlikely to happen as the well intentioned engineers will quickly rally to dispose of this style of leadership. One time the documentation org held a session for internal developers to provide feedback because clearly documentation is not serving the customers. They were shutting down every idea and interrupted in mid-sentence, only agreeing with things that confirmed/supported their agenda. Then working 1:1 with members of the documentation team to launch a product, I realized the individuals also succumbed to selective hearing. They're like recruiters who just scan for buzzwords like 'REST', 'HTTP', and so Google documentation has random sentences explaining to technical clients of a specific technical API what REST, HTTP, gRPC is. The intended audience are paying clients, and I'm not talking about hobbyists, not students who are not familiar with cURL yet, but the documentation writers are effectively the latter. I admit, the documentation staff write more fluid English than I do, but what's the point if they introduce a bunch of superfluous, sometimes even semantically meaningless, sentences wherein readers of documentation can't discern the forest from the trees? It became a second job for me to revise the documentation, and my manager wasn't supportive nor appreciative of me doing this non-engineering work. That's when I started planning my resignation. If Google is serious about cloud and developers, the problem can be solved by paying actual engineers to write documentation.

Code Review at Amazon felt constructive with the user in mind. Code Reviews at Google felt reductive to the pet peeves of the reviewer and minimizing conflict. On that team at Amazon, performance was actually a priority. I actually felt like my Computer Science degree was put to use, but not in a pretentious, ivory tower, scratching your own itch/ego kind of way. The latter opportunities are more common at Google. The Amazon team built their own dependency injector and markup language, not because it was something to brag about, but it was solving an unmet need at the time. HackerNews never forgets about the long list of products Google abandons, but there are also the projects that are dead in the water. At Google, I was adjacent to a team reinventing HTML but defined in YAML, with less functionality and composability than HTML but implicitly requires you to already know HTML. Probably 10,000 humanhours were allocated to this project. The team are exclusively from infrastructure backgrounds. No one wants to say this, but there is a belief, at least based on my impression of Google hiring practices, that backend engineers have higher aptitude, therefore you can train them to be frontend engineers. I don't think this is true. Ironically, when I interviewed at Microsoft they actually asked me interviewing questions requiring browser APIs and interacting directly with the DOM. When I was the technical interviewer at Google, asking candidates such practical questions rather than Leetcode-style problems tripped them up way more. On the Amazon team I worked with, everyone's first programming language is JavaScript. We directly fiddled with the DOM which goes against all the modern web framework abstractions, VanillaJS, native browser APIs, minimal transpiling for compatibility. This was code 1-degree removed from the user and, ironically, as we were fiddling with the DOM and exposing ourselves to all the dangerous state, nothing bad happened. Then again, we sent people to the moon with much less. At Google, I felt n-degrees removed from the user, while standing on top of many more abstractions and yet in many product areas besides things like Search, 99.5% felt good enough, whereas at Amazon I truly believed in 99.999%. On the Amazon team we leaned on Prototypical "inheritance" and embraced JavaScript, rather than trying to fight it, shoe-horning in Java style Classes, because Google ultimately is a Java shop. Angular has singletons, factories, and other symptoms of people exercising their extensive knowledge on the design patterns in Gang of Four. Meanwhile at Google, I saw triply nested for-loops that I refactored to linear time. It wasn't really appreciated, because on the grand scheme of things, Google focuses on being planet scale, which might explain why SMB / hobbyist support for GCP is mediocre. Indeed, Google infra and internal tools are the best. Possibly even over-engineered where there is diminishing returns, possibly inflecting down on productivity because the tools handles too much for you that you are now responsible for knowing its extensive features and capability set. There's always someone who knows, but you gotta make sure you've done your research before you come to them without extensive due diligence. At other places I've worked, including Amazon, I think there is less anxiety in knowing that you don't know and ignorantly reaching out for help because we're all fools anyways. Google has publicly mentioned that they found no correlation between academic GPA and job success, but I'd bet there is a high degree of imposter syndrome. In practice, Google still selects for the academically excellent, where from an academic and school setting you are expected to know the "right answer", but software engineering is an art not a science.

Products, however, are different story. I am back in school, and the school decided to use Google Classroom. This thing has a 1.5/5 rating on the Apple app store. I'm curious how many people work on it. I apologize if it's a lone developer. But I wouldn't be surprised if this was a team of 3-4+ engineers, a product manager, a manager, a UX designer, a UX researcher. Google Classroom, at least in my school's usage, is just a feed of posts. A Facebook group would have sufficed and been much better. I'm imagining there's a sales team for Google Classroom. At least Google's improving on the non-search/Ads business front.

The not-so-brilliant-and-clever part is that by virtue of being free and Google having so many schools captive with free GoogleEDU + Chromebooks, this is something running millions' of kids' schooling, especially now during COVID. But it seems, at every indication, to continue to be someone's pet Google Drive API project, so you see some insane feature omissions because it is clear it would probably require some sort of actual original development work besides the very minimal UI and overhead that Classroom provides. I need to thread lightly, though, 'cause I've made decent money (and had fun) implementing quite a few of these for my own school, but every single time its been clear to me that EVERY OTHER SCHOOL IN THE UNIVERSE would also want/need things like that.

I do see they have a marketing / landing page which makes me feel there is a product charter beyond half-a-SWE: https://edu.google.com/products/classroom/

1. Why did OP do this without talking through it first

2. Introducing a new language to a team is not some small decision, and IMO typically not a good idea

3. Why would it take a month in Java to do what takes a few days in Go

4. If it made this one task faster, the burden it will put on the team in the future can be bad in the long run

Perhaps the team would benefit a move to Go (I doubt that), but it should be something that is planned. Otherwise, they'll have "that" one thing that is written in a language that no one on the team really knows.

Well you don't have enough context to say it was the right call.

> 1. Why did OP do this without talking through it first

I was tasked to prototype / MVP / "tracer dart" and prove that it was feasible. As proven, it took 2 days in Go. If it was done with Unix commands, the pieces can be jumbled together in a day. The point was having a self-contained "documentation via code" example of the exact business logic in such a program. The same can be achieved with a shell scripting language, but it wouldn't have been as readable. Go is about readibility, which is exactly the reason why it was invented Google, because Google prioritizes readibility. Java is readable if you know what idioms and style it's in, but it's also verbose, which is distracting. One, communicating with the source and sink. Two, get an initial picture of nuances in the Protobufs and data format. It happens to be that the Go prototype was 85-90% close to a final solution. In Java, after being able to actually bundle and consume the libraries had undocumented idiosyncrasies. Java is more powerful and thus more flexible, so a Hello World solution could might be in the wrong direction. You have options, no pun intended, on how you handle async.

> 2. Introducing a new language to a team is not some small decision, and IMO typically not a good idea

There was already half a dozen programming languages on the team's codebase, include a Go server which we inherited. So in effect, we should know Go anyways. As much as Google is Java shop, engineers are polyglot and not hired for a single language, in theory.

> 3. Why would it take a month in Java to do what takes a few days in Go

The language itself. Async code is verbose. Opinionated debates over variables should use the keyword final. Debating whether to use inheritance, delegation, function, or whatever composition / code-reuse pattern. It's been empirically shown Java programs are more verbose than other languages, both in tokens and in LoC. Complexity and entropy doesn't scale linearly, either. This is reflected in both client code and library code, which in the case of Google for many libraries is stale and misleading. One such library is authentication. For Java, Google has multiple competing libraries, or you can carve authentication features out of another feature library, but that is wrapped around and pegged to an older version. Something like JavaScript, there is 3 public sets of documentation on OAuth2 in JavaScript, and like 2.5 clients. With Go, there is a single canonical version, and so just figuring out what library you should use is a fraction of the troubles.

Then there is the ecosystem as a whole. You have options for logging library, and getting Gradle and the building system to pull in the dependencies, especially when you are on internal networks, is one thing. Aligning the Gradle build to be consistent with idiosyncrasies of the team's existing codebase is another. You can do inheritance with Gradle, and that's what was involved to be "consistent", because copy-and-pasting code is a no go.

> 4. If it made this one task faster, the burden it will put on the team in the future can be bad in the long run

That's a strawcut. What you are referring to is taking shortcuts, choosing a suboptimal solution because it saved time. Go was purpose built for middleware and microservices. It was the tool for the job, independent of how long it took to build the MVP. Beyond that, tess code is always better. If there was less code needed to build it, there is less code to maintain.

Google cares about code readability. This is exactly why Go was invented. Go is built readable language. Readability is what engenders low maintenance cost burden.

> Perhaps the team would benefit a move to Go (I doubt that)

No, it was not about a wholesale migration to Go. It was about using the right tool for the job, in one specific microservice, instead of having the Java and turning everything into a nail. Imagine if a company was a PHP shop and said everything had to be written in PHP. Frontends, backends, MapReduce jobs. This is the whole point about federating to microservices instead of monoliths. Or JavaScript, JavaScript everything. Hey, that's not bad, Coinbase was built solely on JavaScript. The argument might make sense if this was an esoteric language or a Lisp, but this is Go, which is, in theory, an official programming language at Google.

You do seem to be making assumptions and having expectations on how the team and how Google should operate. Regarding Java, I don't find the claims that Java isn't as good as Go compelling. For you, sure, but to make general claims is silly. There are many successful companies and productive developers using Java.

There are probably companies that are very productive in how you would want to pick and choose languages based on the problem. IMO, the language choice is not all that important, though I do think PHP, JavaScript, and similarly poorly designed languages are probably a hinderance (but again there are many successful companies using these like you said, so I think that's convincing that the language doesn't really matter all that much).

It could say - Google is bad in that and that BUT it has Go. Or it could say - Google designed Go and is interested in its adoption BUT its own managers don't think that Google developers want to learn Go.

But instead it says that Google documentation "does not teach you how to fish" and "you're not sure how to proceed" and at the same time Go somehow gets away with it - "At least with the Go libraries it's feasible to read the entire source code and flesh out things on the edge of documentation".

It's implied. In fact, Go is an "officially" supported language, meaning there is a dedicated team to maintain tooling around the Go ecosystem, sweep for security issues, keep "runtimes" (in this case the compiler and binaries) up to date.

> But instead it says that Google documentation "does not teach you how to fish" and "you're not sure how to proceed" and at the same time Go somehow gets away with it - "At least with the Go libraries it's feasible to read the entire source code and flesh out things on the edge of documentation".

If documentation is going to be equally bad either ways ( that's something I've resigned with), then all else being equal the library implementation which is easier to read would be preferred.

That said, Go being idiomatic also means generated documentation is more standardized. Java has JavaDoc, but that's not enforced or culturally as consistent as Go.

Since you’ve worked at both, do you have an opinion on why protocol buffers aren’t more widely adopted than json?

Google's a great if you want a high standard of living and being pampered. Not the highest pay, but it's more relaxed.

Also if you have a PhD. Google could be a research playground for you.

Everyone at Google is or appears nice. I had a slightly mean team lead at Google once, but he's been always my favorite. Highly technical, no BS, little patience when I wasn't hyper focused. One of my coworkers at Amazon weren't nice, and just confronted me with feedback that I should show up exactly at 9A.M. I appreciate having honest and direct feedback like this, and this is where I grew the most. I don't think I ever received negative feedback at Google, even though I probably should have. Some people prefer environments where everyone is perfectly nice and happy all the time. I think I would like Google more if we didn't sugar-coat things. That would prune products and people who are deadweight, even if that possibly means me. I respect the Finance industry to the degree that they do not mask their profit motive.

> It also sounds like your manager had something to do with it.

Of course. People leave managers, not companies. That said, the managers are part of a system. I did shop around for other teams before I left, but they were all boilerplate CRUD work. CRUD work's also fine, but the value of these projects to users was not clear to me.

> Perhaps it was a lack of promotion?

I'd say that is a symptom, not the cause. It's about being appreciated and having your work understood.

> do you have an opinion on why protocol buffers aren’t more widely adopted than json?

I think some people dwell on the performance difference. I think adoption boils down to ergonomics, ease of use, and tooling. Within Google, there has been significant investment in internal tools/libraries around Protobuf especially Java. For something like Protobuf, it's not broken, why fix it? People at Google are familiar with Protobuf. The outside world is familiar with JSON. When I was at Google, I launched a gRPC/Protobuf API but our clients had significant hardship onboarding. I think this is within the theme of externalized Google tech being inferior to the internal version solely from the aspect of ease-of-use/documentation.

Until TypeScript came around, I think an argument can be made against JSON as lacking type safety. I used TypeScript when it was still in Beta and felt Google was reluctant to this. It doesn't help that TypeScript was pioneered by MicroSoft. To be fair, at the time people didn't trust Microsoft. I mean, people were trusting Chrome more than IE for good reason. Once people actually give TypeScript, I think it's a no brainer

I work for Elastic for the last 6y or so and I feel I’ve been lucky to have managers who cared (for customers, also for the team), provided actionable feedback, and put me in projects that lined up with my strengths and interests. I feel a lot of that is encouraged by the company culture, but esp two individuals I have in mind—I think they’d behave like that in any other company (or burn out quickly).

Would you mind sharing if this was SV or some other region? Do you know if this would a “general” culture for Google/AWS, or limited to certain teams or offices?

While there isn't a way to report problems, or get help with problems, and problems aren't tracked or measured, every problem is a singular example that can be hand-waved away with an "it's just that particular user being dumb".

Refusing to support customers is a choice Google has made in order to be able to ignore problems the engineers won't (or can't) solve.

If you don't mind sharing, what is the bug?

-

My comment originally read as follows, 2 people downvoted it.

>I work at Google and recently tried to file a bug about the calculator embedded in search. It was dastardly difficult to find how to file the ticket. It took me maybe an hour. A better system for filing tickets internally and for filing and triaging tickets from external users would be a tremendous asset for Google.

I didn't work for Google directly but I did work via another company (Tech Mahindra) so I am saying this as somewhat of an outsider compared with you.

You mention a bug about the calculator embedded in search: could you give me the details, and I can try to get it solved via my Google contacts.

For context, in my personal experience as a user and engineer, the Google embedded calculator is the best product among all of Google's many offerings and works flawlessly for all inputs. I find it breathtaking. For example, here is how many feet times pounds you can turn 3000 Calories into:

https://ibb.co/qJ0Qz0L

it worked on my first attempt. What does this mean? Well here's a foot-pound: https://ibb.co/N3WCxYV

If you weigh 180 pounds you're not climbing Mt. Everest twice (29,032′) without burning 3000 Calories. (Even at 100% efficiency).

Try getting a result like that from any other calculator (though Wolfram Alpha gets close).

What's the bug you tried to report? (What did you enter, what is the correct output and why is it correct, and what is the returned output and why is it incorrect?)

I've never seen it make a mistake so far, and I use it heavily for all sorts of things. (Sometimes I force Google to show me the calculator by typing = at the end of my Google query.) Since the product works so well for me personally, I'd love to understand what problem you have with it.

I wonder how many times in the past has it given you the wrong answer without you noticing?

As the other person replied, it is labelled precisely.

The problem is not that they don't have a tool; they could easily build one almost overnight. They have a glut of very competent technical labor, lots of capital, infrastructure up the ass.

They don't care.

The tech people are convinced they're geniuses who build stuff that never breaks.

The business people think they've figured out every problem a user could have and are satisfied that the documentation and snippets of help text are sufficient.

The accountants say "it would cost us more to create such a system and staff it than we would lose in business from not addressing it."

IME that feedback is generally taken seriously.

I imagine Google would getting 10,000s bugs per day if it was too easy.

But then, I am an engineer, not some marketing drone...

Loads of duplication will also follow etc. Sounds like you need entire teams to figure out what the real bugs are at that point and maintain the bug list? Though I can't think of a workflow from the top of my head.

Google with it's "Let's never maintain our products, let the bitrot make them gradually worse and eventually EOL them" approach seems to prefer to avoid that kind of cost.

I used to be a Google fanboy in the early 2000s. Maybe it's coming with age, but these days I prefer boring tech that works well as compared than half-baked moonshots, and Google may have burned me once too many. Other software megacorps (and even some NGOs) do this better than the big G.

Xoogler here - actually we used to say "if you are not buying advertising from us, Google can't help you at all".

And just recently I am great example of that. I used to have a Gsuite account at $6/per month for 3 years, then decided to give up on it b/c I wasn't using it. But unfortunately the domain expired before I could properly disconnect it and cancel my account. You can probably already imagine at this point what kind of hell I went thru with "google help". Ultimately I had someone from India called me 3 times to explain - the questionnaire they sent me has to be answer in specific format: each question has to have one paragraph space, then tab (9), then my answer. I kid you not! I spent 3 weeks, been transferred over email ticket about 10 times and every time they told me the same thing. Even if I did exactly how they want it - I guess email was automatically eating up the tabulate key and replacing it with spaces. Eventually a buddy of mine who still works there (different dept) told me customer support forwards your email to some account that parses message automatically, and they cannot even change one single letter in your message. Even when explaining them on the phone that I am following up with their stupid protocol of one new line, then tab, then my answer, then next line must be second question, their program must be messing it up.

Eventually I gave up on their customer support. It took me/them six months of chargeback disputes for $6 each month until my account must have popped out on someones screen and Google employee gave me 3.5 seconds of their time to click "close this account".

This wasn't the first problem we'd had either.

There was absolutely no one to call, no one to even alert to warn other customers, the status pages were all green.

Instead of bothering with Google, I just opened an account on AWS and migrated whole stack to AWS in ~ 3 hours, pointed DNS at the new load balancers and we never went back and continued doing business without issue for as long as I can remember.

AWS seems to also have support packages: https://aws.amazon.com/premiumsupport/plans/, and their response times are also not supposed to be instant.

Amazon gives great support at an affordable price.

Because email addresses are practically a requirement to function in society, I think they should be a public service. Everyone should have the right to get an email address controlled by a public service institution which guarantees you that you can move between service providers as you please. There could even be a standardized protocol that service providers could use to easily update DNS entries when the user requests a move, assuming that you can identify yourself via some other means.

So I bought my own domain and have spent the last year slowly migrating everything over. I'm still only ~30% of the way there. My whole life was centered around that Gmail address, and I could have lost it in an instant for any and no reason at all. It's horrifying, and happens to perhaps thousands of people every day. As we continue to SaaSify everything this problem is going to come to the fore sooner rather than later. Our entire lives live in the cloud now and it can be deleted without cause or notice.

At the very least I would like to see governments issue people a free state email address which can be hosted anywhere. Email is now a necessity.

In some countries it has already been for a long time, for example Estonia gives everyone by default an email address that is tied to their national ID and you can forward mail from that address to any provider you want.

Edit: Anybody barely uses it though because usually there is no need. But it's there in case you want to use it.

Even if google had customer support agents, what do you want them to do in cases like this? They can't actually validate anyone as the owner of an account, they'd simply be the targets of people begging to access accounts.

Edit: the implication being, we probably simply need most people to just not depend on email for anything important. Unless you can maintain multiple 2FA methods, your email account isn't reliable enough to be trusted with important things.

It’s why Microsoft has done so well for itself in this area over the decades. Sure Office helps, but the fact that your operations guys can be on the phone with their Seattle based offices, and get hourly updates where Microsoft calls you, when something big goes wrong is pure gold to any IT manager in any enterprise. Not only because it lets you solve issues faster, but also because you can tell the organisation that IT is on the phone with Microsoft’s head offices and you are working on a solution with them.

>I'd frequently tell my co-workers, "If you're not paying for it, you're the product."

it seems even if he did pay he was the product, which frankly jibes with my experience of paying for things at Google.

The only exception of course is most but not all FOSS.

I’ve been involved with many software companies that gather various metrics (analytics, crash logs, user info, etc.) but do not sell that data to anyone. As such, the user is not “the product” but the customer. I think there’s a meaningful difference here.

With Apple there is no subtlety because you just can't have what they don't want you to. Apple wants to have a deal with Hollywood so no iOS BitTorrent clients for you. You don't even know that the things you're being deprived of would have been available -- it's the same problem. It's worse. At least with Google if you notice they're removing things you want to see from search results you can switch to another search engine and still use Android. If you want video game ROMs on your iOS device you have to throw it away and buy something else.

And the privacy thing feels like a Trojan horse when they still have all your data on iCloud and have root on your device. Supposedly they don't do anything with it now (except allow iCloud to be subpoenaed by law enforcement without a warrant), and I tend to believe them.

Now suppose we finally get a free hardware phone that isn't a dog. It runs an Android fork with all the privacy invasive stuff stripped out but can still run Android apps and gets OS updates for 10+ years (i.e. indefinitely) because the drivers are in the kernel tree. That would eat a big chunk of Apple's market -- the people who don't want the central control but do want the privacy are going over there. Or just pick whatever scenario you like where Apple's business starts shrinking rather than growing. Nothing lasts forever.

Their executives are under pressure to keep profits up and they have an enormous trove of everyone's data they weren't previously monetizing. Desperate companies do desperate things. Or get acquired by Oracle or AT&T or Huawei.

Since that can happen with non-trivial probability at some future date, you can't put anything on your iPhone you're not willing to have that happen to. And then how is that any better than the alternative? It's even worse if you don't expect it to happen and then it does.

0: https://support.google.com/googleone/contact/googleone_c2c?h...

But it sounds like this "extremely irate user" was paying for it.

Regardless I agree with other comments to the effect that even if you are paying, you are often still the product!

The anaylsis needs to go further than whether one is paying or not. IMHO.

It is not rare to see HN commenters who appear to believe that the act of paying some "user fee" to a "tech" company that willfully caters to advertising, devotes almost all of its resources toward catering to advertisers, and derives almost all its revenue from advertising services, is somehow meaningful.

> he paid Google something for some service and was entitled to phone support and he demanded someone help him

This does not support the conclusion about free users being the product, since the customer was paying based on the statement above.

The one thing I've never understood about google. Some sort of law for a trillion dollar company to have customer service or something.

Google should be employing 10's of thousands of customer service employees to take calls to troubleshoot their customers issues.

On a side note.

Here is my.... the simplest website you have seen since 1989.

https://simplegametime.com

I'm not running a user data farm. I just want to make stupid games, like...

P.S. Zero advertising for anything including my game. Just a 7 line privacy policy. Don't need much more.

At any point. You're done.

Hence the nothing clause.

I'm sure any game I submit to the play will be wrapped in googs analytics.

No matter what my privacy police says.

I agree more laws aren't always the answer but I really do think that companies should take some responsibility as far as customers' data and property is concerned. If I take my car to be serviced, they can't just tow it to a junkyard and tell me to fuck off. Even if they advertised free service. If you can't provide a free service and take responsibility for it, then don't.

IMO, if the service includes "borrowing" property (rent, email server), then they can't just cut the customer off without giving them time and the means to move off. (It would be illegal here for my landlord to step in and lock me out tomorrow)

But that doesn't mean they aren't issues.

The sheer scale of not giving a crap is what is truly impressive. Alphabet has built a monster system meant solely to not have a phone number. That's a scary innovation.

But this isn't true for all of us, google provides support through paid programs and sells services to other businesses. This is more of google specific problem.

Seriously? You stated that you left the cult.