Picture a software engineer submitting code for peer review and revising it based on teammates' feedback. That kind of thinking is exactly what Oklahoma's grade 6 computer science standard 6.AP.PD.01 asks students to practice \u2014 and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.<\/p>\n
\nSeek and incorporate feedback from team members to refine a solution to a problem.\n\u2014 Oklahoma Academic Standards for Computer Science (February 2023)<\/em><\/p>\n<\/blockquote>\n
In plain language: Oklahoma's standard asks sixth graders to seek feedback from team members and use it to make their solution to a problem better through revision.<\/p>\n
In student-friendly terms, the learning target is: "I can seek and incorporate feedback from team members to refine a solution to a problem."<\/strong><\/p>\n
What Students Should Be Able to Do<\/h2>\n
\n
- I can give specific, constructive feedback that names what works and what to improve.<\/li>\n
- I can receive feedback without defensiveness, asking clarifying questions and evaluating suggestions fairly.<\/li>\n
- I can revise a solution to directly address feedback I received.<\/li>\n
- I can use unit vocabulary like feedback, iteration, and constructive correctly.<\/li>\n<\/ul>\n
Along the way, students pick up the working vocabulary of the topic: feedback, collaboration, iteration, refinement, perspective, constructive, implementation, consensus, prototype, revision, stakeholder, validation.<\/p>\n
Misconceptions to Watch For<\/h2>\n
These are the wrong turns students reliably take with this standard \u2014 knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).<\/p>\n
1. "Feedback is the same thing as criticism or pointing out what's wrong."<\/strong><\/p>\n
Use paragraph 4's distinction \u2014 constructive feedback also acknowledges what works well, not just what needs improvement, and focuses on specific, actionable observations rather than vague complaints.<\/p>\n
2. "Good team members implement every single piece of feedback they receive."<\/strong><\/p>\n
Reference paragraph 5 \u2014 not all feedback needs to be implemented, but all of it deserves consideration. Evaluating feedback on its merits is part of receiving it well.<\/p>\n
3. "Reaching consensus means everyone has to agree on everything."<\/strong><\/p>\n
Clarify from paragraph 8 \u2014 consensus means everyone feels heard and can support moving forward, even without complete agreement on every detail.<\/p>\n
4. "Building a rough prototype is a waste of time since it isn't the final product."<\/strong><\/p>\n
Point to paragraph 7's 'fail fast and learn quickly' idea \u2014 prototypes let teams test fundamental decisions cheaply before they become expensive to change later.<\/p>\n
Discussion Starters You Can Use Tomorrow<\/h2>\n
\n
- Why might it be harder to receive feedback on something you worked really hard on?<\/li>\n
- What's the difference between someone disagreeing with your idea and someone criticizing you personally?<\/li>\n
- How might a team handle a situation where two members give completely opposite feedback?<\/li>\n<\/ul>\n
Bringing It Home<\/h2>\n
This topic is a natural one for families. One ten-minute activity to try: Together, pick something you've made or written and ask a family member for specific feedback on it. Talk about which suggestions you'd actually use and why, and which you'd skip.<\/p>\n
Where This Leads<\/h2>\n
Students who can seek and incorporate feedback from team members to refine a solution to a problem are building skills used every day in software engineering, UX research, technical writing\/editing, software testing\/QA, and computer science education.<\/p>\n\n
See the Unit in Action<\/h2>\n\n