برنامه‌نویسی به زبان پایتون |‌ Effective Question Asking

Main ideas & lessons (Effective question asking in programming communities)

• Mentorship is two-way: In a community, some people answer questions and others ask them. To make the community useful (and not spammy), you must learn how to ask effective questions.
• Communities like Stack Overflow enforce strict norms: If you repeatedly ignore rules—especially obvious ones—your question may be closed or you could be banned. Poorly asked questions create spam and waste time, so people leave and the community degrades.
• Asking questions isn’t just “saying the problem”: Formatting, clarity, context, and reproducibility strongly affect whether you get good answers.

---

Common mistakes when asking questions (with key points)

1) Don’t say “hello” (or greetings)

• Don’t greet and wait.
• If you must greet, ask immediately afterward—don’t let greeting messages consume time.
• Rationale: greeting-only posts add noise/spam and reduce perceived value of the group.

2) Don’t ask for permission (“Can I ask a question?” / “May I ask?”)

• Just ask the actual question.
• Permission-seeking adds delay and extra messages in a space whose purpose is questions/answers.

3) Don’t ask about the “wrong problem” (missing context)

Sometimes you:

• solve an initial problem,
• run into a new issue implementing that solution,
• then ask the group about the new issue without explaining the original context.

Consequence: others may help with the later issue, not the real root problem, or the “solution” you assumed is valid may actually be wrong.

---

Methodology / checklist for writing an effective question (detailed)

A) Question specificity and required details

• Be specific: ask exactly what you need.
• Provide all required details, such as:
  • the goal you’re trying to achieve,
  • relevant assumptions,
  • steps needed to reproduce the issue,
  • the exact code involved (or relevant snippets),
  • the exact output/behavior you expected vs what you got.

B) Provide context (“big picture”)

If the question is tied to a project or specific situation:

• state the project context,
• include background needed to understand the constraints.
• If context helps others guide you better, include it.

C) Avoid unnecessary information (but include what matters)

• Remove “story” and irrelevant chatter.
• Include only details that help someone solve the problem—not extra descriptive material that doesn’t contribute.

D) Use proper formatting

• Check punctuation and spelling (avoid lots of typos).
• Ensure the question is easy to read.
• Use correct platform formatting conventions:
  • properly formatted code blocks,
  • correct display of error messages,
  • reasonable line breaks and structure.
• Don’t assume “I’ll ask badly because it’s just a forum”—format affects response quality.

E) Help others reproduce the problem

• State your environment when relevant:
  • Operating system (e.g., Windows),
  • editor/IDE,
  • versions or specific setup details (as applicable).
• Don’t just paste text—add reproduction steps.
• If you can share a reproducible example, do so.

F) Share code using tools (prefer text over images)

• Prefer text code over screenshots.
• If the code is long:
  • use online code-sharing tools that generate shareable links.
• If you’re sharing files or markup (HTML/CSS/JS/etc.):
  • use appropriate online tools designed for those content types.

G) Use screenshots only as a last resort (and do it correctly)

• Don’t send:
  • photos of your monitor taken by a phone,
  • low-quality, hard-to-read images,
  • overly large screenshots with lots of irrelevant content.
• If you must use an image:
  • use a proper screenshot tool,
  • capture only the relevant region (high quality),
  • avoid including unnecessary page areas.

Why: photos and poor screenshots are hard to edit/zoom and often won’t display well across devices.

---

Examples of “good vs bad” questions (as conveyed)

Bad question patterns

• Vague: “My code doesn’t work. Can anyone help?”
• Missing details: no context, no error message, no reproduction steps.
• Generic “fix it” requests without specifying:
  • what exactly is wrong,
  • what you tried,
  • what you expected.

Good question patterns

• Includes:
  • clear goal,
  • code snippet,
  • expected output,
  • actual output/error (copied as text, ideally).
• Structured and readable:
  • separated lines/sections,
  • clear problem statement.

Another key example: “best language” too broad

• Question: “What is the best programming language for web development?”
• Problem: too general—answers depend on many factors (experience, project type, team size, startup vs large company, etc.).
• Improvement: ask a narrower question with specifics:
  • goal (interactive web app),
  • current skills (HTML/CSS only),
  • constraints (beginner-friendly, job prospects, simple ecosystem).

---

Expectations and attitude

• Don’t demand instant help; be reasonable.
• Assume you’re asking busy people—make it easy to respond.
• Don’t take criticism as the end of learning:
  • People may think your question is “stupid,” but asking correctly is still valuable if you’re committed to learning.
• Long-term goal:
  • Ask questions that help not only you, but others too,
  • and contribute by answering other people’s questions when possible.
• Community improvement benefits everyone: giving help and searching for good answers strengthens the ecosystem.

---

Speakers / sources featured

Speakers (mentioned in examples)

• “Professor Raisi”
• “Professor Abdollahian”
• “Azari Jarami” (named in the greeting example)
• “Jesus” (used as an example character in the “greetings/permission” and context narratives)
• “Zuckerberg” (example character)
• “Elon Musk” (example character)
• “Hafez” (used as the sign-off name)

Sources / communities / named websites/tools

• Stack Overflow (rules and example community)
• Kodir (code sharing tool mentioned)
• Stack Overflow article referenced: “why a photo is not good”
• “website.com” (mentioned as a placeholder/example site in the subtitle)