Introduction
Years ago, I took the MBTI test on 16Personalities and learned that my personality falls in the INTP ("The Logician") category. I recently revisited the characteristics and literally laughed out loud. It describes me to a T, especially the non-conventional part. At a prior big bank corporate job, I recall asking my manager, after she caught me walking shoeless, if I could continue doing so. After all, it was super comfortable, and my feet were very hygienic, if I must say so myself. I saw the raised eyebrows. So I did the right thing — I put my shoes back on...and only started walking shoeless after hours.
On a side note, I believe in acute positive stress testing of systems — from daily cold showers to walking outside jacketless and in shorts in extreme winters (yes, I positively and acutely stress my biological system as well). Whether being shoeless in an office counts as social norm stress testing, I'll let Reddit decide. Either way, the raised eyebrows were data. Ok, let's lace up and get back on track!
If you are that person who writes a detailed to-do list weeks out only to drop it, who runs endless "what-if" thought experiments without executing, or who gets stuck in the learn-before-doing rabbit hole instead of actually building...then I can relate. I used to do this a lot, and still catch myself doing it, especially in the theory phase. To be fair, this mindset is highly powerful in the right domains (research, abstract math, theoretical physics, etc.) but in most day-to-day situations, it becomes a severe liability.
So I had to build systems to counter it.
The LAP Principle
The LAP principle is a continuous feedback loop I came up with years ago when I used to run. Even if you don't present your work to others, you must present it to your future self: write, record, document — do whatever it takes to solidify the output. Without the P, most people stay stuck in the L phase forever.
L: Learn
When I approach a new topic, I naturally start with theory. Coming from a math & software engineering background, when I wanted to understand what happens at the metal, I went deep into digital design and computer architecture. I bought books and read a massive amount of theory. (Side note: I debated calling this TAP for Theorize or RAP for Read, but LAP stuck — the race track visual matters, and reading is only one form of learning.)
A: Apply
This is where most people stall. I force myself to apply the theory immediately by working through end-of-chapter problems, creating my own parameters, writing things out by hand, or running experiments. If it's math, I'm doing derivations on paper. If it's digital design, I'm on my FPGA board testing things. Application is the mechanism where actual understanding forms.
P: Present (also, Produce or Publish)
For a long time, I mostly "presented" to myself via notes, personal journals, summaries, and lists of gotchas. That's still incredibly valuable, as you are an audience. But recently I started publishing more publicly, like this blog, and that alters the ecosystem entirely. Gaps get exposed, thinking gets sharper, feedback comes in, and naturally, you loop back to $L$.
Fortunately, running this loop is easier than ever. You can LAP with LLMs to learn faster, apply with targeted assistance, and present to refine your output in real time. No excuses.
The So-What Principle: Embrace Errors
If you're waiting for perfect conditions to pursue a goal, you're already operating under a structurally false assumption: you're assuming zero error. Suppose you have a goal, $g$, on your to-do list. You also have constraints $x$ (such as time, dependencies, and resources) and a plan $f$. The naive, closed-system model is:
This assumes no interruptions, no unknowns, and no friction. That's not reality. When you actually implement $f$ on $x$, you don't get $g$. You get some outcome $g'$ (life happens). A more realistic model is:
Here, $\varepsilon$ (pronounced "epsilon", the statistical symbol for error) captures everything you didn't account for — external events, timing issues, hidden constraints, and random nonsense. We treat $\varepsilon$ as random, not because the universe is fundamentally random (which I think it inherently is from thought experiments I've devised — and no, you don't need knowledge of Quantum Mechanics to get this. I'll save for another blog post how to derive it), but because you do not have full information or control.
Most people implicitly optimize for $\varepsilon = 0$, which equates to perfect execution or nothing. If you're not starting, it's because your model demands zero error. The correct question is not "Did I hit $g$ exactly?", but rather:
You define your threshold. "Cost" could be days lost, money lost, or quality drops. For example, if you plan to finish a project in 7 days ($g = 7$) and it takes 10 ($g' = 10$), the cost is 3. If your acceptable threshold was 5 days, you succeeded. Not perfectly, but successfully. You don't eliminate error; you bound it. Any plan that requires $\varepsilon = 0$ is already broken. Errors happen. Embrace them.
The Edge Cases Principle
"What's the edge case?" is one of the first questions I ask when I approach literally any problem. If you didn't think about the edge case, you didn't think. There are always multiple possible outcomes, and some are low-probability but extremely high-cost. By doing the work to identify these unlikely outcomes beforehand, you avoid despair when one actually happens. It is no longer a random failure; it was simply in the distribution, and you accepted the risk.
To identify edge cases, you must think in terms of distributions rather than single outcomes. You can roughly partition it like this:
Normal cases are what you expect. (Note: I am defining "cases" here as outputs in the codomain, rather than inputs such as the constraints $x$ in the domain. It is possible to define edge cases as edge inputs, but I am treating them differently in this context.) Edge cases are the statistically significant blind spots, i.e., the outcomes that break your assumptions and carry outsized consequences. If the problem is unfamiliar, use heuristics like the Pólya move (solving a related problem to see how its system fails) or the Extremum principle as discussed in Paul Zeitz's The Art and Craft of Problem Solving (solid book!). Push the system to its boundaries by asking what happens when time approaches zero, when cost approaches infinity, or when a user does the absolute dumbest possible thing.
Most people plan exclusively for the happy path. This makes their execution inherently fragile. The true system is the happy path plus everything that breaks it. Define the edge cases early, because if you don't define them before execution, reality will define them for you at full cost.
Case Study: Debugging Procrastination Like a System
Let's stop talking abstractly. Suppose the goal is simple: publish this blog post in 7 days. Naively, $g = f(x)$ where $x$ represents time, energy, and available tools, and $f$ is the writing and editing process. But once execution starts, the real system kicks in: $g' = f(x) + \varepsilon$. Suddenly, you over-edit the introduction, spend three hours changing the title, rewrite the same paragraph ten times, and convince yourself it isn't ready.
But here is the vital distinction: that is not $\varepsilon$.
$\varepsilon$ is external noise — a power outage, getting sick, a family emergency. Procrastination is a bug inside $f(x)$ itself. It happens when your internal error-checking subroutine (perfectionism) goes into an infinite loop, starving the system of compute resources ($x$) before a return value $g'$ can ever be generated. That is not laziness; that is an unstable execution function.
To debug this, we execute a systematic patch:
- Step 1: Bound the error. Stop asking if the post is perfect. Ask if it is good enough to publish and improve from feedback. You are optimizing for bounded error, not zero error.
- Step 2: Identify the edge cases. What if the math looks decorative? What if the post is too abstract? These are no longer vague anxieties; they are testable failure modes.
- Step 3: Apply LAP. Do not get stuck in an endless learning loop. Write the post, model the failure modes, publish it, and collect the data.
- Step 4: Correct the system. If readers are confused, clarify the model. If the tone is too loose, tighten it. That is error reduction, not emotional self-destruction.
This is how you escape perfectionism. You stop treating the first attempt as a final judgment of your intelligence, and you treat it like a system output. Measure it. Debug it. Run the loop again.
The Fault Tolerance Principle (Grace)
You need psychological fault tolerance. In software engineering, a robust system does not kernel panic and crash the moment it encounters an unexpected state or throws a warning. It is designed with try...catch blocks. It logs the error, safely reallocates memory, and keeps running.
When dealing with procrastination, perfectionism, and paralysis, you will inevitably throw errors. You will relapse into old habits. You will occasionally spend four hours on a trivial detail. Standard self-help calls this "giving yourself grace." In systems thinking, it is simply fault tolerance.
Do not let a localized execution failure crash the entire machine. Acknowledge the sub-optimal state, log it as data, adjust your parameters, and iterate forward. That is the whole point.
Conclusion
Now my fellow perfectionist INTPs —
kick off your shoes and relax your feet.
You've already done the hard part: thinking deeply. Now do the other hard part: act under uncertainty.
You've got this.
