There’s a persistent idea in software circles that smaller code is always better. Conciseness is praised, verbosity is criticized, and engineers sometimes compete to see who can squeeze a function into the fewest possible lines. But like most absolutes, this view doesn’t hold up under scrutiny. The size of the code is not inherently good or bad—it depends on the language, the architecture, and most importantly, the team that has to work with it.

The Real Problem: Readability, Not Length

A hundred lines of clear, well-structured, well-documented code is far more valuable than ten lines of “clever” code that only the original author can parse. Shorter code is not automatically simpler code. In fact, collapsing logic into fewer lines often strips away the natural breakpoints that a debugger—or a human reader—needs to follow the flow.

In my experience, the most painful debugging sessions don’t come from long codebases; they come from code that hides its intent. Nothing is more frustrating than a teammate admitting: “We know the code is broken, but we don’t know why it’s broken.” That’s a failure not of testing, but of clarity. Debugging should feel like stepping through a well-lit hallway, not stumbling through a dark maze.

Debugging as a First-Class Citizen

Speed of debugging is a critical feature. An engineer should be able to set a breakpoint, step through the code, and clearly see which values are changing and why. That’s only possible if the code is written with debuggability in mind: breaking complex expressions into named steps, documenting assumptions, and avoiding the temptation to be “too clever.”

This isn’t just theory. Think about modern IDEs: they thrive when they can show you variable state, call stacks, and object structure at every step. If the code collapses three or four logical operations into one dense one-liner, the debugger loses its power. We shouldn’t optimize for line count; we should optimize for insight.

Performance: Scripted vs. Compiled Languages

Now, it’s true that verbosity can matter in certain contexts. In JavaScript and other interpreted languages, more lines can mean slightly more work for the engine. But in compiled languages like Java, C#, or C++, the compiler optimizes away most of the verbosity. The generated executable is the same size whether you wrote three chained method calls on one line or broke them into three separate statements.

In other words: when you’re writing compiled code, verbosity costs you nothing at runtime but buys you a lot at debug-time.

Larry Wall’s Three Virtues

Perl creator Larry Wall once described the “three virtues” of a good programmer: laziness, impatience, and hubris. I’d add a practical interpretation: you should write your code so that someone who’s been coding for just a week can step into the debugger and understand exactly what’s happening. That doesn’t mean dumbing things down; it means writing with empathy for the next person who will have to maintain or debug your code—because odds are, that person will eventually be you.

Conclusion

Code is a communication medium. Yes, it instructs the machine, but more importantly it communicates intent to other humans. Size alone is a poor metric. A small, opaque snippet that hides logic is infinitely worse than a longer block that is easy to step through, inspect, and explain.

So the next time someone criticizes your code for being “too verbose,” ask them: is it harder for the computer, or just harder for the human? If it’s the latter, verbosity might just be a virtue.

const result = [1, 2, 3, 4, 5, 6]
  .filter(n => n % 2 === 0)
  .map(n => n * n)
  .reduce((a, b) => a + b, 0);

console.log(result); // 56
          

const numbers = [1, 2, 3, 4, 5, 6];

// Step 1: filter only even numbers
const evens = numbers.filter(n => n % 2 === 0);

// Step 2: square them
const squares = evens.map(n => n * n);

// Step 3: sum them up
const sum = squares.reduce((a, b) => a + b, 0);

console.log(sum); // 56
          

import java.util.Arrays;
import java.util.List;

public final class Example {
  public static void main(String[] args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
    int result = numbers.stream()
        .filter(n -> n % 2 == 0)
        .map(Integer::valueOf)
        .mapToInt(Integer::intValue)
        .map(n -> n * n)
        .sum();
    System.out.println(result); // 56
  }
}
          

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public final class ExampleVerbose {
  public static void main(String[] args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);

    // Step 1: filter only even numbers
    List<Integer> evens = new ArrayList<>();
    for (Integer n : numbers) {
      if (n % 2 == 0) {
        evens.add(n);
      }
    }

    // Step 2: square them
    List<Integer> squares = new ArrayList<>();
    for (Integer n : evens) {
      squares.add(n * n);
    }

    // Step 3: sum them up
    int sum = 0;
    for (Integer n : squares) {
      sum += n;
    }

    System.out.println(sum); // 56
  }
}