Every developer has opinions. Tools, patterns, architecture, naming, state libraries, folder structures, testing strategies. If you’ve been building software long enough, you’ve probably collected dozens of things you feel strongly about.

But here is the truth:
If you try to push all of them, you dilute your influence.
If you try to defend everything, you end up defending nothing.

The most effective developers I’ve worked with can usually articulate one core principle they will fight for. One idea they will apply pressure on. One thing they believe improves systems long term. Everything else remains flexible.

This is not just for junior developers. It applies at every stage of your career. You might earn stronger convictions over time, but the rule still holds: you only get one hill. You should be able to write it down, defend it, and refine it as you gain more experience.

Why Only One?

Because most decisions in software live in the “multiple options are fine” category.
Postgres or Redis for a job queue tracking? Fine.
Zustand or useState? Fine.
ORM or SQLC? Fine.
This folder layout or that one? Fine.

If you insist on pushing your personal favorite in every discussion, you drain the team’s time, you slow down meetings, and you become harder to work with. And most importantly, you lose credibility when something actually important comes up, because people have learned that you argue about everything.

Focusing on one principle has the opposite effect:

  • You preserve your energy for the issues that matter
  • Your teammates know you only push when there is a real reason
  • Discussions stay on track instead of spiraling into minor debates
  • Your influence builds instead of scattering across ten micro-opinions

This is a filtering mechanism. A way to decide when to lean in and when to let go.

My Hill: Data Boundaries and Contracts

Everyone’s hill will be different. Mine is data boundaries.

I care deeply about how data moves through a system. Which service owns what, where it is transformed, and what the true shape is. I want consistent models across the stack and a clear separation between external input and internal domain logic.

In practice, this means things like:

  • a shared domain package
  • well-defined data contracts
  • predictable transformation layers
  • one consistent definition of concepts like “User” or “Order”

When this clarity is missing, everything becomes harder. Bugs hide in type inconsistencies. Features take longer because no one knows which shape is the “real” one. Two parts of the system mutate the same concept independently. I have seen this go wrong enough times that I will always speak up here.

If I’m going to “die on a hill,” this is it.

Good Hills To Die On (In General)

Good hills usually meet one criterion: they influence the whole system, not just a corner of it. Some examples:

Data contracts Bad modeling causes long-term pain. Good modeling compounds benefits.

YAGNI Over-engineering slows teams down. Simplicity pays dividends.

Centralized logic (such as a single API layer) You avoid fragmentation and unpredictable drift over time.

Build vs buy instincts A well-informed decision here can save or destroy hundreds of dev hours.

These are system-shaping principles. They are worth fighting for.

What Your Hill Should Not Be

Your hill should not be a local preference, a stylistic choice, or something easily changed later.

Some examples:

React state libraries Most are fine. Consistency is more important than the specific one.

Strict testing style preferences You need tests, but obsessing over the perfect form of them helps no one.

Boilerplate-saving abstractions LLMs can write boilerplate. Clarity now beats cleverness.

Tooling preferences Your favorite tool isn’t always the right choice for the team.

These things matter, but they don’t matter enough to be the hill.

A Hill Evolves Over Time

One important part of this is that your hill should not be static. As you see more systems, work with more teams, and experience more pain points, your principle may evolve. You may discover the thing you cared about five years ago isn’t actually the lever that moves the system anymore.

A good hill is something you can defend with stories. A great hill is something you refine over years.

This Is Also a Fantastic Interview Question

One of the best ways to understand a candidate is to ask:

“What is your hill to die on?”

Their answer tells you immediately:

  • what problems they’ve lived through
  • where their engineering instincts come from
  • whether they fixate on preferences or principles
  • how they will contribute to your team’s design conversations
  • whether their convictions map to system-level thinking

Someone who says their hill is “I only use Zustand” probably lacks mileage. Someone who says “I will always argue for clear boundaries in data modeling because here is how it has burned me in the past” is giving you real signal.

This question reveals experience, maturity, judgment, and how someone thinks under pressure.

Pick One Thing. Let Everything Else Be Fine.

You will always have opinions. You will always see things you want to change. But if you push on all of them, you become noise. If you focus on one, you become signal.

Pick the one principle you believe truly matters. Defend it when it counts. Let the rest be fine.

This is how you become someone people trust, someone who uses experience wisely, and someone whose influence actually grows over time.