3 ms·

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

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."
- rantwasp 5y ago
  you are by definition a power user. if your product is for power users that’s fine. if your product is targeted to everyone but only power users can figure it out when there is an issue... well you have a problem. also, being able to figure something out != you should figure it out. your time is limited and the complexity of remembering all those things that you figured out (even if you have the time) will quickly overwhelm you. unless it’s literally your job to support the product you should care about the interface of the product and what guarantees it makes re: hiring devops engineers. i’m sorry, what? if my email suddenly does not work I’m supposed to hire a devops engineer now?

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."
rantwasp 5y ago
you are by definition a power user. if your product is for power users that’s fine. if your product is targeted to everyone but only power users can figure it out when there is an issue... well you have a problem. also, being able to figure something out != you should figure it out. your time is limited and the complexity of remembering all those things that you figured out (even if you have the time) will quickly overwhelm you. unless it’s literally your job to support the product you should care about the interface of the product and what guarantees it makes re: hiring devops engineers. i’m sorry, what? if my email suddenly does not work I’m supposed to hire a devops engineer now?