DEV Community

Cover image for Deleting the “Nice” Anti-Pattern: A Personal Systems Refactor
Khali Sollis
Khali Sollis

Posted on Edited on

Deleting the “Nice” Anti-Pattern: A Personal Systems Refactor

How I removed a legacy behavior that optimized for likability—and paid for it with self-respect.

Context

I recently ran an audit on a behavioral pattern I had been running for years:

If (someone needs something)
→ respond immediately
→ say yes
→ be helpful

I thought this was a virtue.

In practice, it behaved like an anti-pattern:

It scaled poorly
It created hidden costs
It trained other people’s expectations in the wrong direction

So I treated it like deprecated code and started a refactor.

The Bug: Over-Availability as a Default State

The core issue wasn’t kindness.

It was this assumption:

My value = my availability

That assumption created predictable side effects:

No rate limiting on my time or energy
No validation of incoming requests
No distinction between urgent vs. convenient

Everything got processed.

Even when it shouldn’t have.

The Hidden Cost Model

  1. Availability Tax

Every time I defaulted to “yes,” I paid in:

focus
energy
time I didn’t get back

The return?

Sometimes gratitude.
Occasional acknowledgment.

Nothing that actually replenished the system.

  1. Emotional Subsidy

By stepping in too quickly, I removed friction from other people’s systems.

Which meant:

they didn’t need to solve their own problems
they didn’t need to improve
they didn’t experience consequences

I wasn’t helping.

I was preventing upgrades.

  1. Compounding Drift

Over time, this created:

External reliability ↑
Internal alignment ↓

From the outside, I looked dependable.

Internally, I was offloading myself.

Root Cause

This pattern wasn’t random. It was trained.

Being “nice” = being valuable

So I optimized for:

responsiveness
agreeableness
low friction

At the cost of:

boundaries
priorities
self-respect
The Refactor

I didn’t try to “feel different.”

I changed the rules of the system.

  1. Add a Boundary Layer Incoming request → evaluate → optional response

Not:

Incoming request → immediate compliance

Practical change:

I say no without over-explaining

  1. Introduce Pattern Recognition

I stopped treating repeated behavior as isolated events.

If (pattern detected)
→ stop granting access

Practical change:

No more “one more chance” when the data is clear

  1. Implement Rate Limiting

Not everything deserves an immediate response.

Response time ≠ self-worth

Practical change:

I don’t reply instantly just to be liked
Reframing “Kindness”

This was the critical shift.

Old model:

Kindness = availability + accommodation

New model:

Kindness = integrity + choice

And one hard truth:

The people who benefited from my “niceness” called it kindness.
I call it access they didn’t deserve.

What Happened After

When I removed default access:

Some relationships broke
Some dynamics disappeared
Some people pushed back

But:

My energy stabilized
My decisions got cleaner
My time started reflecting my priorities

The system didn’t fail.

Only the parts depending on bad logic did.

Takeaway

This isn’t about becoming cold or unhelpful.

It’s about not running outdated code that trades self-respect for approval.

If your default is always “yes,” you’re not being kind.

You’re running an unbounded process with no resource protection.

Status
Self-Erasure Protocol: deprecated
New system: in production
Rollback: not planned

Top comments (8)

Collapse
 
patjo profile image
Pat Johansen •

I really enjoyed the refactor framing here, especially "My value = my availability" as the root bug. It names something a lot of people run on without ever auditing it. The Emotional Subsidy point stood out most to me, because it reframes over-helping as removing other people's chances to solve their own problems, not as generosity. I also appreciated that you distinguished kindness as "integrity + choice" from kindness as accommodation, and that you were honest that some relationships broke in the process. Thank you for a piece that makes boundaries feel like maintenance rather than coldness.

Collapse
 
thesister profile image
Debbie Sollis •

WOW!! >>> "This isn’t about becoming cold or unhelpful.

It’s about not running outdated code that trades self-respect for approval.

If your default is always “yes,” you’re not being kind.

You’re running an unbounded process with no resource protection"

Collapse
 
anne_jacobs_ac166227aa92b profile image
anne jacobs •

really loved reading this, thank you for sharing

Collapse
 
cj_e49fbe4085948741f2f23d profile image
CJ •

Loved this a whole lot, thank you for sharing!

Collapse
 
kira_m_b9e617f21ee9b4fbe profile image
Jane Jones •

This is such a sharp way to frame the difference between kindness and over-availability. The idea that “my value = my availability” can quietly turn helpfulness into self-erasure, especially when responsiveness becomes an automatic reflex rather than a conscious choice. I especially liked the distinction between kindness as accommodation and kindness as integrity plus choice. The “boundary layer” and “rate limiting” metaphors make the behavioral shift remarkably concrete. Sometimes the most important refactor is realizing that protecting your time and energy isn’t a failure of generosity—it’s an upgrade in self-respect.

Collapse
 
n_c_e4a8149b59e51d8be77 profile image
N. C. •

This is such a sharp and relatable reframing of “being nice.” The highlights that stood out most were the idea of availability tax, emotional subsidy, and the shift from treating every request as urgent to adding a boundary layer. “Response time ≠ self-worth” is especially powerful—it captures how easily responsiveness can become tied to validation. I also liked the distinction between kindness as availability and kindness as integrity + choice. The systems/refactoring language makes the whole concept feel practical rather than abstract, and the reminder that protecting your time and energy isn’t becoming cold—it’s removing outdated logic—is a takeaway that really sticks.

Collapse
 
usernameinvalid profile image
Larry Z. •

• “My value = my availability” feels like the real root bug. The problem isn't kindness itself; it's confusing constant access with personal worth.

• The “availability tax” is a useful way to think about boundaries. Time, attention, and emotional energy are resources, and repeatedly spending them without intention creates a cost even when the behavior looks generous from the outside.

• I especially liked the idea of “emotional subsidy.” When we constantly solve problems for other people, we can unintentionally prevent them from developing their own capacity. Helping isn't always the same as removing every obstacle.

• “Response time ≠ self-worth” is a simple but powerful reframe. Not responding immediately doesn't mean you care less. It means you're choosing when and how to engage.

• The distinction between kindness as availability versus kindness as integrity and choice is probably the most important shift in the piece. A boundary doesn't make generosity disappear; it makes generosity intentional.

• The “pattern recognition” piece is equally important. One isolated request may be reasonable. Repeated demands that consistently violate your priorities reveal a pattern that deserves a different response.

What I appreciate most is that the goal isn't to become less caring. It's to stop making self-erasure the price of being perceived as a good person.

The closing idea lands well: sometimes the system doesn't fail when you establish boundaries—the parts of the system that depended on unlimited access simply stop working.

“Self-Erasure Protocol: deprecated” is a pretty great status update.

Collapse
 
mona_d_4222dda374567263b profile image
Mona D. •

The "emotional subsidy" point is the strongest idea here. Framing constant availability as something that removes friction from other people's systems, so they never have to solve their own problems, shows why over-helping can be a disservice and not just a cost to you. It also makes the case for boundaries in terms that don't require calling anyone selfish.

I also liked the shift from "kindness = availability" to "kindness = integrity + choice." A yes only means something if a no was possible, and that's a useful test for anyone who suspects their helpfulness has become a reflex.

One nuance I'd add: the line about people who benefited from your niceness getting "access they didn't deserve" is true of some dynamics, but it may be too broad to apply to everyone. Some people simply never knew your limits because you never showed them. A boundary often works best when the first version is a clear, low-drama no, and the pattern-based cutoff is reserved for people who ignore it. That keeps the refactor from hardening into treating everyone as an exploiter, which is its own kind of bug.

The "rate limiting" idea is a practical one worth stealing: not answering instantly is a small, low-stakes way to practice that response time isn't self-worth.

Thanks for the honest write-up.