The Power of Order and Sequence — What You Do First Changes the Result

• Opening — The Order I Learned at the Table Tennis Table
• Core Insight — Same Ingredients, Different Order, Different Result
• Going Deeper 1 — Reading Precedence and Dependencies
• Going Deeper 2 — Priority and Sequencing Are Different
• Going Deeper 3 — Building From the Foundation
• A Worked Example — Sequencing Six Months of Learning Japanese
• Application 1 — In Learning
• Application 2 — In Work
• Application 3 — In Communication
• First Principles and the Critical Path — What Must Be Solved First So the Whole Unlocks
• The Psychology of Order — Why We Resist the Right Order
• Pitfalls and Balance — The Trap of Never Starting Because of Order Obsession
• Another Pitfall — Pouring Time Into the Wrong Foundation
• A Collection of Order Anti-Patterns
• Order Within a Day — Sequencing Your Energy
• A Counterpoint — Sometimes Order Matters Less
• A Retrospective — Two Experiences of Redoing Something With a Changed Order
• Order in Habits — Attaching the Small Thing First
• Before the Closing — Training the Eye for Order
• Communication Again — The Order of Documents and Persuasion
• A Practical Framework — The SEQUENCE Check
• Practice Checklist
• Frequently Asked Questions
• Closing — Same Effort, Different Destination
• References

Opening — The Order I Learned at the Table Tennis Table

I play table tennis as a hobby. When I first started, my ambition was clear. I wanted to overpower opponents with one spectacular drive. So even though my basic strokes were shaky, I obsessed over practicing powerful smashes. The result was dismal. The ball kept catching the net or flying off the table, and my skill barely improved.

My coach said one thing. "If you drive before your forehand stance is stable, you are just adding power to a wrong posture. Your order is backward."

That line stayed with me. Even with the same practice hours, what you learn first completely changes your skill a year later. A powerful smash from someone who built their fundamentals first becomes a weapon, but a powerful smash learned without fundamentals becomes a bad habit that is hard to fix.

This essay grows from that realization. We usually fixate on "what to do," but the deeper variable that decides the outcome is "what to do first" — order and precedence. Let us look at how order changes results in software, in learning, in work and communication, and how obsession over order becomes a trap.

Core Insight — Same Ingredients, Different Order, Different Result

Think of cooking. With the same ingredients, the flavor changes completely depending on whether you saute the onion first or the garlic first, and when you add the salt. The ingredient list is only part of the result; the order decides the rest.

Many things in life are like this. Writing a list of tasks is easy. The hard part is in what order to arrange them. Order matters for three main reasons.

First, dependencies. Some work can only begin once other work is finished. Without a foundation, the application collapses.

Second, compounding. When earlier work makes later work easier, a good order yields a larger result from the same effort.

Third, irreversible cost. Some choices are hard to undo once made. An order that does the reversible things first and the irreversible things later reduces risk.

Of these three, compounding deserves a second look on its own. Compounding does not work only with money. What you learn first speeds up how fast you learn the next thing, and learning more at that faster pace accelerates the thing after that. This is why, in learning, you memorize high-frequency words first. Once you know a few hundred frequently used words, most of the sentences you meet afterward become "one or two unknown words among words you already know," which sets off a virtuous cycle of guessing new words from context and absorbing them naturally. Conversely, if you start from low-frequency words, sentences stay blocked as a whole and this virtuous cycle never begins. That is why memorizing the same number of words splits into different results depending on order.

Where compounding is at work, "doing it first" matters more than "doing more of it." So when I design an order, I always ask one question. Among these tasks, which one, if done first, makes the rest easier? Simply pulling that one forward raises the efficiency of the whole.

Going Deeper 1 — Reading Precedence and Dependencies

To design an order you first have to see "what depends on what." Software build systems contain this concept directly. To compile a file, the libraries it depends on must be ready first. The map of these dependency relationships is a dependency graph, and unrolling it in the correct order is called topological sort.

It sounds grand, but the principle is simple. If task A must finish before task B, put A ahead of B. Line everything up so this rule holds for all tasks, and you get an order that proceeds without getting stuck.

The questions for finding dependencies in daily life are these.

• What must already be finished before I can start this?
• What becomes possible only once this is finished?
• Is the real cause of the task stuck right now actually that an earlier step is unfinished?

When I face a daunting project, I write tasks on cards and draw "this first" arrows between them. Then I can see where to start. The starting point is usually a task that depends on nothing — a card with no incoming arrows.

Explaining it only in words stays abstract, so let me actually draw a small side project as a dependency graph. Suppose I am building a personal expense-tracker web app. Read each arrow as "the left must finish before the right can start."

[Gather requirements]
       |
       v
[Design data model] ---------------+
       |                           |
       v                           v
[Build DB schema]          [Screen wireframes]
       |                           |
       v                           v
[Implement backend API] <----- [Frontend skeleton]
       |                           |
       +-----------+---------------+
                   |
                   v
            [API integration]
                   |
                   v
            [Integration test]
                   |
                   v
               [Deploy]

A few things surface in this picture. First, the starting point is "gather requirements." It has no incoming arrows, so it depends on nothing. Second, once "design data model" is finished, two branches (schema, wireframes) open at the same time. That is, these two can proceed in parallel. Third, "integration test" and "deploy" depend on nearly every earlier step, so they sit at the very end.

The interesting part is that before drawing the graph, the urge to "just start with the API" was strong. Writing code feels like the most "real work." But if you write the API first while the data model is still shaky, you end up tearing the API apart every time the model changes. The graph stops that urge and points to the real starting point.

Going Deeper 2 — Priority and Sequencing Are Different

Priority and sequencing are often confused, but they are different concepts.

Priority asks "what is more important." Sequencing decides "what to do first." The most important task is not necessarily the one to do first. If the most important task depends on other preparatory work, you have to do that preparation first.

The Eisenhower matrix is useful for sorting priority. It splits work along two axes, importance and urgency.

But this matrix only tells you "what." "What first" comes from the dependency graph. You have to use both. First narrow down to important tasks, then within those build the order by dependency.

Going Deeper 3 — Building From the Foundation

Like the basic stroke in table tennis, almost every field has a foundation that holds up what comes later. Skip the foundation and you may look faster for a moment, but you soon hit a ceiling.

Learning science offers several concepts that support this. Cognitive load theory says working memory has limited capacity. If basic concepts are not sufficiently automated, processing them fills working memory, leaving no room to learn the application. Conversely, when fundamentals become second nature, that freed-up room lets you handle more complex things.

Take mathematics. Teaching equations to a student shaky on fractions moves the syllabus forward but collapses understanding, because the earlier step of fractions is a dependency of the later step.

That said, "from the foundation" does not mean "only after every foundation is perfectly finished." That is a trap I will address later. The key is the balance of building enough foundation to support the next step while not getting paralyzed by perfectionism.

A Worked Example — Sequencing Six Months of Learning Japanese

Let me unfold the theory into an actual order. I will use the six-month plan I drew up when I picked Japanese back up from scratch. The core was not "what to study" but "in what order to stack it."

First, look at the wrong order people commonly fall into. Many start like this. They work through a thick grammar book from chapter one in order, memorize a wordlist alphabetically, and put off conversation until "their skill is good enough." The problem with this order is clear. Alphabetical words have nothing to do with frequency, the advanced patterns at the back of the grammar book do not stick in the head before the basics at the front are automated, and the conversation that was put off never gets started.

The order I actually drew up was this. It is an arrangement that considers both dependency and the compounding effect.

Let me point out a few principles I deliberately applied here.

First, I put the top dependency at the very front. If you cannot read the script, words, grammar, and listening are all blocked. So I made automating the script within two weeks the number-one item. This is the real starting point with no incoming arrows.

Second, I overlapped what could run in parallel. Words and listening do not strongly depend on each other, so in weeks 3-6 I mixed word memorization and listening on the same day. This is the same as the point in the dependency graph where the branch splits in two.

Third, I nailed down conversation to a date, week 8, rather than "when my skill is good enough." As the 70-20-10 model says, you have to slot real practice in early for learning to accelerate. The points where I got stuck in conversation told me exactly which grammar to fill in next. Had the order been reversed, I would have memorized the whole grammar book without ever knowing which grammar was truly needed.

To state only the result: the felt progress was far faster than my earlier "grammar book from chapter one" attempt that took the same amount of time. I had not added new effort — I had only changed the order.

Application 1 — In Learning

In learning, order makes an especially large difference. Studying the same subject for the same hours yields different results in a different order.

Here are a few order principles I internalized while studying English and Japanese.

1. The frequent first. Not all words are equal. The few thousand most frequent words cover most of actual sentences. Learning in frequency order lets you understand more sentences for the same effort.
2. Comprehension first, production later. Building enough input through listening and reading before moving to speaking and writing feels more natural.
3. Mix in retrieval practice. Research is well known that retrieval practice — trying to recall — is far more effective for long-term memory than simply re-reading. Allocating some portion to retrieval even during the input stage is a good order.

The 70-20-10 model often used in workplace learning also holds the wisdom of order. It is a rule of thumb that 70 percent of learning comes from actual job experience, 20 percent from interaction with others, and 10 percent from formal education. An order that inserts real practice early, even in small doses, accelerates learning more than one that piles on training and defers practice.

Application 2 — In Work

People who design order well travel farther with the same ability.

One principle I use often is "verify the most uncertain thing first." If a project has an assumption you most doubt, check it first with a small experiment. If that assumption is wrong, you can change direction before pouring time into the rest. It is an order that pulls the riskiest dependency forward.

Another is "distinguish reversible decisions from irreversible ones." Make reversible decisions quickly and learn as you go. Make irreversible decisions carefully, after gathering more information. In terms of order, it is a flow of gathering information through reversible experiments, then making the irreversible decision.

Application 3 — In Communication

The order of words also changes the result. Even with the same information, what you say first changes the impression the other person receives.

When delivering bad news, whether to state the conclusion first and the reasons after, or lay the context first and the conclusion after, depends on the situation. For a busy decision-maker, conclusion first is usually better. For a sensitive topic, an order that shares context first to soften the shock can be better.

Giving feedback has an order too. Pointing out concretely what was good first, then stating areas to improve, invites less defensiveness for the same critique. But inserting praise as a formality backfires, so it matters to lead only with the parts you genuinely mean.

First Principles and the Critical Path — What Must Be Solved First So the Whole Unlocks

To design order more deeply, two thinking tools help. First-principles thinking and the critical path.

First-principles thinking is the approach of "do not follow the order others use; rebuild from the most fundamental facts." A conventional order is often not a real dependency but merely a custom. In the Japanese example above, "grammar book from chapter one" was a custom, not a dependency. Ask from first principles and the answer changes. "What is needed first of all to understand a language?" That answer was reading the script and high-frequency words, and that became the real starting point.

The critical path is a concept from project management. In a schedule of many tangled tasks, the longest dependency chain that determines the overall completion time is called the critical path. If a task on the critical path slips by a day, the whole thing slips by a day. Conversely, a task off the critical path can be a little late without affecting the overall schedule. So when you plan an order, you should handle the tasks on the critical path first and with the most focus.

Going back to the expense-tracker app graph drawn earlier, "requirements - data model - backend API - API integration - integration test - deploy" is the critical path. "Wireframes" is a side branch, so being a few days late does not push the overall launch date. If you neglect the critical path while polishing the design to perfection, the launch keeps getting pushed back indefinitely. Here is a table summarizing the difference and use of the two tools.

The two tools do not compete; they complement. Use first principles to find the real starting point, and the critical path to set the focus order after it. Whenever my mind drifts toward a side branch, asking "is this on the critical path" has saved me a lot of wasted time.

The Psychology of Order — Why We Resist the Right Order

Even when my head knows the right order, my body keeps going backward. It is not just me; well-known cognitive biases are at work here.

First, the sunk cost fallacy. Once you have gone far down a wrong order, the feeling of "I have come this far, it would be a waste" keeps you on the wrong path. Like the table tennis smash learned without fundamentals, you fail to fix the bad posture because the time already spent feels too precious to abandon. Cost already spent does not come back no matter what you choose, so a decision should be made looking only at "future gains." But our minds keep counting past investment.

Second, novelty bias and a preference for immediate reward. Basic practice is boring and its reward is slow. Flashy application, on the other hand, is fun right away and stands out. So our hands reach first for the application that gives immediate pleasure rather than the dull fundamentals that form the base of working memory. The urge to write API code before the data model in the expense-tracker app is of the same grain. It looks like "real work" and the output is visible right away.

Third, the planning fallacy. We are always optimistic about how long things take. So we think "I will finish the basics quickly and soon move to the application," fail to allocate enough time to the basics, and rush past them.

Fourth, visibility bias. Work that is good to show others gets picked up first. Screen design is good to show off, but the data model is not. So the invisible work on the critical path gets pushed back.

Knowing these biases, when the urge to go backward arrives, you can put a name to it. "Is this because of sunk cost right now, or just because the application is fun?" Simply naming it lets you step back from the urge. Many times, when my order kept going backward, just writing down which of the four was at work was enough to turn the direction around.

Pitfalls and Balance — The Trap of Never Starting Because of Order Obsession

Having stressed the power of order, there is the opposite trap. Obsession over order can block the start.

I fall into this trap often. When the thought "let me start once I have set the perfect order" arrives, I endlessly refine the plan and never write a single line. When learning a new language, I once spent a month only searching for "which textbook, in what order." This is called analysis paralysis.

This needs balance. Order is a powerful variable that changes results, but most orders can be adjusted after you start. Except for the few cases with clear dependencies — application impossible without the foundation — for many things it is better to just start and refine the order as you get feedback.

The criterion I use is this. Is the loss from a wrong order large or small? For tasks where the loss is large and hard to undo (architecture, large investments), I set the order carefully. For tasks where the loss is small and easy to undo (the order of blog posts, which chapter to study), rather than agonizing over the perfect order, I just start.

To show how this trap actually appears, let me transcribe a conversation that often plays out in my head. One side is the "planner" who wants the perfect order; the other is the "doer" who wants to just start.

Planner: Before starting a new side project, I have to settle on
         the tech stack perfectly. Let me read all the framework
         comparison articles first.
Doer:    You have been reading those comparisons for days, and you
         still have not written a single line.
Planner: Because if I pick wrong, I will have to tear it all out later.
Doer:    Is that really true? What we are building now is a small app
         with three screens. Even switching frameworks would take a
         day at most at this scale.
Planner: Still, is it not better to do it right from the start?
Doer:    Let me change the question. Is this choice hard to undo?
Planner: ...No, actually I can undo it easily.
Doer:    Then this is not an order to design carefully; it is an order
         to start first and adjust. Today, build just one screen with
         the tool you know best. If you get stuck, switch then.
Planner: All right. But I will at least sketch the data model first.
         If that changes, several screens collapse together.
Doer:    Good. That is a real dependency, so doing it first is correct.

The heart of this dialogue is the final agreement. Neither decide everything in advance nor blindly start everything. Start the easily reversible choice (framework) right away, and design first only the hard-to-reverse dependency (data model). Balance is not the planner or the doer winning, but each being placed where it belongs.

Another Pitfall — Pouring Time Into the Wrong Foundation

The advice to build from the foundation has its own trap. If you misjudge what the "foundation" is, you waste time mistaking something unimportant for the foundation. In table tennis terms, fixing your stance is a true foundation, but spending a month choosing a racket brand is a fake foundation.

The question to tell whether it is a real foundation is this. If this is weak, do many later things collapse? If so, it is a foundation. If not, it may be a side branch disguised as one.

A Collection of Order Anti-Patterns

Let me bundle the traps covered so far into the wrong-order patterns I see often. I encourage you to check which of these show up in your own work.

• Flashy first: starting with screen design instead of the data model, with flashy technology instead of fundamentals. The cause is visibility bias and a preference for immediate reward.
• Verification last: deferring the riskiest assumption to the very end, then asking "is this even useful" only after building everything. By then it is too late to undo.
• Waiting for the perfect order: an analysis-paralysis pattern of only refining the plan until the starting order becomes perfect. It is overkill to treat even reversible work with such caution.
• Chasing sunk cost: continuing a wrong order just because you have already gone far. The criterion of the decision is pointed at the past.
• Mistaking convention for dependency: accepting "this is how it is usually done" as a real dependency. The result of not asking again from first principles.
• Endless extension of the foundation: expanding "from the foundation" into "only after every foundation is perfectly finished," so you never move on.

You do not need to try to avoid all six. It is enough to know the one or two you fall into especially often. I tend to fall into "flashy first" and "waiting for the perfect order," so when I start something new I consciously guard against these two.

Order Within a Day — Sequencing Your Energy

So far I have dealt with the large order at the project level, but order also changes results at the small unit of a single day. Even with the same twenty-four hours, output varies greatly depending on what you do and when.

Cal Newport, in "Deep Work," says that time spent deeply focused without interruption creates value. Add order to this and it becomes: place the cognitively heaviest work first, in the time slot when your focus is highest. For many people, focus is highest in the morning. Yet we often let that golden time slip away on checking email and busywork, and put off the hard work to the afternoon when energy is depleted. The order is backward.

I try to set the order of my day like this. I put the one thing that requires the most thinking in the first block of the morning, and during that time I turn off notifications. Low-cognitive-load tasks like replies, meetings, and busywork I gather into the afternoon when focus has dropped. Learning that needs input (reading, listening) I place when my head is relatively clear; simple repetition (review cards, tidying up) I place during tired hours.

This too is a form of dependency thinking. Hard work depends on the resource of "a clear mind." Assigning that work first to the time when that resource is abundant is, in fact, an order that respects the dependency. Start hard work after the resource is depleted, and you do the same work worse in twice the time.

A Counterpoint — Sometimes Order Matters Less

For balance, let me deliberately write a counterpoint that downplays the power of order. Order is not decisive in every task.

First, when tasks are nearly independent of each other. If it is a bundle of tasks with no dependencies, the result is similar whichever you do first. Agonizing over order here is actually a waste of time. Just do whatever is at hand.

Second, when the goal is exploration. In the early exploration stage where you do not yet know what matters, the volume of varied attempts matters more than a refined order. You have to touch many directions quickly and first discover where the real dependencies are. Obsessing over order at this stage is like deciding the route before even drawing the map.

Third, when the cost of changing the order is nearly zero. If you can cheaply rearrange anytime, it is better to proceed and change as you go than to plan a perfect order in advance. The "easily reversible framework choice" in the earlier dialogue falls here.

In short, the places where order greatly changes results are the areas that are "strong in dependency, irreversible, and high in compounding." Outside of those, it is right to consciously reduce agonizing over order and put weight on execution. Knowing the power of order and recognizing the areas where order matters less are the same wisdom.

A Retrospective — Two Experiences of Redoing Something With a Changed Order

Finally, let me briefly write two of my own experiences where consciously changing the order changed the result.

The first is a side project. Long ago, when building a certain tool, I spent the first two weeks polishing the screens. The output was immediately visible and satisfying, but I never verified to the end whether the core logic had value for users, and the project fizzled out. It was a wrong order that deferred the riskiest assumption (is this even useful) to the very end. In the next project I flipped the order. I left the design rough and built first the minimal feature that verifies the core value, then showed it to a few people. The response was lukewarm, so I could change direction early and saved several weeks I would have wasted. I had not worked harder — only the order, pulling verification forward, was different.

The second is language learning. When I first picked English back up, I made completing grammar a precondition for conversation. The order was "I will speak once my grammar is perfect." As a result, I clutched the grammar book for months without saying a word. With Japanese I abandoned this order. I started speaking early while still incomplete, and filled in the grammar on the spot at every point where I got stuck. Real practice became a compass telling me which foundation was truly needed, and I went much farther in the same time.

The lesson of both experiences is the same. What was blocking me was not ability but order, and when I changed the order, the same effort produced a different result.

Order in Habits — Attaching the Small Thing First

Order is also decisive when forming habits. A common mistake when trying to build a new habit is to wedge a big behavior into a new slot all at once. This too can be seen as a problem of order.

An effective order is "linking a new habit behind an already-established habit." A new behavior is like a card connected to nothing; left floating alone, it is easily forgotten. But place a new behavior right after an existing behavior you do every day without fail (for example, drinking water in the morning), and the existing habit becomes the trigger for the new one. From the dependency view, you are making the stable habit the prerequisite work for the new habit.

The order of size matters too. Aim for a big behavior from the start and working memory and willpower are consumed all at once, so it soon collapses. An order that first builds a track with a very small behavior, then adds size on top, lasts longer. When I built my exercise habit, I first established "putting on my shoes and stepping out" rather than "thirty minutes of exercise," then increased the amount. Small first, big later. The same principle is here too.

Before the Closing — Training the Eye for Order

One more thing I want to write is that the eye for order is trained by practice. At first everything just looks like a "pile of things to do," but as you repeat the question of asking about dependencies, the arrows within the pile gradually start to appear.

The fastest way to train that eye is to look back at finished work and ask, "what if I had changed the order?" The more a project did not go well, the more valuable this question is. You discover that a good share of failures easy to blame on ability were, in fact, due to order. As those discoveries accumulate, you naturally start looking at order first when you begin the next thing.

For me, my table tennis coach's one line was the starting point. "Your order is backward" was not just about table tennis; it became a lens that made me re-examine work, learning, and conversation as a whole.

Communication Again — The Order of Documents and Persuasion

After the order of spoken words, order also decides results in writing and persuasion. Even a document with the same content gets read or discarded depending on the order of arrangement.

In technical documents and proposals, the order I try to keep is "conclusion, evidence, detail." A busy reader who does not get the gist from the first paragraph will not read the rest. So I put the most important conclusion at the very front, the evidence after, and the detailed implementation at the very back. The reverse order — laying out a long background and putting the conclusion at the very end — loses the reader before they reach the conclusion.

A different order works in persuasion. It is effective to start from a point the other person already agrees with, stack small agreements, then move to the core claim. Throw the most contentious claim from the start and the other person goes on the defensive first. Building the common ground first is, in fact, "building from the foundation" in persuasion.

A Practical Framework — The SEQUENCE Check

Here are the check questions I use when designing order, arranged as steps.

1. Draw the end picture. Write the state you ultimately want to reach in one sentence.
2. Spread out the tasks. Write the tasks needed to get there on cards.
3. Connect dependencies. Draw "this first" arrows between cards.
4. Find the starting point. Take the card that depends on nothing as your start.
5. Pull risk forward. Bring the most uncertain or irreversible thing forward within the schedule.
6. Start small. Do not wait for the perfect order; take a reversible first step today.
7. Adjust with feedback. Refine the remaining order with information gained as you go.

If I summarize these seven steps in one line, it is this. Set the end, find the starting point through dependencies, pull risk forward, start small and adjust. Steps one through five are "design"; six and seven are "execution and adjustment." People who fall into analysis paralysis stay in steps one through five; people who wander without a plan start from step six. Balance lies in spending only ten minutes on design and moving straight to execution.

Let me also note where each step often goes wrong.

• Going wrong at the end picture: if you write the end too vaguely, the dependencies do not appear. Write it concretely, not "I want to be good," but "small talk in Japanese for thirty minutes six months from now."
• Going wrong at connecting dependencies: mistaking convention for dependency. "Because others do it in this order" is not a real dependency. You have to ask again from first principles.
• Going wrong at pulling risk forward: reaching for the easy and fun work first, deferring the riskiest assumption to the very end. This is where visibility bias and a preference for immediate reward operate.
• Going wrong at starting small: taking too big a first step. If you make "a completed Stage 1" rather than "a reversible single step you can take today" your first step, you defer again.
• Going wrong at feedback adjustment: clinging to the order you set once, to the end. When new information comes in, the critical path can change, and clinging only to the old path becomes a wasted trip.

The name SEQUENCE is not a grand acronym but merely a memory device to not forget "order." What I actually use is just this flow of seven steps, and when I start something new it is enough to write three lines in the corner of a note — the end picture, the starting point, and the riskiest assumption.

To add, this framework is stronger when used together than alone. When a team looks at the same dependency graph and agrees on the starting point and the critical path, unnecessary argument over who should do what first drops sharply. Instead of arguing order in words, you show it with arrows.

Practice Checklist

• Before starting this, did I write down what must already be finished?
• Did I distinguish the important task from the task to do first?
• Did I build enough foundation to support the next step?
• Did I pull the riskiest assumption forward to verify it?
• Did I treat reversible and irreversible tasks differently?
• Am I deferring the start while waiting for a perfect order?
• Did I check whether what I called the "foundation" is the real foundation?
• Did I pull forward the compounding work that, done first, makes the rest easy?
• Did I distinguish the work on the critical path from the side branches?
• Did I place the most demanding work in the most focused time slot?
• Am I still clinging to a wrong order because of sunk cost?
• Am I mistaking a convention for a real dependency?

Frequently Asked Questions

Question: My order keeps changing no matter how I plan it. Is there any point in planning? Answer: There is. The purpose of planning an order is not a fixed schedule but understanding dependencies. Once you understand the dependencies, even when the plan changes you can quickly re-decide what to do next.

Question: My foundation is weak but I need to apply something right now. What then? Answer: A realistic way is to do both at once, filling in the underlying foundation on the spot at each point where the application gets stuck. Real practice becomes a compass that tells you which foundation is truly needed.

Question: Is there a simple way to set priority and sequencing at once? Answer: First narrow candidates by importance, then build the order among those by dependency. Among the important things, the one that depends on nothing is usually the real first step.

Closing — Same Effort, Different Destination

If I compress the lesson learned at the table tennis table into one sentence, it is this. As much as what you do, what you do first changes your destination.

Order is leverage you can get for free. Without working more, simply arranging the same work in a better order changes the result. At the same time, if obsession over order blocks the start, that leverage becomes a shackle. Set order carefully where dependencies are strong, and just start and adjust where they are not. Holding these two together is the key.

If something is stuck for you today, I encourage you to ask once. Is this really a hard task, or is the order simply backward?

References

• David Allen, "Getting Things Done: The Art of Stress-Free Productivity," Penguin Books.
• John Sweller, "Cognitive Load Theory" — overview, https://www.sciencedirect.com/topics/psychology/cognitive-load-theory
• Jeffrey Karpicke, Henry Roediger, "The Critical Importance of Retrieval for Learning," Science (2008) — https://pubmed.ncbi.nlm.nih.gov/18276894/
• Cal Newport, "Deep Work: Rules for Focused Success in a Distracted World," Grand Central Publishing.
• Harvard Business Review, "How to Prioritize Your Work When Everything Feels Important" — https://hbr.org/2020/07/how-to-prioritize-your-work-when-everything-feels-important
• Will Larson, "An Elegant Puzzle: Systems of Engineering Management" — https://lethain.com/