Nah, you had to use all 3. It was 3 connectors for different things.
Our codebase is a mess and I suggested putting “we are not stupid, we just work with Google” into our job ads looking for data engineers proficient with C and JRuby.
Sometimes Google seems so obsessed with open standards that they not only don’t favor their other projects, their projects often simply won’t support each other.
I blame the many Google buzz plus chat clients. Google also suffers from a lot of success, they can be complacent about things other companies obsess about.
My guess is that the Google org culture breeds people who don’t care about the users of their tech one bit.
Make something that’s fun and interesting for the person making it, release, get promoted, abandon.
It’s the kind of people I tend to avoid hiring, and for a good reason. Google makes pretty much all its money from search ads, and hasn’t innovated on that in decades.
That they don’t care wouldn’t be my take, but it may be true for some.
It is true it is hard to get the incentives right, especially if your goal is to make things that don’t get abandoned.
They do a lot of experimentation though, trying to see what works.
I think “what works” and “what users want” are two similar, intersecting but not at all identical sets. Some users like new and broken, others want things that will never work.
I am curious what kind of people do you try to hire, and what do you screen for? I mainly just try to gauge someone’s experience in the field, and ability to to fit a specific role. (I have mostly been involved in Android app dev or related interviews).
I ask things like “how do you solve this common problem”. A goal for me is to try to give basically the same interview over and over again, to make it easier to compare candidates. But over the years it changes of course.
The JPEG XL team at Google Research and the Chrome team seem to have different opinions on the format
I just had someone on my team work with 3 closely related Google data libraries, basically 3 connectors for the same data churning thingy.
One was only compatible with Python, the second was only workable in C, and the third was in fucking JRuby.
Options!
Nah, you had to use all 3. It was 3 connectors for different things.
Our codebase is a mess and I suggested putting “we are not stupid, we just work with Google” into our job ads looking for data engineers proficient with C and JRuby.
Sometimes Google seems so obsessed with open standards that they not only don’t favor their other projects, their projects often simply won’t support each other.
I blame the many Google buzz plus chat clients. Google also suffers from a lot of success, they can be complacent about things other companies obsess about.
My guess is that the Google org culture breeds people who don’t care about the users of their tech one bit.
Make something that’s fun and interesting for the person making it, release, get promoted, abandon.
It’s the kind of people I tend to avoid hiring, and for a good reason. Google makes pretty much all its money from search ads, and hasn’t innovated on that in decades.
That they don’t care wouldn’t be my take, but it may be true for some.
It is true it is hard to get the incentives right, especially if your goal is to make things that don’t get abandoned.
They do a lot of experimentation though, trying to see what works.
I think “what works” and “what users want” are two similar, intersecting but not at all identical sets. Some users like new and broken, others want things that will never work.
I am curious what kind of people do you try to hire, and what do you screen for? I mainly just try to gauge someone’s experience in the field, and ability to to fit a specific role. (I have mostly been involved in Android app dev or related interviews).
I ask things like “how do you solve this common problem”. A goal for me is to try to give basically the same interview over and over again, to make it easier to compare candidates. But over the years it changes of course.
Another words the left hand doesn’t work with the right hand