Oct. 29, 2026
I dropped yesterday’s post (Everyone Should Learn to Code) into Claude just to see what it would say, and it commented, among other things…
“Your idea is: code as a falsifiable externalization of understanding.”
And as much as I usually hate AI writing, even I have to admit that’s a pretty clean summarization of what I’m trying to describe.
I phrased it more like this: Coding allows us to create digital representations of concepts in our minds, which we can then test to see if they hold up.
In one sense, this is more robust than the mental representations themselves, which aren’t directly subject to external verification.
In this post, I’ll provide a simple demonstration of this concept: Deriving the formula for the diagonal of a cube.
Along the way, I’m going to outline some ground rules for how to do it effectively…
- Your code has to be built up “from scratch” and incrementally.
- Your code has to come directly from your own mental model.
- Your code has to be verified using an independent method.
- Your code has to survive your best efforts to “break” it.
1. Build the code from scratch.
This is similar to first principles thinking, which basically entails breaking ideas down into their most fundamental parts (each of which seem axiomatically true to you) and then re-combining the parts.
A key benefit of this approach is that it allows you to avoid memorizing a bunch of complicated information; instead, grasping a few basic principles enables you to combine them into more complex forms in the moment.
Here’s a simple illustration: Offhand, I don’t recall the formula for the diagonal of a unit cube.
(I remember it involves a square root or a cube root or something, but I don’t bother memorizing things like this. As this exercise shows, there’s no need to.)
However, I do know the Pythagorean Theorem (PT), which can be used to derive the diagonal of a cube.
Critically, I know the PT at an intuitive, visual level. I haven’t just memorized it; I know it virtually must be true (p > .99999), based on having seen dozens of proofs. I can’t imagine how it would be possible for it not to be true. So, for this exercise, we’ll accept the PT an axiom or first principle.
Okay, let’s see if we can work out what the diagonal of a unit cube would be… (note that this is a verbal representation)
- By definition, each side of a unit cube is a square, and each edge has length 1 (let’s call each edge e, so e = 1).
- When I visualize a cube in my mind (or draw one), I see that the biggest diagonal (not sure what it’s called, let’s call it D) cuts across the middle of the cube from one corner to the opposite one.
- In my visualization, I notice D forms the hypotenuse of a right triangle, where one side is an edge of the cube (e), and the other is the diagonal of one of the square-sides (let’s call this smaller diagonal d).
- I already know e = 1, but I need to find d. In my visualization, I can see that d is the hypotenuse of another right triangle, formed by d and two sides of that square. Therefore, we can use the PT to find this smaller diagonal…
- e² + e² = d²
- (1)² + (1)² = d²
- 2 = d²
- d = √2
- Now, I can again apply the PT to find the hypotenuse of the larger triangle…
- e² + d² = D²
- (1)² + (√2)² = D²
- 1 + 2 = D²
- 3 = D²
- D = √3
(Okay, now I know why I was thinking there might be a “cube root”…it’s the square root of 3.)
Now, I’m sure mathematicians could show much more efficient ways to derive the formula, but that would risk missing the point.
The point here is that I can build up that higher-level concept in the moment, based on more basic concepts like the PT. My goal is understanding, not speed.
All right. The task now is to write code that represents this concept.
There are various ways I could do this, but I’m going to write an R function that finds the diagonal of any cube I define.
> # This function takes the edge of any cube...> # ...and outputs the "big diagonal"> cube_diag=function(edge=1) {+ d=sqrt(2*edge^2)+ D=sqrt(d^2+edge^2)+ return(D)+ } > # By default, it assumes a unit cube (edge = 1)> cube_diag()[1] 1.732051 > # Note that this is equal to √3...> sqrt(3)[1] 1.732051 > # We can also scale the cube up, say to edge = 2...> cube_diag(2)[1] 3.464102> # So D scales proportionally with the edges...> cube_diag(2) / cube_diag()[1] 2> cube_diag(3) / cube_diag()[1] 3
Clearly, I could simply treat D = e⋅√3 as a memorized fact, which is faster and more efficient…
> cube_diag_fast=function(edge=1) {edge*sqrt(3)}> # This gives the same results with less code...> cube_diag_fast(1:2)[1] 1.732051 3.464102
But, again, that would be missing the point.
If we just wanted the answer, we could have Googled it from the start. The purpose is to create and verify a digital representation of our understanding.
Some Caveats…
Note 1: I don’t mean that ALL code should be built up from scratch. That would be incredibly inefficient for getting work done on a daily basis.
I do think you should build anything you use from scratch the first time or two that you use it. But once you understand something intuitively, it becomes far more efficient to automate.
Understand, then automate.
Note 2: A reasonable question is, “Exactly how far do we need to break things down?” For example, should a person be able to represent these concepts with pure 0s and 1s? (I hope not, because I can’t do that.)
The answer is subjective, but in my view, anything that you already grasp intuitively and visually can be kept “whole” in the code you write.
For example, if you already have an intuitive grasp of the concept of addition, then it’s fine to just use the sum() function (or whatever the equivalent function is in your programming language).
Note 3: I like to dispense with fancy, technical terms when possible. Those terms are important and useful, but the more I use them, the higher the risk that I accidentally end up relying on a concept by name only, without necessarily grasping the underlying idea.
So, yeah…that’s my justification for calling it the “big diagonal.”
(I looked it up just now, and it’s actually called a space diagonal or similar.)
2. Build the code from your own mental model.
If you copy code from another source, or if you regurgitate an explanation you heard someone else give, this does NOT demonstrate independence, which is a core feature of how I define deep understanding (explained here).
To be fair, I’m sure I originally learned this solution, or at least something similar, from someone else a long time ago (geometry class?). But if so, then I’d forgotten it.
I solved it today by visualizing the cube and its diagonal in my mind, independently of any formula or diagram I’ve seen. (Of course, this did rely on my remembering terms like cube and diagonal.)
And I wrote the code myself, in a way that made sense to me. That said, I should definitely check it against an LLM or another source to make sure I didn’t screw anything up…
3. Verify the code using an independent method.
When independent processes come to the same conclusion for any sufficiently complex task, the probability of the result being incorrect decreases.
I looked online, and it turns out there is another version of the formula that I had forgotten about: D = √(e² + e² + e²).
(This jogs my memory about how we can extend into as many dimensions as we want [like hypercubes], and the diagonal will always be calculated by adding another e² under the square root for every additional dimension. But that’s getting off-track.)
Let’s use this “separate” (though algebraically equivalent) method to confirm our calculations…
> # Alternative (equivalent) Formula> cube_diag2=function(edge=1) {sqrt(edge^2+edge^2+edge^2)}> # It gives the same results as our other formula...> cube_diag2(1:2)[1] 1.732051 3.464102
Claude also suggested identifying coordinates for a cube in geometric space and using the dist() function (for the distance formula).
> # Using the Distance Formula> max(dist(expand.grid(x=c(0,1),y=c(0,1),z=c(0,1))))[1] 1.732051> max(dist(expand.grid(x=c(0,2),y=c(0,2),z=c(0,2))))[1] 3.464102
It all matches up.
I guess we could also use measurements of an actual physical box to confirm as well, at least to an approximation. But I think I’ll pass on that…
4. Try to break the code.
The goal here is to ensure that your representation is falsifiable. You want to seek out disconfirming evidence (prove yourself wrong), and if you fail, that makes you more confident (though not certain) that you understand correctly.
To do this, let’s input some silly “edge lengths”…
> # Let's see what kinds of results we get for differing inputs...> cube_diag(0)[1] 0> cube_diag(-1)[1] 1.732051> cube_diag(1e200)[1] Inf
Clearly, our code representation has some assumptions about what lengths we’re dealing with.
- The code works just fine with lengths of 0, even though there is no cube (real or imagined) that contains no space.
- The code also works for negative edge lengths, which doesn’t make sense for a cube.
- The code concludes that a very large cube has an infinitely long diagonal, which is incorrect.
So, if we wanted to employ this function more broadly, we’d need to add more specifications to avoid potential incorrect output.
But overall, I’d say the code accomplishes its purpose.
This exercise makes me more confident that I do understand the concept of a diagonal of a cube, including how it relates to the other properties of the shape.
And this mental representation in my mind exists independently of formulas found online, textbook definitions, or other people’s explanations.
Up next:
