Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Luke Redpath

macrumors 6502a
Original poster
Nov 9, 2007
733
6
Colchester, UK
OK, this forum seems to have an issue with people asking for help without it being very clear exactly what they need help with, so I thought I'd post this: consider this a set of guidelines for getting useful help out of the other FMs on here.

When faced with a problem that you do not know how to solve, first of all, ask yourself these questions:

1. Does this seem like something that should be obvious, or an issue that somebody else has probably solved already? If so, have you tried Googling for the answer? Failing that, have you tried searching these forums for an answer and checking the stickies at the top of the forum?

2. Have you looked at the documentation? If you're having a problem with, say, an NSString, have you looked at the pretty comprehensive NSString documentation?

Having asked yourself these questions, if you still haven't found your answer, its time to ask for help. When posting on here with a question/problem, try and cover the following:

1. Summarize. What is the overall issue you are having? Is your question related to some kind of fundamental design decision, a compile issue (warnings/errors), a crash, unexpected behaviour?

2. Expected outcomes. What did you expect to happen? What is actually happening?

3. Code. Nobody is going to be able to help you, particularly with crashing/compile issues, if you don't post your code. I don't mean pseudo-code, or some kind of mashed up edited version of your code, post as much relevant sample code as you can. Start with the method that is causing you a problem. If that method is referencing variables, post your header and any initialisation. If in doubt, post the entire class and header file. If somebody asks to see some other part of your code, show them. Don't be protective of your code; nobody is here to "steal" your code, we just want to help.

3a. Use CODE tags when posting code. Code posted without using code blocks is difficult to read.

4. What have you tried? It helps to know what you've already tried and what failed. If you've tried looking in the documentation, where have you looked? (if you haven't looked in the docs, return to the beginning of this post).

5. Resolution. If you are able to solve the problem on your own, don't just say "I SOLVED IT" and disappear. Tell us how you solved it. Maybe you'll help somebody else with the same problem if they come across your thread. Maybe the way you solved it wasn't the best way and somebody may be able to recommend a better way.

Finally, a little bit of manners never hurt. If somebody takes the time to help you and/or posts a solution to your problem, it doesn't hurt to acknowledge it and say thanks.
 

robbieduncan

Moderator emeritus
Jul 24, 2002
25,611
893
Harrogate
Any feedback? Additions/changes?

No, not really. I think you've covered everything in your post.

I think your post is good and if everyone read, understood and followed would be great. Your intentions here are good but, I think, the people who don't follow these simple rules are also the sort of people who won't read this (even if it is stickied) :(
 

Luke Redpath

macrumors 6502a
Original poster
Nov 9, 2007
733
6
Colchester, UK
No, not really. I think you've covered everything in your post.

I think your post is good and if everyone read, understood and followed would be great. Your intentions here are good but, I think, the people who don't follow these simple rules are also the sort of people who won't read this (even if it is stickied) :(

I suspect you might be right; we can but try.
 

ataylor2009

macrumors member
Jan 27, 2009
78
0
1. Does this seem like something that should be obvious, or an issue that somebody else has probably solved already? If so, have you tried Googling for the answer? Failing that, have you tried searching these forums for an answer and checking the stickies at the top of the forum?

2. Have you looked at the documentation? If you're having a problem with, say, an NSString, have you looked at the pretty comprehensive NSString documentation?

Having asked yourself these questions, if you still haven't found your answer, its time to ask for help.

As a relative newcomer (<1 year) to programming, I would just like to point out a couple of things. Number one, frequently I find myself in the unenviable position of not knowing what question to ask. When, for example, a view won't appear, should I ask "Why won't this view appear?" or "What's wrong with this view?" or "Is something wrong with my view controller?" or "Why isn't this view being pushed?" or what? As a new guy, I don't usually know if my problem is obvious or generic or the first time it's ever happened to anybody, ever.

Number two, even though I always look at the documentation first, I can frequently look right at the relevant part of the documentation and not understand what I just read. This is not my fault; I'm a relatively intelligent guy who happens to produce technical documentation for a living. The problem is that Apple puts forth a lot of effort making their documents look very pretty, and not a lot of effort making them actually understandable. (Hint to Apple: Go read something by Stephen Kochan. Anything. Then copy it.)

Now, take those two things together: I don't always know what question to ask, and I don't always understand what I'm reading in the "official" documentation. This adds up to a ton of frustration, mostly due to a perfect storm of bad circumstances. The electronic documentation and search tools you mention don't make the leap from "his view isn't appearing" to "he didn't hook something up in IB;" they only show the specific results that contain the search language used to find them.

So people like me end up here, which is the next best thing to a local hang-out where I could talk to other developers live and in-person. I do my best to provide all of the other information you list above, for two reasons: First, obviously, I want a quick answer to my question so I can get back to work, and second, not as obvious but a feeling shared by many (if not most) questioners, is that I don't want to be berated, belittled, or condescended to for asking for help. We're taught all our lives that the only stupid question is the one that isn't asked...but that doesn't really apply when asking for help online (not just here - this happens in on-line forums everywhere spanning every conceivable topic), where questioners frequently have to submit to smartass, sarcastic, "go-look-it-up, dumbass!" answers.

While I applaud the general gist of your original post, I would also offer a suggestion: Take a cue from the stackoverflow.com community, which says (I'm paraphrasing here) "keep it civil, be helpful, don't scold people for asking questions. Remember, not everybody knows as much as you do, and they're here looking for help and trying to learn. Be civil."

[/rant]
 

dejo

Moderator emeritus
Sep 2, 2004
15,982
452
The Centennial State
Any feedback? Additions/changes?
Hmm, I'd recently been PMing with one of the mods on pretty much this topic. One of my concerns is that even with the current stickies, posters tend to ignore them. For example, we have a whole sticky dedicated to remind people to use the code tags and yet, too frequently, code is posted without those tags. We need to way to incite posters into paying attention to these things. Unfortunately, I have not been able to come up with a "magic pill" that would solve this. Maybe a perk? Or perhaps a test of some sort to ensure they have read the relevant information before being allowed to start a thread.

As for specific feedback, here are some of the suggestions I brought up in my PM discussion:
  • please search first
  • if you know there's already threads on a topic, point the OP to them
  • ACTUAL code snippets (too many times changes are made to code to "hide" secrets of what the dev is creating, I believe; those changes usually cause problems)
  • please be specific! "it doesn't work", "it crashes" or "this book on Objective-C" are way too vague to facilitate discussion. error messages, crash log statements, bookname-author-chapter-page are much better.
  • know the basics of iPhone development before posting requests for troubleshooting help (too often we have to point posters to available documentation or recommend they "step away from the real coding and go learn the basics" since it's clear they don't have that knowledge yet)
  • just because you post, doesn't mean you are entitled to a response (often see "100+ views and no response? wtf?" yeah, there could be many reasons why. don't operate on the assumption you will get an answer, especially one you wanted to hear)

The problem is that Apple puts forth a lot of effort making their documents look very pretty, and not a lot of effort making them actually understandable. (Hint to Apple: Go read something by Stephen Kochan. Anything. Then copy it.)
I think you are confusing the needs of reference documentation and educational material. They serve different purposes.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.