Capital de Tokens
Does every child need to learn how to code? The question sounds simple, but it hides three separate debates: what every citizen should understand about technology, how we discover technical interests, and how far compulsory subjects ought to go.
On November 8, 2026, Computer Hoy revisited comments by Linus Torvalds, the creator of the Linux kernel and Git, challenging the idea that all children should become programmers.
The timing matters: this was not a position Torvalds first announced in 2026. The comments came from a conversation at Aalto University in 2012, and he explained a similar view in an interview published in 2014. Nevertheless, the debate is highly relevant in the age of artificial intelligence.
1. What Torvalds Actually Said
During the Aalto conversation, an audience member asked how to encourage children to build their own tools rather than merely consume technology.
Torvalds started from a central idea: specialization is a human strength. We do not need everyone in society to do the same technical work, just as we do not expect every person to train as a doctor or an engineer.
But he also made the other half of the argument, which often disappears from headlines: people who might develop a passion for programming should have genuine opportunities to discover it.
This is not a choice between learning and not learning. It is a distinction among exposure, exploration, and specialization.
In a 2014 interview originally published by Business Insider, Torvalds again supported computing classes in schools as a way for students to discover whether they enjoy programming. He was questioning the assumption that coding should become a universal requirement on a par with reading, writing, or basic mathematics.
2. Three Skills We Should Not Confuse
The phrase “everyone must learn to code” can mean very different things.
| Level | What it means | A school example |
|---|---|---|
| Digital literacy | Understanding and using technology critically and safely | Recognizing a scam, protecting an account, checking a source |
| Computational thinking | Breaking down problems, finding patterns, and expressing instructions | Designing steps to sort objects or navigate a maze |
| Programming | Creating, running, debugging, and maintaining software | Building a game in Scratch or an application in Python |
These three layers are related, but not interchangeable. We can teach computational thinking without requiring every student to master a professional programming language. We can also teach digital literacy without turning everyone into a software developer.
Conversely, a short programming experience can be an excellent way to discover an interest, even if the student never pursues it further.
The educational goal does not have to be producing more lines of code. It can be helping people understand what machines do, where their limits lie, and when to use them.
3. The Value of Raspberry Pi: Making Room for Experimentation and Failure
Torvalds brought up projects such as Raspberry Pi because they lower the cost of accessing a computer that can be explored, modified, and used to build things.
His point was not that every device sold would produce a future engineer. It was more realistic: many devices would end up largely unused, but if a few of them awakened a lasting interest, the opportunity was worth creating.
There is an educational design lesson here:
- A first encounter should be accessible, not intimidating.
- Learners need permission to make mistakes and try again.
- A tool that invites experimentation offers more possibilities than a closed experience where users can only press buttons.
- Success can also be measured through curiosity discovered, not just exams passed.
This connects with a modern paradox: a child can be extremely comfortable with apps, video games, and AI assistants while knowing little about how they are built or the assumptions they make.
4. What Changes with Artificial Intelligence?
This section is editorial analysis, not a claim about Torvalds’s views on today’s AI models.
In the past, building a simple application required writing much of its code by hand. Today, someone can describe a prototype in natural language and receive a first implementation from an AI assistant.
That changes the order in which skills become useful:
- Define a problem: know what we are building and who it is for.
- Break it down: identify inputs, outputs, constraints, and edge cases.
- Evaluate results: check that a solution works and detect bugs, hallucinations, or risks.
- Understand enough: be able to change, maintain, or reject a generated solution.
AI can lower the barrier to creating software. It does not remove the need for technical judgment. Code that is easy to generate can still be insecure, incorrect, or difficult to maintain.
Nor does it make programming education irrelevant. For learners who want to build complex systems, understanding algorithms, types, tests, networks, and architecture remains deeply useful.
The educational question evolves: should everyone be required to write code, or should everyone have the chance to create and understand technology, with pathways for deeper specialization?
5. The Risk of Misreading Specialization
There is a serious objection to Torvalds’s argument: if we only offer programming to children who already show an interest, we may mistake lack of exposure for lack of aptitude.
A child who has never had access to a programmable computer, an encouraging teacher, or time to experiment will struggle to demonstrate an interest they have never had the chance to discover.
A reasonable proposal therefore combines two principles:
- Universal access to introductory experiences: every student should be able to try age-appropriate activities involving logic, creation, and coding.
- Voluntary, well-supported specialization: students who become enthusiastic need projects, teachers, and tools that let them go further.
Using specialization as an excuse to close doors too early would miss the point. Specialization works best when everyone has had a fair chance to discover their preferences.
6. A Practical Model for Schools
Rather than turning every course into professional training, a school could organize technology education around four steps:
Explore. Create an interactive story, a small game, or an animation without making the programming language an end in itself.
Understand. Explain why an instruction produced a result, how information is represented, and what a tool cannot do.
Verify. Test unexpected cases, find a bug, distinguish plausible answers from correct ones, and practice digital security.
Choose. Offer more advanced pathways—robotics, games, electronics, data, design, or programming—without portraying them as the only legitimate form of technological competence.
The same classroom can inspire future engineers, designers, scientists, and citizens with better digital judgment.
Conclusion: Teach Possibilities, Not Professions
Torvalds did not ask schools to keep children away from software. He argued that specialized programming should not be confused with a compulsory skill for every person, and that curiosity needs opportunities to reveal itself.
In 2026, when AI can write code from instructions, that distinction is even more valuable. Schools need to teach students how to understand systems, frame problems, and evaluate results; they must also keep the door open for those who want to dive into software development.
Good technology education does not manufacture programmers on an assembly line: it helps every student discover what they can build and what they need to understand.