You Don’t Need to Know Everything to Become a Great Engineer#

There was a time when I thought great engineers knew everything.

They knew Kubernetes.

They knew AWS.

They knew Docker.

They knew networking.

They knew databases.

They knew why the production server was down at 2:13 AM.

They probably even knew why the Wi-Fi stopped working when someone plugged in the office kettle.

I was wrong.

After spending enough time in software engineering, I’ve realized something much more comforting:

Great engineers don’t know everything. They just know how to figure things out.

And honestly, that’s a much more useful skill.

The “I Know Everything” Engineer#

You know the type.

Ask:

“How does this system work?”

And they immediately start explaining.

“Basically, Kubernetes uses container orchestration with a declarative configuration model that—”

You nod.

They continue.

Twenty minutes later, you have learned about Kubernetes, distributed systems, the history of Linux, and somehow the engineer's opinion about cryptocurrency.

Then you ask:

“So… where is the config file?”

Silence.

They have no idea.

And that's okay.

Because knowing everything isn't the job.

Finding the answer is.

Google Is Not Cheating#

One of the funniest things about software engineering is that we spend years studying computer science just to eventually type:

how to remove this stupid error python

into Google.

Or:

why docker container exits immediately

Or my personal favorite:

what does this error actually mean

And then we find a Stack Overflow answer from 2018.

The answer is:

“Just add this one line.”

You add the line.

It works.

You feel like a genius.

Then you close the browser and hope nobody asks you why it worked.

That's engineering.

And yes, knowing how to search effectively is an engineering skill.

Nobody Remembers Everything#

Think about how much technology we use.

Python.

JavaScript.

TypeScript.

React.

Django.

FastAPI.

PostgreSQL.

Redis.

Docker.

Kubernetes.

AWS.

Terraform.

Git.

CI/CD.

LLMs.

Vector databases.

Message queues.

Monitoring.

And approximately 47 other tools someone decided we absolutely need.

Now imagine trying to remember every API, configuration option, command, edge case, and weird behavior.

You can't.

Nobody can.

Even experienced engineers forget things.

I've seen senior engineers search for:

git undo last commit

And then confidently continue their day.

I've also personally witnessed people who've been using Docker for years type:

docker ps

and then stare at the output like it personally betrayed them.

That's normal.

The Difference Between Junior and Senior Engineers#

It's tempting to think senior engineers are senior because they know more commands.

That's not really it.

A junior engineer might say:

“I don't know how to fix this.”

A senior engineer might say:

“I don't know yet. Let's figure out what's happening.”

That “yet” makes a huge difference.

The senior engineer doesn't necessarily have the answer in their head.

They know how to:

• break the problem down
• find relevant documentation
• search intelligently
• read error messages
• inspect logs
• reproduce the issue
• ask the right questions
• test assumptions
• isolate the root cause
• and, most importantly, avoid making things worse

That last one deserves its own award.

You Are Not Paid to Memorize Documentation#

This is probably one of the biggest mindset shifts in engineering.

You don't need to memorize the AWS documentation.

You need to know where to find the AWS documentation.

You don't need to remember every SQL syntax.

You need to understand what you're trying to query and know how to verify the syntax.

You don't need to memorize every Docker command.

You need to understand containers well enough to troubleshoot when something inevitably explodes.

The real skill isn't:

“I know everything.”

It's:

“I know how to find out.”

The Most Dangerous Engineer Is the One Who Pretends to Know#

There's something much worse than saying:

“I don't know.”

It's confidently giving the wrong answer.

I've made this mistake.

Most engineers have.

You see an issue and think:

“Oh, I've seen this before.”

You change three things.

Restart the service.

Change an environment variable.

Upgrade a package.

Now the original problem is gone.

So are five other things.

Congratulations.

You have created a new problem.

This is why saying “I'm not sure” is actually a sign of maturity.

Because once you admit you don't know, you can start investigating.

Curiosity Beats Knowledge#

Technology changes ridiculously fast.

The framework you learned two years ago might have changed.

The AWS service you used last year might have a completely different feature now.

The AI model you were excited about six months ago might already be considered ancient.

Today's “cutting-edge” technology becomes tomorrow's:

“Oh yeah, we used that once.”

So if your entire engineering ability depends on what you already know, you're going to struggle.

But if you're curious, you're dangerous—in a good way.

Give a curious engineer a new technology and they'll say:

“I've never used this before. Give me an hour.”

Give an experienced engineer something completely unfamiliar and they'll say:

“Okay. Let's read the docs.”

That's how you keep growing.

Learn the Fundamentals, Not Every Tool#

There's an important distinction here.

I'm not saying:

“You don't need to learn anything.”

Please don't interpret this as permission to become the engineer who installs ChatGPT plugins for everything.

You still need fundamentals.

Understand:

• how HTTP works
• how databases work
• how networking works
• how processes and memory work
• how APIs work
• how authentication works
• how distributed systems behave
• how your programming language works
• how to debug

These concepts survive technology trends.

Tools change.

Fundamentals don't disappear.

If you understand the underlying concept, learning a new tool becomes much easier.

The Best Engineers Ask Good Questions#

There's another underrated skill:

asking questions.

Not:

“It doesn't work. Help.”

But:

“The API works locally but returns a 502 in production. The container is healthy, the request reaches the load balancer, and the application logs show no incoming request. I suspect something between the load balancer and container. Here's what I've checked.”

That question is incredibly valuable.

Because you've already done the thinking.

You're not asking someone to solve the problem for you.

You're asking for help moving the investigation forward.

Good engineers don't avoid questions.

They ask better questions.

And Yes, AI Makes This Even More Obvious#

We now have AI assistants that can explain code, generate examples, summarize documentation, and help debug problems.

Which means memorizing everything is becoming even less important.

But there's a catch.

If you don't understand the fundamentals, AI can confidently give you absolute nonsense and you'll happily deploy it to production.

Then at 3 AM:

“Why is our database bill $4,000?”

AI:

“Great question! Here's a scalable architecture…”

You:

“NO.”

AI is a tool.

Your engineering judgment is still yours.

The best engineers aren't the ones who refuse to use AI.

They're the ones who know enough to question what AI gives them.

So What Makes a Great Engineer?#

Not knowing everything.

It's being comfortable saying:

“I don't know.”

Then following it with:

“But I'll find out.”

It's being able to stare at a terrifying error message without immediately restarting the server.

It's reading documentation instead of randomly changing configuration values.

It's asking questions before spending six hours debugging the wrong thing.

It's understanding fundamentals instead of memorizing commands.

It's being curious.

It's learning continuously.

And occasionally, it's knowing when to turn something off and turn it back on again.

Yes.

That is still a valid debugging technique.

Don't let anyone tell you otherwise.

The Goal Isn't to Know Everything#

The goal is to become the kind of engineer who can walk into an unfamiliar codebase, unfamiliar infrastructure, unfamiliar technology, and unfamiliar problem…

…and not panic.

You don't need to know everything.

You need to be able to learn anything you need.

That's a much more powerful skill.

Because technology will keep changing.

New frameworks will appear.

New cloud services will launch.

New programming languages will become popular.

New AI models will arrive every other Tuesday.

And you'll forget half the commands you learned last month.

That's fine.

You can always look them up.

The engineer who knows everything doesn't exist.

The engineer who knows how to figure things out?

That's the one you want on your team.