The Value of Grinding: Why Failure Is an Asset, Not a Tax

A log that is mostly failure

I open my notes folder tonight and scan the entries one by one. The pattern is hard to miss. The vast majority of what I have written down for this Solana MEV project is, by any honest accounting, a record of things that did not work. A simulator that promises a profit and delivers a revert. An assumption about a pool's math that turns out to be wrong by a factor that quietly eats the margin. A custom error code that overlaps with another program's code and sends me chasing the wrong bug for half a day. An on-chain deploy that succeeds technically and then proceeds to drain rent in ways I did not budget for.

If I grade the work by the ratio of things that landed to things that broke, the grade is ugly. And yet, when I look at where my actual understanding of Solana, of AMMs, of MEV economics, of Rust async runtimes sits today versus where it sat months ago, the picture flips. The understanding came almost entirely from the broken attempts. The wins were thin slices. The losses were the curriculum.

This post is an attempt to take that observation seriously instead of treating it as a self-pep talk. There is a real body of research, going back decades and updated as recently as 2025, that explains why a log full of failure is not a sign that the project is going badly. It is, under specific conditions, the literal mechanism by which competence forms.

What "grinding" actually means

In Korean software culture there is a word, sapjil, which translates roughly as "shoveling." It is the word people use for tedious, repetitive, often frustrating work that feels unproductive in the moment. The American developer vernacular has its own equivalents: spinning your wheels, going down a rabbit hole, yak shaving, banging your head against the wall. They all point to the same experience — hours of effort with no visible deliverable at the end, and the suspicion that you are wasting time.

The key word in that description is suspicion. From the inside, grinding and genuine wasted time feel identical. You are six hours into reading transaction logs at 2 a.m. and nothing has worked. There is no internal signal that distinguishes "I am building a deep mental model of how Solana account ordering actually works" from "I am literally just lost." Both feel like flailing. Both make you doubt whether the project is worth continuing.

That indistinguishability is what makes the research underneath this so important. Without it, the default response to a long string of failed attempts is to assume something is wrong with you, your plan, or both. The research suggests that response is, in many cases, exactly backwards.

Productive failure: why failing first actually works

The single most useful frame I have found for thinking about my own log comes from Manu Kapur, a professor of learning sciences at ETH Zurich and director of the Singapore-ETH Centre. His book Productive Failure: Unlocking Deeper Learning Through the Science of Failing was published in October 2024 (Wiley/Amazon listing), and Imperial College London's Centre for Higher Education Research summarized his current thinking in an October 2025 post.

Kapur's core empirical finding is striking. He runs experiments in which one group of students gets direct instruction on a new concept first, then practices. A second group is given a complex problem first, struggles with it, generates a bunch of half-right or wrong approaches, and only then receives the formal instruction. On basic recall tests, the two groups perform about the same. On transfer tasks — applying the concept to a genuinely new problem — the group that failed first significantly outperforms the group that got direct instruction.

The phrase Kapur uses to summarize his stance is the one that lodged itself in my head: "If failure isn't built into our systems, we're under-optimising learning. Failure shouldn't be a bug in education — it should be a feature."

He describes four mechanisms that fire when a learner struggles with a problem before knowing the right answer. According to his research page at manukapur.com, they are: activation of prior knowledge and the surfacing of its gaps; attention focused on the conceptual features that actually matter; explanation and elaboration of those features; and organization of the features into the target concept. None of these mechanisms fire as strongly when you are handed the right answer up front. The struggle is not the cost of learning. The struggle is the learning.

When I map this onto my project, the picture becomes uncomfortably literal. The stretch where I spent days chasing a phantom arbitrage opportunity and finally realized my AMM math overestimated the output was Kapur's Phase 1 — generating and exploring solution methods, including the broken ones. The eventual rebuild of the simulator was Phase 2 — consolidating the lessons into a more canonical model. The log of failed attempts is not noise around the signal. It is the activation step that makes the consolidation stick.

Blameless postmortems: engineering's version of the same idea

Kapur writes about learners. Google writes about engineers, and the conclusions land in almost the same place.

The Google SRE Book has a chapter on postmortem culture that is widely cited inside and outside the company. It opens with a quote attributed to Devin Carraway: "The cost of failure is education." The chapter then makes a structural argument about how to extract that education. A postmortem, in Google's definition, is a written record of an incident — what happened, what the impact was, what the root cause was, what was done to fix it, and what should change so it does not happen again.

The word that does the heavy lifting is blameless. Google's argument is that postmortems work only if they focus on identifying the contributing causes "without indicting any individual or team for bad or inappropriate behavior." The reason is not sentimental. It is mechanical. As the chapter puts it: "You can't 'fix' people, but you can fix systems and processes." And when finger-pointing prevails, "people will not bring issues to light for fear of punishment." A team that punishes the person closest to the failure loses the information that person carries about why it happened.

The operational practices around this culture are unexpectedly specific. Google describes monthly postmortem newsletters, internal postmortem discussion groups, postmortem reading clubs with refreshments, and a training exercise for new SREs called the "Wheel of Misfortune" in which engineers role-play through past incidents. The chapter also notes that in 2014, an SRE who quickly rolled back a problematic release received peer bonuses and applause from company founders — an explicit organizational signal that handling failure well is itself a celebrated skill. The chapter concludes that "thanks to our continuous investment in cultivating a postmortem culture, Google weathers fewer outages and fosters a better user experience."

For a solo developer the team-level structure is overkill, but the principle scales down cleanly. Self-blame is the personal-scale equivalent of blame culture. When I write up a failed attempt as "I'm an idiot for not catching this earlier," I have done exactly what Google warns against: I have made the writeup about a person who cannot be fixed, instead of about a system that can. When I write it as "the simulator's assumption about reserve ordering was wrong because I conflated two AMM variants, and here is the specific line where that assumption lived," the failure becomes a system change. The two writeups look like the same length on disk. They are not the same artifact.

Mindset and the long arc of expertise

If Kapur explains the cognitive mechanism and Google supplies the engineering protocol, Carol Dweck and Anders Ericsson supply the long-arc context.

Dweck's growth-mindset framework, developed over decades at Stanford, distinguishes between treating ability as fixed (failure proves you don't have what it takes) and treating it as developable (failure is information about where to direct effort). The often-quoted line from her work is: "In the growth mindset, failure is a natural part of learning and it is a stimulus to further learning." A 2025 evidence review from Ascension Learning summarizes that students operating with a growth-mindset frame show "more adaptive behaviors and psychological traits, such as resilience in response to failure, which in turn leads to greater academic achievement."

Dweck's framework has direct application to programming. A 2021 study cited on ResearchGate titled Growing Mindsets: Debugging by Design to Promote Students' Growth Mindset Practices in Computer Science Class observes that "while some learners perceive bugs as opportunities for learning, others become frustrated with failure and see it as a challenge to their abilities," and concludes that mindset "plays an important role in persevering in computer science." Same bug, two interpretations, two different career trajectories.

Ericsson's deliberate practice research, summarized in his classic paper available on ResearchGate, is the part that tempers any Silicon Valley hot take. Ericsson is famous for the finding that "many characteristics once believed to reflect innate talent are actually the result of intense practice extended for a minimum of 10 years." But the part that often gets dropped from popular accounts is that deliberate practice is not just hours logged. A Frontiers in Psychology review on NIH emphasizes that the practice has to involve "concentration, analysis, and problem solving" and "rigorous skills assessment, and specific informative feedback." Passive repetition does not count. Practice without feedback does not count.

In that frame, every failed debugging session, every reverted transaction I have to inspect, every architectural decision I have to undo and rebuild — each is one repetition of deliberate practice. The concentration is forced (the bug demands it). The analysis is forced (the symptom doesn't match the hypothesis). The feedback is brutal but specific (the chain either accepts the transaction or doesn't). The 10-year arc looks intimidating from the outside; from the inside it dissolves into a few thousand specific failures, each one a repetition.

When failure stops being productive

It would be dishonest to stop here. The same body of research, particularly the more recent work, is also clear that failure is not automatically educational. There are conditions, and missing them turns the whole thing into wasted motion.

Kapur is explicit about the design requirements. Tasks must be "intuitively accessible yet challenging." Multiple solution pathways must be permitted. There has to be a clear expectation that exploration, not immediate success, is the goal. And critically, there has to be a Phase 2 — the consolidation step where the student-generated approaches get organized into something canonical. Without that, you have failure without resolution, which is just failure.

The 2025 critique of Dweck's framework makes a parallel point. A paper referenced in the Ascension Learning review and circulated on SSRN — The Paradox of Carol Dweck's Mindset: When Growth Becomes Fixation — argues that growth-mindset rhetoric can decouple persistence from effectiveness evaluation. Just persisting, without periodically asking "is this approach actually working?", produces a different kind of damage. The lesson is not that growth mindset is wrong; it is that persistence without reflection is wrong.

Silicon Valley's own "fail fast, fail often" mantra has hit a similar wall. The conference FailCon was founded in San Francisco in 2009 to celebrate startup failure as a learning event, and the slogan became a culture. But a 2022 Entrepreneur essay titled Silicon Valley's 'Fail Fast' Method Is Doing Just That — Failing argues that the method has been criticized as cover for chronic over-optimism, with investors growing more cautious about funding patterns that treat failure as the goal rather than the byproduct of disciplined experimentation. The point is not that the slogan was wrong but that, stripped of the reflection step, it became permission to lose money without learning.

The synthesis I take from this is simple, and it is the standard I want to hold my own log to. Failure with reflection is the asset. Failure without reflection is the tax. The difference is whether something gets written down, whether the writeup names a system change rather than a person, and whether the next attempt is structurally different from the last attempt or just a rerun on a different day.

What this means for a solo MEV project

In the specific context of writing a Solana arbitrage bot from a starting point of zero domain knowledge, the implications are practical.

The first is that the volume of failure I am observing is not a signal to stop. It is closer to a signal that I am operating at the right difficulty level. If everything worked on the first try, I would be solving problems I already knew how to solve, which is the definition of not learning. The phrase Kapur uses about ambiguity — "a certain amount of ambiguity and uncertainty is very powerful for learning" — applies here. The discomfort is the work.

The second is that the act of writing the failure down matters more than I instinctively treat it. There is a real temptation, when something finally works, to skip the writeup and move on. Google's emphasis on the written postmortem, not just the verbal discussion, captures why that is a mistake. The act of articulating forces a level of precision that the in-the-moment understanding does not require. The articulation is where the lessons get hardened into something I can apply to a future problem that does not look like the current one. Without that step, the same lesson tends to get re-learned, sometimes painfully, weeks later.

The third is that the writeup itself has a structure that decides whether it is a postmortem or a complaint. The blameless framing is doing real work even at a one-person scale. A note that reads "I missed this because I was tired" is a complaint. A note that reads "my simulator did not flag this class of opportunity because it modeled the AMM as constant-product when this specific pool uses a different curve, and here is the assertion I am adding so the next mismatch fails loudly" is a postmortem. Both might describe the same incident. Only one of them changes what happens next month.

The fourth, and the one I have the hardest time internalizing, is that the long arc compounds in ways the short arc cannot show. Ericsson's 10-year framing is uncomfortable, but the underlying claim — that expertise comes from a large number of specific, feedback-loaded repetitions — is consistent with what I can already observe in my own log. The topics where I clearly know what I am doing today are almost exactly the topics where the early entries are full of confused half-understandings. The failures are not separate from the competence. They are the path the competence walked in on.

Implications going forward

The practical implication of taking this research seriously is that I plan to keep treating the failure log as a primary artifact rather than scaffolding to be thrown away once something works. Each entry that documents a wrong assumption, a dead-end approach, or a fix that revealed a deeper bug is a deliberate-practice repetition with feedback attached. The collection of those entries, taken together, is the closest thing I have to a syllabus for the parts of this domain that no documentation actually teaches.

There is also a softer implication that matters as much as the procedural one. The internal narrative that surrounds the work — whether I describe a hard week as "making progress through dense material" or as "wasting time" — has a measurable effect on whether I show up the next day. The growth-mindset and imposter-syndrome literature both make this point, and at this point I trust it. The story I tell about the failure log is part of the failure log.

Key Takeaways

• Failure is the mechanism, not the cost. Manu Kapur's productive-failure research finds that students who struggle with a complex problem first, then receive instruction, significantly outperform peers given direct instruction first on transfer tasks. The struggle is doing cognitive work that direct instruction skips.

• Write it down, blamelessly. Google's SRE postmortem culture treats failure as education by demanding a written record that focuses on system change rather than personal blame. "You can't 'fix' people, but you can fix systems and processes." The same logic scales down to solo work as a discipline against self-blame.

• Persistence without reflection is the trap. A 2025 critique of growth mindset and the Entrepreneur critique of Silicon Valley's "fail fast" mantra converge on the same warning: failure becomes educational only when paired with an honest evaluation step. Without it, persistence is just attrition.

• Deliberate practice runs on specific, feedback-loaded repetitions. Ericsson's research emphasizes that expertise requires "concentration, analysis, and problem solving" — not raw hours. Each debugging session that ends with a clearly named root cause is one repetition. A log full of those repetitions is what the long arc is actually made of.

• The failure log is the curriculum. For a solo developer learning a domain from scratch, the entries that document wrong assumptions and dead-end approaches are not noise around the eventual working code. They are the activation phase that lets the working code stick.