The Junior Dev Checklist: 5 Things to Fix Before Submitting Your PR

The most nerve-wracking moment for a Junior Developer isn’t writing the code—it’s clicking the “Create Pull Request” button. follow this guide on Junior Developer Checklist.

You know what comes next. The Senior Developer is going to look at it. You are terrified they will find a massive logic hole, or worse, they will leave 50 comments about things you “should have known.”

As a Senior Dev who has reviewed thousands of PRs, I’ll let you in on a secret: I don’t mind logic errors. Logic is hard. We can discuss logic.

What annoys me (and every other Senior) is sloppiness.

If your PR is full of bad indentation, commented-out code, and inconsistencies, it tells me you didn’t read your own work. If you didn’t read it, why should I?

Here is a 5-step checklist to run through before you submit. If you do these five things, your PRs will be merged faster, and you will look like a pro.

1. The “Format” Sanity Check

Nothing screams “I rushed this” louder than bad indentation.

• Did you mix tabs and spaces?
• Is that } brace on the same line as the code?
• Are your method arguments aligned?

The Fix: Don’t trust your eyes. Trust a robot. Copy your changed files into the Toolshref Java Formatter. Hit “Format.” If the text moves, your code was messy. Paste the clean version back.

What to check:

• Proper indentation in every block
• Consistent use of spaces and line breaks
• No trailing spaces or abandoned debug lines
• Imports are properly organized
• No commented-out code lingering from experiments
• No unnecessary whitespace at the bottom

Why this matters:

Bad formatting sends a message:
You didn’t review your own work before asking someone else to review it.

Example:

If a reviewer opens your file and sees a mix of tabs and spaces, inconsistent braces, and long lines stretching across the screen, you’ve already lost credibility before they even look at your logic.

Clean formatting makes even average code easier to follow.

2. Remove “Dead Code” (The Graveyard)

I often see PRs containing blocks of code that are commented out:

// int oldCalculation = x * y; // DON'T DO THIS
int newCalculation = x + y;

You might think, “I’ll keep it there just in case I need to revert.” No. That is what Git is for. Git remembers the old history. Your codebase is not a museum.

The Fix: Delete all commented-out code blocks. If it’s not running, it shouldn’t be there.

3. The “Print Stack Trace” Sin

When you were debugging the feature, you probably added: System.out.println("HERE 1"); or e.printStackTrace();

If you leave these in, they clutter the server logs. In a production environment, e.printStackTrace() is actually dangerous because it can expose internal system details if an error occurs.

The Fix: Search your file for “System.out” and delete it. Replace e.printStackTrace() with a proper Logger like log.error("Error processing user", e);.

4. Consistent Brace Style

Look at your project’s existing files. Do they do this?

if (condition) {

Or this?

if (condition)
{

If the whole project uses Style A, and you submit Style B, you are breaking consistency. It makes the file hard to read.

The Fix: Use the “Brace Style” toggle in our Formatter Tool (Collapsed vs. Expanded) to match the existing project style perfectly.

5. Remove Unused Imports

Did you import java.util.List but then switch to using an Array? Leaving unused imports at the top of the file creates “noise.” It confuses other developers who might wonder, “Why is this class importing the SQL library? It doesn’t do any database work.”

The Fix: Most IDEs can do this automatically (Ctrl+Alt+O in IntelliJ), but always double-check the top of your file before saving.

Bonus Tip that I use

Test Your Changes Like Someone Trying to Break Them

“Works on my machine” is the fastest way to look inexperienced.

Seniors don’t test a feature only in its happy path. They try to break it. They try what users will try. They purposely trigger edge cases.

What to test:

• The ideal user flow
• The worst user flow
• Wrong input
• Blank input
• Missing data
• Extreme cases
• Large values
• Null conditions
• Browser differences (if applicable)
• Slow network (if applicable)

Why this matters:

Reviewers expect you to test your own work before asking them to review it. If they catch something obvious — a crash, a missing null-check, an unhandled scenario — they will assume you didn’t test anything.

Example:

If your feature fails when numbers are negative, or when a user submits an empty form, or when the server responds slowly, reviewers will instantly question the quality of your testing habits.

Don’t give them a reason to doubt your thoroughness.

Summary | Junior Developer Checklist

Reviewing code takes mental energy. When I see a PR that is perfectly formatted, has no dead code, and follows the style guide, I start the review with a positive mindset. I assume the logic is likely good because the presentation is good.

Don’t let the “easy stuff” be the reason your PR gets blocked. Run through this checklist, use the tools available to you, and submit with confidence.

FAQ | Junior Developer Checklist