Last month, I watched a ten-year-old spend nearly twenty minutes trying to make a cartoon cat move across a screen. The cat moved, but not in the direction he wanted. He changed one instruction, ran the program, saw a new error, and changed another. Nobody gave him the answer. Nobody told him that he was “wrong”. He kept testing.
That small scene captures why I believe children should learn some coding in school. Not because every child must become a software engineer. Not because coding is the latest fashionable subject that anxious parents must buy for their children. I believe children should learn coding because it teaches them to think clearly about cause and effect, to break a large problem into smaller ones, and to treat failure as information rather than humiliation.
But I also believe that much of what passes for coding education in Indian schools is a waste of time and money. A child memorising Python syntax for an examination is not learning to code. A school buying tablets and calling itself “future-ready” is not teaching computational thinking. Coding can be useful, but only if we teach it as a way of making and thinking, not as another subject in which children compete for marks.
Should kids learn coding? Yes—but not for the reason most parents give
When parents ask me whether their child should learn coding, the usual explanation is economic: “Technology is the future. My child should not be left behind.” I understand the anxiety. I see the same anxiety in parents who push their children towards engineering because they fear that every other career is unsafe. I have written earlier about why Indian parents push their children into engineering. Coding classes are now becoming a younger version of the same race.
Parents are told that a six-year-old who learns Scratch will have an advantage over a child who does not. Then come robotics classes, app-building camps, coding Olympiads and expensive after-school programmes. The child may spend hours dragging coloured blocks on a screen while the parent feels reassured that the future has been secured.
It has not.
The main reason to teach coding is not that every child will get a coding job. Most will not. The main reason is that coding makes thinking visible. When a child gives a computer a sequence of instructions, the computer does exactly what it has been told—not what the child intended. This is a wonderful discipline. It exposes vague thinking immediately.
If I tell a child, “Make the character reach the door,” that instruction is useless to a computer. The child must specify the steps: move forward, check whether there is an obstacle, turn, repeat, stop when the door is reached. This is not merely a technical skill. It is the habit of converting a wish into a process.
That habit is useful in every profession, including medicine and investing.
When I counsel a couple undergoing IVF, “We want a baby” is a deeply understandable goal, but it is not yet a treatment plan. We have to understand age, ovarian reserve, sperm quality, previous treatment, medical history and the couple’s tolerance for uncertainty. In the same way, a founder who says, “We want to improve healthcare” has not yet described a business. The idea must be broken into a user, a problem, a behaviour, a product and a way of measuring whether anything improved.
Coding trains this habit early.
What a child actually learns when a program fails
The most valuable moment in learning to code is often the moment when the program does not work.
In school, children are usually trained to avoid mistakes. A wrong answer loses marks. A poor examination result embarrasses the child and alarms the parent. The safest strategy is to remember what the teacher said and reproduce it accurately.
Programming works differently. The error is not a verdict on the child’s intelligence. It is a clue. The child returns to the instructions, identifies an assumption, changes one part and tries again. This process is called debugging, but it is really a method of reasoning.
A child who learns that an error message is a clue—not a judgement—has learned something more valuable than a programming language.
I see the importance of this distinction in my work with founders. Early-stage companies rarely fail because the founder cannot write a business plan. They fail because their assumptions remain untested. They assume patients will pay, doctors will change their behaviour, hospitals will share data, or employers will buy the product. The founder who can run small experiments and learn from the result has a better chance than the founder who protects a beautiful but untested idea.
Children deserve the same intellectual freedom. A coding class should allow them to build something that does not work, understand why, and try again. If the teacher corrects every error before the child has had time to investigate it, the child learns dependence, not problem-solving.
This is also why I am sceptical of coding competitions as the centre of school programming. Competitions reward speed and correctness. They have their place, especially for children who enjoy them. But a school should not confuse solving a puzzle quickly with learning how to make something useful. The child who spends three weeks building a simple interactive story may learn more than the child who wins a timed algorithm contest.
Coding is not the same as computer literacy
There is another reason to be precise. We often use “coding” to describe several different things.
| Activity | What the child does | What the child may learn |
|---|---|---|
| Digital literacy | Uses a browser, word processor, email or presentation tool | How to use technology safely and productively |
| Block-based coding | Combines visual commands in tools such as Scratch | Sequences, loops, conditions and simple logic |
| Text-based programming | Writes instructions in Python, JavaScript or another language | Precision, abstraction, debugging and program structure |
| Computational thinking | Breaks a problem into parts and identifies rules or patterns | A general method of reasoning that need not involve a computer |
All four are useful, but they are not interchangeable. A child who knows how to make a presentation has not necessarily learned to code. A child who can reproduce a Python exercise from a textbook may not understand how to solve a new problem. And a child can learn computational thinking through a paper-and-pencil activity, a board game or a science experiment without touching a computer.
I like Scratch for younger children because it removes the frustration of spelling and punctuation while retaining the core ideas of sequence, repetition and conditions. The child can concentrate on what the program is meant to do. Later, text-based languages become useful because precision matters. But the language is secondary. Teaching JavaScript instead of Python does not automatically make a programme better.
The project matters more than the language.
What should coding look like in an Indian school?
Our schools face a practical problem that is often ignored in glossy discussions about coding. Many classrooms have one computer for several children. Internet connectivity may be unreliable. Teachers may already be overloaded with administrative work. A school may have smart boards but no one who knows how to use them well. In government schools, even access to devices can be uneven. In private schools, access may exist but be used mainly for marketing.
So I would not begin by asking whether a school has a coding lab. I would ask what children are being asked to make.
A good programme can begin with very little equipment. Children can write instructions for a classmate to draw a shape, then examine where the instructions were ambiguous. They can design a paper maze and create rules for navigating it. They can model a queue at the school canteen. They can use a spreadsheet to compare how long different routes to school take. They can build a simple story in Scratch using a shared computer.
After that, I would introduce coding through projects connected to the child’s world:
- Start with a problem the child recognises. A game, a story, a timetable, a quiz or a simple school map is better than an abstract exercise with no visible purpose.
- Ask the child to predict what will happen. Prediction forces the child to form a mental model before pressing “run”.
- Let the program fail. Resist the temptation to intervene immediately. Ask what the child expected, what actually happened and which instruction might explain the difference.
- Change one thing at a time. This teaches the logic of testing rather than random trial and error.
- Ask the child to explain the program to another child. If the creator cannot explain the steps, the program may be working by accident.
- End with reflection, not just a demonstration. What assumption was wrong? What would the child change? What new problem could the same idea solve?
This sequence is more important than whether the school teaches Python in Class 6 or Class 7.
Teachers do not need to be professional programmers. They do need permission to learn alongside their students. A teacher who says, “I do not know why this failed; let us investigate it together,” may teach more than an instructor who has memorised every command but never allows children to struggle.
The danger of turning coding into another coaching industry
India has a remarkable ability to convert every useful idea into an examination treadmill.
We did this with mathematics, English, public speaking and now coding. Once parents hear that coding is valuable, a market appears. The market sells certificates, rankings and the promise of an early advantage. Children are enrolled in weekend classes not because they enjoy making things, but because their parents fear that other children are getting ahead.
I have seen a similar pattern in healthcare. Patients are often sold additional tests because more testing sounds more scientific. But a test is useful only when it changes a decision. A coding course is useful only when it changes how a child thinks or creates. The certificate itself has little value.
Parents should ask a coding provider three simple questions:
- What will my child make by the end of the course?
- How much time will the child spend solving problems independently rather than watching demonstrations?
- How will you respond when the child’s program does not work?
If the answer is mainly about certificates, competitions and future salaries, I would be cautious. If the child is building, testing, explaining and revising, the course may be worthwhile.
There is also a fairness issue. Coding must not become another advantage available only to affluent children in expensive schools. If we make it a compulsory subject without providing devices, teacher training and time, we will widen the gap between children rather than reduce it. The child with a laptop, a quiet room and a private tutor will race ahead of the child sharing one phone with three siblings.
I have written about the waste of children’s time in Poor Children and the Waste of Years. A poorly designed coding curriculum adds to that waste. Every hour in school is precious. We should not spend it teaching fashionable terminology when children still lack the confidence to ask questions, read with understanding or explain their own reasoning.
Should every child learn the same amount?
No.
Every child should get an introduction to computational thinking and a chance to make something with code. But not every child needs advanced programming. Some children will discover a genuine interest and should be allowed to go much further. Others will prefer biology, music, carpentry, literature, commerce or sport. The purpose of universal exposure is not universal specialisation.
This is an important distinction because parents often mistake exposure for a career decision. A child who enjoys building a game at age nine does not need to be labelled a future software engineer. A child who dislikes coding at age twelve has not closed every professional door. We should give children opportunities without turning each opportunity into an identity.
In my IVF practice, I am careful not to promise certainty where biology offers probabilities. Education deserves the same honesty. Coding may help a child develop useful habits. It does not guarantee a job, admission to a prestigious college or entrepreneurial success. It is one tool among many.
The child who learns to write clearly, listen carefully, work with others and persist through difficulty will probably do well even if she never writes a program. The child who learns programming but cannot collaborate, communicate or understand another person’s needs will struggle, regardless of technical ability.
Artificial intelligence makes the question more important, not less
Some parents ask whether coding still matters now that artificial intelligence can write code. My answer is yes, but the reason has changed.
When tools can generate a program from a plain-language request, typing syntax becomes less valuable. Understanding what should be built, whether the output is correct, what assumptions it contains and how it might fail becomes more valuable. A child does not need to memorise every command to use a computer well. But the child needs enough understanding to question the computer’s answer.
This is similar to using medical technology. I can use an ultrasound machine, a laboratory report or an AI-assisted diagnostic tool, but I remain responsible for asking whether the result makes clinical sense. A tool can produce an answer with impressive confidence and still be wrong. The doctor’s job is not replaced by the report.
Likewise, a child who understands loops, conditions, data and testing will be better placed to use AI-generated code than a child who treats the output as magic. Coding education should therefore move away from memorising syntax and towards understanding systems, testing outputs and recognising bias and error.
Children should also learn that software is not neutral. The choices made by programmers affect what people see, which applications are easy to use, whose data is collected and who is excluded. A school that teaches children to build a simple recommendation system should also ask what happens when the recommendation is wrong. A class that creates a facial recognition demo should discuss consent and privacy. Technical ability without judgement is not enough.
The surprising benefit: coding can make children less dependent on adults
The moment that stayed with me from the ten-year-old and his cartoon cat was not that he solved the problem. He did not, at least not during the time I watched him. What impressed me was that he did not look at the adult every time something went wrong.
He had learned that the computer was not an authority to please. It was a system to investigate.
This is a small but important shift. Indian education trains children to wait for the correct answer from the teacher, the textbook, the coaching class or the parent. Coding can give them a private space in which they are allowed to decide what they want to create and then discover whether their instructions work.
That independence is also what I look for in founders. I do not expect an early-stage founder to know everything. I do expect the founder to notice a problem, form a hypothesis, test it and return with evidence. I would rather back someone who has run five small experiments than someone who presents a perfect slide deck full of unsupported claims.
Schools should teach children the same lesson: do not wait for permission to think.
My position is therefore straightforward. Yes, children should learn coding in school—but as a practical language for expressing ideas, testing assumptions and making things. It should not become another compulsory race, another source of certificates, or another excuse to neglect reading, writing, play and human relationships.
If a school tells me that its coding programme has produced a hundred certificates, I am not impressed. I want to see one child show me a project that failed, explain why it failed, and describe what she changed. That child has learned something no certificate can measure—and that is the child I would trust with the future.