How to think about programming
What decided how far I got — and it was not the language I picked.
⏱ About 2 min read
The question I asked wrong
The first thing I asked when I started was: "which language should I learn first?"
I spent weeks reading language comparisons. Looking back, those weeks were close to worthless.
The better question is: how do I break a big task into steps small enough for a machine to follow?
A language is only the notation for writing those steps down. Switch languages and the notation changes; the hard part stays exactly where it was.
The three things that mattered most
1. Breaking problems down. Turning a vague request into concrete steps. This is the skill I spent the longest practising and the one I use the most.
2. Reading other people's code. I used to think programming was mostly writing. In practice I read far more than I write — my colleagues' code, library code, and my own code from three months ago.
3. Debugging with a method. Early on I fixed bugs by guessing and changing things at random. Later I learned to narrow the search: work out what is definitely correct, what is definitely wrong, and squeeze the suspect region until it is small.
The exercise I keep recommending
Take something you do every day — making a cup of coffee, say — and write out the steps in enough detail that someone who has never done it could follow along.
You will notice how many obvious steps you skipped. A computer reacts exactly like that stranger.