5 ms·

yep. i remember asking a question on google groups about some AppEngine query early on a Saturday morning thinking, "this will never be answered". about 15 min

yep. i remember asking a question on google groups about some AppEngine query early on a Saturday morning thinking, "this will never be answered". about 15 minutes later Guido van Rossum answered my question.

criddell 5y ago
I read about a similar example this week. Some news orgs filed FOIA requests for Dr. Anthony Fauci's email and I was surprised at how many regular people just emailed him and got a response. Apparently the guy answers about 1000 emails per day.
derefr 5y ago
Also, people who say so-and-so company (usually Google) is hard to contact for support, or that they require expensive support contracts before they'll talk to you, have likely never tried sending email to the appropriate mailing list for the product. It's amazing how often doing this completely bypasses any corporate first-line-support structure in the way, and just puts the email right into the inbox of the line engineers working directly on the product. It's also amazing how quickly those line engineers reply. (It's as if they treat "replying to random messages on the product mailing list" as their highest-priority job. Or maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked.)
- 0xEFF 5y ago
  The appropriate mailing list email address is often listed right at the bottom of the blog article too.
- mercer 5y ago
  I've more than once had one of the core developers of Elixir or Phoenix answer a question almost right after asking it in the Slack or IRC channel. I often felt a bit embarrassed to take up their time considering how 'basic' these questions were. I've had similar experiences in other language/framework communities. It's amazing how helpful some of these very productive people can be to random chat visitors :)!
  - mst 5y ago
    The trick is to remember that they're almost certainly working on that stuff because they enjoy making users happy, so they're also doing support for the same reason. I do feel a little bit embarrassed if it turns out they're reading the docs to me, but I feel embarrassed about that whether it's an expert or a fellow n00b ;)
    - mercer 5y ago
      Haha, I've found that to be good training to always read the docs first.
- rantwasp 5y ago
  no. there is a big difference between having support and having someone that is passionate about something helping you out. support should be there and should be available from the simplest issues to the most complicated things about A PRODUCT. you will not get much traction if you ask the same things to the people expert person on a mailing list.
  - derefr 5y ago
    I guess I've never needed "support" in that sense. I almost always solve problems with the products/services we use myself — up to and including forking the vendor's codebase to fix their shit for them — because it's almost always the fastest way to do things. I've already been working with their product for a while, and I already know exactly what my own problem is. Provided I also know the language their code is written in, that translates to being able to code a patch myself, faster than I can get someone on their end to comprehend the problem I'm having. That applies up until the point where there's a problem surface that's just plain inaccessible to me (i.e. the inside of a proprietary mobile app or SaaS service), at which point I have to reach out to tell them that it's broken / missing something on their end. (And even then, if I have a spare hour and access to the offending binary, I'll reverse-engineer it a bit to see if I can hotpatch it while waiting for them to get back to me.) I suppose, for people who don't think this way, there can be value in "support." But IMHO there's more value in just hiring some DevOps engineers who do think that way. Then all the easy "support" requests get handled in-house, and so you'll only ever need the kind of "support" that involves direct bug reports to the engineers from the vendor who built the thing.
    - gowld 5y ago
      > forking the vendor's codebase to fix their shit for them How well does that work for a hosted cloud service?
      - derefr 5y ago
        I mean, if I know that some service is using e.g. Redis under the covers, and the problem is in Redis itself, then submitting a patch upstream to Redis; waiting for it to get upstreamed; and then telling the cloud host to update their Redis version to solve the problem — is usually a pretty reliable path. But otherwise, like I said, that's when "the problem surface is inaccessible."
- TimPC 5y ago
  It depends on your issue. We got good support emailing with the TF Lite team on a neural net bug. I think if you’re interacting with open source in a value add way google support is often quite good. If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent.
  - shaftway 5y ago
    > If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent. > Maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked. Integrating sales or classic customer support is boring. I mean, I get that it pays the bills, but when I've got a million priorities, boring work that I don't really get credit for goes to the bottom of the pile.
- deanCommie 5y ago
  It's a great concept in theory, but in practice...find me the email list for Google Photos. Or Google Keep. These are two Google products that I use daily (including paying for one!)
  - derefr 5y ago
    Well, yeah, there does have to be a public mailing list. My point was that there are often public mailing lists, where engineers with real engineering problems could discuss those problems with the engineers responsible for the product/service; and yet the engineer with the problem nevertheless doesn't even think of using the mailing list to reach out, but instead decides to go through regular customer-service support channels to get their problem solved.
    - filoleg 5y ago
      >Well, yeah, there does have to be a public mailing list. Imo, this is not scalable or sustainable, and mailing lists are not a replacement for adequate customer support. The only reason sending emails directly to mailing lists for specific Google products works is precisely because those mailing lists are not public and not flooded with bajillions of emails from the general public. So those who send the emails are already somewhat pre-screened in a way, because if you know that mailing list email address in the first place, you are very unlikely to send something like "my cousin couldn't remember password to their google photos account, can you fix this please". That's why everything there ends up being read and addressed. If those mailing lists were public, then they would be just as useless and ineffective as the current customer support routes currently are for Google. Tl;dr: mailing lists for specific products are a nifty workaround for the time being, but they aren't a good sustainable solution for shitty customer support. Making those mailing lists public will not only not help solving the problem, it will just make those mailing lists as ineffective as the current customer support. There is no "one weird trick" to solve the customer support adequacy issues with Google,it has to be an actual customer solution that won't be easy and will take time.
      - zikzak 5y ago

criddell 5y ago

I read about a similar example this week. Some news orgs filed FOIA requests for Dr. Anthony Fauci's email and I was surprised at how many regular people just emailed him and got a response. Apparently the guy answers about 1000 emails per day.

derefr 5y ago

Also, people who say so-and-so company (usually Google) is hard to contact for support, or that they require expensive support contracts before they'll talk to you, have likely never tried sending email to the appropriate mailing list for the product. It's amazing how often doing this completely bypasses any corporate first-line-support structure in the way, and just puts the email right into the inbox of the line engineers working directly on the product. It's also amazing how quickly those line engineers reply. (It's as if they treat "replying to random messages on the product mailing list" as their highest-priority job. Or maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked.)

0xEFF 5y ago
The appropriate mailing list email address is often listed right at the bottom of the blog article too.
mercer 5y ago
I've more than once had one of the core developers of Elixir or Phoenix answer a question almost right after asking it in the Slack or IRC channel. I often felt a bit embarrassed to take up their time considering how 'basic' these questions were. I've had similar experiences in other language/framework communities. It's amazing how helpful some of these very productive people can be to random chat visitors :)!
- mst 5y ago
  The trick is to remember that they're almost certainly working on that stuff because they enjoy making users happy, so they're also doing support for the same reason. I do feel a little bit embarrassed if it turns out they're reading the docs to me, but I feel embarrassed about that whether it's an expert or a fellow n00b ;)
  - mercer 5y ago
    Haha, I've found that to be good training to always read the docs first.
rantwasp 5y ago
no. there is a big difference between having support and having someone that is passionate about something helping you out. support should be there and should be available from the simplest issues to the most complicated things about A PRODUCT. you will not get much traction if you ask the same things to the people expert person on a mailing list.
- derefr 5y ago
  I guess I've never needed "support" in that sense. I almost always solve problems with the products/services we use myself — up to and including forking the vendor's codebase to fix their shit for them — because it's almost always the fastest way to do things. I've already been working with their product for a while, and I already know exactly what my own problem is. Provided I also know the language their code is written in, that translates to being able to code a patch myself, faster than I can get someone on their end to comprehend the problem I'm having. That applies up until the point where there's a problem surface that's just plain inaccessible to me (i.e. the inside of a proprietary mobile app or SaaS service), at which point I have to reach out to tell them that it's broken / missing something on their end. (And even then, if I have a spare hour and access to the offending binary, I'll reverse-engineer it a bit to see if I can hotpatch it while waiting for them to get back to me.) I suppose, for people who don't think this way, there can be value in "support." But IMHO there's more value in just hiring some DevOps engineers who do think that way. Then all the easy "support" requests get handled in-house, and so you'll only ever need the kind of "support" that involves direct bug reports to the engineers from the vendor who built the thing.
  - gowld 5y ago
    > forking the vendor's codebase to fix their shit for them How well does that work for a hosted cloud service?
    - derefr 5y ago
      I mean, if I know that some service is using e.g. Redis under the covers, and the problem is in Redis itself, then submitting a patch upstream to Redis; waiting for it to get upstreamed; and then telling the cloud host to update their Redis version to solve the problem — is usually a pretty reliable path. But otherwise, like I said, that's when "the problem surface is inaccessible."
TimPC 5y ago
It depends on your issue. We got good support emailing with the TF Lite team on a neural net bug. I think if you’re interacting with open source in a value add way google support is often quite good. If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent.
- shaftway 5y ago
  > If you’re looking for support for integrating for sales or classic customer support it can be terrible to non-existent. > Maybe it's just that they're technical people, and my questions are usually very nerd-snipe-y, and get them hooked. Integrating sales or classic customer support is boring. I mean, I get that it pays the bills, but when I've got a million priorities, boring work that I don't really get credit for goes to the bottom of the pile.
deanCommie 5y ago
It's a great concept in theory, but in practice...find me the email list for Google Photos. Or Google Keep. These are two Google products that I use daily (including paying for one!)
- derefr 5y ago
  Well, yeah, there does have to be a public mailing list. My point was that there are often public mailing lists, where engineers with real engineering problems could discuss those problems with the engineers responsible for the product/service; and yet the engineer with the problem nevertheless doesn't even think of using the mailing list to reach out, but instead decides to go through regular customer-service support channels to get their problem solved.
  - filoleg 5y ago
    >Well, yeah, there does have to be a public mailing list. Imo, this is not scalable or sustainable, and mailing lists are not a replacement for adequate customer support. The only reason sending emails directly to mailing lists for specific Google products works is precisely because those mailing lists are not public and not flooded with bajillions of emails from the general public. So those who send the emails are already somewhat pre-screened in a way, because if you know that mailing list email address in the first place, you are very unlikely to send something like "my cousin couldn't remember password to their google photos account, can you fix this please". That's why everything there ends up being read and addressed. If those mailing lists were public, then they would be just as useless and ineffective as the current customer support routes currently are for Google. Tl;dr: mailing lists for specific products are a nifty workaround for the time being, but they aren't a good sustainable solution for shitty customer support. Making those mailing lists public will not only not help solving the problem, it will just make those mailing lists as ineffective as the current customer support. There is no "one weird trick" to solve the customer support adequacy issues with Google,it has to be an actual customer solution that won't be easy and will take time.
    - zikzak 5y ago