- Limits and Humility — Learning to Be Finite
- Designing Within Constraints
- Blessed Are the Poor in Spirit (Matt 5:3)
- Avoiding Tech Arrogance: A Posture of Learning
Technical knowledge can be empowering.
The first time we solve a difficult problem, understand a complex system or become the person others ask for help, confidence grows. That confidence can be useful. Good work often requires clear judgement, decisive action and the courage to recommend a direction.
But confidence can quietly become something else.
We stop saying, “I think.”
We stop asking, “What might I be missing?”
We begin assuming that experience has made us immune to error.
Technical arrogance rarely announces itself dramatically. More often, it appears in small habits: dismissing a junior colleague, ignoring user feedback, refusing to revisit an architectural decision or treating disagreement as evidence that someone else does not understand the problem.
The danger is not merely that arrogance makes us unpleasant to work with.
It makes our work less reliable.
Expertise Does Not Remove Our Limits
Experience matters.
A skilled engineer can recognise patterns that a beginner may miss. Years of practice create intuition. Familiarity with systems helps people diagnose faults, anticipate risks and make better decisions.
Yet expertise does not remove human limitation.
No one sees every consequence.
No one understands every user.
No one remembers every detail.
No one is free from bias.
The more complex a system becomes, the less realistic it is for one person to understand the whole of it. Modern software may depend upon frameworks, cloud services, third-party packages, external APIs, inherited databases and business rules created long before the current team arrived.
Expertise should therefore increase humility, not eliminate it.
The more we learn, the more clearly we should see how much remains unknown.
The Seduction of Being the Expert
Being recognised as knowledgeable feels good.
People listen.
Questions are directed towards us.
Our opinion carries weight.
This can gradually become part of our identity. We no longer simply possess expertise; we need to be seen as the expert.
Once that happens, uncertainty becomes threatening.
Admitting that we do not know may feel like losing status. Changing our mind may feel like weakness. Someone else’s better idea may feel like a challenge rather than a contribution.
The result is defensive decision-making.
Instead of asking which solution is strongest, we protect the solution associated with us.
Instead of welcoming correction, we explain it away.
Instead of helping others grow, we keep knowledge concentrated around ourselves.
A team may still appear productive for a while, but it becomes fragile. People stop raising concerns. Junior colleagues learn to remain silent. Mistakes survive longer because challenging them feels unsafe.
Certainty Can Be More Dangerous Than Ignorance
Ignorance is not always the greatest technical risk.
Unrecognised ignorance is worse.
A person who knows they are uncertain may investigate, test and seek advice. A person who is falsely certain may move quickly in the wrong direction.
This is why phrases such as these are valuable:
- “I may be wrong.”
- “Let us test that assumption.”
- “What evidence would change our minds?”
- “Can someone review this?”
- “How does this behave in production?”
- “What have users actually experienced?”
These are not signs of incompetence.
They are signs of disciplined thinking.
Good engineering does not require us to doubt everything endlessly. It requires us to distinguish between what we know, what we infer and what we merely assume.
Learning From Junior Colleagues
Technical arrogance often appears in how experienced people respond to beginners.
A junior developer may ask a question that seems obvious.
They may suggest an approach that has already been tried.
They may misunderstand part of the system.
It is easy to respond impatiently.
Yet beginners also notice things experienced people have stopped seeing.
They may question a process everyone else has accepted without thought. They may bring knowledge from newer tools, recent training or another industry. Because they are not yet immersed in the team’s habits, they may identify assumptions that have become invisible.
A healthy team does not pretend every suggestion is equally good.
It does, however, make every person safe enough to contribute.
Explaining why an idea will not work is different from mocking the person who offered it.
Technical leadership should increase the confidence and capability of others, not merely demonstrate the superiority of the leader.
The Value of Peer Review
Code review is often described as a quality-control process.
It is also a practice of humility.
Submitting work for review means accepting that another person may see something we missed. Reviewing someone else’s work means approaching it carefully rather than using the process to display authority.
The best reviews focus on the work, not the worth of the person.
They ask questions.
They explain risks.
They distinguish required changes from personal preferences.
They recognise good decisions as well as problems.
Peer review works best when everyone, including the most experienced team members, participates. If senior people are exempt from challenge, the review process becomes a hierarchy rather than a safeguard.
No one should be too important for their work to be examined.
Architecture Is Not Personal Identity
Technical decisions can become strangely emotional.
Frameworks, programming languages, database designs and architectural patterns are tools. Yet people sometimes defend them as though criticism of a choice were criticism of their character.
This is especially common when someone has invested significant time in a system.
The architecture becomes “my architecture.”
The migration becomes “my plan.”
The product becomes “my vision.”
Ownership can produce care, but it can also make revision difficult.
A humble engineer can separate personal worth from a technical decision. They can say:
“This was reasonable based on what we knew then, but the situation has changed.”
That sentence is not an admission of failure.
It is evidence of maturity.
Good decisions are always made within a particular context. New information, increased scale, changing user needs or emerging risks may justify a different approach later.
Listening to Users
Technical arrogance does not only affect relationships within development teams.
It can also shape how engineers treat users.
Users may describe a problem imprecisely.
They may call a page “the database” or describe an error message as “the internet disappearing.” Their explanation may not match the internal structure of the system.
It is tempting to conclude that they do not understand.
Technically, that may be true.
But users understand their own experience.
They know where they became confused.
They know which task they could not complete.
They know when a process made them feel excluded, anxious or powerless.
Our role is not to demand that users describe problems in engineering language. Our role is to listen carefully enough to translate their experience into technical understanding.
When many users struggle with the same feature, the problem is rarely that all of them need to become better users.
Humility in Debugging
Debugging exposes the limits of our understanding.
We begin with a theory.
The logs appear to support it.
We change the code.
The fault remains.
At this point, pride can make the process longer. We become attached to our first explanation and interpret every new detail through it.
Humility allows us to reset.
What do we actually know?
Which assumptions have not been tested?
Can we reproduce the issue?
What changed recently?
Is the failure occurring in the place we think it is?
Some of the most time-consuming bugs survive because someone was certain they knew where the problem could not be.
A posture of learning remains open to surprise.
The Limits of Metrics and Models
Data can create its own form of arrogance.
Dashboards, models and statistical outputs appear objective. Numbers can make decisions feel indisputable.
But every metric reflects choices.
Someone decided what to measure.
Someone chose which records to exclude.
Someone defined success.
Someone selected the time period.
A model may be mathematically impressive while still reflecting incomplete, biased or outdated data.
Humility in data work means asking what is absent as well as what is present.
It means recognising that a precise number can still be misleading.
It means listening when lived experience conflicts with the dashboard.
Evidence should guide us, but we must remain honest about what the evidence can and cannot establish.
Saying “I Don’t Know”
Three words can transform a technical culture:
“I don’t know.”
Used responsibly, they do not end the conversation. They begin investigation.
“I don’t know, but I will find out.”
“I don’t know enough about that area; let us involve someone who does.”
“I don’t know whether this will scale; we should test it.”
These statements make work safer because they expose uncertainty before uncertainty becomes failure.
Pretending knowledge may protect our image temporarily, but it transfers risk to users, colleagues and organisations.
Honesty is more valuable than the appearance of certainty.
Building a Posture of Learning
Humility is not a feeling we wait to develop.
It can be built through practice.
Keep notes on decisions and revisit them.
Invite review before work feels finished.
Ask quieter team members for their perspective.
Read outside your preferred technology stack.
Treat incidents as opportunities to understand systems rather than occasions to find someone to blame.
Pay attention to questions that make you defensive.
Notice when you are speaking to prove expertise rather than solve the problem.
Learning requires more than consuming information. It requires becoming correctable.
Confidence and Humility Belong Together
Humility does not mean becoming hesitant about everything.
Teams need people who can make decisions.
Users need clear recommendations.
Leaders sometimes need to choose a path before all uncertainty has disappeared.
The goal is not insecurity.
It is grounded confidence.
Grounded confidence says:
“Based on the evidence available, this is the direction I recommend.”
Arrogance says:
“This is obviously the only sensible answer.”
Grounded confidence can explain its reasoning, acknowledge trade-offs and change when new evidence emerges.
It is strong enough to remain teachable.
The Invitation
Consider the way you hold your technical knowledge.
Does expertise help others grow, or does it create distance?
Can colleagues question your decisions safely?
When did you last change your mind because someone else offered better evidence?
Do you listen to users whose language is imprecise but whose experience is real?
The technologies we use will change.
Frameworks will be replaced.
Best practices will evolve.
Systems we once considered modern will become legacy systems.
A posture built entirely upon being right will eventually become brittle.
A posture of learning can continue growing.
Bring confidence to your work.
Use the experience you have gained.
Make decisions responsibly.
But leave room for correction.
Ask better questions.
Welcome review.
Listen carefully.
Say “I don’t know” when it is true.
Because the strongest technical professionals are not those who have stopped learning.
They are those whose knowledge has made them more curious, more generous and more aware of their limits.
That is not weakness.
It is wisdom.
