Why Writing 100 Lines of Code Can Be Better Than Just 2

Let me tell you a story.

You walk into a room with 100 light bulbs.
One of them is broken — it doesn't turn on.
Your job is to find out which one is broken.

The Simple Way

Let’s say you're holding a list of 100 bulbs.
One of them is broken — it doesn’t light up.
The most obvious way to find the broken bulb is to check them one by one.

for (int i = 0; i < bulbs.size(); ++i) { if (!bulbs[i].isOn()) { return i; } }

What’s happening here?

• You're starting from the first bulb.

• You check: "Is this bulb ON?"

• If it’s ON, move to the next one.

• If it’s OFF, you’ve found the broken one — and you stop.

This method is simple and works well.
But here’s the problem: what if the broken bulb is the last one in the list?

You’ll have to go through all 100 bulbs — checking each one until the end.
That means your program does 100 checks in the worst-case scenario.
It’s like testing every single switch in a room, one by one, just to find which one doesn't work.

It’s easy to write, sure. But it’s not efficient, especially if you’re dealing with a large number of items — like 1,000 or 10,000 bulbs.

Now let’s try to be clever instead of just going one-by-one.
What if we could reduce the number of checks by grouping the bulbs?

Instead of checking each of the 100 bulbs individually, we divide them into 10 smaller groups, where each group has 10 bulbs.

So now we have:

• Group 0 → Bulbs 0–9

• Group 1 → Bulbs 10–19

• Group 2 → Bulbs 20–29
  ...

• Group 9 → Bulbs 90–99

Now, instead of testing every single bulb right away, we test each group as a whole.
We check: “Are all the bulbs in this group ON?”
If yes — move to the next group.
If not — we’ve found the group that has the broken bulb.

After identifying the faulty group, we check the bulbs inside that group one by one to find the exact broken one.

for (int g = 0; g < 10; ++g) { bool groupOk = true;

for (int i = g 10; i < (g + 1) 10; ++i) { if (!bulbs[i].isOn()) { groupOk = false; break; } }

if (!groupOk) { for (int i = g 10; i < (g + 1) 10; ++i) { if (!bulbs[i].isOn()) { return i; } } } }

What’s Happening in the Code?

1. We loop through all 10 groups (g from 0 to 9).

2. For each group:

   • We check if all 10 bulbs are ON.

   • If yes — move to the next group.

   • If not — we found our faulty group.

3. Then we loop through that group and check each bulb one by one.

4. As soon as we find the bulb that’s OFF, we return its position.

With the smarter approach:

• You test 10 groups.

• Then at most 10 bulbs inside the faulty group.

• So, around 20 total checks, even in the worst case.

  Why This Matters

  Yes, the smarter method takes more lines of code.
  But it makes your program way faster and more efficient — especially when you deal with large numbers like 1,000 or more.

  So, writing longer code doesn’t mean you’re doing something wrong.
  It could actually mean you're thinking better.

Final Thought

Anyone can write a 2-line loop.
But understanding the problem deeply and building an efficient solution —
even if it takes 100 lines —
that’s what real developers do.