This is the third essay in Reckoning with Reality. The previous essay examined the limits of profit. This one turns to a more personal question: why can greater ability sometimes make it harder to reach the facts?
I used to think that avoiding something must look like scrolling on a phone, procrastinating, or doing nothing.
Later I learned that the hardest form of avoidance to recognize is often remarkably diligent. It comes with thorough documentation, elegant architecture, an unbroken commit history, and late nights at work.
The only thing missing is the person who might say no.
Ability Actively Searches for Problems That Suit It
When all you have is a hammer, everything looks like a nail. This is not merely because the hammer is arrogant. The more practical reason is that driving nails gives it definite feedback.
Engineers see disorder and instinctively want to build systems. Skilled writers meet a growth problem and think of content. People with sales experience put more faith in distribution. Those who come from supply chains tend to believe the product determines everything.
Each judgment contains some truth. The trouble is that people overestimate the importance of the part they know and underestimate the parts their existing abilities cannot handle.
The study of organizational learning has a term for this: the “competency trap.” A method that brought success in the past keeps receiving resources and practice, so the organization becomes ever better at it. Exploring a new method looks inefficient by comparison. The more mature an ability becomes, the cheaper it is to call upon. Turning toward an unfamiliar ability means becoming a clumsy beginner again, working inefficiently under the judgment of others.
We therefore reach a comforting conclusion with suspicious ease: the most important problem in front of me happens to be the problem I am best equipped to solve.
The Feeling of Control Is a Powerful Reward
Code has one relative advantage: many errors announce themselves. If performance is poor, it can be measured. If an interface fails, it can be traced. Engineering certainly has intermittent failures, incorrect requirements, and causal chains that resist diagnosis. But compared with a stranger’s silence, I am more familiar with how to narrow these uncertainties.
Markets do not usually provide stack traces.
A user who does not reply may have a weak need. Or the message may be unclear, the timing wrong, the trust insufficient, or the user simply busy that day. A single failure supports many explanations at once. It offers no unambiguous answer and no guarantee that harder work will improve the result.
This ambiguity injures our sense of control. The mind retreats to familiar territory and searches for tasks it knows how to finish. Organizing research, rewriting code, and optimizing a workflow all provide an immediate, legible reward.
The problem is not that these tasks have no value. The problem is that they often leave the decisive uncertainty untouched.
If I do not know whether anybody needs a product, reducing its response time from two hundred milliseconds to fifty will not answer the question. The system improves; the problem remains exactly where it was.
Complexity Can Protect Self-Regard
A simple action is sometimes harder than complicated work.
I went through three rounds of revisions on DayPage’s nighttime capture interface. I rejected the central orb, replaced it with a radial waveform drawn on canvas, then repeatedly removed elements that were too large or too numerous. Every round posed a concrete problem and delivered a feeling of completion. Meanwhile, the question “When is this ready to place in more people’s hands?” remained far less clear. Deletion was within my power. Delivery meant letting someone else decide whether any of those deletions mattered.
The experience taught me that sending an imperfect proposal to a stranger may be technically trivial. Waiting to see whether they respond can strike directly at one’s self-regard. Building an automated system may take two weeks, but if it fails, the failure can still be blamed on the technology, the time, or the resources.
Complexity gives failure more places to hide.
If a project is large enough, we can always say the timing was wrong, the features incomplete, or the team understaffed. A simple experiment that nobody pays for leaves far fewer excuses.
This is also why intelligent people are drawn to grand problems. Grand problems sound important and are difficult to falsify. A person can labor for years toward “transforming an industry” without answering why one specific customer will not buy today.
Ability becomes armor. It helps me produce results, and it keeps me from touching the parts where I am unskilled, exposed, and liable to embarrassment.
Sunk Costs Begin to Argue for the System
Building too early creates another danger: it changes the judgments that follow.
If a prototype took one day, it is easy to stop when nobody uses it. After investing three months, admitting that the direction is unsound also means admitting that a large amount of work failed to create the value we expected.
People find it hard to evaluate their own past this way. The definition of success begins to move. No paid users? Look at registrations. No registrations? Look at visits. Few visits? At least we learned a lot technically.
Learning does have value. But when the goal quietly shifts from commercial validation to personal development, the project is answering a different question even while we continue to describe it as progress.
The more complete a system becomes, the more reasons it creates for its own maintenance. Code needs upgrades. Documentation needs revisions. Old decisions demand compatibility. Something built to serve demand begins to manufacture demand of its own.
It is like tending a station with no passengers. Eventually, most of the work consists of maintaining the station, which makes it all the more necessary to believe that a train will someday arrive.
Invert the Problem: How Can I Make Sure I Never Meet a User?
Instead of asking how to succeed, begin by asking how to guarantee failure.
If I wanted to make sure that a product never encountered real demand, the most reliable program would probably be:
- Delay the first delivery until the system is complete.
- Discuss it only with friends who agree with me.
- Measure progress using tasks under my control.
- Add features whenever results fail to appear.
- Explain unwillingness to pay as the user’s failure to understand the value.
Combined, these practices can keep an intelligent and diligent person working for a very long time while learning almost nothing new.
The remedy, viewed in reverse, need not be grand. It usually means changing the order: expose the result to external judgment first, then decide which abilities deserve further investment.
Ability Should Grow Where the Friction Is
I now set a plain threshold for production-grade system building: has the same action occurred in reality, and has repetition begun to create a definite loss?
If the process has not occurred, automation is probably solving an imagined problem. If it has happened only once or twice, manual work is usually the cheaper way to learn. Once repetition is slowing feedback, increasing error, or damaging delivery, engineering ability has found its proper place.
There are important exceptions. Lost data cannot be recovered. A security incident cannot simply be treated as a lesson after the fact. A compliance error can end the game, and migration costs compound over time. These areas deserve forethought. The purpose of early judgment is to prevent irreversible loss and preserve options. The mistake of premature construction is building every option at once for a scale that does not yet exist.
A good system is like a callus: it grows where friction has returned again and again. Pain arrives first, so the body knows where protection is needed.
The Other Side of the Circle of Competence
The circle of competence is often understood as “do only what you understand.” That principle is useful for limiting major commitments, but it should not prohibit inexpensive learning. It has another, less discussed side: knowing when your advantage is interfering with your ability to observe.
It is prudent to place large bets inside one’s circle of competence. It is equally important to enter a state of temporary incompetence in order to acquire new facts. The comfort zone describes how something feels; the circle of competence describes the boundary of what one knows. They are not the same. Leaving comfort does not automatically expand competence. The boundary moves only when we return with feedback.
When my friend said, “Become the user first,” he was not asking me to abandon engineering. He was asking engineering to speak later. First observe how people in the field muddle through their work, which frustrations recur, and which costs someone actually bears.
The greatest waste of ability is not leaving it unused. It is applying it with precision to a problem that does not matter.
Responses