Mastering Code Reviews | Article 2: Context First — Why I Read the Ticket and the POM Before the Code

If you open a Pull Request and immediately start looking at the .java files, you’re doing it wrong. You are looking at the “How” before you understand the “Why.”
I’ve seen seniors approve beautiful, perfectly tested code that solved a problem the business didn’t actually have. That’s a massive waste of time and money.
Here is my personal 5-minute ritual for starting any review. I don’t look at a single line of logic until these two things are checked.

The “Problem” Check (The Ticket)

I always open the Jira or Linear ticket first. I’m looking for one thing: What is the actual pain point?
If the ticket says “Fix slow checkout” and the PR is refactoring the “User Profile” service, I stop right there. I don’t care how clean the refactor is. I’ll leave one comment: “How does this speed up the checkout process?”
The Lesson: If you don’t know the problem, you can’t judge the solution. Don’t let a developer “sneak in” a massive refactor under the guise of a small bug fix unless the team agreed to it.

The “Dependency” Check (The pom.xml)

In a Java project, the pom.xml (or build.gradle) tells me more about the risk of a PR than the Java code does. Before I look at the logic, I look at the dependencies.
I ask myself:
Did they add a new library? If they added a 5MB library just to parse one JSON string, that’s a “No.” We have Jackson for that.
Is this a version bump? Did they sneak in a Spring Boot or Hibernate upgrade? That needs its own testing cycle; it shouldn’t be hidden in a feature PR.
Is this a “Shadow” Dependency? Are we pulling in something that has security vulnerabilities (CVEs)?

The “Scope” Check (The File List)

I look at the list of changed files. If a PR is supposed to be a “Simple UI fix” but I see changes in the DatabaseRepository or the SecurityConfig, my alarm bells go off.
The “Senior” Question: “Why is this change touching so many unrelated areas?” This usually means the code is tightly coupled, or the developer is “scoping out”—changing things they shouldn’t be touching.

Why this saves your life

By doing this 5-minute triage, I catch the “Architectural” mistakes before I waste 30 minutes reading the logic.

• If the intent is wrong, I reject it immediately.
• If the dependencies are dangerous, I flag it immediately.

Only once I’m satisfied that the PR is solving the right problem with the right tools do I finally click on the .java files.

The Bottom Line

Don’t be a line-by-line reader. Be a system thinker. Spend the first 5 minutes confirming that the PR actually should exist before you worry about how it’s written.

In the next article, we’ll finally dive into the code. I’ll show you how I trace Data and Stateto find those “invisible” Java bugs that unit tests always seem to miss.