Some thoughts on teaching and learning programming, particularly for scientists and engineers.
- #3: Read slowly. A novice who skims code understands it not.
- #4: Reading code does not mean reading the words. It means: For each line of code, ask (1) what is the program state (variable values, etc.) before the line and after the line, and (2) what did the line do.
- #8: When reading a CS textbook, ask what each term means (and look it up if needed), restate the text in your own words, and give an example of the concept. You cannot skim.
- #39: The hardest part of programming is translating a complex human task into instructions a computer (which can only do a few things) can understand.
- #42: Star Trek references are fun, but use examples that connect with student interests. Business examples for business majors, art examples for artists, and science examples for scientists.
- #84: Following coding recipes can be a good starting point, but ultimately you need to learn how to take a complex task and break it up into subtasks that a computer can execute.
- #100: For beginners, it's more like learning piano than philosophy. It's more a skill than a subject.
- #111: It's better to practice coding 15-30 minutes everyday than many hours once a week. Learning programming is a marathon, not a sprint.
- #121: When you code, you are using a computer. When you learn to code, you are learning to think like a computer. Using a computer is not the same as learning to think like a computer. This is why IDEs have limited use for students learning to code. The tools that make IDEs useful for writing code can hinder students from learning to think like a computer. Autocompletion, hints, etc. can prevent students from wrestling over what the code is doing.
- #132: There's no law of nature that says if you do not learn how to program in one college term you should stay away from computers for the rest of your career.
- #133: Some learn to program in a few weeks, others a few months, a few years, or a few decades. The important part is to learn in whatever way works for you and not give up.
- #152: When reading code, don't read it token-by-token. That doesn't lead to understanding. Read it expression-by-expression and then line-by-line.
- #182: Code in a book isn't just to read but also to try out. Type in an example. Then, change values and commands and see what happens. Can you explain what happened?
- #183: Examples are great but are not self-teaching. Just reading an example is not enough. Explain line-by-line what the variables equal before-and-after and what the line changes.
- #207: Recursion is hard (h/t @gvwilson). Be patient with yourself.
- #224: Novices know how to think as humans. Now they need to also learn to think like a computer. Humans are smart. Computers are not.
- #225: Your smartphone has misled you into thinking computers are smart. It is the people who programmed your smartphone who are smart. To think like a computer, you have to lower your expectations of the computer.
- #277: Code completion tools have limited pedagogical utility for novices. Typing in the "right" code is not as important as understanding how the computer will process the code you are typing in.
- #297: You don't go from novice to expert overnight. Don't expect to intuit the solution to a coding problem just because you learned the programming construct. Be patient with yourself.
- #310: Beware, novices, the premature Google search: Wrestle with breaking down the problem into steps before looking online.
- #311: Beware, practitioners, the belated Google search: You don't need to wait until you're desperate.
|
For more on learning Python programming: An Introduction to Python Programming for Scientists and Engineers, by Johnny Wei-Bing Lin, Hannah Aizenman, Erin Manette Cartas Espinel, Kim Gunnerson, and Joanne Liu (Cambridge University Press, 2022). |
