Reviewing a junior developer’s first pull requests can be very revealing. You can learn what details you may not have explained. You can learn where the developer’s skills need improvement or are stronger than you may have expected
Read task instructions/bug descriptions a final time before submitting a Pull Request.
This may seem simple, but any developer can get lost in the weeds and “jump the gun” when submitting a pull request.
A developer can get excited about solving a problem; then submit a PR without realizing their solution did not completely solve the issue.
A final read thru can save you from potential embarrassment.
In a similar vein, if you’re asked to utilize a plugin, package or framework you should read its documentation.
For example, I have assigned tasks with instructions to use Bootstrap’s CSS classes. The assignee will then stop and ask me Why isn’t this working? in reference to a CSS class that doesn’t exist in Bootstrap.
If documentation had simply been read, we would have saved time and energy.
Make sure your
linters are working and read the style guide
I have rejected plenty of pull requests that could have been merged had the Junior developer gotten their
At Chiedo Labs we primarily use VS Code. Below are some helpful linter plugins you can utilize in your VS Code setup:
Check all appropriate browsers/devices
Another avoidable reason to reject a pull request is when a developer fails to check changes on multiple screen sizes. Their desktop styles look great but on smaller screens, it turns to a wonky mess
Similarly, make sure tests pass and the code builds correctly.
I hope you found these brief and helpful. Happy Coding.