Theory
Presenting to, and assessing, peers
Beyond the formal panel, you will present your work in a seminar to your class and faculty, and take part in peer review, evaluating each other's work. Both are valuable, and both mirror real professional practice, where developers routinely present to teams and review each other's work.
This lesson covers seminars and peer review: presenting in a semi-formal setting, and giving and receiving feedback against clear criteria. Learning to evaluate others' work fairly, and to take feedback on your own gracefully, is a professional skill you will use throughout your career, in code reviews, design reviews, and team discussions.
Theory
Seminar and peer evaluation
A seminar is a presentation of your project or a topic to your class and a faculty panel, more relaxed than a final viva but still a real audience. It builds your public-speaking confidence and your ability to field questions in front of peers.
Peer review has students evaluate each other's presentations or projects against agreed criteria, for example: clarity of presentation, technical depth, presentation quality, completeness, and how well questions were answered. You both give feedback (assessing classmates fairly against the criteria) and receive it (hearing others' honest views on your work).
Using shared, clear criteria keeps peer review fair and focused, everyone is judged on the same, transparent standards, rather than on personal impressions. It makes the feedback useful and the process just.
Formula
Give feedback constructively, receive it openly
Peer review works only if feedback is handled well. When giving feedback, be constructive: specific ('the architecture slide was unclear'), kind (respectful, not harsh), and actionable (suggest an improvement). The aim is to help, not to tear down. When receiving feedback, be open: listen without getting defensive, thank the reviewer, and consider the points seriously even if they sting a little.
These are exactly the skills real teams need for code review and design review, where colleagues critique each other's work daily. Learning to give and take feedback gracefully now prepares you for that. Constructive critique, offered and received well, makes everyone's work better, which is the whole point of peer review.
Quiz
What makes peer feedback constructive and useful?
- Being harsh and personal to make the point strongly
- Being specific, kind, and actionable (pointing out a clear issue and suggesting an improvement), aimed at helping rather than tearing down
- Only ever giving vague praise with no substance
- Refusing to give any feedback at all
Show the answer
Being specific, kind, and actionable (pointing out a clear issue and suggesting an improvement), aimed at helping rather than tearing down
Constructive feedback is specific (naming a clear issue, like 'the architecture slide was unclear'), kind (respectful, not harsh), and actionable (suggesting an improvement), and it aims to help the person improve, not to tear them down. Option A (harsh and personal) demoralises and is unprofessional; feedback should critique the work, not attack the person. Option C (vague praise only) is comfortable but useless, it gives nothing to improve on. Option D (no feedback) defeats the purpose of peer review. The goal is honest, respectful, useful critique, the same skill used in professional code and design reviews, which makes everyone's work better.
Think first
Why is learning to give and receive feedback such an important professional skill?
Peer review is a class exercise. Why does it matter so much for your career? Then tap.
Show the answer
Because professional software work is deeply COLLABORATIVE and depends on continuous mutual FEEDBACK, code reviews, design reviews, retrospectives, so the ability to give and receive critique well is essential to being an effective, valued team member, and it is a skill that must be learned and practised, which peer review does. In real software teams, your work is constantly reviewed by others and you review theirs: before code is merged, colleagues review it for bugs, clarity, and quality (code review); designs are critiqued before being built (design review); and teams reflect on how they are working (retrospectives). This is not optional or occasional, it is the daily fabric of professional development, because it is how teams catch mistakes, share knowledge, maintain quality, and improve. Doing it WELL requires two skills that do not come naturally to everyone. GIVING feedback constructively, being specific, kind, and actionable, so that critique helps rather than offends, and so people stay motivated and the work genuinely improves; harsh or vague feedback poisons team relationships and helps no one. RECEIVING feedback gracefully, listening openly, not getting defensive, separating critique of your work from your self-worth, and acting on valid points; a developer who cannot take feedback becomes difficult to work with and stops growing. Both skills are hard precisely because feedback touches ego: it stings to be told your work has flaws, and it is tempting to soften critique into uselessness or to lash out. Practising in low-stakes peer review, with clear criteria and a learning purpose, is exactly how you build the maturity and habits to do it well before the stakes are your job. Employers highly value people who can review others' work helpfully and accept review humbly, because such people strengthen a team, while those who cannot create friction and stagnate. So peer review is not a mere class exercise; it is training in one of the most important collaborative skills of a software career, giving and receiving critique constructively, which underpins the quality and health of every real development team. Learn to critique and be critiqued gracefully now, and you become a stronger professional and colleague.
Summary
Key takeaways
- A seminar presents your project or topic to your class and a faculty panel, building public-speaking confidence in a semi-formal setting.
- Peer review has students evaluate each other's work against agreed criteria (clarity, technical depth, presentation quality, completeness, handling of questions).
- You both give feedback (assessing fairly against the criteria) and receive it (hearing others' views on your work).
- Shared, clear criteria keep peer review fair and focused, everyone judged on the same transparent standards.
- Give feedback constructively (specific, kind, actionable, aimed at helping); receive it openly (listen, do not get defensive, act on valid points).
- These are the exact skills real teams use in code review and design review, essential to collaborative software work.
- Memory hook: seminars build presenting; peer review builds giving and receiving constructive feedback, a core professional skill.