How a Programmer Tried to Crack the Rubik's Cube

I had a Rubik's Cube in 1981. I never solved it. I peeled the stickers off, which felt like cheating but also felt inevitable, and which I now understand was its own kind of algorithm: reduce the problem space until the answer is trivially obvious. I mention this not as confession but as orientation. When I watch Sebastian Lague's new video, Coding Adventure: Solving the Rubik's Cube, I am not watching from a position of detachment. I am watching with the particular attention of someone who once held the problem in his hands and surrendered.

Lague's coding adventure series has built a following by doing something that sounds simple but isn't: showing the actual process of building something complicated, including the parts where it doesn't work. This episode is twenty-four minutes long and covers the construction of a virtual cube, the design of a compact binary state representation, and three progressively more capable solving algorithms. The cube, as a puzzle, has always withheld its last secrets at precisely the wrong moment.

What the cube actually is

Before any algorithm, you need to understand what you're working with. The 3x3 Rubik's Cube has 26 external physical pieces—8 corners, 12 edges, and 6 center faces (counting the centers, which sit fixed and don't migrate between positions). The 6 centers, as Lague correctly notes, can be treated as locked in place, since rotating a center is mathematically equivalent to rotating both adjacent faces in the opposite direction. That leaves 20 pieces that actually move, but 26 that exist.

The number of ways those 20 movable pieces can be arranged: 43,252,003,274,489,856,000—roughly 43 quintillion, a figure documented thoroughly in the mathematical literature and summarized accessibly on the Wikipedia page for optimal Rubik's Cube solutions. It is a number that resists intuition. The known universe is approximately 13.8 billion years old. If you had been making one random cube move per second since the Big Bang, you would not yet have visited every possible configuration.

It was proven in 2010—by a team using Google's computing resources to exhaustively verify all positions—that every scrambled cube can be returned to solved in 20 moves or fewer. This is called God's Number. Lague mentions it early, and it functions throughout the video as a horizon: reachable in theory, practically inaccessible with the tools at hand.

The elegant compression at the center of this project

Lague's most interesting decision isn't the solving algorithm. It's the representation.

The naive approach—tracking each cubie as a 3D object and rotating it geometrically—is, as he puts it, "ridiculously inefficient" for the millions of positions a solver needs to evaluate. So he strips the cube down to pure information: two integers. Edge positions and orientations packed into a 64-bit value. Corner positions and orientations packed into another. The entire state of the cube, in memory, fits in a space smaller than a short sentence.

The orientation encoding is worth pausing on. An edge piece can occupy the correct location but be flipped—white facing forward instead of up, say. Lague handles this by establishing a hierarchy of face rankings (top/bottom outrank front/back, which outrank left/right) and checking whether each colored sticker occupies a face of appropriate rank for its color. Oriented or not, one bit per edge. It is the kind of solution that looks inevitable once explained and would not have occurred to most of us unprompted.

Corners are trickier. Three possible orientations per corner, mapped to three cases based on where the white or yellow sticker lands. The encoding works, but Lague admits, "I definitely feel like I'm missing something more elegant—I'd love to hear if you have better ideas." That invitation is characteristic. He treats the viewer as a collaborator rather than a student, which is part of what makes the series work.

The decision to pre-compute the movement maps and paste them as raw constants into the code—rather than generating them at runtime—is the kind of choice that reveals a craftsman. It's not about speed. "It's essentially instant," Lague says. "It just feels nice." I understand that entirely. There is a kind of integrity in keeping the solving logic clean of the graphical machinery that surrounds it. The separation is aesthetic as much as architectural, and I mean that as a compliment.

Three solvers, each teaching the next

The brute-force recursive search establishes the problem's shape. Depth one: fine. Depth four: a millisecond. Depth seven: seven seconds. Depth eight: two minutes, visiting—per Lague's own benchmarking in the video—approximately 11 billion nodes. Depth twenty: not in any reasonable lifetime.

The exponential explosion is not a surprise to anyone who has thought about combinatorics, but watching it unfold in real benchmark numbers is instructive. Pruning helps. Eliminating immediately repeated face turns cuts that two-minute depth-eight search to 36 seconds. Eliminating redundant opposite-face sequences (which commute and therefore don't need to be explored in both orders) brings it to about 16 seconds. Parallelizing across 18 threads gets it to roughly 3 seconds. Progress, yes. But depth twenty remains a fantasy.

This is where Lague pivots—and watching it happen is one of those moments in a coding series where the educational architecture quietly shifts gears. He has been building toward a ceiling, and now he decides to stop trying to break through it and build something useful beneath it. The greedy solver scores each position by counting how many cubies are correctly placed and oriented, subtracts the move count to prefer efficiency, and iterates. It finds a solution on the first scramble. "Wait, did that actually work? I was not expecting that."

Tested across a thousand scrambles, the greedy solver averages 44 moves and succeeds 9.6% of the time. The failure mode is instructive: it gets the cube mostly solved, then cannot see far enough ahead to fix the remaining pieces without dismantling what it's already built. Myopia, in algorithmic form. It is solving for the present at the expense of the future, which is a problem not confined to cube-solving programs.

The Sandwich Solver—Lague's name for his meet-in-the-middle approach—addresses this by running a second search backward from the solved state. This backward pass, according to Lague's video, populates a dictionary of known states within five moves of solved, using roughly 10 megabytes of memory (going one move deeper would jump to 150 megabytes and significantly slow the search). The forward solver can then recognize when it has reached a position in that dictionary and know it is close. The approach is sound: two searches, each covering half the distance, meeting somewhere in the middle of a space too large for either to cross alone.

What this is actually about

Lague is not a competitive speedcuber. He is not a combinatorialist. He is a programmer who looked at a hard problem and decided to think carefully about it, in public, in real time. The value of the video is not the solution—the cube has been solved optimally by programs far more sophisticated than this one, and Lague knows it—but the quality of thinking on display.

The bit manipulation, the orientation encoding, the pruning decisions, the acknowledgment of dead ends: these are craft moves. They reflect a mind that has learned to find satisfaction in the fit of things, in the cleanness of an abstraction, in the moment when the data structure and the problem align well enough that you can almost feel it.

I spent twenty minutes in 1981 failing to solve a physical cube before I reached for the stickers. Lague spent considerably longer building three algorithms of increasing sophistication, each one teaching him something the previous couldn't. The cube, for what it's worth, looks exactly the same at the end of both stories. The difference is in what was built along the way.

Harold "Harry" Goodman is Buzzrag's spoken word and audio storytelling correspondent. A former NPR radio producer, he has covered audio craft for four decades.