Learners in our Community often share their projects. But they don’t review other people’s projects as often.
Today, I want to urge y’all to review other people’s projects more often to keep our Community healthy and strong.
These project reviews are very valuable for our Community. They create value for everyone involved:
Value for project sharers: It often takes courage to complete a project and, even more so, to share it with the Community. Getting good feedback makes it worth it. We know this.
Value for project reviewers: What’s not so apparent is that you get value by reviewing projects too. Every project is unique. You learn something new from every project. Also, it’s just fun to look at how your peers approached the project that you just completed.
I have discovered that most of our Community has a couple of hesitations against reviewing other people’s projects:
- Time-consuming — there appears to be a mental barrier that the task of reviewing a project will take a long time, maybe even hours.
- Imposter Syndrome — Sometimes, learners feel that they don’t have adequate knowledge to review other people’s projects.
If you are one of those learners, I want to debunk these hesitations and provide you with some tips for reviewing other people’s projects effortlessly.
You can find the latest Guided Projects shared by your peers in the Projects category.
It’s easy to leave a useful feedback on any of those projects in just 15–30 minutes. Here’s how:
Pick some aspects of the project that you feel comfortable with and give feedback on just those aspects.
There 4 general areas that one can dive into based on their level of familiarity with the project in particular and programming itself, in general:
Students want to put these projects on their resume. Therefore, it should be accessible to both technical and non-technical folks. Is the project resume-ready?
- Is it easy to follow what the author is doing in the project overall?
- Is the project divided into neat sections with headings?
- Are there enough Markdown cells to complement the code? Do they do a good job at explaining it?
- Are the graphs and tables helpful?
- Is the output of code readable?
- How do you feel about the storytelling in the project?
Without diving into the depths of the code, you can comment on the
- use of good, descriptive variable names
- use of functions in the code to reduce redundancy
- presence/absence of documentation for functions
- consistency of style
If you are comfortable diving into the code, it can be helpful to point out
- if the code has bugs
- if the code is efficient
- how some part can be made more efficient
- if the analysis actually answers the question that the author intended to answer
Apart from these, here are some silly mistakes that learners often make:
- Unrendered images
- Commented-out code left in the project
- Forgetting to re-run the whole notebook
- Broken links that don’t open
There are 19 bullets above; your feedback will be appreciated if you can address even few of these bullets.
Be clear about the effort you’ve put in while reviewing. If you haven’t dived too deep into their projects, say something like “After quickly going through your project…”, “Taking a quick glance at your project…”.
If you haven’t dived into the code mention “Without diving deep into your code, I want to say…”.
It is important to keep a tone of encouragement. It’s easy to do so when you find the project outstanding. In other cases, you should appreciate the effort of completing the project and be clear in mentioning the ways of improvement.
Let me know if you have any questions by replying below.