Stop Fixing the Same Mistake Repeatedly: How to Break the Cycle of Repeating Failures

I fixed the same kind of mistake five times this month before I changed how I work

Mirza Iqbal fixed five instances of the same kind of mistake in a single month. Each fix provided temporary relief but led to zero long-term progress, revealing a cycle of coping rather than learning.

Why This Matters

Most developers rely on tests and safeguards that only reflect cases they imagined, not real-world failures they’ve experienced. This gap means repeated mistakes go uncaught, wasting time and eroding trust in safety nets, as Iqbal discovered when his green checks masked recurring issues.

Key Insights

• Green checks prove survival of imagined cases, not real-world resilience—Iqbal’s walls missed failures because they mirrored his imagination, not his scars (2026).
• Blocking legitimate work is more dangerous than missing bad work—overriding a false positive wall leads to its abandonment, causing all protections to fail (Iqbal’s experience).
• Failures fall into five categories: blocks good work, misses bad work, crashes on ugly input, destroys while helping, says yes to incomplete work—each wears a green check initially (Iqbal’s list).
• Replaying scars over testing imagination—recording actual failures as permanent checks ensures repeat mistakes are caught automatically (Iqbal’s method).

Practical Applications

• Record real failures: After patching a bug, save it as a permanent replayable test—prevents that exact failure from returning unnoticed (e.g., Iqbal’s approach).
• Avoid false positives: If a safeguard blocks legitimate work too often, it gets overridden and eventually removed—balance protection with usability to prevent system abandonment.
• Audit trust: Regularly check if your most-trusted safeguards have ever been tested by real failures—ensures they aren’t just mirrors of your imagination.

References:

• https://dev.to/mjmirza/i-fixed-the-same-kind-of-mistake-five-times-this-month-before-i-changed-how-i-work-hec