Being Honest About What You Know and What You Do Not

Earlier in my career, I wanted to answer technical questions quickly. A confident answer seemed like evidence that I understood the subject. Saying “I need to check” felt like admitting that I was not experienced enough.

That instinct is understandable, but it can create the wrong kind of pressure. A familiar symptom is not always a familiar cause. A tool that worked in a small project may have different consequences at scale. A decision that seems obvious from a design may depend on a requirement nobody has stated.

Experience has made me more comfortable distinguishing what I have observed, what I reasonably suspect, and what I cannot yet verify. Those distinctions are not excuses to avoid making decisions. They make it possible to make a decision without claiming more certainty than the evidence supports.

Confidence is not the same as knowledge

In a meeting, a short direct answer usually sounds stronger than one with conditions. But speaking fluently about a technology is not the same as knowing whether it is suitable for the current problem. A confident claim can travel into a proposal, a delivery plan, or an estimate before anyone has tested its assumptions.

Consider an illustrative frontend defect that appears only after deployment. The layout works locally, but the released page looks wrong on a particular mobile viewport. It would be easy to declare that a CSS selector is responsible. That may be true, yet different HTML, cached assets, content length, browser behavior or a platform integration could produce the same visible symptom.

A more accurate statement is: “I can confirm the rendering problem. CSS is one plausible cause, but I need to compare the deployed markup and computed styles before saying which change will resolve it.” It names an observation, a hypothesis, and the next test.

That answer may not satisfy someone who wants certainty immediately. It is still more useful than a confident fix for an unconfirmed cause.

Experience has levels, not just a yes-or-no label

When someone asks whether I know a framework or architecture, the honest answer often needs more detail than “yes.” I might have read its documentation, built a prototype, deployed one small feature, maintained a production system, or worked through an upgrade that exposed its limits.

Those are different kinds of experience. None should be dismissed, and none should be presented as equivalent. Studying a tool can support a thoughtful comparison. Maintaining it through change gives evidence about operational costs. Working in one environment does not automatically prove how it will behave in every other environment.

For a technical recommendation, I find it useful to be clear about four things: what I have used directly; what I understand from documentation or other evidence; what I am inferring about this specific project; and what needs a test or another person’s expertise.

This is particularly important when a recommendation touches responsibilities beyond one developer’s role. I can understand how a form behaves in the browser while still needing a backend or operations colleague to confirm its storage and delivery guarantees. I can assess a CMS’s interface without claiming that I understand every licensing or infrastructure consequence.

An unknown is useful only when somebody can act on it

There is an unhelpful way to acknowledge uncertainty. Saying “We need more information” can end a conversation while leaving the problem unchanged. If nobody knows which information is missing or who will obtain it, the uncertainty simply moves into the next meeting.

I prefer a smaller, testable statement. For example: “We know the frontend submitted the request. We do not know whether the receiving service accepted it. I will check the response and the receiving record, and we can decide after those observations.”

This is not a claim that every unknown can be solved by one quick test. Sometimes access is missing, an external provider must answer, or available data is fundamentally incomplete. In those cases the next useful action may be to identify the dependency, describe the decision we can safely make now, and name what would change it later.

A responsible uncertainty statement therefore has three parts: the boundary of current knowledge, the evidence needed to cross it, and the owner or condition for the next decision. Without those parts, “I do not know” may remain truthful but still fail to help.

Do not turn assumptions into commitments

A hidden assumption often becomes more expensive as it moves through a project. Someone guesses that a service response is reliable. The implementation plan assumes that response is always available. The estimate treats the integration as straightforward. The delivery promise is then built on a condition nobody verified.

When the condition fails, everyone can point to a reasonable explanation, but the team has already paid for the uncertainty. Identifying the assumption early would not necessarily have prevented the problem. It might have changed the scope, sequencing, contingency or wording of the commitment.

I try to express estimates and recommendations in terms that decision-makers can use. For example: “This estimate covers the new frontend interaction with the documented API. We have not tested the older template against the new asset, so compatibility verification remains a separate task.”

A conditional estimate is not weaker merely because it has conditions. It is weaker if those conditions are hidden and the number is presented as certain.

Honesty should not become a performance of hesitation

Being careful does not mean qualifying every sentence or avoiding a recommendation until nothing is unknown. That would make expertise less useful. Professionals are often asked to act with incomplete information, and a defensible decision can still be made.

The distinction is between material uncertainty and detail that does not change the decision. If two implementation options have the same cost and risk under the known constraints, a small untested styling difference may not matter yet. If the choice could break a live checkout or invalidate a reported result, the missing evidence deserves attention.

Sometimes I can make a direct recommendation: “Use the existing component because the interaction contract is unchanged and its tests cover this state.” At other times I should say: “Separate these components because the business rules have diverged; here is the evidence and the cost of maintaining one conditional implementation.”

The point is not to sound uncertain. It is to calibrate the strength of the recommendation to the strength of the evidence.

The questions we ask reveal what we understand

Unasked questions often turn into accidental requirements. “Hide this content” could mean remove it visually, remove it from the accessibility tree, or remove it from the document entirely. “Save the form” could mean show a confirmation locally, accept the request on the server, or make it available to the team receiving it.

A question like “Should hidden content remain accessible to screen readers?” does not show that the engineer is uninformed. It identifies a missing decision that changes the implementation.

Good questions are specific enough to make progress. They say which assumption is being tested, which decision depends on it, and what would count as a useful answer. The worst version of curiosity collects details without changing the plan.

Seniority makes accuracy more consequential

People often rely more heavily on statements made by experienced colleagues, reviewers, managers or founders. That authority can save time when it is well founded. It can also magnify the damage of unsupported certainty.

A junior engineer’s hypothesis may affect one local fix. The same unverified assumption, expressed as a senior recommendation, might become an architectural choice or delivery commitment. That is why the responsibility to distinguish facts from inferences grows with influence.

I also think leaders make it easier for others to report uncertainty when they do it themselves. If the most experienced person can say “My earlier assumption was wrong; here is the new evidence,” then correction becomes part of the work rather than an embarrassment to conceal.

The goal is neither false confidence nor constant doubt. It is a team that can revise a decision when reality provides better information.

A useful way to state what you know

When a recommendation matters, I try to reduce it to a clear sequence. First: what have we observed? Second: what explanation or option does that evidence support? Third: what do we still not know? Fourth: what check would change our recommendation?

This makes an answer easier to challenge constructively. Colleagues can question the observation, add a missing constraint, or suggest a better test. The conversation becomes about improving the conclusion rather than defending the person who first stated it.

I no longer think saying “I need to verify that” reduces my credibility. Said without preparation, it can be unhelpful. Said with a clear boundary and an actionable next step, it is one of the ways professional judgment becomes trustworthy.