As I mention in my recent [interview with Robert ‘The Duke’ Fedoruk](https://youtu.be/ewd-Bb%5F7t9g) ([9:46](https://youtu.be/ewd-Bb%5F7t9g?t=586)), I truly believe that the highest calling of mankind is to **learn**, and then to **teach**.
I’m _far_ from the only person in the ServiceNow developer community who feels this way! This fact is obviated by the _incredible_ community of new and seasoned administrators, developers, and architects who are constantly trawling the community and just looking for ways that they can contribute.

That said, if you’ve spent much time in the community, you may have noticed that some questions go completely _un-answered_, while some elicit _dozens of responses_ within the first hour; and some that receive dozens of responses, are mostly comprised of questions with no real answers.

**This article** aims to help explain why that is, and to help you ask better questions, more clearly, and get accurate help effectively. If you read this article carefully, you should come away with an understanding of:

* What leg-work you’re expected to do, before asking a question
* What information you need to provide in your question, in order for us to help
* How to format your question so that it’s easy to read and understand
* Some tips for phrasing your question in a way that makes it clear what you’re trying to do

If you see someone posting a question which doesn’t follow the guidelines mentioned in the **Guide to Getting Help** section of this article, link them to this article ([gettinghelp.snc.guru](http://gettinghelp.snc.guru/)) and tell them which rule they’ve violated!

When I use the word “rules” in this article, I mean that in a **lighthearted** kind of way. “Violations” of these rules are not cardinal sins, and aren’t even always wrong. These “rules” are really just guidelines

> **_Pro-tip_**_: To link directly to the “_[_Rules_](https://snprotips.com/blog/2020/1/20/getting-help-from-the-servicenow-community#rules)_” section of this article, use_ [_rules.snc.guru_](http://rules.snc.guru/)_._

There are loads of great resources for learning about the ServiceNow [**API**](https://developer.servicenow.com/app.do#!/api%5Fdoc?id=no-namespace), getting basic ServiceNow [**training**](https://developer.servicenow.com/app.do#!/training/landing), and [**learning about the platform in general**](http://books.snc.guru/); but when you get stuck, where can you ask questions?
Well, if you’re willing to follow the guidelines below, there are several great resources for getting help. Here are a few of them:

* The official [**SN Community forums**](http://community.servicenow.com/)
* **Pros**: Permanent (or semi-permanent). Large community. Decent text formatting options.
* **Cons**: Responses can be slow, and much of the community is disillusioned by the Community forums due to the slowness of responses from question askers, and the tendency of askers to “abandon” threads and not mark answers as correct. Posters often fail to mark answers as correct, which negates some of the “gamification” that might otherwise make you want to participate and help out on the forums despite its issues.
* The unofficial [**SN Dev community Slack**](https://snowslack.herokuapp.com/)
* **Pros**: Fast responses. Large community. Better thread support
* **Cons**: Lack of history (messages disappear after a short while). Large community also means the channels can “flow” very fast, and some things are missed.
* The unofficial [**SN Dev community Discord**](https://discord.gg/y43VtUX)
* **Pros**: Relatively fast responses. Permanent history (easily searchable). Breakout voice/text/screen-share ‘rooms’ that can act like super-threads and/or group voice/screen-share channels for live help when necessary.
* **Cons**: Smaller subset of the community, fewer eyes may be on your question (depending on the time of day).

This article will cover some specific points that are unique or perhaps more specific to the ServiceNow developer communities, and ServiceNow in particular. That said, we’ll also cover some pointers for “asking good questions” as a developer in general. We’ll probably repeat a lot of the sage advice mentioned in some of the existing articles on the topic of asking good questions as a developer; so, to give credit to those that came before, here are some other articles and resources which have also aimed to help developers ask better questions, and get help more effectively:

Please do feel free to read some of those articles too, as some will cover things that this article doesn’t, and others may have far more detail.

Below, you’ll find some basic “_rules_” for getting help and asking effective, clear questions that make it easier for others to help you. When a rule applies mainly to a specific platform, that will be noted at the beginning of the rule.

While you peruse the guidelines below, also consider reading this _excellent_ episode of the ServiceNow Podcast **CJ & The Duke**. In this episode, they discuss and share some sage advice about how to get help from the community, what steps you need to take before reaching out, and _how_ to interact with those you’re trying to get help from, in a way that’s most likely to get you the help you’re looking for.

1. First and foremost: **Try to solve your own problem first**! This is probably the most critical step.
This not only might save yourself and others a lot of time, but will show people that you’ve done your due diligence, and are therefore someone who’s going to be much easier to help.
1. The _bare minimum_ version of this, is searching Google for your problem. Try a few variations on your query.
1. Imagine you were going to post your question to the community. What would you title your post? Try entering something similar to that into Google, and see if anyone’s asked a similar question!
2. This is most effective when combined with **rule #2**.
3. If people can see that you're not **trying to help yourself**, they'll stop **trying to help you**!
Demonstrate that you've at least tried to solve the problem on your own, by telling us what you've done and linking any articles you tried to use for help, including how you adapted them for your specific use-case and any specific code you used (see **rule #2**)
2. Always include any **steps you've already taken** and any articles you've tried to use to solve the problem, **including all of the _exact_ code that you've used**.
1. When mentioning steps you’ve already tried, don’t just say “it didn’t work”; tell us exactly **_how_** it didn’t work. Mention what you _expected_ to happen, and exactly what _actually_ happened. Include **screenshots** if possible. The more we know, the more easily we can help!
2. Include any specific **errors**, **messages**, or **other behavior** you noticed when trying your solution(s).
3. If you didn’t find anything useful for your problem when searching Google, consider mentioning the exact search terms you used.
3. **Always post your code** when asking a question about code.
Don’t say “_hey, I’m trying to hide a field using .setDisplay(‘field’, false) but it’s not working_”
Instead, I mean, _do_ say that, but then also include the entirety of the code so we can see that you’re using g\_user.setDisplay() instead of g\_form.setDisplay(); or that you’re using .setDisplay() on a line that will never actually run because it follows some code that has both an _if_ and an _else_ block, both of which have _return_ statements in them.
Point is - **post your code**, and **post your _complete_ code**. It really helps us, help you!
1. No, I said _post your code_; **don’t post a _screenshot_ of your code** \- or, god forbid, **_please_ don’t post a _cellphone photograph of your screen with your code on it_**… ever. _Please_.
4. When posting your code (_which you should_ **_always_** _do, if the solutions you’ve tried involved code_), always be sure to **format your code properly** on the platform you’re posting it on. Never just hit _CTRL+V_ and post - always use the formatting tools at your disposal.
If you’re not sure how to format code on a given platform, here’s a quick primer:
1. **Discord & Slack**: If your code is a single line, wrap it in **_backticks_** _\`like.so()\`_. For muti-line code blocks, use **_three backticks_** _before and after your code block \`\`\`like so\`\`\`._
1. _Backtick_ is the same key as _tilde_ on your keyboard (but without holding _Shift_); probably right above _Tab_, and below _Escape_.
2. On Slack, you can also select/highlight your code, and press **_CTRL+SHIFT+C_** to format a single line of code, or **_CTRL+ALT+SHIFT+C_** to format a multi-line code block.
2. **Community forums**: When posting a question or reply on the SN Community forums, in the rich-text formatting bar at the top of the editor, you’ll see an “Insert/Edit code sample” button that looks like a semicolon wrapped in curly braces (**{;}**). Click this button to open a dialog in which you can select a language, and paste a multi-line code snippet.
For single-line code, click on the drop-down at the top-left of the editor that says “Paragraph”, and select “Preformatted” with your single-line code selected.
5. When you post a question, **respond to clarifying questions in a timely manner**.
1. Don’t ask the question if you don’t have time to be responsive to people trying to help answer it. Instead, wait until you can have a back-and-forth with anyone who replies, in a timely manner.
There’s little that’s more frustrating than _trying_ to help someone who has apparently abandoned their own question only minutes after posting it.
2. This is _especially important on_ **_Slack_** _and_ **_Discord_**, where real-time communication is expected.
6. Ask **specific questions; not generic ones**.
Sure, some level of generality is fine, but posting a question like “I’ve never set up Discovery before. How do I do it?” is asinine.
1. Before posting a question, think about how it could _possibly_ be answered.
If someone asked you “I’ve never cooked food before; how do I do it?” - you might rightly be annoyed. In addition to making it clear that the person hasn’t even bothered to do the bare-minimum by googling their question and learning a little bit about some of the basic techniques of cooking, they’ve also asked an essentially _unanswerable_ question. There is no way to answer such a vague and unhelpful question without writing nearly an entire book on the topic, or asking dozens of follow-up questions to get at some of the **specifics** of what they’re **actually trying to do**, and providing information and resources on _those_ specific things one-by-one. (See **rule #6**)
2. Remember: **the community is not paid**. We’re all just fellow nerds who learned the same way you are, and who are grateful to the community that existed back in those days, so we’re trying to give back by helping the next generation of developers just like we were helped.
So please, don’t make it so we have to pull your teeth out, as it were, just to get a hint of what you’re _actually asking_, so we can _help you_.
**The harder you make it to help you, the less likely you are to get quality help, or any help at all.**
7. Don’t ask questions that **require clarification**.
(Note: _Do_ _ask_ them; just include enough information that it _hopefully shouldn’t require any further clarification_ of what you’re asking. Just do your best. ♥)
1. This is similar to rule #5, in that you should carefully consider how the question _could_ be answered, given the information you’ve provided.
2. Nobody expects you to already know the answers to your own questions, but think carefully about whether you’ve provided enough information for someone to be able to answer your question, or if they would have to ask you a bunch of follow-up questions.
1. If I ask “How do I compare the values in two fields in a script?” - you can’t really answer that question without knowing more.
Is it a client-side, or server-side script? - Are they the same _type_ of field? - What have you already tried?
Any obvious questions that someone is likely to ask, should be answered by you, preferably in the same post as the question, or at least in an immediate reply on the thread.
8. **Slack & Discord**: When posting a question, **write out the entire question** \- carefully and thoughtfully - **and then press _Enter_**.
_This applies to responses within threads as well as to your initial question._ Try to respond adequately and thoroughly within one message at a time, even if you respond to multiple people and questions in a single reply message.
1. Do not post your question in 5 separate messages, like _“Hey guys” \[enter\] “I have a question” \[enter\] “I’m trying to get this script working…” \[enter\]_ (and so on…).
This is really annoying for several reasons; one of which is that this can spam people with **notifications**. It also makes it unclear which of the multitude of messages should be the base for the **thread** about your question. Finally, it also clutters the channel and makes it much harder to follow and parse, especially if someone asks another question in between two messages you posted about _your_ question.
2. A **single question** should have a **single base message** and a **single thread**. There are _very few_ exceptions to this.
9. If responding to a specific person, **tag them**.
If responding to a specific question or comment that isn’t the one immediately preceding your reply, **quote it**.
1. This makes the thread of conversation and your responses much easier to follow, for anyone who doesn’t see your question immediately, but comes in looking to help a bit after it was initially asked.
2. This also makes sure that the person who said the thing you’re responding to, knows you’ve responded to them.
10. **Don’t abuse tags or DMs**. Tag people who are part of the conversation, but _do not_ just automatically tag anyone who you think might be able to help. **We all have day-jobs**, and volunteer our time for helping the community when we can. Tagging specific people just because you’re not getting an immediate response is extremely rude and presumptuous. Those people are busy, too. This applies equally to tagging someone within a channel, and DMing someone who hasn’t asked you to (especially since moving your question to DMs means nobody else can see the answer and troubleshooting process, so nobody else can learn!)
There are two primary **exceptions** to this rule:

* Do not try to **get the community to do your job for you**.
Nobody should be expected to know _everything_, but if you’ve never written a single line of JavaScript before, you should be **taking a JS course**; not asking questions that can be easily answered by Google.
If you’ve never done ServiceNow development before, you should be [**taking some SN Dev training**](https://developer.servicenow.com/app.do#!/training/landing) or [**reading a book**](http://books.snc.guru/) on the topic, not copy-pasting from your requirements doc into the community and expecting someone to literally do your job for you **for no pay**.
1. If you’re being paid to do something, you should have _some idea_ of what you’re doing; but that doesn’t mean it’s your fault if you don’t know something yet! Just don’t expect the community to do it 100% for you, start-to-finish.
Instead, ask your manager to provide some budget or resources for **training**! As I mention in my article on [**ServiceNow as a career-path**](http://career.snc.guru/), this is a **perfectly reasonable request**!
2. Not knowing how to do something specific is _not_ the same as trying to get the SN dev community to do your job for you. If you have a specific question, please **don’t let this point scare you off from asking it**!
Remember that impostor syndrome is real, and if you ever feel like “I’ll _never_ be a _real_ developer!” - realize that most of us (myself included) felt the same way at some point.
All that **rule #12** is asking, is that you try to use the resources at your disposal to _try_ to learn the basics and solve your own problems before you come to the community asking for us to help you, and try to avoid asking questions that are tantamount to “do it for me”.
* Don’t _just_ say “Hello”. Instead, _get to the point_. I realize that when people send a separate message (and notification) with just “hi”, _they think_ that they’re being polite… but they are not. It notifies everyone in the channel/message multiple times, and after the first one is a pointless “howdy”, the rest will often just be ignored.
1. As annoying as a message that just says “what up” followed by a minute or two of silence while you write your actual question is, it is _ten times more annoying_ to get a “bonjour”, and then have your conversational partner just _wait_ for you to respond.
2. Read \- this hilarious and extremely apt site will guide you! I wanted to copy/paste a lot of their points here, but I’d rather direct the traffic to their site - so please do check it out!
* _That which is bestowed to you, in the fullness of time, return to that from whence it came._
Er, uh, that is… if the community helps you learn and grow as a developer, **try to return the favor** whenever you can.
As a new developer, nobody expects you to answer a question for every one you ask; but over the course of your career, try to return and help out anyone you can now and then.