A Development Team Stalled by “Where to Break Lines in Code” ── It Might Not Be a “Trivial Issue”

“We’re in a big dispute over which line breaks make the code easier to read, and the feature we were supposed to release still isn’t out.”

── This was an offhand comment a leader made at the end of a meeting in a certain development team.

When people on the management or executive side hear this, they may feel an urge to say:

“Stop fighting over such tiny details and just ship it already…!”

We’ve seen many similar situations over the years.

Because both “code readability and maintainability” and “moving the product forward” matter, teams sometimes get stuck, unable to strike a good balance.
“If we don’t ship now, other projects will be affected” vs. “If we ship now, we’ll break consistency” ── this kind of tug-of-war happens all the time in real teams.

In this article, starting from this vague frustration:
Why does “a discussion about line breaks” become such a big issue that it can hold back the product?
We’d like to sort this out together, aligning the perspectives of both the team and management.

What was actually happening

In a certain development team, there was a feature scheduled for release last month.
Implementation was complete, behavior was fine. QA was done.

…But then, something unexpected happened during code review.

On the Pull Request, opinions clashed over line breaks, indentation, and coding style.
Comments like “We should standardize this style as a team” and “This way is easier to read”
sparked increasingly heated debate over the details.

That in itself shouldn’t be a bad thing ──
but in the end, the discussion dragged on, and the team decided, “We can’t merge this yet.”
And the release was postponed.

The people involved, and their roles and thoughts

This isn’t just a simple technical clash.
There are people in different roles on the team, each with their own “non‑negotiables” and “view of the situation.”

Let’s take a closer look at them.

👨‍💻 Engineer A (the person who implemented the feature)

• Role
  • The person who actually implemented the feature and got it working.
• Perspective and thoughts
  • They feel both attachment and “responsibility” toward the code in front of them.
  • They worry that “if we ship it as is, it might be a pain to fix later.”
  • At the same time, they also realistically think, “It works, so I want to ship it first.”
  • They’re torn because they care about the team.

“Is it right to ship now, or should we push a bit more… I see both sides, and that’s why it’s hard.”

🧑‍🔬 Engineer B (the reviewer)

• Role
  • Reviews code written by others and points out areas for improvement.
• Perspective and thoughts
  • They genuinely want to improve the development experience for the whole team.
  • They’re aware that “I might be the one maintaining this code in the future.”
  • If they leave the rules vague at this point, “exceptions” may pile up and become technical debt for the team.
  • That’s why they feel the need to draw a line here.

“It may look trivial, but I’m convinced that ‘if we compromise here, we’ll suffer more later.’”

🧑‍💼 Engineering Manager (responsible for leading the dev team)

• Role
  • Coordinates so engineers can work smoothly and maximizes the team’s output.
• Perspective and thoughts
  • They fully understand how both sides feel.
  • Precisely because they think “neither side is wrong,” the decision is hard.
  • They don’t want to damage trust within the team. But if they delay the decision now, it might be a loss for the business. They feel responsible to both.

“Should I prioritize the release? Or the team’s consensus? I struggle with this every time.”

📋 Product Manager (PM)

• Role
  • Oversees everything from product planning to release, responsible for delivering value to users and the business.
• Perspective and thoughts
  • They may not be familiar with technical details, but they’re very sensitive to the timing of delivering product value.
  • They feel anxious because they don’t understand “why we can’t ship when it looks done.”
  • They also feel a gap between expectations from the business side and the current situation.

“Isn’t it already in a state where we can ship? The ‘reason we can’t release’ is hard to see…”

👔 Executive (CEO)

• Role
  • Responsible for the overall direction and results of the business. They must make decisions directly tied to release timing and competitive strategy.
• Perspective and thoughts
  • In day‑to‑day management decisions, “Can we release or not?” carries huge weight.
  • At the same time, they feel stressed because it’s hard to see “what exactly is causing the delay.”
  • They understand technical concerns, but they speak from the perspective of “What should be prioritized right now?”

“Why is ‘where to break a line’ being prioritized over beating competitors to market or this week’s campaign initiatives…?”

Do people really argue over “line breaks”?

Some of you may be thinking, “Come on, are line breaks really that big a deal?”

But in real teams, these kinds of “small differences in how you write code” can surprisingly often become a spark for debate.

For example, code like this ──

// A’s style (submitted for review)
sendEmail(
  user.email,
  'Notifications',
  generateEmailContent(user.name, product.info),
  true
);

// B’s suggested style
sendEmail(
  user.email,
  'Notifications',
  generateEmailContent(
    user.name,
    product.info
  ),
  true
);

Or a case like this:

// A’s PR (thought it was short enough for one line)
const payload = { userId, isActive, permissions };

// B’s preference (requested change in a review comment)
const payload = {
  userId,
  isActive,
  permissions
};

To those thinking, “Either way is fine, isn’t it?”

In fact, many people feel that way at these points. But those “tiny differences,” when they pile up, can sometimes have surprisingly large effects.
And when the discussion turns to which is more readable, or whether the team should standardize on one style,
these can become “non‑negotiable points” for engineers.

If decisions like these are clearly defined in a style guide, that’s great.
But when the rules are vague, the debate starts from scratch each time, and reaching agreement becomes difficult.

In this way, small differences end up stopping the team’s work before anyone realizes it ──
and that’s part of the background behind situations like the one we’re looking at here.

This might not really be about “line breaks”

At first glance, it looks like a small issue of “where to break a line.”
But we feel there are more fundamental, structural issues lurking behind it.

Technical correctness vs. product progress

• As engineers, we want to “write clean code for the future.”
• But from the product side, “delivering to users now” sometimes takes priority.

Even if both sides are on the same team, if their value axes differ, the meaning of “being right” changes.

Without a foundation for agreement, trivial decisions become brakes

• When “who decides and how” is unclear, rather than “which is correct,” discussions tend to go in circles.
• Without a team style guide or clear boundaries of discretion, you end up defining the points of contention from scratch on the spot.

Common similar stories

• “We’re already using Prettier, so why are we debating that setting now?”
• “I want to change this for consistency, but delaying the release by a week for that is…”
• “I’m worried this might become technical debt, so I want to hold off.”
• “I feel like we’re nitpicking so much in reviews that we’re losing sight of what matters.”

Some of you may be thinking, “Yeah, that’s happened in our team too.”
This problem is far from rare, and because each role has its own kind of correctness, it’s not a simple issue.

So what should we think and do in situations like this?
Let’s keep going and look at “hypotheses about the causes” and “practical measures teams can take.”

Why do release schedules get blocked by line‑break debates?

By now, some readers may be wondering:

“Isn’t this just because you ‘haven’t set any rules’?”

That’s certainly part of it.
But in our experience, there are often more complex overlapping factors.

In this section, we’ll dig into a few hypotheses about why these “seemingly trivial debates” can hold a team back.

Hypothesis 1: There are no rules, so you have to decide ad hoc every time

This might be the most common pattern.

• No style guide or internal team rules
• Decisions like “Which way in this case?” are left to ad hoc discussion each time
• And this repeats with every review

The real purpose of code review should be essential checks like design and responsibility boundaries, and preventing unexpected behavior.
But if energy is consumed by debates over “surface‑level style,” it becomes harder to get the full value out of reviews.

Hypothesis 2: “Who decides?” is undefined

For example, when it’s unclear “who has the final say on this kind of style,” discussions can stall without resolution.

• The developer raises points they care about
• The reviewer offers a different view
• But no one can say, “Let’s do it this way”

As a result, the only option left is “everyone talks until they’re satisfied.”
This means consensus building within the team takes more time and effort than it should.

Hypothesis 3: Anxiety that “if we don’t decide now, we’ll suffer more later”

Some implementers and reviewers strongly feel:

• “If we proceed like this, we’ll have the same debate again.”
• “If we don’t lock down the rules now, this will become technical debt.”

This is a responsible attitude and a very important perspective for the team.

But the result can be a situation where reaching agreement now takes priority over releasing, and
the short‑term goal (i.e., releasing the feature) gets pushed back.

Hypothesis 4: The “review culture” has become a “ritual” rather than a “means to an end”

If reviews are treated like a mere rite of passage, excessive interference in details becomes more likely.

• “I’ll point it out because it caught my eye.”
• “I pointed this out before, so I’ll say it again.”
• “If I don’t point things out, it’ll look like I’m slacking.”

Originally, reviews should be a place to improve product quality, learn from each other, and build trust.
But if that purpose gradually fades and the atmosphere becomes “reviews = pointing out lots of things,”
the goal of discussion can shift from “improving” to “correcting.”

To summarize a bit…

In most cases, several of the hypotheses above overlap rather than just one.

Of course, none of this comes from bad intentions.
If anything, it all stems from the desire to “make things better” and “do things properly.”
No one is trying to blame anyone; it’s just a case of “good intentions missing each other.”

But if those intentions remain slightly misaligned and never quite mesh,
before you know it, the habit of the team stopping itself can become normalized.

Solutions to keep the team from stalling

We’ve looked at several hypotheses for “why teams can stall over something as trivial as line breaks.”

Next, we’ll introduce some response patterns we’ve actually seen work in practice to answer the question:
“So how can we keep moving forward in these kinds of debates?”

None of these are silver bullets, but they can work well depending on the situation, so read them as “possible approaches.”

Establish a style guide

This means documenting shared team rules about how to write code.

By preparing “agreed‑upon rules” for things like “we don’t need to debate this anymore,” you can avoid starting from zero every time.

• Break lines if an object has 3 or more properties
• When function calls are nested, break arguments onto separate lines
• Break JSX props when a line exceeds 80 characters

That said, if you try to “create a perfect guide from the start,” you’ll get stuck, so it’s better to start small with whatever bothers you most and build from there.

Enforce Prettier and ESLint in CI

Share formatter and linter settings across the team and have formatting and detection run automatically.

By letting “tools” enforce rules instead of “people,”
the review process shifts from a forum for opinions to a forum for checking facts.

• It becomes “fix it because CI fails,” not “fix it because someone pointed it out.”
• It reduces the risk of style comments straining relationships.

Clarify the purpose and depth of reviews

Align as a team on “what reviews are meant to check.”

For example:

• Keep style comments as comments only, but still Approve
• Thoroughly review structure and design‑related parts
• Foster a culture of spinning off concerns into separate issues

With such operational rules, it becomes easier to decide “Should this block the PR or not?”

Decide decision‑makers in advance

A simple mechanism: if “who has the final say on this” is clear, discussions are less likely to go off track.

For example:

• The frontend lead has the final say on style
• Certain files are under the discretion of the implementer
• When team rules are ambiguous, the PM decides based on priority

If the way decisions are made is acceptable to everyone, the points where discussions can stall become clearer.

Foster a “ship first” culture

This is more of a cultural topic, but one approach is to cultivate a team attitude of
“ship once it’s good enough, rather than perfecting everything before release.”

Of course, code quality is important.
But if the team can distinguish priorities like “shipping now matters more” and “we’ll log style debates as issues and handle them later,”
then “keep moving instead of stopping” becomes a viable option.

Summary

Instead of blaming the fact that you stalled, build a “structure that makes stalling less likely.”

The solutions we’ve discussed aren’t “the one right answer”; they should be adapted to each team and project.

What matters is not saying “I can’t believe we’re fighting over line breaks…”
but rather asking:

Why did the team grind to a halt over something so trivial?

It may be important to reframe that question structurally and look for ways to move forward.

Five small improvements you can start right away

By now, some of you may be thinking:

• “I get that it’s important, but doing everything at once seems impossible…”
• “So what can we actually do in our current situation?”

Changing systems and culture takes more energy than you’d think.
That’s why we believe it’s realistic to start with “small but effective” steps.

Here are some actions that we’ve found to be both helpful and easy to try.

Briefly review past PRs or Slack threads where debates flared up

This is a slightly unusual but recommended action.

“Didn’t we have a bit of a fight over this before…?”
Ever have that thought pop into your head?

If you trace Slack threads or GitHub PR comments,
you’ll see “what topics caused work to stall” and
“how you eventually found a compromise.”

• You might notice “similar patterns kept repeating.”
• You might discover decision criteria like “this is why we moved forward that time.”

📝 Even a light summary like this is fine:

### Summary of review / debate examples

- 2023/11/04: [PR #456 About if‑statement style inside useEffect](https://github.com/...)
- 2023/12/18: [Slack discussion: How do we order props?](https://slack.com/...)
- 2024/01/05: [PR #789 Indent width 2 or 4](https://github.com/...)

*Rather than which side was right, the fact that “this topic came up back then” is what’s useful.*

By keeping a small record like this:

• New members are less likely to stumble over the same issues.
• You may realize, “Maybe it’s time to formalize a rule for this.”
• The team’s decision‑making criteria gradually get articulated.

These small changes add up over time.

Have the team review Prettier / ESLint settings once

Sometimes just “lightly checking whether the tool settings are right” can drastically reduce style comments in reviews.

• Team members have slightly different Prettier configs
• Some people don’t have “format on save” enabled in VS Code
• ESLint rules are left in a half‑configured state

These “configuration mismatches” can cause style inconsistencies and become unnecessary seeds of debate.

Try an approach of “Approve the review, but leave comments for concerns”

This is an easy, low‑stress practice to adopt.

• “I’m concerned about this, but not enough to block the PR.”
• “A comment is enough; it doesn’t need to be fixed right now.”

In such cases, you can Approve and move forward, then later collect those points into an issue.
This lowers the tension around “Does this block the review or not?” while still preserving attention to quality.

Casually chat as a team about “review fatigue”

Bringing up topics like this in a regular meeting or on Slack can be effective:

“Have you ever felt stuck during a review?”
“Have you recently felt like things were getting a bit too nitpicky?”

By talking in a casual setting rather than a heavy one, people can feel “It’s not just me.”
From there, natural moves like “Should we make a small rule?” or “Let’s decide who to consult first” can emerge.

Turn concerns into issues and create a “we’ll think this through later” bucket

When something feels off during review but you’re unsure whether to block the PR now…
simply “turning it into an issue to sort out later” gives you the option to keep moving without stopping for debate.

This is also useful as part of traffic‑controlling tasks by separating “current work” from “future improvements.”

In closing: Toward a team that doesn’t stall

Let’s look for small tweaks that help us keep moving.

None of these are big transformations, but we believe that small adjustments like these, accumulated over time, bring you closer to being a “team that doesn’t stall.”

You won’t get perfect consensus or optimal settings overnight.
But if you keep taking small steps that feel like “We could try this” or “This seems doable,” your team’s ability to “keep moving” will change.

We also support building these kinds of “hard‑to‑stall teams.”

Code reviews, style guides, process improvements ──
we help untangle the “invisible friction” that lies between technology and team operations.

For example:

• Designing team decision‑making and consensus rules
• Supporting improvements to review culture and workflows
• Helping align and build consensus with executives
• Supporting the introduction and configuration of formatters / linters
• Supporting the introduction and use of AI‑based code review (to reduce review load and provide a third‑party perspective)

Because we come in as an external third party, we can:

• Voice and translate things that are hard for insiders to say
• Take a bird’s‑eye view of the overall structure without siding with any one role
• Turn small conflicts into “forward momentum” for the team

From that position, we support team dialogue and consensus building.

“We keep getting stuck on the same things.”
“We want to move forward, but we can’t because we can’t reach agreement.”

In times like that, it might be worth considering getting help from a third party. If you’re interested, feel free to reach out.