I Stopped Writing Clean Code — And My Productivity Doubled

Why “Clean Code” Can Backfire

We’re told that clean code is the goal: small functions, no duplication, perfect abstractions. In practice, chasing that ideal before you have a working feature leads to over-engineering, endless refactors, and delayed releases. The best code is often the code that ships and then evolves with real usage.

Example: you need to fetch active users and send a welcome email. The “clean” approach might look like this—abstract, generic, built for a future you don’t have yet:

// Over-engineered before the feature even works
interface IUserRepository { findActive(): Promise<User[]>; }
interface IEmailService { sendWelcome(user: User): Promise<void>; }
class WelcomeFlow {
  constructor(
    private repo: IUserRepository,
    private email: IEmailService
  ) {}
  async run() { /* ... dependency injection, interfaces, 3 files */ }
}

Or you could ship something that works in one place, then extract interfaces when you actually have a second implementation. Ship first.

// Good enough to ship and iterate
async function sendWelcomeToNewUsers() {
  const users = await db.query('SELECT * FROM users WHERE status = ?', ['active']);
  for (const user of users) {
    await sendEmail(user.email, 'Welcome!', getWelcomeBody(user));
  }
}

Four Shifts That Doubled My Output

When to Refactor (and When Not To)

Refactor when you’re about to add a second use case that would duplicate logic, when a function has become too long to reason about, or when onboarding someone and the code is confusing. Don’t refactor “because it could be cleaner”—refactor when the mess is actually costing you time.

• Do refactor: When you’re touching the same area for the third time, when tests are hard to write, or when a new teammate is lost.
• Don’t refactor: Before the feature works, for hypothetical future requirements, or to satisfy an abstract “clean code” checklist.

Readability Beats Cleverness

The most maintainable code is often boring: clear names, straightforward control flow, a bit of duplication if it makes intent obvious. Clever one-liners and deep abstraction hierarchies might feel satisfying to write, but they slow down everyone who has to read and change the code later—including you in six months.

Clever (hard to scan):

const activeIds = [...new Set(arr.filter(Boolean).map(x => x.id))].filter(id => validIds.has(id));

Readable (easy to change):

const ids = items.filter(item => item != null).map(item => item.id);
const uniqueIds = [...new Set(ids)];
const activeIds = uniqueIds.filter(id => validIds.has(id));

Same behavior. The second version is a few lines longer but anyone can adjust the rules or add logging without decoding a one-liner.