Aperture of mastery
What practice teaches depends on what the exercise asks of us.
By André Givenchy
One of the most striking results in the study of practice came from a college student learning to remember strings of numbers.
After more than 230 hours of laboratory practice, his digit span had grown from seven to seventy-nine. He had developed ways to organize the numbers, drawing partly on his knowledge of running times. A sequence that would otherwise be difficult to retain could become something familiar enough to retrieve.
It is easy to stop at the improvement and make this a story about persistence. The researchers did something more useful. They examined what had improved.
In a separate test three months into the training, they switched from digits to letters. His span fell back to about six consonants. The result did not erase his progress with numbers. It located that progress. Ericsson, Chase, and Faloon's 1980 paper describes a learned memory skill, not a general expansion of every capacity we might call memory.
That is one person doing one laboratory task. It cannot supply a universal method for creative work. But it offers a useful interruption to the way we talk about getting better.
Ericsson, Chase, and Faloon's 1980 paper(opens in a new tab)
Better at what, exactly?
A designer can become faster at arranging a familiar kind of screen without becoming better at deciding whether the screen is needed. A founder can become fluent in explaining the company without becoming more accurate about why someone buys. In both cases, the improvement may be genuine. The danger lies in asking it to stand for a different ability.
This matters when we design our routines. A protected hour, a daily sketch, a weekly critique. Each creates an opportunity to practice, but none decides what the practice will teach. If the exercise rewards finish, it can train finish. If it rewards speed, it can train speed. We still have to ask whether the rewarded performance is the one the work requires.
Consider a team reviewing a prototype. If the review ends when the screen looks convincing, the review does not require the team to discover what happens when someone cannot complete the task. If the review asks a person to use it, the team encounters a different kind of information. The design may be beautiful and still require a decision the person does not understand.
These are different exercises, and both can be worthwhile. Visual judgment is not trivial. Nor should every sketch become a research project. Some practice should isolate a small skill precisely because attempting the whole job would make the feedback impossible to interpret.

The distinction is between choosing a narrow exercise and forgetting that it is narrow.
A useful practice has a route back to the larger work. After developing the isolated skill, you put it under conditions that can expose its limits. The screen must work with real content. The explanation must survive a question it was not written to answer. The familiar technique must earn its place when the constraint changes.
This makes routine less reassuring than a streak on a calendar. It may reveal that you have spent a month improving something that was never the main difficulty. That is unwelcome information, but it is information you can use. Another month of the same exercise would not make it less true.
Discipline gives practice a place in the day. Judgment decides what belongs in that place. The two support each other only when the routine leaves room for the work to disagree with what you thought you were learning.

Dear Segern
Advice for intentional people
I keep working through JavaScript lessons, but I forget earlier ideas before I use them. How do I know whether to keep studying or start a project?
André GivenchyFounder, Segern
Try a small piece of work that requires one of the things you have just studied. Keep it small enough that you can tell where you get stuck. A page that filters a short list is a better test of that skill than a plan to build an entire application.
Before opening the lesson again, write down what the page needs to do. What enters? What should change? What should appear when there are no matches? You may discover that you understand the problem but cannot remember the syntax. Looking up an array method is different from needing someone else to decide what the program does.
If the missing part is the decision itself, return to a worked example with that question in mind. Then close it and make a small change the example did not cover. The change gives you something to explain, rather than another sequence to reproduce.
Finishing the project will not establish that you can build anything. It can show you which parts you can now carry into a less guided task, and which still need attention. Use that information to choose the next lesson.
If several concepts are unfamiliar at once, an isolated exercise may be the kinder and more useful choice. Keep a route back to the project so that the exercise remains connected to what you want to make.
Have a question of your own? Send a question to Segern↗(opens in a new tab).
segern.principles
About Segern↗- 01
Let real work guide what you practice.
Attempt something small and meaningful. Notice where your understanding, judgment, or skill falls short, then practice that part and try again. Check your progress through what you can do and explain, not just what feels familiar.
- 02
Handle the edges on purpose
Plan for empty, loading, error and extreme cases so the experience remains understandable and usable.
- 03
Make your reasoning legible
Make the reasons for a decision traceable rather than leaving them implied.
segern.design
Designs worth a closer look.



