← All issues
AIRING’S CORRESPONDENCELetters · Questions · Replies

Some questions return.
So do the words that help.

EchoA JOURNAL OF LETTERS & REPLIES
No. 05
Learning & creating2 exchanges · 4 themesReplies by Airing

No. 05 / Learning & creating

As tools get faster, how does judgment endure?

Code arrives more quickly, but you worry you can only accept an answer that looks right.

A watercolor illustration of Airing’s bear. Tools make things faster. Judgment takes practice.
Tools make things faster. Judgment takes practice.
Airing · From a reply, translated · 21 Mar 2026Read this reply ↗
to consolidate your understanding and cultivate judgment.

Use the speed tools provide to understand, verify and transfer what you learn.

Start with your questionContents +

Let one completed task leave understanding you can use on the next.

In March 2026, Shutong asked about direction amid changing roles. Earlier, Yuanshan had asked how to learn technology deeply. This is my reading of the two replies together: predictions stay in their historical context, and the practical exercises are extensions made for this essay.

01 Reading notes

Separate a changing environment from a verdict on yourself.

Shutong's letter asks two questions. One concerns living with composure; the other concerns keeping a job as technology changes. In his mind they were connected: being unable to see the industry's future meant his inner foundation was weak. I could feel that accumulated pressure, but did not want to charge one person's character with all the uncertainty an environment creates.

I responded first to how he saw himself, then to tools and career preparation. This does not mean a change in outlook can change the market. It means that “I am simply incapable” need not close off possible action in advance. Sensitivity can increase worry, but it can also help someone notice needs, feedback and details others miss.

The reply predicted changes in the boundaries between roles over the following two years. Revisiting it, I place that judgment explicitly in March 2026, rather than present a developing situation as an accomplished fact. Readers need not accept every part of my prediction to have reason to practice judgment and learning across fields. Those abilities can be tested in tasks already at hand.

I would therefore make the anxiety more specific: which kind of work am I afraid will disappear, and in which current task can I not independently judge the result? The first may have no immediate answer; the second can point to a concrete exercise. Bring the problem within reach of observation to identify what needs work, rather than endlessly expand the list of things to catch up with.

02 Reading notes

After producing the result, complete the act of judgment.

In the reply I suggested trying new tools, bringing them into work and life, and using them to develop yourself. There is another important phrase: consolidate understanding and cultivate judgment. If all you record is how many products you have tried, familiarity with interfaces can easily pass for deeper understanding of a problem.

For a small existing task, I would first write down the conditions it must meet, then involve the tool. Once a result arrives, the comparison concerns more than speed or code length: are those conditions actually satisfied? Which inputs were missed, where might it fail, and what changes in another environment? This is an exercise developed from the letter, not a claim that the original reply reported completed tests.

When something fails, avoid simply returning the error to the tool until one version stops complaining. Try to retain at least one explanation: what was the earlier assumption, which observation contradicted it, and why is the change relevant? Even if a tool ultimately completes the task, understanding can remain with you.

This does not require investigating every underlying principle on every occasion. Choose one important, bounded uncertainty and verify it carefully. Explaining which conditions you have checked and which remain unchecked is itself part of judgment. It supports the next decision better than a general “the tool made it, so it should be fine.”

Airing · From a reply, translated · 21 Mar 2026
to consolidate your understanding and cultivate judgment.
Open this letter

03 Reading notes

Start at the limits of use. Ask how the approaches differ.

Yuanshan had asked why experience with hardware, software, frontend and backend work still left him feeling proficient in none. My suggested sequence was to learn how a technology works in a small project and where its limits lie, then explore principles, similarities and possible improvements. That earlier reply gives judgment a more concrete starting point.

I would not measure depth by the number of tools learned. When two approaches deliver the same feature, the useful question is under which conditions each is suitable. One may be easier to change, another less resource-intensive. These differences mean something only in relation to goals and constraints. Memorizing advantages and disadvantages alone may not help with a real choice.

When tools can rapidly produce several implementations, I am more willing to slow down for the comparison. Choose one dimension that matters to the task, understand what each approach does, and use a small observation to test your guess. The aim is not to crown an eternal winner, but to leave an explainable reason for this decision.

Writing down that reason also exposes gaps. If all you can say is that an approach is more advanced, without naming the present problem it solves, further investigation is worthwhile. Growth can happen precisely here: moving from a familiar judgment to identifying conditions, evidence and what is still unknown.

04 Reading notes

Transfer an understanding. Do more than learn another name.

My reply to Shutong also suggested trying other fields outside work and using AI to study across disciplines systematically. This does not demand immediate competence in every role. I would rather see a small attempt beyond familiar boundaries that he can both complete and explain, revealing what prior experience transfers and what needs learning anew.

Start with something that has a clear purpose, such as a small tool for information you repeatedly organize by hand. If the interface is unfamiliar, use it to understand input and feedback. If data processing is unfamiliar, trace how the data changes. A specific goal keeps learning across fields from becoming another collection of courses.

Afterward, I would keep a short record: what did I expect to be similar, what proved different, and which principles still worked? This can turn an accidental success into experience deliberately available next time. It also becomes easier, in an unfamiliar area, to know whom to ask and which assumption needs checking.

Tools can shorten the route to a first attempt, but cannot decide how deeply I want to understand it. I hope some of the time saved by speed can go to apparently slower acts: explaining, comparing, verifying and looking back. They may not immediately yield a new title, but can give me a more concrete foothold when the next change arrives.

Correspondence / Learning & creating

The letters

Two readers. Two exchanges.

From email correspondence · Reader aliases · Complete anonymized translations

ECHO / PASS IT ON

Share this issue

The cover of this issue of Echo