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
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.
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?
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.
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.
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:
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.