.   .   .
We're always looking for great talent‼️ 🚀😄 And we're passionate about driving innovation and improving lives. Join us as we help social impact organizations and enterprise customers build their web apps. Apply today!
.   .   .

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.

Recently, I found myself repeating some general “helpful feedback” which led me to list my suggestions here. There are many “How to write a Pull Request” blog posts out there. This is not intended to be a comprehensive list, but a set of simple reminders.

Read task instructions/bug descriptions a final time before submitting a Pull Request.

Image result for read again

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.

Read documentation

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

xkcd #1513

I have rejected plenty of pull requests that could have been merged had the Junior developer gotten their linters working first.

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.