A Note to the Engineer I Was 5 Years Ago

If I could sit across the table from the engineer I was five years ago, I don’t think I’d tell him which technologies to learn.

I wouldn’t tell him to learn Kubernetes earlier.

I wouldn’t tell him to become better at system design.

I wouldn’t tell him to read more books, write more code, or collect more certifications.

I’d tell him something much simpler:

Stop trying so hard to prove that you’re good.

I know why you are doing it.

You want people to notice your work.

You want your manager to know that you can be trusted.

You want your teammates to see that you understand things.

You want to be the person who has the answer when someone asks a difficult question.

And there is nothing wrong with ambition.

But eventually, you’ll discover something that nobody tells you early enough:

Your career doesn’t grow because you know more answers. It grows because you learn to ask better questions.

Five years ago, you probably think being a strong engineer means knowing the technology better than everyone else.

So you learn.

Another framework.

Another cloud service.

Another design pattern.

Another database.

Another certification.

And every time you discover something you don’t know, you feel slightly behind.

That feeling never completely disappears.

Because technology is too big.

There will always be someone who knows more about Kubernetes than you.

Someone who understands databases more deeply.

Someone who has designed systems at a scale you’ve never experienced.

Someone who can explain a concept you have never even heard of.

That’s okay.

Your job isn’t to know everything.

Your job is to know how to learn, how to reason, and how to make good decisions with incomplete information.

That’s what experience slowly teaches you.

You’ll spend years writing code and feeling productive because your commit history is full.

But eventually you’ll realize that not all work has the same value.

Sometimes the most valuable thing you can do is write zero lines of code.

Maybe you discover that the requirement itself is wrong.

Maybe you ask one question that prevents three teams from building the wrong thing.

Maybe you notice a failure mode nobody considered.

Maybe you convince the team not to introduce another unnecessary service.

Maybe you simplify an architecture instead of making it more sophisticated.

These things don’t always show up in a sprint report.

They don’t always appear in performance metrics.

But they are engineering.

Senior engineers don’t just produce more code. They reduce the amount of unnecessary code the organization needs to produce.

Remember that.

This one will take you longer than you expect.

Someone will ask you a question in a meeting.

You won’t know the answer.

You’ll feel pressure to say something intelligent.

Don’t.

Say:

“I don’t know. Let me look into it.”

There is tremendous strength in that sentence.

Because pretending to know creates fragile decisions.

Admitting that you don’t know creates room for investigation.

And there’s another important distinction:

“I don’t know” is not the end of the conversation.

It is the beginning of the right one.

Ask:

What do we actually know?

What are we assuming?

What evidence do we have?

What would change our decision?

What happens if we’re wrong?

Those questions will take you much further than trying to sound certain.

This might be the hardest lesson.

You’ll spend days designing something.

You’ll defend your decisions.

You’ll draw diagrams.

You’ll explain trade-offs.

And six months later, reality will teach you something your design couldn’t.

Traffic will behave differently.

A dependency will become a bottleneck.

A requirement will change.

A failure mode you didn’t anticipate will appear at 2 a.m.

And you’ll realize:

The architecture wasn’t a prediction of the future. It was a hypothesis about the future.

That’s an important distinction.

Good architects aren’t people who always design systems that turn out exactly as expected.

They’re people who design systems that can change when their assumptions turn out to be wrong.

So don’t fall in love with your architecture.

Fall in love with the reasoning behind it.

And be willing to change your mind.

You will eventually realize that engineering is not primarily a technology problem.

It’s a people problem.

The developer who asks the “obvious” question may be seeing something you missed.

The junior engineer who disagrees with you might have a better idea.

The teammate who is struggling might not need another technical explanation. They might need someone to patiently walk through the problem with them.

Don’t become the engineer everyone is afraid to approach.

Become the engineer people trust when they’re stuck.

There is a difference.

One creates dependence.

The other creates capability.

Your greatest contribution won’t always be what you build. Sometimes it will be the engineers who become better because they worked with you.

Titles matter.

Compensation matters.

Promotions matter.

But don’t let them become your only scoreboard.

There will be years when you get promoted quickly.

There will be years when you don’t.

There will be moments when someone else gets the opportunity you wanted.

It will hurt.

That’s normal.

But keep building your capability.

Learn to communicate.

Learn to make decisions.

Learn to handle ambiguity.

Learn to understand business, not just technology.

Learn to write.

Learn to mentor.

Learn to disagree without becoming disagreeable.

Because eventually, your career becomes less about what you can personally do and more about the size and complexity of problems you can help solve.

Slow down.

I know you don’t believe me yet.

You think you have to keep moving.

One more skill.

One more project.

One more promotion.

One more milestone.

But five years from now, you’ll realize how quickly these five years passed.

You’ll remember the difficult projects.

The late nights.

The failures.

The moments when you thought you weren’t good enough.

But you’ll also remember the people.

The conversations.

The teammates you helped.

The problems you solved together.

The moments when you finally understood something that had confused you for months.

Those are the things that will stay.

So work hard.

Be ambitious.

Keep learning.

But don’t spend your entire career running toward the next version of yourself.

Take a moment to notice the engineer you have already become.

If I could leave you with just five things, I’d write them on a piece of paper and put them next to your monitor:

Keep learning.

Keep questioning.

Keep building.

Keep helping people.

And when you’re finally the experienced engineer in the room, remember what it felt like to be the one who didn’t know.

Because someday, someone five years behind you will be looking at you the way you are looking at the engineers ahead of you today.

And when that happens, I hope you don’t just show them how to build better systems.

I hope you help them become better engineers.

— A note from five years later