Being Honest About What You Know and What You Do Not

There was a period in my career when I felt that experience should make me faster at answering questions.

If someone asked about a technical issue, I wanted to identify the cause immediately. If a client asked whether something was possible, I wanted to give a confident answer. If a discussion moved into an area I only partly understood, I did not want to be the person who slowed it down by saying, “I need to check.”

I thought uncertainty would make me look less capable.

Over time, I learned the opposite.

Some of my least useful answers were the ones I gave too quickly. Some of my most responsible contributions began with an honest boundary: this is what I know, this is what I suspect, and this is what I still need to verify.

Being honest about what you do not know is not the absence of expertise. It is part of using expertise responsibly.

Knowledge becomes more useful when its boundaries are visible.

Confidence is easy to hear

In meetings, confidence is often more visible than knowledge.

A direct answer sounds strong. Technical language creates authority. A clear recommendation gives everyone a sense of progress. Careful language can sound hesitant beside someone who speaks without qualification.

But confidence and correctness are different things.

A person can sound certain and still be wrong. Another person may speak carefully because they understand how many conditions the answer depends on.

This matters in technical work because similar symptoms can have very different causes.

A broken mobile layout may come from CSS, unexpected HTML, CMS content, browser behaviour, cached assets, feature flags, or an environment-specific platform configuration. I may understand the frontend symptom very well and still be unable to confirm the root cause without comparing the actual output across environments.

The honest answer is not always, “I know” or “I do not know.”

Often it is:

I know this part. I have a strong hypothesis about the next part. I cannot confirm the cause until I check the remaining evidence.

That answer is more precise than confidence for its own sake.

Knowledge is not binary

We often talk about knowledge as though it has only two states: you know something or you do not.

Professional knowledge is more layered.

I may have read about a tool but never used it. I may have built a small project with it but never maintained it. I may have maintained it for years but never operated it at large scale. I may understand its technical strengths while knowing little about its licensing, organisational cost, or suitability for a particular team.

These are not equal levels of knowledge.

A responsible recommendation should make the level clear.

When I say I have experience with something, I try to ask myself what that experience actually includes:

• Have I only studied it?
• Have I implemented it in a controlled example?
• Have I shipped it in production?
• Have I maintained it after the initial release?
• Have I seen how it fails?
• Have I used it under conditions similar to the current project?

The last questions matter more than they first appear. It is easy to recommend a technology after a successful demo. It is harder to judge it after upgrades, changing requirements, production incidents, and years of maintenance.

Pretending to know creates more work

A hidden knowledge gap rarely stays small.

An uncertain answer becomes an assumption. The assumption enters a plan. The plan shapes an estimate. The estimate becomes a promise. By the time the original uncertainty is exposed, several people may have made decisions around it.

The cost is no longer only a wrong answer. It is rework, delay, confusion, and damaged trust.

There is also a personal trap. Once we have spoken confidently, we become tempted to defend the answer rather than revise it. Admitting uncertainty later feels harder than admitting it at the beginning.

This is one reason I value the sentence “I need to verify that” much more than I once did.

It protects the quality of the decision before pride becomes involved.

Honest uncertainty should still be useful

There is an unhelpful way to say “I do not know.”

It can be used to step away from responsibility, end the discussion, or leave the problem with someone else.

That is not the kind of honesty I mean.

A useful boundary includes the next step.

For example:

I can confirm the frontend behaviour, but I do not have enough evidence to say whether the cause is in the application code or the production platform configuration. I will compare the generated HTML and network responses first.

Or:

I have used this approach in smaller systems, but not at the scale you are planning. Before recommending it, I would check its operational limits and speak with someone who has run it under similar conditions.

Or simply:

I do not know the answer yet, but I know how to investigate it.

This kind of honesty does not stop progress. It gives progress a reliable direction.

The goal is not to remove uncertainty. It is to place it where everyone can see it.

Experience has made me more careful, not less capable

Earlier in my career, I expected experienced professionals to have immediate answers.

Now I think one sign of experience is knowing when an immediate answer would be irresponsible.

After you have seen a small configuration difference cause hours of debugging, or a simple request affect accessibility, search, content editing, and maintenance at the same time, certainty becomes more expensive.

You begin to ask what evidence supports the conclusion. You separate what is observed from what is inferred. You become careful about applying a solution from one environment to another.

This is not hesitation. It is calibrated confidence.

The strongest professionals I have worked with are not uncertain about everything. They are very clear about which parts are established, which parts are judgment, and which parts need investigation.

Questions are part of the work

People sometimes avoid questions because they believe questions expose weakness.

In practice, unasked questions become hidden assumptions.

A good question can reveal that two people are using the same word differently. It can expose an unavailable dependency, a conflicting goal, or a success condition nobody defined. It can prevent a team from implementing the wrong thing efficiently.

The important distinction is between asking without preparation and asking after thinking carefully.

“Can you explain everything again?” is different from:

“The requirement says the content should be hidden visually. Should it also be removed from the accessibility tree, or does it need to remain available to screen readers?”

The second question does not show a lack of knowledge. It shows attention to a decision the requirement did not make.

Experience has not made me ask fewer questions. It has helped me ask them earlier and more precisely.

Seniority increases the responsibility to be accurate

The more responsibility a person has, the more dangerous unsupported confidence becomes.

A junior developer’s guess may affect one implementation. A senior engineer’s guess may shape an architecture. A manager’s guess may become a delivery commitment. A founder’s guess may influence what a client pays for and what a team spends months building.

This is why honesty becomes more important as authority grows.

People may act on your words because of your role, even when you intended them as a casual opinion. The burden is therefore not to sound certain. It is to signal certainty accurately.

I try to use language that reflects the evidence:

• “I confirmed” when I have verified it.
• “I expect” when experience supports the conclusion but conditions remain.
• “My current hypothesis” when the cause is not proven.
• “I do not know yet” when more information is genuinely required.

These phrases are small, but they help other people make better decisions.

Honesty changes team culture

When experienced people pretend to know everything, others learn to hide uncertainty too.

Problems remain unreported because nobody wants to look unprepared. Questions arrive late. Risks are softened. Meetings produce agreement without understanding.

When leaders state their limits clearly, the opposite becomes possible.

A developer can say that an estimate depends on an unknown integration. A designer can say that a user assumption needs validation. A manager can admit that a priority is still a judgment rather than a proven fact.

This does not make the team less confident. It makes the team’s confidence more trustworthy.

Credibility is not having an answer for everything

No serious professional knows everything in their field.

Frontend development alone crosses browser behaviour, semantics, accessibility, performance, design systems, testing, content platforms, security, analytics, search, deployment, and many other areas. Each of those areas can be a career by itself.

The goal cannot be complete knowledge.

The goal is to understand enough to act responsibly, recognize when the boundary has been reached, and know how to move beyond it without pretending.

I no longer think “I do not know” is the opposite of expertise.

Used honestly and followed by responsible action, it is one of the clearest signs that expertise can be trusted.