There is nothing more gratifying for a small child than taking things apart. Observing children, usually around the age of two, one notices they are completely entranced by the physicality and feel of objects. They touch, smell, taste, apply force, and rotate the object, in a bacchian feast of sensual stimuli. That, however is not a physical process at all. Apart from the obvious sensory feedback, the child is actually conducting a complex mental process.
Jean Piaget, the famous Swiss psychologist known for his work on child development, tells us that children go through four developmental stages.
A Sensorimotor Stage (birth – 2 years old) where they learn about the world through their senses and the manipulation of objects.
The Pre-operational Stage (2 – 7) where children develop memory and imagination, understand things symbolically, as well as the ideas of past and future.
The Concrete Operational Stage (7 – 11) during which they become more aware of external events, as well as feelings other than their own.
And finally a Formal Operational Stage (11 – ) in which children are able to use logic to solve problems, view the world around them, and plan for the future.
When the child (2 – 7) is taking things apart, manipulating them and putting them back together she actually constructs a mental image of the object, its parts, and their spatial relationships. This learning process creates an understanding of how things work, or better so, defines the physical world constraints allowing physical objects to interact.
What the two year old is doing is in fact not much different than the work of an architect, mechanic, or software developer.
According to the Oxford dictionary, coding, sometimes refereed to as programming is: “The process of writing computer programs”. Seasoned programmers would tell you coding is simply the process of instructing a machine to do a predefined set of operations.
Is it?
Obviously, the purpose of coding is to create a well formed and functional computer program, and the method employed is writing down a set of instructions for the machine to execute. Those however must not be mixed with the process of coding.
Much like the child evolving mental model of the now completely dismantled toy lying in front of him, a coder develops a mental image of the problem prior to writing a single statement.
If you are not a technical person, and never gone through the above experience, try to imagine an architect building a skyscraper, or a city planner designing the transportation routes around a megalopolis. In order for them to be able to put their plans on paper enabling its execution, they need to envision the structure and inter-relationships between the different parts of the city/building.
Such a city planner would have to create a mental model (image) in order for her to construct the complex grid of roads, subterranean tunnels, and pathways that would optimally serve metropolitan inhabitants. She has to take into account the interplay between the infrastructure, buildings, people’s needs, commercial outlets and their requirements and many other crucial details, all affecting the final design.
And she has to do it before she pencils anything down.
A good city planner, as well as a good architect or coder, goes through such processes before he or she implement a single line of code/blueprint. Writing down the code is a translation of that mental model into a language understood by the underlying machine or, in case of architects, a set of blueprint drawings. Languages, by the way, and their abstractions are crucially important for this translation process to be as quick and error-free as possible (something we would expand on in future articles).
If you have been around programmers for some time, you probably heard the term “10x coder” bounced around. The highly-coveted mythological 10x coder is the one that manages to write high quality code in tenth of the time other programmers do. Those would usually be spotted sitting in the midst of a large humming open space, earphones on, punching the keys on their keyboard in a staggering pace.
10x coders are the envy of normal programmers, and a major cause of frustration for the latter. But, how are they different? What allows those geeky looking unicorns to produce such quality results in such a short time? The answer is that they have a huge head start. The 10x coder has already solved the problem, built the mental model, and now punching the keyboard, he is merely translating it into code.
Good 10x coders hold a multi-dimensional image of the problem, and a visual image of the code itself at the same time. Coding then becomes an act of copy-translate-paste of the mental model into a text editor.
To make this clearer, think about a very large LEGO construction laid on the floor beside an equally large blank piece of paper. You are a LEGO employee writing the manual for LEGO fans to be able to reproduce your creation and need to describe it on paper using nothing but text and drawings.
You’ll probably start by going around the LEGO looking at it from various angles, while drawing a description of it on the piece of paper. At some point you realize that you have a mental image of the entire LEGO construction and another one of the text and drawings on the paper. It becomes much easier to envision any part of the LEGO immediately followed by writing or drawing an instruction at the right place on the sheet of paper.
This process, where one is engulfed within a mental image, freely and almost effortlessly traveling in its mindscape, is sometime refereed to as being in the zone. You’ve probably heard people telling you to shun away from some coder as he is in the zone. What they are actually asking of you is not to interrupt that fragile state of mind allowing him to hold this monumental multi-dimensional construct in his head (and you really shouldn’t, it’s very annoying).
Well, that seems simple enough. A motorcycle is a mechanical construction combining an engine, gearbox, transmission, a set of brakes, wheels and place for you to grab on while it whirs forward at formidable speeds.
Untrue.
I think Robert Pirsig beautifully phrased it in his classic Zen and the Art of Motorcycle Maintenance:
That’s all the motorcycle is, a system of concepts worked out in steel. There’s no part in it, no shape in it, that is not out of someone’s mind.
Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance
A motorcycle is a set of concepts, interacting. It is an idea, or better so, a hierarchical set of ideas put together in functional harmony to serve a purpose. In that sense a motorcycle is no different than an intricate computer program. Both are a hierarchical functional structures aimed at executing a goal. A motorcycle should drive, while a program should output a result.
Once you understand that, the similarities between a computer program and a motorcycle become apparent. A mechanic working a faulty motorcycle is employing the same kind of thinking as a coder would when approaching a program execution error.
An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the > mechanic does.Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the > greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem so taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.
Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance
Both the good mechanic and the 10x coder share a holistic view of the apparatus at hand. Both have a mental model of the parts and their relationships allowing them to travel through the bike/code mindscape. Sometimes, as Pirsig describes, they would stop and stare. They are not lazying off, rather doing the most important part of their job, traversing the model. This holistic view is what allows a motorcycle mechanic, as well as a 10x coder to be extremely good at what they do.
Every biker knows the feeling. The intoxicating moment when the ride becomes an effortless set of motions gliding through the curve, a moment when bike and rider become one. It is a Zen moment if there ever was one. During that moment, be it short or lengthier, the rider is in: the zone. Her actions, the way she handles the bike, how she moves on it, or handles the bars and throttle all become part of a holistic mental image comprised of thousands of details going by at enormous speeds.
But still, how is it possible to ingest all this data in real time and still take the right decision? How does a rider positions himself at the exact angle to match the line of the curve, its camber, a changing radius or the occasional debris? The answer is that he has already done so. By the time the bike leans through the turn, the rider has already taken that turn in his mind.
Watch Philipp Oettl, a MotoGP rider preparing for the race, eye closed, imagining each and every turn in his mind’s eye.
The MotoGP is one of the toughest motorcycle races (superseded only by the Isle of Mann TT). Riders take great care preparing for it, as a split second decision can cost them the podium. Much of the training is indeed physical as the ride is an incredibly taxing exercise but none of the workouts would do if the rider does not memorize the optimal path through the turns. Beforehand.
Oettl, preparing for the race is not much different than the 10x coder blazing on his keyboard. Both carry out a complex task using a pre-built mental model. Both seem to be operating in the physical world, but in fact they are completely immersed in their own internal representation of it, continuously translating it into real-world actions. Only once they have mastered that internal representation can they ride/code with such efficiency and effortless flow.
And that leaves us with just one final question: Why?
The answer is both complex and extremely simple. It shares much of the underlying reasoning, but we would not answer it here today. Instead, let me leave you with this short video that tells some of the why.
