alephnan · 4 years ago
I worked at both Amazon and Google. It was only at Amazon where I was exposed to the Craft of software development. Personally, I feel there is a nuanced difference to the role at Amazon being SDE ( Software Development Engineer ) whereas Google is SWE ( Software Engineer ). It's almost like Google thinks Software Developers are lower tier than Software Engineers, but I'd like to think of myself as doing more than just engineering and tweaking things which already exist.
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.
