SolveFor42

The 42 Principles · Principle XLI

Curiosity Never Ends

Lifelong curiosity, remaining teachable, learning across generations and disciplines, and resisting intellectual stagnation.

LearningMentoringPersonal GrowthCareer Growth

Never Stop Asking Why

Nearly everything interesting I have ever learned began with a question.

Why?

How?

What happens if?

What am I missing?

Could this be done differently?

What is actually happening underneath this?

Those questions are simple.

Children ask them naturally.

Somewhere along the way, many adults learn to stop.

Experts are especially vulnerable.

The more we know, the easier it becomes to believe we already understand.

That is dangerous.

Expertise should give you better questions, not fewer of them.

Curiosity Built the Engineer

Every engineer begins by not knowing.

The first computer.

The first program.

The first network.

The first database.

The first server.

The first failure.

At some point, something captured our attention.

We wanted to understand it.

So we opened it.

Changed it.

Broke it.

Fixed it.

Read about it.

Asked someone.

Tried again.

Curiosity came before expertise.

Expertise was simply what accumulated because curiosity kept asking questions.

"I Don't Know" Is Where Curiosity Begins

Earlier in this book, I argued that admitting what you don't know is a strength.

This is why.

"I don't know" is not the end of the conversation.

It is the beginning of discovery.

I don't know.

Let's find out.

That second sentence changes everything.

The dangerous engineer is not the person who lacks an answer.

It is the person who has stopped looking for one.

Ignorance is temporary when curiosity survives it.

Do Not Let Experience Become Certainty

Experience is valuable.

It gives us patterns.

Instinct.

Context.

Judgment.

But experience can create another problem.

We begin recognizing situations so quickly that we stop investigating them.

"I've seen this before."

Usually, that is useful.

Sometimes, it is exactly how we miss the thing that is different this time.

The symptoms may look familiar.

The cause may not be.

Use experience to form the hypothesis.

Use curiosity to test it.

Ask What Changed

One of the most useful troubleshooting questions in technology is remarkably simple:

What changed?

A system worked yesterday.

It does not work today.

Something changed.

Maybe the code.

Maybe the network.

Maybe the certificate.

Maybe the permissions.

Maybe the data.

Maybe the dependency.

Maybe the environment.

Maybe something nobody realized was connected.

Curiosity follows the evidence.

It does not become emotionally attached to the first explanation.

Look Underneath the Abstraction

Modern technology makes extraordinary complexity appear simple.

Click the button.

Call the API.

Deploy the container.

Run the query.

Open the application.

Most of the time, that is exactly what we should do.

Abstraction allows us to build enormous systems without understanding every transistor underneath them.

But occasionally the abstraction leaks.

Then curiosity matters.

What is the button actually doing?

Where does the request go?

What happens when the API fails?

Where is the data stored?

What assumption is the framework making for us?

What exists underneath the easy button?

You do not need to understand everything all the time.

You should remain willing to understand more when the problem demands it.

Curiosity and Humility Are Partners

Curiosity requires humility.

You cannot genuinely ask a question while believing you already possess every answer.

The sentence:

"What am I missing?"

contains an assumption.

There may be something I do not see.

That is humility.

And it is one of the reasons curious engineers continue growing long after others plateau.

They remain teachable.

Ask the Junior Engineer

Sometimes the person with the least experience asks the most important question.

"Why do we do it this way?"

The experienced people answer:

"Because that's how we've always done it."

That sentence should make you curious.

Maybe there is an excellent reason.

Find it.

Maybe the reason disappeared five years ago.

Find that too.

New people have an advantage.

They have not yet learned which assumptions everyone else stopped questioning.

Listen to them.

Fresh eyes often see the assumptions experience has learned to ignore.

Read the Error

Curiosity is often less glamorous than people imagine.

Sometimes it simply means reading.

The error message.

The log.

The documentation.

The source code.

The release notes.

The configuration.

The packet capture.

The query plan.

The evidence is frequently sitting directly in front of us.

Curiosity is the willingness to keep looking until the evidence makes sense.

Break Things Where Breaking Is Safe

Some lessons are difficult to learn by reading.

Build the lab.

Create the test environment.

Change the setting.

Stop the service.

Delete the test resource.

Restore it.

Introduce latency.

Remove the permission.

See what happens.

Controlled failure teaches systems in ways diagrams cannot.

The important word is controlled.

Curiosity without judgment creates incidents.

Curiosity with guardrails creates understanding.

The Rabbit Hole Still Exists

Curiosity has a weakness.

We already discussed it.

Rabbit holes.

Every answer reveals three more questions.

Every dependency reveals another dependency.

Every interesting discovery invites another hour of investigation.

That does not mean curiosity is bad.

It means curiosity requires discipline.

Principle XXXVII was not:

"Stop exploring."

It was:

"Solve Real Problems."

The distinction matters.

You can write the interesting question down.

Return to it later.

Experiment in the lab.

Research it after the project is finished.

Curiosity does not require abandoning responsibility.

Curiosity chooses the questions. Judgment decides which ones deserve today's attention.

Learn Outside Your Lane

Some of the most valuable ideas come from crossing boundaries.

A database engineer learns networking.

A network engineer learns security.

A developer learns operations.

An operations engineer learns programming.

A technical leader studies psychology.

An engineer studies business.

A scientist studies history.

A teacher studies technology.

Fields that appear unrelated often contain patterns that transfer.

The broader your curiosity becomes, the larger your library of possible solutions becomes.

Ask Better Questions

Early questions are often broad.

"Why doesn't it work?"

Experience improves them.

"Which layer is failing?"

"What evidence would distinguish these two causes?"

"What assumption must be true for this design to work?"

"What happens when that assumption stops being true?"

"What would prove me wrong?"

Better questions reduce the distance to useful answers.

That is one of the ways expertise and curiosity reinforce each other.

Knowledge helps you ask better questions.

Better questions create more knowledge.

Technology Will Not Wait for You

Technology changes too quickly for anyone to declare themselves finished.

The tools you master today will change.

Platforms will disappear.

Languages will evolve.

Architectures will shift.

Security assumptions will be challenged.

New capabilities will make old limitations irrelevant.

Some things you spent years learning will eventually become obsolete.

That is not wasted knowledge.

You learned how to learn.

That skill survives every platform.

The most durable technical skill is the ability to become a beginner again.

Stay Willing to Be a Beginner

Being a beginner becomes harder as your career advances.

People expect you to know things.

You expect yourself to know things.

Then you encounter something completely unfamiliar.

Good.

That feeling is valuable.

Read.

Ask questions.

Experiment.

Make mistakes somewhere safe.

Let someone younger teach you.

Let someone with less seniority know something you do not.

Your title does not require omniscience.

It should give you enough confidence to learn without pretending.

Curiosity Creates the Future

Every improvement begins with dissatisfaction about something we currently accept.

Why does this take twenty steps?

Why can't this be automated?

Why does this fail every month?

Why do we need this dependency?

Why can't the customer do this themselves?

Why are we solving the same incident again?

Why not?

That last question has built an extraordinary amount of the world.

Someone looked at an accepted limitation and became curious enough to challenge it.

There Is Always Another Question

After decades of working with technology, I know more than I did when I started.

I also know how much more there is to understand.

Every answer exposes another layer.

Every system connects to another system.

Every solution creates new possibilities.

That does not discourage me.

It is what keeps engineering interesting.

There will always be another problem.

Another technology.

Another mystery.

Another person who knows something I don't.

Another question worth asking.

Good.

I hope that never changes.

The day you stop being curious is not the day you finally know enough. It is the day you stop discovering how much more there is to learn.

Follow the Question

Curiosity becomes valuable when it changes what you do.

Anyone can wonder.

Engineers investigate.

We form a theory.

Gather evidence.

Test the theory.

Discover that we were wrong.

Change the theory.

Test again.

That process may look less elegant than having the answer immediately.

It is also how many real answers are found.

Curiosity asks the question. Discipline follows it until the evidence answers.

Start With What You Know

When something fails, separate what you know from what you think.

These are not the same thing.

We know the application returned an error.

We think the database is slow.

We know authentication failed.

We think the password is wrong.

We know the server stopped responding.

We think the network dropped.

That distinction sounds small.

It is enormous.

Facts are evidence.

Theories are explanations for evidence.

Confusing the two is one of the fastest ways to spend hours solving the wrong problem.

Write Down the Assumption

Every system contains assumptions.

The DNS record resolves correctly.

The certificate is valid.

The service account still has permission.

The route exists.

The dependency is available.

The data has the expected format.

The clock is correct.

The configuration matches production.

Most of the time, these assumptions are true.

That is why they become invisible.

When troubleshooting becomes difficult, make them visible again.

Ask:

"What must be true for this to work?"

Then test those things.

The Most Dangerous Assumption Is the One Everyone Shares

A team can collectively be wrong.

In fact, agreement can sometimes make an incorrect assumption harder to discover.

Everyone "knows" the network is fine.

Everyone "knows" the application didn't change.

Everyone "knows" that account has access.

Everyone "knows" the backup works.

Until someone checks.

Curiosity gives you permission to verify what everyone believes.

Not because you distrust the people.

Because systems do not care what people believe.

Consensus is not evidence. Verify the assumption that would hurt most if everyone were wrong.

Ask What Would Prove You Wrong

One of the best questions in troubleshooting is:

"What evidence would prove my theory wrong?"

This protects us from falling in love with our own explanation.

If I believe the network is causing the problem, what result would demonstrate that the network is working correctly?

If I believe CPU is the bottleneck, what measurement would make me investigate somewhere else?

If I believe a deployment caused the failure, what evidence would eliminate it?

A theory that cannot survive attempts to disprove it is not much of a theory.

Curiosity should attack its own conclusions.

Change One Thing at a Time

When people become frustrated, they often begin changing everything.

Restart the service.

Change the configuration.

Update the package.

Clear the cache.

Reboot the server.

Reset the account.

And suddenly...

It works.

What fixed it?

Nobody knows.

The immediate problem may be gone.

The understanding is gone too.

Controlled investigation changes one meaningful variable when practical and observes the result.

That takes patience.

It also preserves the lesson.

If you change everything at once, you may restore the system while destroying your ability to learn why it failed.

Reproduce Before You Repair

When practical, reproduce the problem.

Can you make it happen again?

Under what conditions?

Does it happen for every user?

Every server?

Every request?

Every dataset?

Every location?

Every time?

Intermittent failures are difficult precisely because the triggering condition is hidden.

Reproduction helps expose it.

A reproducible problem is usually much closer to becoming an understood problem.

Reduce the Problem

Large systems create large search spaces.

Reduce them.

Does the problem exist without the load balancer?

Without the application?

Against the database directly?

With a different account?

From another network?

Using a known-good file?

Against a single node?

Each test removes possibilities.

Eventually the giant mysterious system becomes a much smaller problem.

Curiosity does not mean randomly exploring everything.

It means narrowing intelligently.

Compare Good With Bad

One of the fastest ways to learn why something fails is to find something similar that works.

Working server versus failing server.

Working account versus failing account.

Yesterday's configuration versus today's.

Development versus production.

Successful request versus unsuccessful request.

What is different?

Sometimes the difference looks irrelevant.

Do not dismiss it too quickly.

The strange difference may be the clue.

Follow the Evidence Across Boundaries

Problems rarely respect organizational charts.

The application team may believe it is a network problem.

The network team may believe it is an application problem.

The database team may believe it is storage.

Storage may believe it is the operating system.

The customer does not care.

The system is failing.

Follow the evidence wherever it goes.

Across teams.

Across technologies.

Across layers.

Across ownership boundaries.

Principle XXXI told us to own the outcome.

Curiosity tells us how.

The root cause does not care which team owns the ticket.

Look Where Nobody Is Looking

Difficult problems often survive because everyone keeps investigating the same places.

The obvious logs have been checked.

The normal metrics look fine.

The common causes have been eliminated.

Good.

Now the investigation becomes interesting.

What are we not measuring?

What happens immediately before the failure?

What external dependency exists?

What changed outside the system?

What assumption have we never verified?

What component is so reliable that nobody thought to check it?

Curiosity expands the search only after evidence justifies expanding it.

Time Is Evidence

When did the problem begin?

Not approximately.

As precisely as possible.

2:17 PM.

Good.

What happened at 2:17 PM?

Deployment?

Certificate renewal?

Scheduled task?

Backup?

Network change?

Authentication event?

Resource spike?

Dependency failure?

Human action?

Logs from different systems become dramatically more useful when aligned by time.

A timestamp can connect events that otherwise appear unrelated.

Absence Is Evidence Too

Sometimes the clue is what did not happen.

A scheduled job never started.

A request never reached the server.

A log entry was never written.

A replication event never arrived.

A health check never returned.

The absence of an expected event helps locate where the chain broke.

Ask not only:

"What happened?"

Ask:

"What should have happened next?"

Then determine why it didn't.

Read Beyond the First Error

The loudest error is not always the root cause.

A service crashes because a dependency failed.

The dependency failed because authentication expired.

Authentication failed because time drifted.

The application reports:

"Service unavailable."

True.

Not useful enough.

Curiosity walks backward through the chain.

What caused this?

And what caused that?

And what allowed that condition to exist?

Eventually you stop treating the symptom and reach something worth fixing.

Five Whys Are Not Magic

Asking "why" repeatedly can be useful.

It can also become mechanical.

Real systems do not always have a single straight chain of causation.

Failures can involve several conditions interacting.

A capacity limit.

A configuration change.

An unusual workload.

Missing monitoring.

An incomplete rollback.

None alone may have caused the incident.

Together they did.

Curiosity should seek understanding, not force reality into a convenient template.

Know When You Have Enough Evidence

Investigation can continue forever.

There is always another log.

Another dependency.

Another theory.

Another layer.

At some point, you have enough evidence to act.

That requires judgment.

Can we explain the failure?

Can we reproduce or reasonably account for it?

Does the proposed fix address the cause?

Can we validate the result?

Can we recover if we are wrong?

If yes, act.

Curiosity should improve decisions.

It should not become an excuse to avoid them.

Preserve the Discovery

A difficult problem solved but not documented becomes someone else's difficult problem later.

Write down:

The symptom.

The evidence.

The misleading clues.

The root cause.

The fix.

The validation.

The lesson.

This is where curiosity connects directly to Principle XXXVIII.

Make It Better Than You Found It.

Do not merely leave behind a working system.

Leave behind understanding.

Discovery that remains only in your head dies when your memory, role, or availability changes.

Automate the Question

Sometimes the investigation reveals something we should never need to investigate manually again.

We checked disk space.

Monitor it.

We checked certificate expiration.

Alert on it.

We compared configuration drift.

Detect it automatically.

We queried replication health.

Schedule the check.

We discovered a recurring pattern in logs.

Build detection for it.

The best investigation may produce a question the system learns to ask for us.

Curiosity Improves Design

Curiosity should begin before failure.

What happens if this server disappears?

What happens if the API becomes slow?

What happens if the credential expires?

What happens if the customer doubles their workload?

What happens if someone enters unexpected data?

What happens if the deployment fails halfway through?

What happens if the backup cannot be restored?

These questions sound pessimistic.

They are not.

They are design tools.

Curiosity imagines conditions the happy path would prefer to ignore.

Ask the Uncomfortable Question Early

Some questions become expensive when delayed.

Do we actually need this?

Who will support it?

How will we recover it?

What does this dependency cost?

What happens when the person who built it leaves?

Does the customer understand the limitation?

Are we solving the real problem?

Can we prove the backup works?

Is this secure?

The earlier those questions are asked, the cheaper the answers usually are.

Curiosity Needs Courage

Not every question is comfortable.

Sometimes curiosity discovers that the architecture is wrong.

The project assumption is wrong.

The documentation is wrong.

The metric is misleading.

The accepted explanation is unsupported.

Your own design is the problem.

Then curiosity requires something more.

Integrity.

Principle XXIX was Truth Over Comfort.

If the evidence contradicts what we wanted to believe, the evidence wins.

Especially when the mistake is ours.

Curiosity without honesty searches only until it finds the answer it wanted.

Share the Mystery

You do not have to solve everything alone.

Sometimes the fastest path forward is:

"I don't understand this. Can you look at it with me?"

Another person sees a pattern you missed.

They ask a question you never considered.

They have experience you do not.

Curiosity is collaborative.

A room full of people honestly trying to understand a problem is far more powerful than a room full of people trying to prove they were right.

Teach People How You Investigate

When mentoring, do not show only the final answer.

Show the path.

"I checked this because..."

"This result eliminated..."

"I expected this, but instead we saw..."

"That made me question..."

"This evidence changed my theory..."

That teaches something far more valuable than the solution to one incident.

It teaches how to approach the next mystery.

Keep a Beginner Nearby

Beginners ask inconvenient questions.

Good.

They ask why a process has twelve steps.

Why two systems contain the same data.

Why the name makes no sense.

Why something must be done manually.

Why everyone ignores a warning.

Experienced people often stop seeing these things because we have adapted to them.

The beginner has not.

Do not dismiss the question because the person lacks experience.

Investigate whether the question exposed something experience taught everyone else to tolerate.

Curiosity Is a Practice

Curiosity is not merely a personality trait.

It is something you practice.

Read outside the immediate problem.

Build things you do not know how to build.

Talk to people outside your specialty.

Study failures.

Study successes.

Ask why.

Test assumptions.

Change your mind.

Remain interested.

The world is far too complicated to run out of things worth understanding.

Closing Thought

The mature engineer does not need to have every answer.

They need something more durable.

The willingness to investigate.

The discipline to follow evidence.

The humility to change their mind.

The judgment to know when to act.

And the curiosity to ask the next question after everyone else believes the problem is already understood.

Do not measure your expertise by how quickly you can say, "I know." Measure it by how skillfully you can discover the truth when you don't.

Stay Interested

Curiosity is larger than engineering.

It is a way of moving through the world.

There are people you have not met.

Places you have not seen.

Ideas you have not considered.

Skills you have never attempted.

Books you have not read.

Questions nobody has answered.

And perspectives you may never encounter unless you deliberately go looking for them.

A curious life remains unfinished.

That is not a flaw.

It is the opportunity.

There is always more world than there is time to understand it. Stay interested.

Be Curious About People

People are complicated systems too.

We see behavior.

We infer motive.

That inference is often where trouble begins.

Someone disagrees with us.

Why?

Someone reacts unexpectedly.

Why?

Someone approaches the same problem differently.

Why?

It is easy to substitute judgment for investigation.

"They don't understand."

"They don't care."

"They're difficult."

"They're wrong."

Maybe.

Or maybe we are missing context.

Ask.

Listen.

Understanding another person's reasoning does not require agreeing with their conclusion.

It simply means being interested enough to understand how they arrived there.

Curiosity Makes Better Conversations

Most arguments are structured around responses.

While the other person is speaking, we prepare ours.

We identify the flaw.

Construct the rebuttal.

Wait for our turn.

Curiosity changes the objective.

Instead of asking:

"How do I prove my point?"

Ask:

"What does this person see that I don't?"

Now disagreement becomes information.

Maybe they are wrong.

Maybe you are wrong.

Maybe both of you hold different pieces of the answer.

You cannot discover that while waiting only for your turn to speak.

Listen to understand the argument before deciding how to answer it.

Ask Before You Assume Motive

We rarely have direct access to another person's intentions.

Yet we assign motives constantly.

They did that because...

They said that because...

They want...

They don't care about...

Sometimes our interpretation is correct.

Sometimes it is a story we created from incomplete evidence.

Curiosity creates a pause.

"What else could explain this?"

That question can prevent unnecessary conflict.

It can also reveal problems that accusation would have hidden.

Learn From People You Disagree With

Agreement is comfortable.

Disagreement can be educational.

You do not need to adopt someone's conclusions to learn from their reasoning.

Ask what evidence they consider important.

Ask which assumptions they are making.

Ask what experiences shaped their position.

Ask what would cause them to change their mind.

Then ask yourself the same questions.

If your position is strong, examination will strengthen it.

If it is weak, examination gives you an opportunity to improve it.

Either result is useful.

Changing Your Mind Is Not Losing

People sometimes defend old conclusions because changing them feels like admitting defeat.

It isn't.

If new evidence changes your understanding, updating your conclusion is exactly what rational thinking should produce.

The alternative is much worse.

Imagine discovering better evidence and deliberately keeping the worse answer because you already said it publicly.

That is not consistency.

That is pride.

Changing your mind because the evidence improved is not weakness. It is evidence that your thinking still works.

Do Not Turn Opinions Into Identity

The more tightly an idea becomes attached to identity, the harder it becomes to question.

If changing an opinion feels like changing who you are, curiosity becomes threatening.

Separate yourself from the conclusion.

You are not your architecture.

Your programming language.

Your methodology.

Your theory.

Your favorite technology.

Your old decision.

Those are things you currently believe or prefer.

They can change.

You remain.

That freedom makes learning much easier.

Learn Something You Are Bad At

Expertise is comfortable.

Beginners are clumsy.

That is one reason adults sometimes stop learning completely new things.

We become accustomed to competence.

Then suddenly we are terrible again.

Good.

Learn the instrument.

Try the language.

Build the furniture.

Write the story.

Cook something unfamiliar.

Study mathematics you never understood.

Take apart something you have never repaired.

Ask the embarrassing question.

Being bad at something new reminds you what learning feels like.

It also makes you more patient with everyone who is still learning what you already know.

Read Outside Your Profession

An engineer who reads only engineering eventually limits the material available to their imagination.

Read history.

Science.

Economics.

Psychology.

Biographies.

Philosophy.

Fiction.

Art.

Business.

Medicine.

Architecture.

Learn how other disciplines think.

A problem in one field may resemble a problem solved centuries ago in another.

Human beings reuse patterns constantly.

Different vocabulary can hide remarkably similar ideas.

Curiosity crosses the vocabulary.

Study How We Got Here

The present makes more sense when you understand what came before it.

Technologies have histories.

Organizations have histories.

Processes have histories.

Ideas have histories.

Many strange decisions were once reasonable responses to conditions that no longer exist.

If you understand the original problem, you can make a better decision about whether the old solution still belongs.

Without history, we inherit rules.

With history, we inherit context.

Before calling an old decision foolish, understand the world in which it was made.

Ask Why the Rule Exists

Rules can encode lessons.

Sometimes expensive ones.

A strange security requirement may exist because someone was compromised.

A review process may exist because a deployment once failed catastrophically.

A checklist item may represent an accident nobody wants repeated.

Do not casually remove something simply because you do not understand it.

First ask why it exists.

Then investigate whether that reason still applies.

Curiosity protects us from two opposite mistakes:

Blindly preserving obsolete rules.

And blindly removing useful ones.

Look Back at Your Own Work

Curiosity should occasionally point backward.

Open something you designed five years ago.

Would you build it the same way today?

Probably not.

That is good.

It means you learned.

Do not be embarrassed by every old mistake.

Study it.

What did you believe then?

What did you not know?

What experience changed your thinking?

What would you teach your younger self?

Your own history is a dataset.

Use it.

Let Younger People Teach You

Years of experience provide enormous value.

They do not provide exclusive ownership of good ideas.

Someone entering the field today has learned in a different environment.

Different tools.

Different assumptions.

Different abstractions.

Different possibilities.

They may see a solution that would never occur to you.

Let them show you.

Seniority should increase your ability to recognize good ideas.

It should not increase your need to be the source of them.

Experience should make you easier to teach, because experience has already shown you how often certainty eventually becomes obsolete.

Let Older People Teach You Too

The opposite mistake happens just as easily.

New does not automatically mean better.

People who have been solving problems for decades carry lessons that may not appear in documentation.

They remember why certain safeguards exist.

They recognize failure patterns.

They have watched fashionable ideas disappear and return with different names.

Ask them what they learned.

Ask about the failures.

Ask what they would do differently.

Experience is expensive knowledge.

When someone is willing to share it, listen.

Curiosity Connects Generations

The younger person asks:

"Why do we still do this?"

The experienced person asks:

"What happens if we stop?"

That can be an excellent conversation.

One challenges assumptions.

The other supplies history.

Together they may discover a better answer than either would have produced alone.

Curiosity turns difference into collaboration.

Travel Without Moving

You will never visit every place.

Meet every person.

Experience every life.

But human beings discovered something extraordinary.

We can preserve experience.

Books.

Letters.

Research.

Stories.

Music.

Film.

Art.

Recorded conversations.

Documentation.

Someone can spend thirty years learning something and leave enough evidence for you to begin understanding it in an afternoon.

That does not replace experience.

But it gives curiosity reach far beyond one lifetime.

Ask Questions Without Immediate Utility

Not every question needs a business case.

Some things are worth learning because they are interesting.

How does that work?

Why does that happen?

Who discovered it?

What would happen if?

Curiosity sometimes produces value years after the original question.

Sometimes it produces no measurable value at all.

That is okay too.

A life optimized exclusively for immediate utility becomes very small.

Wonder deserves some room.

Protect Wonder

Children can spend an hour investigating something adults walk past without noticing.

A bug.

A rock.

A machine.

A shadow.

A strange sound.

Adults become efficient.

We learn what deserves attention.

That is useful.

It can also make the world invisible.

Occasionally stop.

Look.

Ask.

How does that work?

Why is it shaped that way?

Who built it?

What happened here?

You do not need to turn every observation into a project.

Sometimes noticing is enough.

Curiosity Requires Time

You cannot explore everything while moving at maximum speed.

Some understanding requires sitting with a problem.

Reading beyond the summary.

Following the footnote.

Testing another possibility.

Talking with someone longer than necessary.

Thinking.

Efficiency matters.

But a life with no room for exploration eventually optimizes away discovery.

Leave some unscheduled space for questions whose value you cannot predict yet.

Be Careful What You Think You Know

One of the strange effects of learning is discovering how simplified many early explanations were.

The simple explanation was not necessarily wrong.

It was appropriate for the level of understanding at the time.

Then another layer appeared.

And another.

This should make us cautious.

Some things we confidently understand today may eventually reveal deeper layers too.

That does not mean nothing can be known.

It means knowledge should remain open to refinement.

Certainty Should Be Earned

Different claims deserve different levels of confidence.

Some things are well established.

Some are probable.

Some are plausible.

Some are speculation.

Curiosity respects those differences.

Say:

"I know."

"I think."

"The evidence suggests."

"I don't know."

Those are not interchangeable statements.

Precision about uncertainty is part of intellectual honesty.

Ask Better Questions of Yourself

Curiosity should not point only outward.

Why did that bother me?

Why am I avoiding this?

Why am I defending this decision so strongly?

Why do I want this answer to be true?

What am I afraid of discovering?

What would I do differently if nobody were watching?

What am I pretending not to know?

Those can be uncomfortable questions.

They can also be useful ones.

Systems are not the only things that benefit from honest investigation.

Curiosity Makes Humility Easier

The larger your understanding becomes, the easier it should be to see its boundaries.

Every field contains specialists who have spent entire careers studying a tiny portion of reality.

Then another specialist spent a career studying the layer underneath that.

And another studied the history.

And another studied the consequences.

There is too much to know.

That should not make us feel inadequate.

It should make us grateful that other people know things we do not.

We need each other.

Never Graduate From Learning

School eventually ends.

Training classes end.

Certifications expire.

Projects finish.

Careers change.

Learning should continue.

You do not need a classroom.

You need a question.

Find something you do not understand.

Begin there.

Read.

Ask.

Experiment.

Listen.

Build.

Fail.

Try again.

Then teach what you learned.

And find another question.

The World Is Still Interesting

After enough years, it is easy to become cynical.

You've seen the bad architecture.

The failed project.

The repeated mistake.

The unnecessary meeting.

The technology that promised to change everything.

Then another new idea appears.

It is tempting to dismiss it before looking.

Resist that.

Skepticism is useful.

Cynicism is lazy.

Ask whether there is something genuinely new.

Maybe there isn't.

Sometimes there is.

Stay curious enough to find out.

There Will Never Be a Final Answer

That may sound strange in a book called Solve for 42.

But I think it belongs here.

We want answers.

We build models.

Create principles.

Develop systems.

Write documentation.

Pass knowledge forward.

And then reality gives us another question.

That is not failure.

That is life.

Every generation inherits answers from the one before it.

Then discovers questions those answers could not anticipate.

The work continues.

Closing Thought

Do not allow knowledge to make the world smaller.

It should make the world larger.

Every answer should reveal more connections.

More possibilities.

More people worth listening to.

More assumptions worth examining.

More things worth understanding.

Stay teachable.

Stay willing to change your mind.

Stay willing to become a beginner.

Stay interested.

Curiosity is not the search for one final answer. It is the decision to remain open to the next question for as long as you are capable of asking it.

Founder's Commentary

I Still Want to Know

I have spent a large part of my life asking questions.

Some of them were important.

Some were probably ridiculous.

Some turned into projects.

Some turned into careers.

Some led me down rabbit holes that consumed far more time than they deserved.

And some changed the way I understood everything that came after them.

I don't regret asking.

Curiosity has been one of the constants of my life.

I still want to know.

"I Don't Know" Has Never Been the Problem

There are an extraordinary number of things I don't know.

That list has not become shorter as I have gotten older.

It has become more visible.

When I was younger, knowing a little sometimes made me feel like I understood a lot.

Experience corrected that.

Every layer I learned revealed another layer underneath it.

Every specialty introduced me to people who knew vastly more about some part of it than I did.

Every difficult problem reminded me that systems are usually more complicated than the first explanation suggests.

Eventually, "I don't know" stopped feeling like a problem.

The important question became:

What do I do next?

For me, the answer is usually:

Let's find out.

There is no shame in not knowing. The opportunity begins with what you do after you realize you don't.

I Have Always Wanted to Look Underneath

I have never been particularly satisfied with:

"It works."

I want to know why it works.

What is underneath it?

What talks to what?

Where does the data go?

What happens when this part disappears?

Why was it designed this way?

What happens if I change that?

Sometimes this tendency is useful.

Sometimes it leads directly into a rabbit hole.

I have learned to recognize the difference better over the years.

Not perfectly.

Probably never perfectly.

But I don't want to lose the instinct.

I Like Problems I Don't Immediately Understand

There is something satisfying about encountering a problem where the answer is not obvious.

The easy problems are useful.

They need to be solved too.

But the strange ones are memorable.

The intermittent failure.

The impossible metric.

The configuration that should work but doesn't.

The behavior that contradicts the documentation.

The problem everyone has already investigated.

Those are the ones that make me lean forward.

Something doesn't make sense.

Good.

There is something here to learn.

The Best Problems Change Your Understanding

Sometimes you solve a problem and learn one fact.

A setting was wrong.

A service stopped.

A certificate expired.

Useful.

Then there are problems that change your mental model.

You discover that two systems interact differently than you believed.

You learn that an assumption you carried for years was incomplete.

You discover a dependency nobody documented.

You realize the symptom you had always associated with one cause can come from somewhere completely different.

Those lessons stay.

The system begins looking different because you understand more of what is happening underneath it.

That is one of the rewards of curiosity.

I Don't Want to Be the Person Who Already Knows Everything

I have met people who seem uncomfortable admitting they do not know something.

I understand why.

Experience creates expectations.

Titles create expectations.

Customers expect answers.

Teams expect answers.

Sometimes you expect answers from yourself.

But pretending to know does not create knowledge.

It creates risk.

I would rather say:

"I don't know."

Then start investigating.

If someone else in the room knows, even better.

Teach me.

Some of My Teachers Were Not Teachers

I have learned from managers.

Engineers.

Customers.

Coworkers.

People I mentored.

People who mentored me.

People with decades more experience.

People with almost none.

I have learned from documentation.

Failures.

Bad designs.

Excellent designs.

Arguments.

Incidents.

Experiments.

Mistakes.

And occasionally from something someone said almost casually that changed the way I looked at a problem.

You never really know where the next useful lesson will come from.

That is another reason to keep listening.

Titles Should Not End Curiosity

The farther someone advances in a career, the easier it becomes to live inside what they already know.

That would be a terrible outcome for me.

I don't want experience to become a museum of things I used to understand.

Technology will keep moving.

The next generation will build things differently.

Some of what I know today will become foundational.

Some will become obsolete.

Some will become trivia.

That's fine.

I don't need every old answer to remain valuable.

I need the ability to learn the next one.

Experience should not protect you from becoming a beginner again. It should teach you that you can survive being one.

I Want People to Challenge Me

I have said throughout this book that I want people around me who will challenge my thinking.

Curiosity is part of the reason.

If I am wrong, I want to know.

If there is a better design, show me.

If I missed something, tell me.

If you know something I don't, teach me.

I may ask questions.

I may challenge your answer.

I may make you defend it.

That isn't necessarily disagreement.

Sometimes that is how I learn.

And sometimes, after all the questions, I will still disagree.

That's okay too.

Curiosity does not require universal agreement.

It requires willingness to understand.

Being Wrong Is Useful

I don't enjoy being wrong.

I don't think most people do.

But I have learned to appreciate what being wrong can provide.

Information.

If I expected one result and received another, I just learned something about my model.

Something is missing.

That is useful.

The worst response would be trying to force the evidence to agree with me.

Reality has no obligation to protect my opinion.

So change the opinion.

Change the theory.

Keep the evidence.

The Rabbit Holes Are Part of Me Too

I have spent ridiculous amounts of time investigating things simply because I wanted to understand them.

Some produced useful results.

Some produced ideas years later.

Some probably accomplished absolutely nothing.

I am okay with that.

Curiosity needs boundaries when customers, deadlines, budgets, and responsibilities are involved.

That is why judgment matters.

But outside those boundaries?

Sometimes I want to know just because I want to know.

Not everything interesting needs to become profitable.

Not everything learned needs to become productive.

Sometimes understanding is enough.

Technology Never Ran Out

One of the things I love about technology is that it never runs out.

Every time I thought I understood computers, there was another layer.

Hardware.

Operating systems.

Networks.

Databases.

Distributed systems.

Security.

Cloud computing.

Automation.

Artificial intelligence.

And underneath every category are hundreds more.

Nobody gets to the bottom.

There isn't one.

There is simply another layer of understanding.

For a curious person, that is a pretty good place to spend a career.

Curiosity Became More Important, Not Less

When I was young, curiosity helped me acquire knowledge.

Now I think it serves another purpose too.

It keeps knowledge from becoming rigid.

It reminds me that today's best answer may eventually improve.

That my experience is valuable but incomplete.

That someone else may see something I don't.

That the next problem may not behave like the previous one.

Curiosity keeps experience alive.

Without it, experience can slowly become certainty.

And certainty eventually stops learning.

I Hope I Never Finish

There will probably never be a moment when I look around and think:

That's it.

I understand enough now.

I hope not.

I hope there is always another technology I haven't used.

Another book I haven't read.

Another problem I haven't seen.

Another person who knows something I don't.

Another idea that makes me reconsider something I thought I understood.

Another question.

That sounds like a much more interesting life.

The Question Behind the Questions

After forty-one Principles, there is an obvious temptation to believe we have been collecting answers.

In a way, we have.

Lessons.

Patterns.

Failures.

Practices.

Beliefs earned through experience.

But none of these Principles are intended to end the conversation.

They are starting points.

Ways of thinking.

Things I believe are worth carrying forward.

Someone will improve them.

Someone will challenge them.

Experience may refine them.

The world will certainly test them.

It should.

Because the purpose was never to possess the final answer.

It was to become better at searching for one.

One More Question

And that brings us to the end.

Almost.

Forty-one Principles.

Forty-one attempts to describe things I have learned about engineering, leadership, responsibility, failure, trust, knowledge, people, and the work we leave behind.

There is one Principle remaining.

That seems appropriate.

Because after all the questions in this book, there should be one question left.

Not another technical question.

Not another troubleshooting problem.

Something larger.

After everything we have built...

Everything we have learned...

Everything we have taught...

Everything we have protected...

Everything we have left behind...

What was it all for?

That is a question worth saving for 42.

Never be afraid to reach the edge of what you know. That edge is not where knowledge ends. It is where the next question begins.

Related Principles

Continue the idea.

These Principles share themes with Principle XLI.