3 ms·

If I may ask you, because that's something I've wondered many times with Google: why are the docs and self-help support option so basic on most of these things?

If I may ask you, because that's something I've wondered many times with Google: why are the docs and self-help support option so basic on most of these things? I understand the idea of "automate it, it must scale", but especially then I'd expect the systems to add/correct/delete info to be super streamlined, the documentation to be very thorough and covering all business cases etc. Yet it feels like the opposite is true: the GUIs are generally sub-par and feel like "okay, we have a great API. Can you throw some GUI on it?", the documentation is short and often either outdated or did not cover certain cases in the first place, and "what to do if this doesn't solve your problem" is rare. Is that "we want to be a platform, not a service provider" and meant to discourage end-users from using the system directly and pay a professional agency instead that handles the support issues? Because that's really the only explanation I've heard so far that makes some sense. It feels like Google is putting more manpower in developer relations than in customer relations and I've never understood why.

mjw1007 6y ago
On documentation: I've seen dozens of articles on this site about hiring practices from large technical companies, and Google in particular. I don't remember seeing anything suggesting they even verify that the people they're hiring are capable of writing basic documentation, let alone that they appreciate the importance of it being complete, correct, and up to date. Every indication is that Google vastly undervalues documentation, both for internal and external purposes.
- MattGaiser 6y ago
  > Every indication is that Google vastly undervalues documentation, both for internal and external purposes. This just seems to be companies as a whole. Documentation is a low-status activity (no promotions or raises available for doing it) that still requires decent cognitive function, so it is not something you want to do when you are energized and ready to go nor something you can do when tired and not in the mood to work. There are no automated tests to tell you that the documentation no longer works, so the engineers would need to periodically check. We have automated tests in code because engineers won't comprehensively check everything. In my org we frantically document when an engineer gives notice. Otherwise, we can't even keep the URLs updated or maintain a running list of configuration variables.
  - mjw1007 6y ago
    There's a virtuous circle with documentation: if you start with something that's complete and correct, then when you make a change which is visible to the code's clients you can go and change the documentation in the same patch series, and check that this happens as part of the main code review. Digging yourself out of the hole where your documentation is already wrong or incomplete is much harder: when you go to describe a change you might find that the thing you're changing isn't mentioned, or is described wrongly, or there is no terminology for the thing you need to talk about. So you need everyone to take care that standards don't slip, which is why it's important to make the importance of documentation part of the company culture, and make sure every programmer is capable of doing their bit.
  - gfxgirl 6y ago
    There's a startup idea there. Be the company that makes excellent docs. Get all the other companies to pay your company to make and maintain their docs.
  - coredog64 6y ago
    I don’t know about that. At my last employer we had one guy on DevRel and a big part of his job was making sure we had good documentation. When other teams complained, we first checked to see if the docs were good: If they were, we pointed them to the docs. If the docs were wrong, confusing, out-of-date or missing we’d apologize and fix the docs. He didn’t get a promotion, but he did have a lot of positive visibility. When there was a round of layoffs, other teams lost engineers but we got to keep him.
- ThrowawayR2 6y ago
  > "I don't remember seeing anything suggesting they even verify that the people they're hiring are capable of writing basic documentation" Large companies hire technical writing specialists to do documentation, not software developers.
andybak 6y ago
I wonder how much better Android would be as a platform if Google interviewer for good taste in API design and communication skills rather than whiteboard logic problems and advanced CS skills. Did you think to check whether the new hire who can write a regex parser in his head can also design a library that other people want to use without screaming?
v7p1Qbt1im 6y ago
Endless data analysis probably told them 99.99% of consumers will never need support for any free product. I updated some opening hours and needed to delete a dead link on the search engine. All this stuff is automated and works great. Unfortunately this means there are still something like half a million edge cases that get issues like unwarranted account lockouts.
jdm2212 6y ago
Once you start letting anyone edit, you have to solve a bunch of other problems: various kinds of spam, non-spam low quality edits, deconflicting manual edits with other data sources. The easy/default solution for most things is to have a trustworthy sources only (official website, Google My Business page, etc.) and a decision tree for choosing which one wins. The Maps feature for editing listings was a ton of work spanning a bunch of teams over several months, but that kind of investment is made only after every other option has been exhausted because it's so slow and expensive and scales poorly relative to just ingesting more data and throwing ML at it.
- luckylion 6y ago
  Sure, giving everybody direct editing access isn't a good idea. I'm just surprised that so many somewhat user-interaction features feel sub-standard. The maps or gmail gui are super polished, so obviously there are people who do that kind of thing, but others feel rushed, like they were given to an intern that really wanted to leave for the weekend. E.g. the Knowledge Boxes on SERPs. When I was invited to add/edit to them for a notable client a few months back, it was barely documented, cumbersome, error and response messages were vague and it felt like a proof of concept. I guess I'm just wondering: is that by design, has someone tested that and figured out "if people feel like they're using ebay's dysfunctional interface, they'll spend more money on ads", or is it just that somebody gets a task "hey, add a form to edit that, please" and they're like "well, they didn't ask me to make it pretty and I really need to leave soon"?
  - jdm2212 6y ago
    Oh yeah I'd bet crappy UIs are just laziness/sloppiness/prioritization rather than malice. The glamorous frontend work that gets lots of design attention is the stuff that has billions of users. I saw some A/B testing for ad engagement that drove UI decision making, but it was always short-term and related to search -- like, "we updated the model today, and users click on the ad 1% more often in the treatment group". FWIW I was pretty much at the bottom of the totem pole so if there was some nefarious plot to provide crappy UIs I wouldn't've been in the loop anyway.

mjw1007 6y ago

On documentation: I've seen dozens of articles on this site about hiring practices from large technical companies, and Google in particular. I don't remember seeing anything suggesting they even verify that the people they're hiring are capable of writing basic documentation, let alone that they appreciate the importance of it being complete, correct, and up to date. Every indication is that Google vastly undervalues documentation, both for internal and external purposes.

MattGaiser 6y ago
> Every indication is that Google vastly undervalues documentation, both for internal and external purposes. This just seems to be companies as a whole. Documentation is a low-status activity (no promotions or raises available for doing it) that still requires decent cognitive function, so it is not something you want to do when you are energized and ready to go nor something you can do when tired and not in the mood to work. There are no automated tests to tell you that the documentation no longer works, so the engineers would need to periodically check. We have automated tests in code because engineers won't comprehensively check everything. In my org we frantically document when an engineer gives notice. Otherwise, we can't even keep the URLs updated or maintain a running list of configuration variables.
- mjw1007 6y ago
  There's a virtuous circle with documentation: if you start with something that's complete and correct, then when you make a change which is visible to the code's clients you can go and change the documentation in the same patch series, and check that this happens as part of the main code review. Digging yourself out of the hole where your documentation is already wrong or incomplete is much harder: when you go to describe a change you might find that the thing you're changing isn't mentioned, or is described wrongly, or there is no terminology for the thing you need to talk about. So you need everyone to take care that standards don't slip, which is why it's important to make the importance of documentation part of the company culture, and make sure every programmer is capable of doing their bit.
- gfxgirl 6y ago
  There's a startup idea there. Be the company that makes excellent docs. Get all the other companies to pay your company to make and maintain their docs.
- coredog64 6y ago
  I don’t know about that. At my last employer we had one guy on DevRel and a big part of his job was making sure we had good documentation. When other teams complained, we first checked to see if the docs were good: If they were, we pointed them to the docs. If the docs were wrong, confusing, out-of-date or missing we’d apologize and fix the docs. He didn’t get a promotion, but he did have a lot of positive visibility. When there was a round of layoffs, other teams lost engineers but we got to keep him.
ThrowawayR2 6y ago
> "I don't remember seeing anything suggesting they even verify that the people they're hiring are capable of writing basic documentation" Large companies hire technical writing specialists to do documentation, not software developers.

andybak 6y ago

I wonder how much better Android would be as a platform if Google interviewer for good taste in API design and communication skills rather than whiteboard logic problems and advanced CS skills. Did you think to check whether the new hire who can write a regex parser in his head can also design a library that other people want to use without screaming?

v7p1Qbt1im 6y ago

Endless data analysis probably told them 99.99% of consumers will never need support for any free product. I updated some opening hours and needed to delete a dead link on the search engine. All this stuff is automated and works great. Unfortunately this means there are still something like half a million edge cases that get issues like unwarranted account lockouts.

jdm2212 6y ago

Once you start letting anyone edit, you have to solve a bunch of other problems: various kinds of spam, non-spam low quality edits, deconflicting manual edits with other data sources. The easy/default solution for most things is to have a trustworthy sources only (official website, Google My Business page, etc.) and a decision tree for choosing which one wins. The Maps feature for editing listings was a ton of work spanning a bunch of teams over several months, but that kind of investment is made only after every other option has been exhausted because it's so slow and expensive and scales poorly relative to just ingesting more data and throwing ML at it.

luckylion 6y ago
Sure, giving everybody direct editing access isn't a good idea. I'm just surprised that so many somewhat user-interaction features feel sub-standard. The maps or gmail gui are super polished, so obviously there are people who do that kind of thing, but others feel rushed, like they were given to an intern that really wanted to leave for the weekend. E.g. the Knowledge Boxes on SERPs. When I was invited to add/edit to them for a notable client a few months back, it was barely documented, cumbersome, error and response messages were vague and it felt like a proof of concept. I guess I'm just wondering: is that by design, has someone tested that and figured out "if people feel like they're using ebay's dysfunctional interface, they'll spend more money on ads", or is it just that somebody gets a task "hey, add a form to edit that, please" and they're like "well, they didn't ask me to make it pretty and I really need to leave soon"?
- jdm2212 6y ago
  Oh yeah I'd bet crappy UIs are just laziness/sloppiness/prioritization rather than malice. The glamorous frontend work that gets lots of design attention is the stuff that has billions of users. I saw some A/B testing for ad engagement that drove UI decision making, but it was always short-term and related to search -- like, "we updated the model today, and users click on the ad 1% more often in the treatment group". FWIW I was pretty much at the bottom of the totem pole so if there was some nefarious plot to provide crappy UIs I wouldn't've been in the loop anyway.