281–290 of 520 posts
Earlier quoted context omitted.
The only people experiencing offense here seem to be the ones who don't like the term child raiser for some reason.
I don't have a dog in this fight, but if there's a pushback on a change, that's defense, not offence.
Is this a terrible dad joke?
Earlier quoted context omitted.
Because not everyone who raises a child is their actual parent. See also the need for terms like “caretaker”, and “legal guardian”.
Why do we have to change our language (and behaviour) for the edge cases? Is a grandparent who raises their grandchildren offended by the word parent? I doubt it. What’s the point?
When that's the topic at hand we should keep those distinctions in mind.
> Early employees would often encourage each other to "fail fast" as a means to innovation, but that's no longer easy in an environment where failure implies a layoff. Big tech is in a really tough spot when it comes to innovation. Google has developed a reputation for killing off products too easily. Many have commented here and elsewhere that you can’t trust them to invest in using their new products because they m…
FWIW, the only person I've ever actually met with a 20% project was working on quantum
Earlier quoted context omitted.
IMO I felt that battle was lost couple of years back when my wife was pregnant with our youngest. We were looking for CDC guidelines on covid booster for expectant mothers. The website mentions "pregnant people". That's when I felt discourse is evolving to cater to the edge cases. https://www.cdc.gov/coronavirus/2019-ncov/vaccines/recommend...
[flagged]
Earlier quoted context omitted.
So, Google’s choice of architecture prevents them from open-sourcing or maintaining projects a tad longer than absolute necessary. I’d say they dug their own grave, if it has such a large impact on the trust of customers. Maybe Google3’s architecture was excellent for worldwide scalability and costs, but let’s see which one matters in the long term.
Google and their codebase architecture have been around for a while now in the scale of software lifecycle. How far out do we need to wait before its "long term", and how will we know if failure was from decades of business decisions vs repo architecture?
There was a time when Google was also Guava and a myriad of Java libraries helping the rest of the world. It’s a design choice, they chose to stop helping, because of their repo. Perhaps it also helped avoid leaks, since copied code can’t be used outside of Google.
Earlier quoted context omitted.
Language should be adequate to the context of a conversation. If you were writing a legal document, or some policy for a kindergarten it might make sense to make that distinction, but this is a public forum with many non-native speakers. Parents is a concept pretty much all of us are familiar with and if you say parents we'll understand you mean people using the service because they care for young kids.
Language should be adequate to the context of a conversation. If you were writing a legal document, or some policy for a kindergarten it might make sense to make that distinction, but this is a public forum with many non-native speakers. Child-raiser is a concept pretty much all of us are familiar with and if you say child-raisers we'll understand you mean people using the service because they care for young kids.
and to clarify: I chuckled with sympathy reading your response :-)
Earlier quoted context omitted.
Open source is very hard for a bunch of reasons: * Code at Google3 is one giant monolith that has dependencies on things that aren’t open sourced. Even if they could be, they don’t make sense outside of Google * most services internally run on internal services like Borg and GFS rather than GCP for historical reasons. That maybe has changed now but I suspect a lot of stuff depends on internal infra not available on G…
So, Google’s choice of architecture prevents them from open-sourcing or maintaining projects a tad longer than absolute necessary. I’d say they dug their own grave, if it has such a large impact on the trust of customers. Maybe Google3’s architecture was excellent for worldwide scalability and costs, but let’s see which one matters in the long term.
Yes - Google chose a monorepo because of the engineering and business advantages it gave them. For example, all binaries had a common dependency that implemented all sorts of common functionality they found binaries on their servers needed out of the box - that’s why a simple c++ hello world on Google3 results in a many many mib binary that includes an http server for performance monitoring. It’s an opinionated codebase but the opinions are largely documented and explained and aren’t crazy (just because you may make other decisions or prioritize things differently doesn’t mean Google’s choice are wrong). And again, please don’t hyper focus on what I wrote as “oh it only has this one advantage”. There’s lots of advantages and I’m just giving very basic examples. It’s been a fairly long time since I worked at Google and someone who works there is going to have a more authoritative explanation of how things work now as things will inevitably changed some.
You may say they dug their own grave while the internal teams find it helps them run services and maintain things because there’s 1 way of interacting with the artifacts of lots of different teams. And they weren’t going to open source EOL projects anyway and maintenance decisions have nothing to do with google3 and are product and engineering led decisions.
Also, they have a bunch of tooling to manage open source projects that mirror google3 projects. It’s doable for projects that care / who it’s important to but it is also a lot of work (eg can write rules that bidirectionally rename files, functions, c++ namespaces, comments that can strip out code before outgoing synchronization, etc etc). if I recall correctly the tool itself was open sourced too.
As for customer trust, again I point out that not only is the Google3 aspect a minor detail, open sourcing wouldn’t even impact customer trust in a large way. It might with a certain segment of the technical population, but that’s not the people Google cares about in terms of public trust. And any open sourcing also has to find motivated maintainers who are not going to be motivated by 0 pay and a huge amount of bug reports and feature requests from users who started with maintenance support of paid engineers and focused product vision. Make sure not to extrapolate your own predilections as a tech engineer onto the general population.
Earlier quoted context omitted.
Open source is very hard for a bunch of reasons: * Code at Google3 is one giant monolith that has dependencies on things that aren’t open sourced. Even if they could be, they don’t make sense outside of Google * most services internally run on internal services like Borg and GFS rather than GCP for historical reasons. That maybe has changed now but I suspect a lot of stuff depends on internal infra not available on G…
Google Wave was my fave sunsetted project or Google graveyard project. First time I used it I could really see the potential. But as you pointed out, it's often not that simple.
Earlier quoted context omitted.
is it available to all employees and do they all get on a single waitlist or do executives get a preference.
It was certainly executive-level pricing :) To answer your question, I don't know. The wait list was well over a year, and it was many many times more expensive than other childcare options in the Mountain View area, and utterly unaffordable for me on a senior SRE salary.
oh got it. Top comment made it sound like it was cheap/free of cost