Every summer when I was growing up, my family would travel from New Delhi to Bhowali, a small town in the hills near Nainital. I was born in Nainital and spent my first few years in Bhowali before we moved to Delhi. My family still has a home there. Those two months each summer were the opposite of city life. Green hills, cool air, and the kind of quiet that makes you notice things.

We lived on the campus of Jawaharlal Nehru University in New Delhi, where my uncle Pushpesh Pant was a professor. Growing up on a university campus meant that learning was just part of the air you breathed. I used to walk to JNU’s computer center to send email through the UUCP/SMTP gateway on ERNET. We did not have a network connection at home, so that was the only way.

I was in fifth grade that summer. I had been programming since second grade, when my friend Rishab Ghosh let me use his Sinclair ZX Spectrum. By fifth grade I had my own computer at home, an IBM PC compatible, and I had taught myself BASIC, Pascal, and Logo. I played cricket and soccer and table tennis and practiced martial arts. I also loved programming.

But that summer in Bhowali, I did not have my computer. It was at home in Delhi, and I was two months away from it.

So I decided to write a game on paper.

The game was a car racing game, the kind where a road scrolls toward you and you use two keys to steer left or right, trying to keep your car on the road. I had seen games like this before. There were skiing versions, airplane versions, all built on the same idea: a narrow path moving down the screen, obstacles appearing, and you trying not to crash. The whole thing would be drawn with text characters on the screen. No graphics card needed, just characters arranged to look like a road, a car, and whatever else I could represent with the symbols available to me.

I got a notebook, the kind we used for schoolwork, and I started writing BASIC code by hand. Line by line, page by page. I wrote the logic for the road curving left and right. I wrote the part that read which key the player pressed. I wrote the part that checked whether the car was still on the road or had crashed. I thought about how the screen would scroll, how to make the game get harder as it went on.

Over the course of two months, I filled about a dozen pages with code. And I checked it carefully. I went through every line looking for spelling mistakes in the commands, mismatched parentheses, wrong variable names. I ran the program in my head, what we called a “dry run,” stepping through the code line by line, imagining what the computer would do at each step. I did this many times. By the end of the summer, I was sure the code was right.

When I got back to Delhi and sat down at my computer, I typed in every line exactly as I had written it. I was careful. I did not want a single typing mistake to ruin two months of work.

I typed RUN and pressed Enter.

What appeared on the screen looked nothing like a car racing game. Characters flew across the screen in patterns I did not recognize. Things moved in ways I had not planned. It was not a game. It was a mess.

I stared at it for a while. Then I tried to fix it. I went back through the code, looking for the mistake. But there was no single mistake to find. The code had no syntax errors. BASIC did not complain about any line. Every command was spelled correctly. Every variable name was consistent. Every line was valid. The computer accepted all of it. It just did not do what I wanted it to do.

This was confusing in a way I had not experienced before. I was used to mistakes being obvious: a misspelled command, a missing line number, something the computer would refuse to run. This was different. The computer ran my program happily. It just produced the wrong result.

I spent days trying to debug it. But with a dozen pages of code written away from a computer, the logic errors were so deeply woven into the program that I could not untangle them. I could not find where the road-drawing logic went wrong, or where the key-reading part fell out of step with the screen updates. Everything depended on everything else, and none of it worked together.

Eventually, I gave up on the paper code entirely. I started over from scratch, building the game the way I had always built programs before: write a few lines, run them, see what happens. Add a little more, run it again. Fix what breaks. Keep going. That was how I had learned to program since I first touched Rishab’s Spectrum. It was not a method anyone had taught me from a textbook. It was just common sense. You build something small, check that it works, and build on top of it.

The game I built the second time actually worked. The road curved. The car moved. You could crash. It was not sophisticated, but it did what I intended.

I have often thought about that experience and what it taught me. What I took away from it goes beyond programming, and I want to share it because I think it applies to a lot more than writing code.

Every line of my paper code was valid BASIC. The syntax was right. If you looked at any single page, you would see nothing wrong. But a program is not a collection of correct lines. It is a system where every part has to work with every other part. I had checked the pieces but I had no way to check the whole without actually running it. Something can be correct in every piece and still be wrong as a whole. I have seen this in schoolwork, in group projects, in plans that look perfect on paper. The pieces make sense individually but they do not fit together until you actually try to make them fit.

And I had been so sure it would work. I spent two months checking that code. I earned my confidence, or I thought I did. But being sure about something, even after a lot of careful work, does not make it true. The only way to know if something works is to try it. I have tried to remember this every time I feel certain about something I have not actually tested.

The most useful thing I learned, though, was something I already knew but did not appreciate until it failed. Everything I had ever built, I had built a little at a time. Write a few lines, run them, fix them, write more. That summer in Bhowali was the one time I tried to build the whole thing first and test it later. And it failed completely. So now I know why I do it the way I do it. Build small, test often, and do not go too long without checking whether what you have actually works.

I am writing this from Philadelphia, where I am a student at Temple University. It is summer and I am here, not in Bhowali. This is the first summer I can remember where I am not with my family. I miss the hills, and I miss sitting on the veranda with a notebook while the rain comes in. Writing this has been a way of going back there for a little while.