Episode 4: Code Reviews Are Not a Formality

Jona Obrador • May 12, 2026

Most development teams run code reviews like a checklist. Does it work? Any syntax issues? No obvious problems — approve. That rhythm might feel productive, but it skips the part where real engineering actually happens.



Code reviews are not about validating code. They are about improving decisions.

Where Projects Actually Go Wrong

What's Already True Before a PR Is Opened

By the time a pull request lands in your queue, the first three stages of the development process have already played out. In Episode 1, we established that specs rarely arrive fully formed. Episode 2 showed how every timeline carries hidden trade-offs. And Episode 3 explored how much depends on what gets surfaced — and what doesn't.


That code is already built on assumptions. It reflects incomplete context, prioritization calls, and decisions no reviewer was present for.


If the review ends at "LGTM," all of those hidden choices go unchecked. That is how teams accumulate tight coupling, performance gaps, and systems that technically work but buckle under pressure. Not because engineers aren't capable — because no one challenged the thinking underneath the code.

By the time a pull request lands in your queue, the first three stages of the development process have already played out. In Episode 1, we established that specs rarely arrive fully formed. Episode 2 showed how every timeline carries hidden trade-offs. And Episode 3 explored how much depends on what gets surfaced — and what doesn't.


That code is already built on assumptions. It reflects incomplete context, prioritization calls, and decisions no reviewer was present for.

What's Already True Before a PR Is Opened

If the review ends at "LGTM," all of those hidden choices go unchecked. That is how teams accumulate tight coupling, performance gaps, and systems that technically work but buckle under pressure. Not because engineers aren't capable — because no one challenged the thinking underneath the code.

What Strong Code Reviews Actually Examine

What Strong Code Reviews Actually Examine

Working code is the minimum bar, not the finish line. Effective code reviews push beyond syntax to the structural questions that matter long-term.


Questions worth asking during any review:

  • What happens when this runs on a high-volume account?
  • Is this logic tied too tightly to a single module?
  • Are we solving today's requirement or creating tomorrow's technical debt?


Here is a practical example. Instead of "Looks good," a more useful comment might be: "This works, but since it runs on every save, have we considered the governance impact on high-volume accounts?"

Working code is the minimum bar, not the finish line. Effective code reviews push beyond syntax to the structural questions that matter long-term.



Questions worth asking during any review:

  • What happens when this runs on a high-volume account?
  • Is this logic tied too tightly to a single module?
  • Are we solving today's requirement or creating tomorrow's technical debt?

That one question can prevent a production incident and a much harder conversation later.

How to Give (and Receive) Better Code Review Feedback

The quality of a code review depends on how feedback is framed — and how it is received.

Feedback that moves the work forward:

Instead of... Try...
"Refactor this." "If we centralize this in a use case, it will be easier to maintain long-term."
"This is messy." "The logic is correct. Let's talk about clarifying the structure."
"LGTM." "This works. Have we stress-tested the edge case at scale?"

On the receiving end, this is where many engineers struggle. Code review feedback can feel personal, like a critique of the work or of the person behind it.



Strong engineers shift that framing. Code reviews are not about who is right. They are about whether the system is sound. The goal is to pressure-test decisions together, not defend them.

Why Healthy Code Reviews Have Friction

If your team's reviews are always smooth — no questions, no pushback, instant approvals — that is not a sign of efficiency. It is a signal that real review is not happening.


Healthy teams have friction in their code reviews. Not toxic friction, but thoughtful and intentional. That is where:

  • Blind spots get caught before they become incidents
  • Trade-offs get discussed instead of inherited
  • Engineering judgment gets shared across the whole team

If your team's reviews are always smooth — no questions, no pushback, instant approvals — that is not a sign of efficiency. It is a signal that real review is not happening.


Healthy teams have friction in their code reviews. Not toxic friction, but thoughtful and intentional. That is where:

  • Blind spots get caught before they become incidents
  • Trade-offs get discussed instead of inherited
  • Engineering judgment gets shared across the whole team


Review friction, done right, is how development teams grow together.

Why Healthy Code Reviews Have Friction

Review friction, done right, is how development teams grow together.

Code Reviews Reflect the Team Behind Them

The bigger principle: code reviews are a delayed design conversation. When teams treat them that way — as a space to surface assumptions, examine trade-offs, and build shared understanding — the systems they build are stronger for it.


The quality of a team's code is a direct reflection of the quality of its conversations. That is especially true in NetSuite environments, where one under-reviewed script can ripple across an entire tenant configuration.


At ATSOURCE, the developers placed come prepared for exactly this. They understand that the real engineering work happens in the review, not just in the code.


If you are building or scaling a NetSuite development team, let's talk about how to structure your development practices for quality and long-term maintainability.

Jona Obrador Senior Netsuite Developer

Meet the Author

Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.

Tags

Accelerate ERP Success with Expert Solutions

Ready to put what you've learned into practice? ATSOURCE delivers both the specialized talent and comprehensive NetSuite support you need to turn strategy into results.‍Connect with our experts today and move from planning to performance.

Floating question marks and a lightbulb above white podiums, with a purple gear on the right.

Episode 3: Engineer Communication Skills: Why Knowing Isn't Enough

By Jona Obrador • May 5, 2026
Discover why engineer communication skills matter as much as code quality—and how raising risks early keeps NetSuite projects on track.
Episode 2 promo: purple slide, “NetSuite Project Estimation: Why It’s About Risk, Not Time,” with computer illustration

Episode 2: NetSuite Project Estimation: Why It's About Risk, Not Time

By Jona Obrador • April 28, 2026
NetSuite project estimation isn't a time prediction — it's a risk assessment. Learn how strong developers surface uncertainty early and make estimates teams can actually plan around.
Purple podcast-style cover: “NetSuite Requirements: Why the Ticket Is Never the Full Story” with app icons on a podium

Episode 1: NetSuite Requirements: Why the Ticket Is Never the Full Story

By Jona Obrador • April 21, 2026
NetSuite requirements are rarely what they appear on the surface. Learn how strong developers bridge the gap between what's written and what the system actually needs.