D
D
Documentation
Search…
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

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
  1. 1.
    Acknowledge that they have struggled
  2. 2.
    Reassure them that many people struggle with such problems
  3. 3.
    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
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.
  • If the work is good and doesn't require changes, select "Approve"
  • If the work needs work, select "Request changes"
  • If you've done a review, but don't have time to complete it, but the comments are valuable, select comment.
You will then be able to filter the pull request list by what needs approving.
​

Labelling the Pull Request

When you have completed your review, set the label as reviewed.
If the trainee has not completed the mandatory work leave it as to-review but add the label not completed.

Suspicion of 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.

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.

3. Mentor Responsibility

Education volunteers are responsible for a group of trainees from Intro to Digital to Post Graduation
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
Please ask your Programme Managers for the best place to record this information as it will vary from class to class.
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