I Used to Think "Accepted" Meant I Was Done Learning

Whenever I solve a LeetCode problem, I have a simple objective.

Get the green Accepted badge.

Move on to the next problem.

For a long time, I never questioned that habit.

Recently, while solving Matrix Diagonal Sum, something changed.

Not because the problem was difficult.

Not because I found a faster algorithm.

But because another accepted solution made me realize that I had been treating "Accepted" as the finish line.

Maybe it isn't.

Maybe it's the beginning of another kind of learning.

My Solution Was Accepted

For the problem, I naturally separated the computation into two parts.

The primary diagonal.

The secondary diagonal.

Even though both could be traversed in a single loop, my mind treated them as two independent responsibilities.

So I maintained two variables.

One for each diagonal.

After both sums were computed, I handled the only special case.

The duplicate center element in an odd-sized matrix.

The solution worked.

It was accepted.

Looking back, I had only solved the algorithm.

Then I Saw Another Accepted Solution

Later that day, I was browsing a DSA discussion group.

Someone had shared another accepted solution for the same problem.

At first glance, it looked almost identical.

Same complexity.

Same result.

Same acceptance.

Then one small condition caught my attention.

It didn't correct the state.

It prevented the unnecessary state.

That tiny difference stayed in my mind.

The Interesting Part Wasn't The Code

My first thought wasn't:

This solution is shorter.

Nor was it:

This solution is faster.

Both solutions run in O(n) time and O(1) space.

The interesting part was something else.

Both developers were solving the same problem.

But they were thinking differently.

That realization made me stop comparing implementations.

Instead, I started comparing thought processes.

I Accidentally Discovered Two Design Principles

When I reflected on my own solution, I realized I had unconsciously followed a principle.

Separation of Concerns.

Each variable represented exactly one responsibility.

Neither diagonal depended on the other.

The final answer was simply a combination of two independent computations.

The second solution reflected a different principle.

Prevention is Better Than Correction.

Instead of creating an invalid state and fixing it later, it prevented the invalid state from ever existing.

Neither principle is universally better.

Both are valuable.

Both belong in an engineer's toolbox.

I Realized I Had Been Looking At Accepted Solutions Incorrectly

Earlier, whenever I opened another accepted solution, I usually looked for things like:

• Shorter code
• Better complexity
• Cleaner implementation

Now I find myself asking a different question.

What is this solution trying to teach me?

Sometimes the lesson is about complexity.

Sometimes it's about readability.

Sometimes it's about software design.

Sometimes it's simply a different way of thinking.

The code becomes secondary.

The thinking becomes the lesson.

Every Engineer Leaves Clues Behind

Something else occurred to me.

Every accepted solution represents a series of decisions.

Why this variable?

Why this condition?

Why this traversal?

Why this order?

Those decisions rarely happen by accident.

They reflect how someone approached the problem.

Reading another solution isn't just reading code.

It's observing another engineer's reasoning.

Maybe This Is Why Reviewing Solutions Matters

I still believe solving the problem yourself should come first.

The struggle matters.

The mistakes matter.

The debugging matters.

But after reaching Accepted, I don't think learning should stop there.

That might actually be the best time to learn.

Because now you're no longer trying to survive the problem.

You're free to understand how other people approached it.

Not to replace your solution.

Not to memorize theirs.

But to expand your own way of thinking.

My Takeaway

This experience changed one small habit.

Getting Accepted is no longer my finish line.

It's an invitation to ask one more question.

How else can this problem be thought about?

I think that's where engineering starts becoming interesting.

Not because there is always a better solution.

But because there is almost always another way of thinking.

Final Thought

Every accepted solution carries a lesson.

Sometimes it's an algorithm.

Sometimes it's a design principle.

Sometimes it's simply another engineer's way of thinking.

The lesson is already there.

You just have to dig it out.

Acknowledgement

The second solution shown in this article belongs to another developer who shared it in a DSA discussion group.

Before including it in my learning notes, I reached out and requested permission to use the screenshot with proper credit.

I'm grateful for both the permission and the insight it gave me.