Ask for feedback that's actually useful

Vague requests like "what do you think?" get vague, polite answers that don't help you improve. Specific questions, such as "is this the right approach for X" or "what would you check first if this broke", get specific answers. They also show you can take feedback seriously, which matters as much as the feedback itself.

Why "is this good?" doesn't work

When you ask "is this good?", the other person has to decide what "good" means, which part to look at, and how honest to be. Most people answer by skimming, finding nothing obviously broken, and saying "looks great!" It's kind, and almost useless.

The problem isn't the reviewer. A vague question gives them no job to do. It also puts all the effort on them: they have to figure out what your project is, what stage it's at, and what you're worried about.

A specific question flips that. It tells them exactly where to look and what kind of answer you need, so even five minutes of their attention produces something you can act on.

Give context before the question

Before asking anything, give the reviewer the minimum they need to orient themselves:

• What it is: "A to-do app with localStorage persistence."
• What stage it's at: "Working, but the styling is unfinished, so please ignore that."
• What you're trying to learn or decide: "I'm about to add user accounts."

Saying what stage it's at, and what to skip, prevents wasted feedback. Otherwise someone may spend their whole time on button colours you already plan to change, and never get to the part you actually wanted reviewed.

Include a direct link to the repository, the specific file, or the live demo. Every extra click is a reason for a busy person to put it off.

Ask questions that have useful answers

Good feedback questions are narrow enough to answer and about something you can change. Compare:

• Vague: "Thoughts on my code?"
• Specific: "In storage.js, is it reasonable to save the whole task list on every change, or will that cause problems later?"
• Specific: "If the weather API call failed, what would you check first, and does my error handling make that easy?"
• Specific: "Could you follow my README and tell me the first step where you got stuck?"

Aim for one to three questions per request. Ten questions feel like homework and tend to get none answered well. Pick the ones where an outside view would change what you do next.

Choose the right person and respect their time

Match the question to the reviewer. A friend who isn't a developer is great for "can you follow the README?" or "is it clear what this app does?", but can't judge your code structure. A more experienced developer, a mentor, or a community forum is better for code questions.

Make it easy to say yes:

• Say how long it should take: "about 10 minutes."
• Put everything in one message: context, link, and questions.
• Make it clear that "no time right now" is a fine answer.

On public forums and Discord servers, read the channel rules first, and post a small code snippet or link rather than a screenshot of code, so people can copy and test it.

Receive it well and close the loop

How you respond decides whether people help you again. When feedback arrives:

• Thank them, even when it's critical.
• Ask clarifying questions instead of defending: "Which part felt messy? Could you point to an example?"
• Don't argue in the moment. Take time to think; you don't have to agree with everything.

You decide what to act on. If two reviewers disagree, ask for their reasoning and weigh it against what the project is for.

Finally, close the loop. A short message like "I split app.js into three modules based on your suggestion, here's the commit" shows the feedback mattered, and makes people much more willing to help next time.

What to do now

Ask for feedback on the project you just documented:

1. Write two or three specific questions about the parts where you're least sure, such as a design choice, error handling, or whether the README can be followed.
2. Write a short message with context: what the project is, its stage, what to ignore, and a direct link.
3. Send it to one or two people suited to those questions, with a realistic time estimate.
4. When replies arrive, thank them, ask for examples where things are unclear, and note what you'll change.
5. Make the changes you agree with, then tell each reviewer what you did.