Two Pieces of Code, Same Answer — Which One Should You Write?

Introduction

This is my first post. It has been one year since I became an engineer with no prior experience.

Now, once you become an engineer and start learning programming, there is a phrase you will hear at least once:

"Shorter (simpler) code is better."

Is that true? The other day, I put my own code next to a model-answer-style solution, and I ended up doubting this phrase.

The subject is a classic matchstick problem.

The Matchstick Square Problem

You make squares in a row with matchsticks. The first square needs 4 sticks, and from the second square on, each one shares a side with its neighbor, so you only add 3 sticks each time. The question: how many matchsticks do you need to make n squares?

 _ _ _
|_|_|_|   ← 3 squares = 4 + 3 + 3 = 10 sticks

What came to my mind was not a formula but a motion. Build the first square with 4 sticks, then keep adding 3 — and that hand movement became my code, just as it was.

① Thinking turned into code

function countMatchsticks(squareCount) {
  const FIRST_SQUARE = 4;   // the first square takes 4 sticks
  const STICKS_TO_ADD = 3;  // add 3 for each square after that

  let total = FIRST_SQUARE;
  for (let i = 0; i < squareCount - 1; i++) {
    total += STICKS_TO_ADD;
  }
  return total;
}

You can see it turns the earlier description — "4 sticks for the first square, then 3 more for each square after that" — into code, motion by motion.

On the other hand, there is a much shorter way to write this.

② The short version

function countMatchsticks(squareCount) {
  return 3 * squareCount + 1;
}

Both return the same answer. So, which one should you write?

What Happened in My Head When I Read Them

Let me be honest.

With the longer code, I saw the matchsticks the moment I read it. That motion — build a square with 4 sticks, keep adding 3 — sits right on top of the code. So I knew it was correct just by reading it.

The short one was different. Looking at 3 * squareCount + 1, no matchsticks appeared in my head. So how did I convince myself that this one was also correct? — I plugged in the same numbers and checked. n=1 gives 4, n=2 gives 7, n=3 gives 10... OK, it works.

There is an important asymmetry here.

• ① Thinking turned into code: you understand it by reading it
• ② The short version: you cannot trust it without verifying it

Short code outsources the labor of verification to the reader.

Naming the Variables Reveals a Cruel Difference

There is an experiment that makes this difference much clearer: try giving meaningful names to both pieces of code.

The long one was easy. FIRST_SQUARE (the first square takes 4 sticks), STICKS_TO_ADD (3 more for each square after). Even with every comment deleted, the variable names alone tell the story of the matchstick world.

What about the short one?

The 3 can still be named: "three sticks per square." But there is no name you can give to the + 1. In the world of matchstick squares, "one stick" does not exist as a thing. "One stick" is a step in a process.

That +1 is nothing but a leftover of the calculation that split the 4-stick square into "3 sticks + 1 stick."

In other words, the short code breaks down the moment you try to express its intent through variable names. It is proof that the intent no longer lives in the code.

So Is "Shorter Is Better" Completely Wrong?

Here is the interesting part: in the world of mathematics, the conclusion flips. In math, the fully expanded 3n + 1 is without question the better form.

Why does the right answer flip?

In math, 3n + 1 shows up as the result of stating a proposition and proving it through logical argument. The story of "why this works" is stored outside the formula — in the proof itself. That is why the formula can be stripped down to its most minimal, beautiful form: the story is safely kept somewhere else.

Coding is not like that.

For example, say a colleague (or your future self) opens this code for the first time six months from now. All they can read is the code, the documentation that comes with it, and maybe the comments.

No proof notebook is attached. So the story — the author's intent — has nowhere to live but inside the code.

• 4 + (n-1)*3 is the form that folds the proof into the expression
• 3n + 1 is the form that throws the proof away

The belief that "short code is justice" turns out to be a bad import: we took the aesthetics of mathematics — where the story can live outside the formula — and carried it straight into the world of code, where the story has no choice but to live inside.

Conclusion: Which One Should You Write?

I have been sounding like a story-first advocate, so let me step back and look at it flatly.

It is neither "short = justice" nor "long = careful." The question to ask is this:

"What do I want to tell the next person who reads this code?"

If you want to convey the story of the motion, write it so the steps are visible. If the answer alone is enough — the logic is already proven and shared, or comments and tests keep the story somewhere else — write it short.

My conclusion this time: as a beginner, you have absolutely no reason to be ashamed of the "long but motion-visible" code you wrote.

Bonus: Where This Story Goes Next

At its core, this was a story about a choice: keep the intent in the code, or erase it. Now, flip the question — what if there were situations where you want to erase the intent on purpose...? There are. The world of obfuscation and security.

But that is a story for another article.