What Lego, Meccano and Linka Taught Me as a Child That Made Me a Better Software Engineer
I’m sure it can’t be pure coincidence that a large number of the people who are software engineers today grew up playing with toys such as Lego, Meccano and Linka.
I can’t help but think that the countless hours I spent building, dismantling, playing, struggling and eventually understanding them contributed to being better at many of the equivalent activities I perform as a software engineer today.
So what is it about these particular toys?
Component Parts… and Lots of Them!
All of them provide a huge pile of component parts. That’s basically all you get. Occasionally, they come in a kit intended to make a particular outcome or piece, but what they all have in common is that you end up building up a huge collection of parts… in a box under your bed!
With software, the — albeit much more complex — component parts are the language constructs, commands, utilities, OS features and web browsers we are provided with. As-provided, they don’t do particularly much, but they are a starting point, just like those Lego bricks. Being virtual, unlike Lego, they thankfully come in a limitless supply!
Rules
The component parts of these toys have certain rules and restrictions governing how you can connect them together and therefore what you can build with them.
With Lego, you can largely only stick blocks on top of one another in quite restrictive ways, parallel to each other or at right angles. But even within those limitations, the possibilities are still almost endless.
With Meccano, the rules are more complex as you can bend pieces, connect them at weird angles, use wheels, axles, belts and cogs. There are more rules to learn, but the possibilities are also arguably more interesting.
As for Linka, which I used to create buildings and models out of plaster of paris, you create the component parts using rubber moulds, but this also means you can modify those parts, chop them up or combine them in very free-form ways.
My favourite example as a child was a house that had partly collapsed. It required creation of walls with natural-looking holes in them. For some reason, this departure from rigid rules fascinated me.
Visualising Possibilities
The problem with component parts is that they represent nothing in their raw form… other than possibilities.
Children who grew up with these toys slept with a box of possibilities under our beds!
This means you start to visualise what you are going to build, to reason about what is possible and to hold those ideas in your head.
Initially, many children put Lego bricks together at random, but they soon learn to visualise something and to build that… or at least something close to it.
“What are you building?” — They also learn to talk about what they are going to build and to explain it.
With software, there are so many possibilities that you could never simply code at-random. You need to visualise an outcome, perhaps something mid-way between the real-world outcome you want and the code required to achieve that. We tend to call these “abstractions”: Representations of something at a certain level of detail, hiding the complexities within it.
The same is true of Lego, Meccano and Linka: You might imagine building a house (an abstraction), then imagine the detail of the walls (another abstraction), windows, roof etc.
Piecing those abstractions together in your head, at different levels of detail, and understanding whether it will be possible to build them in real life, given the component parts and rules, is an amazing skill that these toys teach by trial-and-error… and a huge step towards doing the same with software, which is a much more abstract, complex and invisible medium.
Discover, Experiment & Learn
Aside from random construction, the other thing no one does with these toys is to sit and imagine an outcome in all of the detail required to build it, then just build it.
These are not sequential play activities. There is always an element of discovery, experimentation and learning what does/doesn’t work. You often need to tweak your approach and try again.
Perhaps the four Meccano pieces you thought would connect together to form a perfect square don’t align correctly, because of the nuts & bolts involved. Perhaps the 4th floor of your Linka house doesn’t support itself and needs reinforcing. Perhaps the windows in the Lego car are too high for the figures you intended to drive it.
What these discoveries teach you are deeper and more complex rules and realities about the component parts you are using.
In software, we call this discovery and repetition “iteration”: Repeating an activity, usually with new information. In this case trying, experimenting, learning, and trying again.
No one imagines and then builds software in a strict sequence without a degree of discovery and iteration, and no one does that with these toys either.
Diagnose & Fix
It is easy to start with a clean slate and to build something from scratch in Lego, Meccano or Linka, but another thing entirely to have a half-finished item and to figure out what’s wrong with it or how to progress with it.
Maybe you need to partly dismantle it in order to fix the problem, then put it back together again.
The same is true of software: We don’t often get “greenfield” opportunities or a clean slate. Usually, we have an existing product or system to fix or to continue building.
The analysis skills required to figure out what’s going on with something complex are hard-won, and often the result of years of trial-and-error. It’s my belief that you can’t really teach them, but you can discover them if the environment in which you play affords you sufficient possibilities, is complex and full of potential problems, but still interesting enough to entice you to break through those problems and to make progress.
You start to see and to analyse the world in the same ways that you need to analyse software.
I’m not sure whether these three products are played with by children today as much as they were in the 70s and 80s, when I grew up with them. I really hope they are.
The possibilities they present, the challenges and opportunities to learn are second to none and, I’m sure, result in skills that often make better engineers in many fields: software, architecture, construction, aeronautics…
As the creator of Lego once wrote in a leaflet found in early boxes…
“The most important thing is to put the right material in their hands and let them create whatever appeals to them.”
Whether that’s Lego, Meccano, Linka or a first computer, I couldn’t agree more!
