Don't start with the code. Start with the change you want to create.

Writing Code Isn't the Job

Writing code.

Learning new technologies.

Studying different programming languages and sitting down at a computer to gradually turn an idea into something real.

And then comes that moment when it finally works exactly the way you imagined.

It feels great.

Engineering is a rewarding profession, and there is real joy in building things.

But there is something worth remembering.

Writing code itself isn't the job.

Lines of Code Don't Define "Done"

Someone uses the system you built and says,

"Oh, that's convenient."

"That really helps!"

Something that used to be difficult becomes a little easier.

A task that used to take a long time gets done faster.

A process where people often made mistakes becomes easier to navigate.

Perhaps these are the things engineers are really creating:

change.

You can write thousands of lines of code, but if the problem you set out to solve is still there, the job isn't finished.

On the other hand, if a single line of code solves someone's problem, that one line can have tremendous value.

What matters isn't how much code you wrote. It's what changed because of it.

That's where the real outcome of engineering lies.

What Would You Build for Yourself or Your Family?

Let's step away from work for a moment.

Imagine you're building a small system for yourself or your family.

"It would make my mornings easier if this happened automatically."

"It would be useful if pressing this button sent a notification to my family."

"I always forget this. It would help if something reminded me the day before."

That's probably where you would start.

A feature that makes you grin when you use it.

A little mechanism that makes someone in your family say, "Wow, that's useful!"

What you're trying to create isn't code.

It's the small, positive change that happens because of it.

Start by Looking at What Is Happening Now

The same applies when we build systems professionally.

First, look carefully at what is happening today.

Who is struggling?

What is taking too much time?

Where do mistakes happen?

Then ask:

• What could we change to make things better?
• Who is this feature really for?
• How much should we automate?
• Who needs to know the result?
• When do they need to know?
• What is the least disruptive way to communicate it?

Once we understand those answers, it's time for the code.

Build it yourself when that makes sense.

Use an existing solution when a good one already exists.

If a single API call solves the problem, that's perfectly fine too.

What matters isn't how much you build. It's how well you solve the problem.

Engineers Create Change

The ability to write code is, of course, important.

Without technical skills, we cannot turn our ideas into working systems.

But what are those skills for?

This brings us back to the imagination we discussed in the previous article.

Imagine the person who will use the system.

Understand where they are struggling.

Think about what could make things a little better.

Then use technology to make that change real.

So perhaps an engineer's job isn't simply

"to write code."

Perhaps it is

"to use technology to create positive change."

Engineering Time

When the code works, it feels great.

But then someone uses it and says,

"Oh, that's convenient."

And smiles.

That's the moment when the code becomes useful to someone.

The job isn't to write code.

The job is to solve problems.

And code is one of the wonderful tools we have to do it.