In my MFA program, I'm about to enter a phase where I'll be submitting a lot of my work for peer and instructor review. The prospect has me a bit nervous. My ego and selfishness sometimes make me resistant to changing my "vision" for a piece. But I recently came across some advice from a published novelist (one of my professors) about working with her editor, and one detail stuck with me. When he offered a note he felt strongly about, he'd sometimes add: if you follow this advice, it might ruin the book. That sounds strange for an editor to say, but it was his way of drawing a line: this is worth considering, but it's not a command. You're still the author. That distinction matters more than it sounds. New writers tend to get this wrong in two ways. The first is rejecting every note that doesn't match your original vision; treat feedback as noise, and you never grow past the instincts you started with. The second is worse: taking every single note at face value and rewriting your story into something that pleases everyone except you. Writers who do that often end up with technically competent work they don't recognize as their own. The better path is closer to an idea borrowed from improv comedy: "Yes, and." You don't accept a note wholesale, and you don't dismiss it outright either. You look for what's actually underneath it. In the example I read, the editor suggested adding a new major male character to a story with an all-female cast. The writer didn't do that, but the concern behind the note (wanting a stronger connective thread between the two leads) turned into one of the best changes in the book. The literal suggestion got discarded. The instinct behind it didn't. That's the mindset I want us to bring into our feedback threads here. When someone tells you your opening scene confused them, or your dialogue felt stiff, your first job isn't to defend the page; it's to sit with the note and ask what's really underneath it. Sometimes the answer is "nothing, this reader just isn't my audience." Often, though, there's a kernel worth keeping even when the specific fix doesn't feel right.