From Grappler to Engineer: What the Mat Teaches About Code

I have been observing an interesting phenomenon: practitioners who achieve mastery in one domain often excel in others that seem, on the surface, entirely unrelated. The concert pianist who becomes a successful surgeon. The chess grandmaster who builds profitable trading systems. The athlete who transitions into business leadership.

The conventional explanation invokes transfer of "soft skills"—discipline, work ethic, the ability to perform under pressure. This explanation is not wrong, but it is incomplete. Something deeper is at work.

Consider the intersection of Brazilian Jiu-Jitsu and software engineering. These activities appear to share nothing. One involves physical combat; the other involves abstract symbols manipulated through keyboards. One is ancient in its roots; the other barely exists as a distinct profession. One leaves you exhausted and bruised; the other leaves you exhausted and caffeinated.

And yet the practitioners who cross between these domains consistently report the same insight: they are the same activity.

This essay explores why.

The Structure of Expertise

The psychologist K. Anders Ericsson spent decades studying expert performance across domains. His research revealed something surprising: expertise has a consistent structure regardless of field.¹

Experts do not simply know more facts than novices. They perceive differently. Where a novice sees a chess position as a collection of pieces, the grandmaster sees patterns, threats, and possibilities. Where a novice sees a guard pass as a sequence of movements, the black belt sees relationships between bodies, spaces, and forces.

Ericsson called this "chunking"—the ability to perceive complex situations as unified wholes rather than as collections of parts:

"Expert performers have acquired cognitive structures that allow them to perceive, remember, and process information in ways that are qualitatively different from those of beginners. These structures are not general abilities; they are highly specialized mental representations developed through years of training in a specific domain." ²

The insight generalizes beyond perception. Experts in any domain have developed mental models—frameworks for understanding how elements in their domain relate and interact. These models allow them to predict consequences, identify leverage points, and recognize patterns that remain invisible to novices.

The transfer of expertise between domains occurs when the mental models align. Brazilian Jiu-Jitsu and software engineering, it turns out, require remarkably similar models.

Lesson One: Ego is Expensive

Walk into any Brazilian Jiu-Jitsu gym as a beginner, and within the first week, a practitioner who weighs thirty pounds less than you will systematically dismantle your every attempt at resistance. It does not matter how strong you are, how smart you think you are, or how many instructional videos you have consumed. The mat provides immediate, unambiguous feedback.

This feedback is uncomfortable. The ego resists it. The temptation is to make excuses—they got lucky, you were tired, they used some trick. But the practitioners who improve fastest are those who can accept the feedback without defensive rationalization.

The philosopher Daniel Dennett describes this capacity as "Rapoport's Rules"—a set of principles for productive disagreement that begin with the requirement to state your opponent's position so clearly that they say "I wish I had thought of putting it that way."³ The principle applies beyond argument. In any domain that provides feedback, the first requirement is the capacity to receive that feedback without distortion.

Software engineering offers the same lesson. The compiler does not care about your intentions. The test suite does not care about your elegant theory. The production server crashing at 3 AM does not care about your confidence in your implementation.

The code either works or it does not. The design either scales or it does not. The system either handles edge cases or it fails in production.

The engineer who can receive this feedback without ego—who can say "my approach was wrong" rather than "the requirements were unclear"—improves faster than the one who cannot. The grappler who can tap, analyze what went wrong, and immediately try again improves faster than the one who makes excuses.

Both activities teach the same fundamental lesson: reality provides feedback, and the quality of your response to that feedback determines the rate of your improvement.

Lesson Two: Leverage Over Force

The physicist Archimedes allegedly said: "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world."⁴ The statement captures something essential about effective action: properly applied leverage can accomplish what raw force cannot.

Brazilian Jiu-Jitsu is fundamentally a system for creating mechanical advantage. The art emerged in Brazil through Helio Gracie, who was smaller and weaker than his brothers. Unable to rely on strength, he refined techniques to maximize leverage—to create positions where a smaller body could control and submit a larger one.⁵

A proper armbar does not require strength. It requires angles. The hip placement, the grip, the angle of your body relative to theirs—get these right and the submission is inevitable. The force applied to the elbow joint is multiplied by the lever created by your entire body. A 130-pound practitioner can break the arm of a 200-pound opponent if the mechanics are correct.

Software engineering follows the same principle.

When building systems, the question is not "how much code can I write?" but "where can a small amount of well-placed code create outsized impact?" What architectural decisions will make future development easier rather than harder? What abstractions will allow complexity to be managed rather than merely accumulated?

The naive approach to software development treats effort as the primary input. More hours, more lines of code, more features. This is the equivalent of trying to muscle through a guard pass. It works sometimes, against weaker opposition, when you are fresh. It does not scale.

The sophisticated approach looks for leverage. A well-designed interface that separates concerns. A testing framework that catches bugs before they reach production. A deployment pipeline that makes releases routine rather than traumatic. These are architectural armbars—positions that create mechanical advantage, that allow a small team to accomplish what a larger team using brute force cannot.

Lesson Three: Position Before Submission

There is a fundamental principle in Jiu-Jitsu that beginners violate constantly: establish position before attempting a submission. If you try to armbar someone from a bad position, you will lose the armbar and probably end up in a worse spot.

The principle seems obvious once stated. In practice, it requires discipline. The armbar is exciting. The position-building is boring. The temptation is always to rush toward the finish.

John Danaher, widely regarded as one of the greatest Jiu-Jitsu coaches in history, articulates the principle with characteristic precision:

"Your first task is to create a situation where your opponent cannot escape. Your second task is to create a situation where your opponent cannot defend. Only then do you attack. Beginners reverse this sequence—they attack first, then wonder why their attacks fail." ⁶

In software, this translates to foundations before features.

I have observed projects fail because developers rushed to build features on shaky foundations. No tests. No clear architecture. No shared understanding of the domain model. They went for the submission without establishing position.

The features get built. They appear to work. Then the requirements change, and the codebase cannot accommodate the change. Or traffic increases, and the system cannot handle the load. Or a new developer joins, and they cannot understand the code well enough to modify it safely.

The disciplined approach invests in foundations first: folder structure, testing setup, continuous integration pipelines, database schema design. Only when the position is established does feature development begin.

This is less exciting than coding the visible product. It is also why some projects survive contact with reality and others do not.

Lesson Four: The Tap is Information

In training, practitioners tap constantly. You tap when you are caught. You tap when the position is inescapable. You tap so you can reset and try again.

The tap is not failure. It is information.

Carol Dweck's research on mindsets distinguishes between a "fixed mindset"—the belief that abilities are static—and a "growth mindset"—the belief that abilities can be developed through effort and feedback.⁷ The growth mindset treats failures as data points rather than judgments.

"In a fixed mindset, everything is about the outcome. If you fail—or if you're not the best—it's all been wasted. The growth mindset allows people to value what they're doing regardless of the outcome... They're tackling problems, charting new courses, working on important issues." ⁸

The practitioners who improve fastest are those who can tap, analyze what went wrong, and immediately try again. They treat every submission as a data point—evidence about a gap in their understanding that needs to be addressed.

The same applies to software development. A failing test is not a problem; it is the system telling you something. A bug in production is not defeat; it is feedback about an edge case you did not anticipate. A feature that does not meet requirements is not failure; it is information about a misalignment between your model and the user's needs.

The engineer who can process this feedback dispassionately—neither deflecting blame nor descending into self-criticism—maintains the capacity to improve. The one who treats failures as evidence of inadequacy eventually stops taking risks that might lead to failure, which means they stop learning.

Lesson Five: Controlled Aggression

Brazilian Jiu-Jitsu requires a particular mental state that is difficult to articulate. It is not relaxation—passivity leads to being dominated. It is not aggression—blind aggression leads to mistakes that sophisticated opponents exploit. It is something in between.

The martial arts researcher Phillip Zarrilli calls this state "heightened awareness without fixation"—a mode of attention that is simultaneously focused and diffuse:⁹

"The ideal state is one of readiness without tension, attention without fixation. The practitioner perceives everything but grasps at nothing. Action arises spontaneously in response to circumstances, without the intervention of deliberate decision."

This maps directly to engineering under pressure. When a system is down and users are affected, the temptation is either to panic—make changes without thinking, break things further—or to freeze—analysis paralysis while the problem compounds.

The experienced engineer, like the experienced grappler, maintains controlled aggression. Focused action. Quick but deliberate decisions. Trust in trained responses combined with awareness that the situation may require adaptation.

The capacity to maintain this state under pressure is not innate. It is developed through repeated exposure to pressure situations where the stakes are real but the consequences are survivable. Training rolls prepare the grappler for competition. Production incidents prepare the engineer for crises. In both cases, the training is not simulation but reality at reduced stakes.

Lesson Six: Training Partners, Not Opponents

Here is something non-practitioners often misunderstand about Jiu-Jitsu: your training partners are not your opponents. They are your collaborators.

When practitioners drill techniques together, they are working toward a shared goal—mutual improvement. A good training partner provides realistic resistance: not so much that you cannot learn the technique, not so little that you develop bad habits. The resistance is calibrated to challenge you at the edge of your current ability.

This collaborative frame transforms the relationship. Your partner's success does not come at your expense; their improvement creates a better training environment for you. When they learn a new technique, they can now teach you that technique through sparring.

The best engineering teams work the same way. Code reviews are not adversarial. They are collaborative efforts to make the code better. When someone finds a bug in your work, they are not attacking you—they are helping you improve.

I have observed teams where code review becomes competition, a way to prove intellectual superiority. These teams produce worse code. The social dynamics poison the technical process. People become defensive, stop taking risks, optimize for appearing smart rather than for building good systems.

The teams that treat review as training—as collaboration toward shared improvement—consistently outperform. The feedback flows freely because it is not perceived as attack. The learning compounds because everyone is teaching everyone else.

The Convergence

After years of observing practitioners who cross between these domains, I no longer see them as separate activities. Engineering and Jiu-Jitsu are both practices—domains that require ongoing refinement, that reward consistency over intensity, that develop expertise through feedback loops.

Both punish the same vices: ego that prevents learning, impatience that skips foundations, panic that degrades performance under pressure. Both reward the same virtues: humility, discipline, the capacity to process feedback without defensiveness.

The philosopher Alasdair MacIntyre defines a practice as "any coherent and complex form of socially established cooperative human activity through which goods internal to that form of activity are realized."¹⁰ By this definition, both Jiu-Jitsu and software engineering qualify. Both have internal goods—states of excellence that can only be appreciated by practitioners. Both require initiation into traditions that define what excellence means. Both develop virtues in those who pursue them seriously.

Perhaps this is why expertise transfers. The virtues developed in one practice are the same virtues required by another. The mental models are different in their content but similar in their structure. The practitioner who has learned to learn in one domain has acquired a meta-skill that applies everywhere.

Or perhaps both activities simply attract people who enjoy solving problems—whether those problems involve bodies or code.

Either way, the practice continues. The mat teaches. The codebase teaches. The lessons are the same.

Bibliography

Ericsson, K. Anders, and Robert Pool. Peak: Secrets from the New Science of Expertise. Houghton Mifflin Harcourt, 2016. ↩
Ericsson, K. Anders. "Deliberate Practice and the Acquisition of Expert Performance." Academic Medicine 79, no. 10 (2004): S70-S81. ↩
Dennett, Daniel C. Intuition Pumps and Other Tools for Thinking. W.W. Norton, 2013, p. 33. ↩
Pappus of Alexandria. Synagoge, Book VIII. The attribution to Archimedes is traditional but possibly apocryphal. ↩
Gracie, Renzo, and Royler Gracie. Brazilian Jiu-Jitsu: Theory and Technique. Invisible Cities Press, 2001, pp. 1-12. ↩
Danaher, John. Interview with Lex Fridman. Lex Fridman Podcast, Episode 182, 2021. ↩
Dweck, Carol S. Mindset: The New Psychology of Success. Random House, 2006. ↩
Dweck, Carol S. Mindset, p. 48. ↩
Zarrilli, Phillip B. When the Body Becomes All Eyes: Paradigms, Discourses and Practices of Power in Kalarippayattu. Oxford University Press, 1998, p. 187. ↩
MacIntyre, Alasdair. After Virtue: A Study in Moral Theory. University of Notre Dame Press, 1981, p. 187. ↩