These are not lessons I read about. They are things I had to learn the hard way — through failed code runs, missed strokes, lost debates, and hypotheses that didn't survive contact with data. I wrote them down because writing forces precision.
None of them are original. But they became mine at a specific moment, in a specific room, when something finally clicked.
These expand on entries from the Thought Log in the main portfolio. If you came here from the index, you already saw the seeds — this is where they grew.
BP debate's structure forces something unusual: you argue positions you haven't chosen, in front of an audience, on a timer you can't stop. The motion drops fifteen minutes before you speak. You get the bench assigned — government or opposition — and build from there, regardless of what you actually believe. The round ends when the clock runs out, not when you run out of arguments.
Most activities reward being right. Debate rewards being wrong well — staying structured while losing an argument, rebuilding a case while the gap is visible to everyone in the room. The skill isn't confidence. It's functional performance under acknowledged uncertainty. You keep going not because you've resolved the problem, but because the format requires you to.
I started applying this to debugging. When a test fails mid-run, the instinct is to stop and fix immediately. The better move: finish the iteration, see the full output, understand the complete shape of the failure before writing a single new line. The first symptom is rarely the root cause. You learn more from the completed error than from the first thing that went wrong — because the first thing points at the surface, and the surface is almost never where the problem lives.
The broader principle: certainty zones masquerade as comfort zones. The activities that force you into public uncertainty — debate, competitive rowing, shipping software to real users — are the ones that actually build anything durable. Everything else is practice in controlled conditions, which is useful, but not sufficient.
"The round doesn't end when you spot the hole in your own case. It ends on a timer. Build anyway."
Three years of rowing, one counterintuitive lesson: the hardest part of training isn't the training. It's the thirty seconds at 5:30 AM when you're not fully conscious yet and you're negotiating with yourself about whether to get up. That negotiation is the actual obstacle. Not the cold dock, not the ugly first stroke, not the 1200-metre wall — those you get through by momentum. The negotiation happens before momentum is possible.
Pre-commitment is the skill. Not discipline — discipline is what you have after the decision is made. Pre-commitment is deciding the night before that the negotiation won't happen. You don't debate the alarm. You remove the decision from the moment entirely, placing it somewhere where you're less tired, less comfortable, and more honest about what matters.
The same pattern shows up in building: deciding to write tests before you need them, to spec the interface before you write the implementation, to ship before you feel completely ready. The value isn't in the tests or the spec specifically — it's in taking the decision out of the moment when you're under deadline, or when the code is nearly working and the urge to skip the test and just ship is overwhelming. Past-you made the call. Present-you executes it.
The 5:30 alarm doesn't teach endurance. Endurance is what happens after you're out the door — the body figures that part out. What the alarm teaches is to not trust in-the-moment-you with decisions that matter. The good news: in-the-moment-you doesn't have to be strong. Last-night-you already made the call.
"Once you're out the door, the body figures it out. The skill being practiced isn't endurance — it's pre-commitment."
For JouleRoute, I had a hypothesis about LLM inference efficiency but no dataset. The temptation was real: write a theoretical argument, cite existing literature on early-exit transformers, claim a plausible improvement range, and submit. It would have been faster. It might even have been convincing, at least to a first read.
The honest path was harder: build the Python simulator that generates the data, instrument it with statistical controls, and then run the hypothesis through it — nine seeds, three workload types, paired permutation tests. It took six weeks before I wrote a single sentence of the paper. But the result is that I actually know whether it works — not whether it should, in theory, under favorable conditions, if you squint at the related work the right way.
This is the difference between an interesting argument and a verified claim. Arguments are cheap — anyone who's read the literature can produce one. Environments that generate honest data are expensive, because they force you to confront the result rather than argue toward a predetermined conclusion. The cost is the point. It's what separates the claim from wishful thinking.
Applied broadly: before you claim your design system improves UX, build the prototype and watch a real person use it. Before you claim your autonomous routine is reliable, run it two hundred times under varied conditions and log every deviation. The simulator isn't a shortcut to the paper. It is the actual work. Everything written after is just description.
"Building the test before the claim changes how confident you need to be before you start."
"Excellent team performance." "Significant improvement." "Consistently high results." Every portfolio uses these phrases. None of them mean anything. They cannot be evaluated, challenged, or built upon. They exist to create an impression without providing the information required to verify it — which means they're not actually saying anything at all.
The version that means something: "First Chinese team to reach Champion Alliance at California Invitational 2025. 98% autonomous routine consistency across 12 qualifying matches. Cohen's d = 7.49, p = 0.005." These aren't numbers for bragging. They're the minimum information required to evaluate the claim — and evaluation is the only thing that makes a claim worth making.
I learned this from debate. In BP, you can't say "the economy will improve." You need a causal mechanism, a timeframe, and a counterfactual. The judge asks: what exactly will happen, by when, and compared to what alternative? Good arguments answer before being asked. Bad arguments rely on the listener filling in the gaps favorably — which works exactly once, with exactly the right audience, and never again.
Specificity is also an act of respect — to the reader, to the judge, to yourself. Vague claims can't be wrong, which is precisely the problem. They can't be improved either, because there's nothing to target. An earned specific is vulnerable: it can be tested, falsified, updated. That vulnerability is what makes it useful. That's the version worth building toward.
"Vague claims can't be wrong. That's the problem."