Monday, May 4, 2009

How to ask me a question

This has been on my chest for a while now. I often get asked questions about coding flash over aim, email, pm, etc. I don't mind answering questions, but I am not a personal tutor for everyone.

Anyway, this is how you should ask me questions (it's a good guide to follow in general too):

1. Don't sent me .fla files, send me a link to a .swf file, or a .txt file with the code in question. I'm not going to drudge through your source to figure out what's wrong, and part of getting better at coding is learning to isolate where your problem it. It's easier for you to do that than me, since I don't know how your code works, this is something you should do before asking me your question. If you show me a swf, I can help tell you where to look to find the problem usually if that's what your problem is.

2. Figure out exactly what it is you want to ask me. Numerous times I get asked, "what's wrong with my code" and they show me a swf, and from looking, 90% of the time the ENTIRE thing is messed up and buggy, or nothing seems messed up and buggy, and neither of those situations helps me help you. I also get this sometimes: "Can I ask you a question?" "ok," "How do I make [complicated feature]?" As I mentioned before, I'll answer questions and help point you in the right direction for tracking down bugs, but I am not a tutor. Make your question specific, technical, brief, and detailed. Rather than ask me how to do accurate collision detection, for instance, ask me how to collide a point to an irregular shape, or a circle to an irregular shape. I'm fine with those types of questions, but being generic doesn't help, and even if I answer the generic question one way, it most likely isn't the answer you were looking for, and it wastes both our time.

3. Narrow the code you send me. I don't need all your code, only the parts relevant to what your question is about. If you can't figure out what parts are relevant, either you have a really really weird problem, or you need to spend a little while learning how to code before attempting something big.

This is how I'll answer your questions:

I won't edit source files for you.
I won't code stuff for you.

I might point out syntax errors or typos, or give you one or 2 lines, or tell you to move this line there and such, but those are only minor changes.

If your code structure is way off or confusing to answer, i'll let you know, but I wont be able to help you much.

If it's a theoretical thing, I'll tell you what to look up online in order to accomplish what you're trying to do.



Post a Comment

Subscribe to Post Comments [Atom]

<< Home