There's only one way to learn to code.

Dr. Stephen Krashen[1] says there's only one way to acquire language: when we understand messages. Speaking is the final part of a process that begins with reading, listening, and gaining understanding.

[1] Stephen Krashen on Learning Language

This idea seemed intuitive to me, this is how I learned to speak English: Months reading scholastic books, watching Gumby, and eventually impressing Brett and Brandon at the park by saying "The apple trees look beautiful", my first words.

My first programming teacher[2] would use a very similar technique a few years later to induct me as part of the rpgarena.com[3] staff: He sent me a PHP file, explained that this was the code for a *gallery*, then asked me to tell him what each line of code meant. My first answer was pretty wrong, so he corrected me and we tried again. Eventually I was asked to write a gallery.

[2] RK's Twitter

[3] Archive of RPG Arena

Almost two decades later, there's not a lot of advice that I would give, but I feel very confident about this one: **If you want to become a better software engineer, you should read a lot of code.**

The most brilliant engineers I know are good because of how they're able to *read*, *understand* and *analyze* the code and the problems they solve. Every instruction put down is heavy with context and intentionality: it's the result of a toolbox of abstractions, useful patterns, and I've-seen-this-befores.

Experts can recall much more because of this toolbox: "Beginners, ignorant of the functional significance of these words, appeared to adopt very general mnemonic techniques [...] The experts' associations from long-term experience with these words in programming predominated over common-language associations" (Mc Keithen et al.[4], 1981).

[4] Mc Keithen et al.

Many activities can help build this toolbox for understanding: Analyzing the whole (eg. Indicating the overall structure of a program, identifying redundant parts, summarizing the purpose of a program), the relationships in the code (eg. diagramming how the code flows), or understanding the blocks and atoms that make it (Izu et al.[5], 2019).

[5] Izu et al.

I like thinking of this in terms of the hermeneutic circle[6]: you try to understand the whole and the context around it and use that to better understand the individual constituent parts, and use that to understand the whole and the context around it, etc.

[6] The Hermeneutic Circle

No matter how you do it: **Read code frequently, try to understand it**. It's the best way to develop your skills.