What I Hated about working at Google

#neetcode #leetcode #python

[cw]

As a former Amazon engineer, I empathize with you. Another annoying thing about using these internal tools is that the skills you gain are largely non-transferable; you are only able to apply the knowledge of using that tool to one company.

[kevinstefanov]

i work at IBM as a developer of operating systems and its exactly the same here, we literally use our own inhouse programming languages for development, scripting and testing and if we do use a well known public programming language, we actually have our own implementation of it and its compiler. We dont use Oracles java and jvm, we have our own implementation of java and jvm :) we have our own implementation of C as well. The hardware is our own, the operating system is our own, the languages we write it in are our own, known languages implementations are our own, EVERYTHING, literally the only thing that we haven't implemented ourselves internally at IBM is stuff like git and Jira, lmao.

[cornellouis]

This is exactly true (at other companies also). Promotion = make something new - not "save other people time in the long run." Incentive problem.

[rockyscarlet]

No documentation? 😂

Funny this big ass company has the same problem as a small one.

[dhillaz]

Hot take: A tool isn't complete unless its documentation is complete.

The developer shouldn't have been promoted until their tool was completed. And at the very least the tool shouldn't have been implemented as a standard until it was documented.

[TechnicallyTrent]

I worked at a FAANG and can relate. It is of course part of the job, but at a certain point it becomes completely unsustainable and you burn out. The entropy just increases non-stop. The biggest nightmare is when you need to CHANGE those external tools and there is no test suite.

That's why it is so refreshing to work on personal projects.

[darrennew]

As an Xoogler, I 100% agree with this. My first job was figuring out how to purge the old records in some program's database, and there was like three layers of abstraction between having the data in a protobuf and stuffing that protobuf into the database. I kept thinking "Is everything here really that complex?"

It takes about a week to figure out how to compile and run your program, a couple weeks to figure out how to deploy it, and a couple months to learn all the bits you need to (say) write a Hello World program from scratch that can be accessed from the internet.

And yeah, every library was google-specific. You didn't use the file system, you didn't use memory allocation, you didn't use the debugger, the compiler, etc etc etc.

[WillDelish]

We have this same issue at Amazon. Documentation sucks. I try very hard to avoid as much internal tooling in my design. Its very hard though, cause folks are so brainwashed with these tools / traditions, they can’t think outside them.

[robchr]

Having worked in small companies and startups and switching to a big tech company, saw a similar issue. Much of the time the big tech company wants "control" over a solution instead of using first party and community open source tools for a given problem. I was much more productive working in small companies and startups that let me choose the best tool for the job instead of relying on internal tools.

[Beaste]

I doubt there is a place without abstractions, the only difference being whether they are known third party tools or something internal, developed due to lack of alternatives in the industry.

[flexdash]

I worked for a small startup that had an abstration hell. Its not really a big company problem, this is just human nature. We want to see patterns in everything and we create abstractions for that reason. I truly believe this has to do with how our brain works.

[emilemil]

I experience this too. We have a library of generic frontend components that was developed by a team over several years. Now that team has scaled down significantly as no additional components are being made.

My team discovered that none of the components supported right-to-left languages which we required, and adding the support was deemed too big of a task for the small maintenance team.

So now we have to manually hack rtl support into all of the components we use, which has a high chance of breaking if we update the version of those components. It sucks.

[giuliopimenoff]

google docs for their apis really suck, can't imagine internal ones

[Evilanious]

I like the distinction between good abstraction and bad abstraction. If I wished I could just do it the way I wanted to rather than the way the abstraction enforces, the abstraction might be counterproductive.

[JobinJacobKavalam]

I am one of those internal tool makers. Not to forget the love that users give is also a big contributing factor to the health of these projects. There is nothing like seeing one of your users champion your tool, not because they have to, but because they choose to. I am eternally grateful to such people. That, my friends, is what it means to be charitable in programming.

[Cyrus_II]

I liked the point that you seemed to make about abstraction, that abstraction is only good if you (almost) never have to worry about the level underneath it. If you constantly have to peek underneath to solve problems or do things that the abstraction isn't good at then you either have a horrible abstraction or maybe the abstraction isn't made for what you're trying to do.

[andersjohnson]

IMO, one of the main reasons that Google is struggling in the cloud market is that they have (or had?) a framework (its name begins with an H) that would have been instrumental for testing their cloud offerings, but they allowed it to fall out of maintenance in much the same way as you're describing. This is what happens when you have a "no promotion for maintenance" policy.

[k_gold]

Idk about the abstraction problem, but one thing these tools probably solve is inconsistency. Like you said, if everyone is forced to use the same tool, either the entire codebase breaks or nothing does. And that's what we want, deterministic behavior

[eclipse]

The CEO and CTO of the startup I worked for came from AMD.
He was obsessed with in-house engine, in-house source (even if it was just renamed from open source) and complete control, even though there was better open source available. Instead of focusing on our own technology, which wasn't open source.
He wanted to do everything in-house, even invent the wheel.
I thought it was just him, but from the comments here it seems to be a systemic problem in a large organisation, not just a few individuals.

[Kanal]

I work as COBOL application programmer. Reading source code to understand how programs work is my daily routine (obsolete or no documentation). Static and dynamic analysis of assembly code is also something that happens from time to time. I'm not mad about this though, because I know it's something that makes my job secure. There are not many people that are capable of solving such problems. Imagine being that one guy responsible for one of internal Google tools. You are not likely to get fired.