Clarity Over Brevity

Early computing rewarded brevity. Storage was expensive. Screen space was limited. Condensing complex operations into as few characters as possible was a practical constraint. Those constraints are gone. But the instinct remained — brevity started feeling like craftsmanship. A dense one-liner became a way to signal expertise.

The problem is that code is read far more often than it's written, and the reader rarely has the context the writer had. A clever one-liner might save thirty seconds today. It costs thirty minutes tomorrow when someone has to decode it.

// Brief
const actUsr = users.filter(u => !u.dAt && u.lstLgn > thirtyDaysAgo);

// Clear
const activeUsers = users.filter(user => {
  const notDeleted = !user.deletedAt;
  const recentlyActive = user.lastLoginAt > thirtyDaysAgo;
  return notDeleted && recentlyActive;
});

The brief version is shorter. It's also a puzzle. The clear version takes four more lines and no explanation.

The same principle applies to function calls. A bare number tells you nothing:

// Brief
items.splice(0, 1);

// Clear
const FIRST_ITEM = 0;
const REMOVE_ONE = 1;
items.splice(FIRST_ITEM, REMOVE_ONE);

In both cases the "brief" version saved a few keystrokes and lost all context. The longer version carries its meaning with it.

Brevity should emerge as a side effect of good design, not as the primary goal. When you're choosing between a clever trick and an obvious solution, obvious wins — because expertise isn't proved by how little you wrote. It's proved by how quickly someone else can follow it.