Suggestions on asking for technical help on the web

[halfer]

Preamble

This is unrequited advice for Fly users wanting help, and no-one needs to heed it. I am merely a Fly enthusiast, with a side-interest in technical mentoring. Should this post unduly ruffle feathers, I shall delete it. However, it may be helpful for new posters. Suggestions for improvements, or general comments, are welcome.

Most questions posted here are incomplete, unreadable, and/or impossible to answer. A number of posters do not know that some folks who help here are hobbyists and volunteers. A good number of question authors have not read the documentation, or even the error messages they are receiving.

I may enjoy a little leeway above employees because employees are, I assume, obligated to be nice to posters who are making no earnest effort to solve their own problems. I don’t want software engineering or systems design to be regarded as dark arts only open to a select few, but I’d not be doing anyone a kindness if I claimed that either are easy. They are nothing of the sort.

I might even go so far as to say that we do not do people a favour if we always spoon-feed answers to them. We are doing fellow engineers a service if we can help them in a way that helps them become more self-sufficient in the future.

Asking questions

So, a few pointers shall now follow. The benefit in following them is that readers may get answers to their problems faster; either they ask better questions, or they may even be guided to answer their own questions.

1. Use the formatting tools here. There is a preview window, please use it. The forum software uses Markdown, which is so established as an industry standard that engineers have no excuses not knowing it. Use block formatting for code, config, and logs. Use inline code formatting for commands and one-line snippets. It’s worth noting that Markdown is also used in GitHub, GitLab, Bitbucket, Reddit, Jira, and lots of other engineering-related tools.
2. Consider posting enough detail in your first post that you do not have to be asked for more information. I’d wager more than half of the posts here from Fly users fall into this category. Readers, obviously, cannot see your screen. Include your TOML file and your Dockerfile if they are helpful. Describe what debugging you have done so far. If you used console commands, list them explicitly. If you use deploy tools in GitHub, say so.
3. Read the Fly documentation. It is really very good. Find out how to get logs from your machines. Find out how to shell into a machine so you can see what processes are live, or what addresses listeners are attached to. Find out how to scale an app so it contains multiple machines in a region. Find out how to scale an app so it is multi-region.
4. If you’re an engineer but you haven’t used Linux or Docker, no problem. You should learn the basics though; a bit of reading in the short term will pay dividends.
5. If you are not an engineer, then you may struggle. All the cloud providers would love to provide a system that simplifies system design, and my earlier point about not gatekeeping still applies, but there needs to be a cut-off. We recently had someone demanding to know what an out-of-memory error means, and I am not sure what helpers are meant to answer to that, other than broad generalisations. If you’re an entrepreneur, then I wish you luck, but your risk is not failing: your risk is succeeding, and then having paying customers on your platform that has no engineers supporting it.
6. If something does not work in Fly, try building it and running it in Docker on your laptop. If it does not work locally then it definitely won’t work remotely. A good chunk of questions fall into this category; testing a system locally rules out a whole category of problems. The basics of Docker are super-easy to learn: you can get Hello World running in ten minutes, generally on any operating system, free of charge.
7. Occasionally things go wrong on the Fly platform. Please be aware that no-one is causing problems deliberately; building global-scale cloud requires extraordinary talent, and things still can go belly-up. Sometimes hardware fails, sometimes there is an unpredictable surge in demand in a region and it causes machine creation problems. Sometimes there is an outage. Please don’t get snippy or abusive in these situations; it doesn’t help the engineers who’re on-call, and your app will not become available faster.
8. If you have a billing or account management query, drop a line to billing@fly.io; it is not a bother if you post your question here, but someone will probably ask you to drop an email anyway.

There. What did I leave out?

[mayailurus]

There is a lot of good advice and (even better) intent here, and I gave it a ♡ despite not entirely agreeing with all details of tone, etc., …

@halfer

If you have a billing or account management query, drop a line to billing@fly.io

I really wish this one was emphasized structurally—e.g., as its own pinned (a.k.a. sticky) thread, a dedicated Payment and Account forum category, a mention on the Billing page of the dashboard, …

@halfer

Suggestions for improvements, or general comments, are welcome.

One thing that can help with documents such as this is to order it with the top two or three most crucial tips first, then consensus advice that basically everyone agrees with—but harried posters might forget in the heat of the moment—then the broader philosphical discursions and motivations, and finally any parts that are your own personal views (weakly or strongly held).

@halfer

If you are not an engineer, then you may struggle. All the cloud providers would love to provide a system that simplifies system design, and my earlier point about not gatekeeping still applies, […]

I’ve said broadly similar things in the past (and still believe them!), but this might need additional disclaimers—about it maybe not being Fly.io’s own view and/or aspirations. (I don’t actually know for sure, myself.)

For example, in their recent job posting for an Elixir-heavy UI role (which maybe went unfilled?), they said that they intend to be…

[…] a public cloud platform that has the ergonomics of “platform as a service” offerings like Heroku, but the power, flexibility, and economics of a hyperscalar cloud.

That’s neat! and I know you weren’t arguing against it. But that overall “should be magic” drift, combined with “RX” threads and blog posts, possibly indicates a different line of thinking than your (5) paragraph.

@halfer

Most questions posted here are incomplete, unreadable, and/or impossible to answer.

I think this is an overestimate, but I really see where you’re coming from…

One thing that might have been overlooked is that old-timers remember the days when the forum was the place to contact Fly.io employees. And some have lifetime discounts, or similar, due to having been very early adopters. This might lead to a guess that the former pattern of posting a vague “not working sometimes” yet still getting a resolution from someone who went and checked via the backend would continue informally.

Also, many users have stated explicitly that they just don’t understand the phenomenon of paying for something and then not being able to contact the company in any way.

Consequently, any link or button that has “support” in the name, regardless of a “community” disclaimer preceding it, will tend to be assumed to be the sought-for contact mechanism that their model of commerce says does exist. This is like the industrial-design example of a door handle that is clearly labeled “push” yet looks exactly like a pull bar.

This is going to be super-hard to dissuade through PSAs, etc.

Anyway, just my own, weekend 2¢…

[lillian]

@mayailurus

@halfer

If you have a billing or account management query, drop a line to billing@fly.io

I really wish this one was emphasized structurally—e.g., as its own pinned (a.k.a. sticky) thread, a dedicated Payment and Account forum category, a mention on the Billing page of the dashboard, …

thanks, this is actionable from our end. I’ll update the sticky thread on Monday.

there is a mention of billing@fly.io on the support page of the dashboard:

but I’ll see if we can make it more visible at all.

[halfer]

Great feedback, thanks @mayailurus.

despite not entirely agreeing with all details of tone

It’s a very good point. I don’t claim to be a particularly great engineer, and Big N certainly are not sending headhunters in my direction, but lately I do find myself getting a little tetchy at what I perceived to be a lack of rigorous thought, and a deeply-ingrained learned helplessness, from folks learning how to build software.

I am not deliberately channelling a BOFH, but I can see how I might be perceived as such. It may be Stack Overflow’s fault, or at any rate the fault of the thousands of objectively low-quality questions we get every day on that platform. I am stuck in a never-ending loop of eternal Septembers, and it is encouraging me to tell the kids to get off someone else’s lawn.

To practical considerations: this document is useless if it is not helpful (and I acknowledge the bit about PSAs being ineffective in some cases). Thus, if the community finds my post useful, such that helpers might refer to it, or that we might sticky it, I would be fine with editing it to make the tone less grumpy.

I’ve said broadly similar things in the past [about non-engineers giving it a go] but this might need additional disclaimers—about it maybe not being Fly.io’s own view and/or aspirations.

Oh yes, totally agree. This was a personal commentary bit; indeed, I suppose it all is. I can only speak for myself, etc. I am happy to take feedback on whether this is useful to mention; maybe Fly wants to democratise the cloud to the degree that every Tom, Dick, and Harry can give it a whirl, aided to varying degrees of success by angry typing into an AI chat prompt.

One thing that might have been overlooked is that old-timers remember the days when the forum was the place to contact Fly.io employees.

I’m definitely late to the Fly party, but I doubt there is much overlap between the groups that you and I are referring to. Those early adopters will have helped Fly find early bugs, and they are possibly not the kinds of folks given to posting content-light please-halp-me pleadings on the internet.

One thing that can help with documents such as this is to order it with the top two or three most crucial tips first, then consensus advice that basically everyone agrees with—but harried posters might forget in the heat of the moment—then the broader philosophical discursions and motivations, and finally any parts that are your own personal views (weakly or strongly held).

Yep, totally agreed. It was a bit of stream-of-consciousness order, and I’d have no objections to reordering.

As for harried posters, it is a good point: do we try to educate forum visitors at the point of joining the community, or when they’re dashing off an it-doesn’t-work skip-fire question, prior to chucking their laptop out the window? My experience on SO is that once a user is desperate enough to post, it’s too late to advise them (other than gamely helping them in-thread by walking them through the creation of a decent question).

[halfer]

I’ll post to keep this open for one more seven-day cycle, in case other helpers/readers might be tempted into responding.

I don’t have a firm objective in continuing the conversation, other than the original goal, which is to see if folks can be helped to asked better questions, so they obtain help faster, and become more self-sufficient. (I acknowledge this may not be possible in loose-knit communities, as posters may not generally be open to advice, and they just want technical support).