P.S. This was originally written before AI coding became mainstream. I made a small edit in October 2025 because the idea feels even more relevant now. AI can write code faster than most of us ever could. That makes the question even more important. Are we trying to write more code, or are we trying to solve the right problem?

There is a phase almost every engineer goes through.

We measure productivity by volume.

Lines written.

Functions added.

Logic handled.

Edge cases covered.

The longer the code, the prouder we feel.

It looks like effort.

It feels like intelligence.

But somewhere along the journey, many of us realise something uncomfortable.

Coding and problem solving are not the same thing.

When we start out, writing code feels like building muscle.

We add layers.

We create abstractions.

We prepare for every possible scenario.

The system grows.

And growth feels like progress.

Until someone more experienced looks at it and quietly asks,

“Do we need all this?”

That one question can collapse weeks of effort into a moment of clarity.

Because writing code is often the easiest part of engineering.

Resisting code is harder.

Anyone can add logic.

It takes maturity to remove it.

Junior engineers often expand solutions.

Senior engineers learn to compress them.

Not because they know less.

Because they see the problem more clearly.

Think of software like architecture.

A beginner may build walls everywhere for safety.

Rooms inside rooms.

Doors inside doors.

Everything separated.

Everything protected.

A seasoned architect removes walls carefully.

Not because they are careless.

Because they understand the structure.

The building becomes simpler.

Not weaker.

Software is similar.

Every line of code we write carries future weight.

Someone has to read it.

Understand it.

Test it.

Maintain it.

Debug it.

Refactor it.

Code does not end when we ship it.

That is when its maintenance life begins.

So complexity is never free.

It quietly becomes debt.

There is an engineering lesson many of us learn late.

The feature we do not build will never fail.

The abstraction we avoid will never confuse the next developer.

The edge case we do not unnecessarily over solve will never create a new bug.

Sometimes, the absence of code is stability.

This does not mean we avoid hard problems.

It means we solve them proportionately.

Not every problem deserves architectural grandeur.

Some problems deserve simple, readable, boring solutions.

Boring code is underrated.

Because boring code scales operationally.

Flashy code often scales ego.

Problem solving begins before coding.

Understanding the constraint.

Clarifying the requirement.

Challenging the assumption.

Asking whether the problem should be solved in code at all.

Sometimes the best solution is a process change.

Sometimes configuration is enough.

Sometimes removing a feature solves what we were planning to build around.

If coding is always our first instinct, we may be solving symptoms instead of causes.

There is also readability.

We do not write code only for machines.

We write it for future humans.

Teammates.

New joiners.

Reviewers.

And our own tired future selves, opening the same file six months later and wondering what we were thinking.

Clever code may feel impressive in the moment.

Clear code helps the team long after the moment has passed.

That is engineering empathy.

Now AI makes this distinction even sharper.

Machines can generate code quickly.

Functions.

Interfaces.

Documentation.

Tests.

Integrations.

Sometimes full applications.

So if writing code becomes easier, our value cannot remain only in typing it.

It has to move upward.

Into architecture.

Judgment.

Clarity.

Knowing what should be built.

Knowing what should not be built.

Knowing when generated code is useful, and when it is quietly dangerous.

AI expands execution.

Engineers must deepen discernment.

A useful metaphor is a city.

Coding is like adding roads.

Problem solving is deciding which roads are actually needed.

More roads do not always mean better traffic.

Sometimes they create confusion.

Sometimes they increase maintenance.

Sometimes the better answer is not another road, but a better junction.

Good urban planners do not optimise for asphalt.

They optimise for movement.

Good engineers should not optimise for code volume.

They should optimise for outcomes.

So especially for engineers starting out, the mental shift is important.

We are not paid to write more code.

We are trusted to solve problems.

And sometimes, the best engineer in the room is not the one who adds the most.

It is the one who understands what can be removed.