Coursework Feedback
Code review at CYF
Giving effective, actionable feedback is one of the ways that we can best help our trainees learn and grow.
1. Giving Feedback
Do your code review in public directly on the trainee's Pull Request. Use all the features of GH Code review. It's part of what we are teaching. There are marking guides in many repositories to help with common responses.
Do this short training on Pull Requests to refresh yourself if you haven't worked with Github recently: https://lab.github.com/githubtraining/reviewing-pull-requests
You can find all the open PRs that have requested your review on Github
https://github.com/pulls/review-requested
Feedback Advice
Be Positive
Above all else be positive and be kind. Our trainees want to learn and want to understand. They work really hard.
You should pull out small wins from bad code and encourage them to continue and try again. Many of our trainees suffer from low confidence and a well timed comment of motivation can be all it takes to push them to success.
If in doubt, consult our key rules.
Directing to Resources
If you can tell that a trainee has been struggling with a particular area, one way that you can help is to
Acknowledge that they have struggled
Reassure them that many people struggle with such problems
Direct them to an online resource that will help them understand the problem better
Don't write long, complex explanations. It's a time sink, especially when great resources already exist.
Please note: Do not just link to documentation! Link to a tutorial or guide that explains the documentation.
If you hit upon a really effective teaching moment, please share it with the group.
Fixing Bugs
If the bug is a simple compilation or formatting error it's perfectly fine to suggest a fix to the issue. For example, an incorrect relative URL is a simple error that does not imply a deeper misunderstanding of the content and so can be safely fixed. You can suggest this change as a line edit and guide your trainee to incorporate the feedback using the GH tools.
Prompting to Ask Questions
Make every error a teaching moment, mention that you see other trainees struggling with the same concepts and that asking questions on Slack can be a way to remedy their problems.
Explaining an Obvious Mental Model Issue
When a trainee implements code in a way that seems nonsensical the root cause can often be a misconception in how they have built their mental model. If you can obviously tell from their homework what their misunderstanding is then you are encouraged to correct them.
If they seem to fundamentally misunderstand a concept then it is best to refer them back to the source material.
Formatting
It never hurts to remind the trainee of the importance of proper formatting and indentation
Quickly Giving Feedback
Visual Studio Github Plug-in
https://github.com/microsoft/vscode-pull-request-github
You can use the VSCode plugin, which allows you to make comments from directly inside VS Code and allows each comparison between Pull Requests.
Use the code review tool in GitHub
This not only gets the trainees used to using it, but also make it easier for other reviewers to know if work has been reviewed. The process is documented here at point 7.
Plagiarism
We take plagiarism seriously at Code Your Future. If you suspect a trainee has deceptively copied code please raise it directly with your Programme Manager and we will address it directly with the individual. If trainees have worked together but don't know how to explain this clearly, coach them to mob their commits, either using git-mob or GitHub Authors.
2. Grading
Grading does not work well for our model so we stopped doing it.
Different teachers grade homework at different levels, and we have many many different teachers coming in and out. Often grading falls away after initial enthusiasm, so the "data" becomes sketchy and unreliable. It also places trainees into a child role, motivated externally by reward, instead of being in charge of their own learning. We do lots of 121 code review instead of grading, and focus on building real software together that works in the world, evaluated with good unit testing.
We aim to give trainees feedback rather than grades. You should always prioritise meaningful technical mentorship and personal feedback over processes like grading. CYF is not a school. It is a community where adults come together to share skills and develop software. Give your feedback directly on GitHub and ideally line by line on actual code.
3. Mentor Responsibility
Education volunteers are responsible for a group of trainees from Intro to Digital to Employment.
They are responsible for
Code review of trainee coursework and side projects
Technical mentorship
Recording feedback on trainee progress for their assigned trainees according to the needs of the cohort
There is a standard tracker to help organise this work. Ask your Program Manager.
If you are unable
You are responsible for communicating with other education team volunteers to find someone to cover these responsibilities
If you have completed your code review and you feel able to do more, please offer your time to other volunteers to help them
If trainees haven’t completed their coursework
Please liaise with the PD team lead to follow up with that trainee
Last updated