A Tale of a Rubik's Cube, Mahler's Ninth, and a Misbehaving Data Warehouse

I remember rushing through dinner so I could get back to the living room floor.

This would have been around 1979. I was fourteen or fifteen, and the Rubik’s Cube had entered my world before the books, methods, notations and algorithms were widely available. At least, they were not available to me. There was no YouTube video to watch, no website to search, no helpful forum post, and certainly no AI assistant into which I could upload a few photographs and ask for the next move.

There was just the cube, a growing pile of A4 paper, and the urgent feeling that I was close to understanding something.

I had spread the pages across the floor, trying to represent the cube in different ways. I needed to flatten a three-dimensional object onto a two-dimensional page. I needed a way to describe positions, movements, colours and faces. I did not have a notation, so I invented one. I did not have algorithms, so I tried to discover them.

I would make a move, observe what had changed, try to work out what had stayed the same, and then attempt to repeat or modify the sequence.

Within about twenty-four hours I had got almost all the way there. I could reach a state where two cubies were in the right place but wrongly oriented. That was maddening and wonderful. I was not lost. I was almost there, but the final obstruction required a different kind of thought. It was no longer enough to move pieces into place. I had to find a transformation that changed what needed changing while preserving what I had already built.

Eventually I found it.

Over the following months I found more transformations. Some moved more pieces at the same time. Some were more efficient. Some were more general. I kept extending the method until, I think, I reached the limit of what my working memory could comfortably hold. At some point the sequences became too large to manage without a better formal system.

Looking back, the interesting thing is not really that I solved a Rubik’s Cube. Plenty of people have solved Rubik’s Cubes, many faster and more elegantly than I ever did.

The interesting thing is that, without a method to copy, I started building a private language for it. I created a representation, tested transformations, observed consequences, and refined a repeatable process. I did not know those words then. I did not know I was doing anything that sounded remotely like computing. But I was learning how to think about something too complicated to hold all at once.

Years later, I had a similar experience with Mahler’s Ninth Symphony.

I had spent a great deal of time with music notation. A score was not a mysterious object to me. It was a working document: notes, rhythms, dynamics, bowings, fingerings, entries, rests, page turns, all the practical instructions needed to turn ink into sound.

But the first time I listened to Mahler’s Ninth while reading the full score, something different happened.

The score was not telling me what to play. It was showing me the music as a system. A halting figure was handed from one instrument to another, changed a little each time it moved. Lines appeared and dissolved. A colour in the woodwind altered the meaning of a string phrase. A horn entry shifted the whole landscape. Material that might have passed unnoticed in the recording became visible on the page, and once visible, became audible.

The notation and the sound locked together.

A symphonic score is a map of events happening in time. At the climaxes of the Ninth, twenty, thirty, forty separate lines may be moving at once, dense and independent, each with its own shape and logic. None of them exists entirely alone. They support, obscure, contradict, echo and transform one another.

The cube had required me to invent a representation. Mahler showed me what it felt like to inhabit one.

The same skill appears in IT, although the objects are usually less beautiful.

I once worked on a misbehaving data warehouse whose performance was degrading every day. The visible symptom was simple enough: things were getting slower. But there are many ways to make a data warehouse slow. You can blame the queries, the indexes, the hardware, the volume of data, the scheduling, the optimiser, the network, or whatever else happens to be nearby.

The answer came from imagining the system beneath the abstraction.

As the warehouse grew, the distribution of data across disk was changing. The queries were spreading I/O across more of the physical storage. What should have been useful locality was turning into scattered access. The cache was becoming less effective. More and more work was missing the cache and going back to disk.

The fix was to sort the data, and to sort the queries, in key order. Performance recovered. In fact, it improved beyond the previous baseline.

There is a pleasingly heretical quality to that solution. In a relational system, the idea that stored data should have an order that matters is almost anathema. A relation is unordered. If you want order, you ask for it. That is the theory, and the theory is not wrong.

But physical reality still exists.

Blocks sit on disks. Reads have locality, or they do not. Caches reward some access patterns and punish others. Time is real. Distance is real. Hardware may be abstracted away, but it has not disappeared.

Relational theory was not wrong. It was just not the whole system.

That, I think, is the thread connecting the cube, the score and the data warehouse. In each case, the visible thing was not enough. The colours on the cube were not enough. The notes on the page were not enough. The performance graph was not enough.

The useful work happened in the space between representation and reality.

The cube on the floor, the score on the stand, and the system in production each demanded a way of thinking about hidden consequences: what a move preserves, how one musical line changes another, why logical data might behave differently when it meets disks and caches.

This may be why I have never felt my route into IT was as strange as it looks on paper. I have a music degree and no formal IT qualifications, but I do not think I arrived untrained. Music had already taught me how to read structure, listen for interaction, practise difficult passages, and perform under pressure. The cube had taught me notation, transformation, and state before I had names for them.

IT gave those habits somewhere else to go.

The modern question is what happens when so many of the intermediate steps become instantly available.

Today, in the same situation as my teenage Rubik’s Cube obsession, I would not be alone on the living room floor. I could search for notation instantly. I could find the mathematical structure of the cube, the standard transformations, beginner methods, speed-solving methods, videos, diagrams and communities. I might even be able to upload photographs of the cube and ask a machine what moves to make next.

Is that a loss?

Not necessarily. We should not romanticise ignorance. There is no virtue in unnecessary obscurity, and there was nothing noble about not having the right book. A teenager who starts with known notation and known methods might move faster into deeper questions: group theory, optimisation, programming solvers, designing new puzzles. Access to inherited knowledge can lift us. That is civilisation doing what it is meant to do.

But there is another possibility.

The cube can be solved without the solver being changed by it. The answer can arrive before the model has formed. The move sequence can be copied without understanding what it preserves, what it disturbs, or why it works.

That is not only true of cubes. It is true of code, systems, mathematics, design, and probably most serious skills. Tools can help us build better models faster. They can also let us act without building a model at all.

That is the real shift. A machine can now produce fluent answers: generate code, explain errors, suggest architecture, offer the next move. Used well, it removes pointless friction and makes learning more accessible. Used badly, it lets us confuse access with understanding, and answers with models.

Which raises a question worth taking seriously. If answers are becoming cheap, what becomes valuable?

I think it is the models that are hard to shortcut. Some understanding can be handed over intact. Some cannot, because the only way to acquire it is to build it yourself, slowly, in contact with the thing itself. You cannot be handed the feel of what a transformation preserves. You cannot be handed the ear that hears one line bend another. You cannot be handed the instinct that the performance graph is the symptom and the disk layout is the disease. Those models are made, not delivered.

And the experiences that make them are scattered. A cube on the living room floor. A score on the stand. A warehouse in production. None of these is the arts, or STEM, or anything tidy. What they share is that they resist the shortcut. They force you to construct a model strong enough to act on, and humble enough to revise.

For years the fashionable answer has been more STEM: more coding, more technical education, more obviously economic skills. I understand the impulse. My own working life has depended on technical skill. But if machines are becoming better at producing code, solving formal problems and offering plausible answers, then the scarce skill is no longer producing answers quickly.

It is judging them.

To hear what is missing. To understand how one part changes another. To connect notation to reality. To build an internal model strong enough to act on, and humble enough to revise. That is what the Rubik’s Cube gave me by accident. It is what Mahler’s Ninth gave me through sound and notation. It is what the misbehaving data warehouse demanded in production.

So the answer is not to restrict the tools. We should use them, and teach the next generation to use them well, and let them stand on the shoulders of giants.

But we should also make sure they still encounter the things the tools cannot do for them.

A machine can show the next move. It can suggest the code. It can explain the system.

But it cannot build the model on your behalf. It cannot hear the symphony from inside the orchestra for you. It cannot turn notation into judgement in your body and mind.

That is no longer just a sentimental defence of an old-fashioned education.

It is becoming part of how we stay capable.