"Why are there 4 unique keys on this table named masterkey, masterkey2, mk1, mk4?"
Principle Engineer. "Well, the masterkey indicates which key this was mastered on, if you check the masterkey db, which is just "id, timestamp, masterid", this is required to comprehensively log the creation date of the row to maintain the db's audibility in case of SOC audit.
masterkey2, refers to the masterkey2 db, which contains "id, timestamp". Any change to the row requires an update to masterkey2, again for auditbility for last modification reason.
mk1, contains "id, userid". Which is the user that created the row.
Finally, mk4 refers to the new mk4link table, which is a LinkTable that links the main table to the mk4update table. mk4update is 'mk4id, username, timestamp, creator' and contains a list of any changes to the table and a flag indicating this is the creation date. Have you done a SOC compliance report before? No? Well, all of this is mandated by the SOC compliance, its kind of ugly, but it works and is absolutely required."
These kinds of initiatives happen all the time in every company, including Google. A team lead generally would quash this in the interest of reliability/safety/etc, I think.
Bigger companies IME, tend to be the ones that can afford to reinvent the wheel, and also tend to have the ~~arrogance~~ size to feel that they are a special enough snowflake to eschew something off the shelf and build something custom tailored exactly to their needs. They also have big enough budgets to be able to spare the manpower on it.
My experience has been largely in the financial space, maybe that is the key difference.
I've worked at _very_ large multi-nationals where, in my anecdata, I've seen such hand-tuned monstrosities deployed.
At a startup, a flawed but functional deployment today is better than a perfect deployment tomorrow. I've never heard of a startup that was successful because it got software right in it's early stages.
I've seen people do things like this more than once, even talented people. They some how get an idea in their head and go way down a rabbit hole without stepping back and realizing it's the wrong design. I think that pattern is more possible in small companies because they are less likely to have their work reviewed often, do formal design sessions, or be pairing with another experienced engineer. I don't buy that things like this don't happen at FAANGs because they are just oh-so-much-better, I would guess it's mostly because they have more mature practices.
> people work on entirely useless products that get canceled a year later.
You just described 99% of startups :-)
First of all, selfishly I am learning like crazy. I am able to work on the world's most advanced software defined networking implementation in Google Cloud, and it's just amazing and mind boggling.
Second, I create real value for a lot of people: the reliability I help improve has a direct effect on the happiness of the Google Cloud customers that run on our platform.
Third, even outside my Cloud business unit, while no company is perfect and there are clearly issues around data usage and centralization, I still think Google's effect on society is wildly and massively positive, it improves all our lives like not many other companies have ever done, so I have no problem at all working here.
But that's just me, I have no problem in accepting that your opinion might be different and you would never work there for ethical reasons, your (my?) loss :-)
You are correct that no company is perfect, but some are less perfect than others. It seems many people like just shrug their shoulders and move on pursing the fun projects they are well-paid to work on. Such is the human condition.
In my case a lot of it comes down to me, as an insider, knowing that you're wrong. "Monetizing people" is sort of meaningless. That's an objection to capitalism, if anything, not Google. Google no more monetizes people than a bank, or a rideshare company or even a university. Short of maybe fundamental research, you're not going to find a job that doesn't monetize people under some interpretation.
As for a "surveillance society", I don't really think that's true. The care my coworkers take with user data is, in a word, significant.
There are certainly things that Google has done that I think aren't ethical, but I'm much better positioned to be aware of and change those things as an insider than an outsider.
And then of course there's the multitude of selfish reasons: compensation, interesting technical work, intelligent coworkers, etc.
Typical thing, that really happened: a coworker at a startup ("senior engineer") had to do some calls to a very simple HTTP API from an embedded C++ component. She proceeded to hand craft her own HTTP requests and manually dispatch them to a manually instantiated connection using sockets, and then manually parsing HTTP responses (!!). I suggested to not spend time on such irrelevant code, I was ignored. Management didn't chime in.
She kept having problems and problems once that 100s-lines long thing hit production, as you can imagine (every software engineer should know that writing a network client from scratch is not easy!): finally I broke down, linked libcurl in the application, and in 2 hours and 30 lines of code I had the whole thing solidly working. And that's how I afforded working 40 hours a week instead of 60.
At Google, this would never happen.