To get useful feedback on your code, share a small, runnable piece with one specific question, in a place where developers actually review code, and reply to every comment you get. "Thoughts on my repo?" gets silence; "Is this retry logic safe under concurrent calls?" gets answers.
1. Make it small
Nobody reviews a 4,000-line repository for free. Extract the part you are unsure about into a snippet or a single PR: a function, a module, a schema. If it cannot be understood in five minutes, it is too big for a first ask. Add a one-line README on how to run it or what input it expects.
2. Ask one question
Pick the kind of feedback you want and say it:
- Correctness: "Does this handle the empty-array case?"
- Design: "Should this be one class or two functions?"
- Performance: "This runs on 10k rows; is the nested loop a problem?"
- Readability: "Would you understand this without the comment?"
Reviewers calibrate to the question. Without one, you get style nitpicks.
3. Post it where line comments are possible
A snippet with syntax highlighting or a PR link lets people point at a line. Screenshots do not. On DEVAE, snippets can be shared with collaborators and discussed in a thread; a GitHub PR works too. Tag the language so the right people see it.
4. Go to the right room
General feeds are for showing work; feedback needs people who review for a living. Try a stack-specific community hub, a code-review request thread, or a live room where you share your screen and walk through it — ten minutes of live review often beats a week of comments. Offer to review something of theirs in return; reciprocity is the fuel of every review community.
5. Close the loop
Reply to every comment, even to say "I disagree because…". Apply what you accept, then post the revised version with a short note on what changed. People review again for those who visibly use their feedback.
Handling harsh feedback
Separate the tone from the content. Extract the claim ("this leaks a connection"), verify it, and respond to the claim only. If someone is rude and wrong, ignore them; if they are rude and right, fix the bug and thank them briefly. You are collecting information, not approval.
A weekly habit
One snippet a week with one question, reviewed by two people, will improve your code faster than any course. It also builds the relationships that turn into pair sessions and referrals.
A worked example
A developer learning Rust posts a 60-line function that parses a config file, with the question "Is my error handling idiomatic, or should I use a crate?" Two people reply: one suggests thiserror for the error enum, another points out that a match could be a ? with a From impl. She applies both, replies with the diff, and asks a follow-up about testing the failure paths. A third person offers to pair on the tests in a room. Total time from post to reviewed, tested code: two days.
Questions people ask
**Is it safe to post company code?** No. Extract the pattern into a standalone example with fake data, or ask about the approach rather than the code. Never post secrets, internal URLs or customer data.
**What if I get conflicting advice?** Ask each reviewer what problem their suggestion prevents. Pick the one whose problem you actually have. Conflicting advice usually means both are right in different contexts.
**How do I give feedback in return?** Read the code before commenting, ask what kind of feedback they want, point at specific lines, and lead with the most important issue. One good comment beats ten nitpicks.
