I Used to Think Being Good at Coding Was Enough

When I was a student, software seemed pretty simple to me.

If you wanted to succeed, you had to be good at coding.

The better you coded, the more valuable you were.

Learn more languages.

Learn more frameworks.

Read complicated source code.

Become a stronger engineer.

That was the path I saw.

I didn’t know there were other paths.

Then I started working.

The first few years were exactly what I expected.

Writing code.

Fixing bugs.

Shipping releases.

Meeting deadlines.

Occasionally staying late.

Life as a developer was pretty straightforward.

Things started to change when I began working with Japanese clients.

I met people who, from a technical perspective, weren’t particularly impressive.

Salespeople.

Consultants.

Project managers.

Some of them barely understood the technology behind the products they were selling.

And yet, they created enormous value.

They understood customers.

They asked good questions.

They aligned people.

They turned vague ideas into projects.

And projects into business.

For a long time, I didn’t understand that.

I remember thinking:

Why are these people so important?

Why do customers spend more time talking to them than to developers?

Why does the company need them?

Years later, I think I finally understood.

Customers don’t buy source code.

They buy outcomes.

It sounds obvious now.

But it took me years to truly understand what that meant.

Most customers don’t lose sleep over frameworks.

They don’t argue about clean architecture.

They don’t care whether the system runs on Java or Go.

At least not at first.

What they care about is much simpler.

Can this solve my problem?

That realization slowly changed how I see this industry.

I still enjoy technology.

I still write code.

I still build things.

I don’t think coding is unimportant.

Far from it.

It’s one of the most valuable skills I’ve ever learned.

I just don’t think it’s the whole profession anymore.

The longer I work, the more I feel that software is built by more than code.

People.

Communication.

Trust.

Expectations.

Decisions.

Responsibility.

And sometimes, three-hour meetings where nobody actually understands each other.

That’s probably why I named this website Andy Don’t Like Code.

Not because I hate coding.

I don’t.

I just don’t want to spend my entire career becoming slightly better at coding every year.

I’m more interested in understanding everything that happens before the code gets written.

And even today, I’m still learning.