7 ms·

Lessons I Wish I Had Been Taught (1996) [pdf]

249 points by samasblack 9y ago

AnimalMuppet 9y ago
It's not obvious from the title, but it's lessons about giving mathematics lectures and about doing mathematics. Most of the lessons are applicable to any technical subject, though. Worth reading.
cholmon 9y ago
1) Lecturing - Every lecture should make only one main point - Never run overtime - Relate to your audience - Give them something to take home 2) Blackboard Technique - Make sure the blackboard is spotless. - Start writing on the top left-hand corner 3) Publish the Same Result Several Times 4) You Are More Likely to Be Remembered by Your Expository Work 5) Every Mathematician Has Only a Few Tricks 6) Do Not Worry about Your Mistakes 7) Use the Feynman Method 8) Give Lavish Acknowledgments 9) Write Informative Introductions 10) Be Prepared for Old Age
- joe_the_user 9y ago
  A good portion of these points involve "integrate into the mathematical exposition methods of your time" and become useless as exposition methods change. If blackboards are supplanted by digital whiteboard that autoerase or autoscroll, exposition may different - slide techniques would be useful to include. Another portion involve the "exposition culture" - that the greatest of a given mathematician still has to interface with mathematics proper (or at the limit, a mathematician who is "outre", "out-there", may publish a theorem and have mathematics simply throws up it's hands as happened with ABC theorem - at least so far). Essentially, have a strategy that lets you keep working on the hard stuff but without getting entirely lost on it. But I think the really cool parts involve rules of thumb for going through life and solving a few hard, important problems. This reminds me of Andrew Wiles talking about the problem that really, really smart math grad students have when confronted with problems that they can't solve in 24 hours. Edit: and naturally, it's worth noting that exposition method and culture are important for anyone also working on hard problems since knowing the "smell" of good or bad proofs is crucial if one is going forward towards a really big proof - see the point that most good proofs can survive a little bit of error.
  - jacobolus 9y ago
    Blackboards are much better as lecture tools than digital whiteboards with autoscroll, or most uses of powerpoint, or whatever else people try, in my experience. I wish that more lecturers would consider returning to blackboards, instead of the lazy slides they currently do. It would both improve their talks and waste less of their prep time. The nice thing about blackboards is that lecturers don’t try to write every word on a screen, but just talk as normal, only putting up explicitly technical content like diagrams and formulas. They can add or remove things from the board in response to audience feedback, and can improvise new ideas. Maybe most importantly, (sufficiently large) blackboards keep a large amount of context in view at any given time. Blackboards are especially good as classroom tools because they are a fundamentally improvisational and accessible medium. You can’t prepare all the drawings in advance, which means that anything a lecturer can do on the board a student can in principle also do, and the form of the teacher’s lecture is a direct part of the pedagogy: the student can learn to imitate the same mode of thought with access to the same tools. There can be a drawing- and formula-based dialog between teacher and students in which they are all operating as equal peers, unlike powerpoint where one participant spent hours making a bunch of pretty graphs or typing up formulas in a cryptic markup language, and the other participant gets no insight whatsoever into how. Making good use of computers would mean handing out interactive demonstrations with their full code available [code might be implemented in some drawing-based environment, not necessarily just lines of ASCII] at every lecture, and then showing how the code works and showing how to twiddle the parameters as part of the lecture, alongside the traditional writing-and-drawing-on-a-blackboard part of the lecture. Ideally students would have some way of also interacting with the same medium during class. But making good interactive diagrams or writing code whose primary purpose is exposition takes 2 orders of magnitude more prep time than just throwing words and static diagrams up, and is just not feasible for individual lectures in a current education setup. Ideally we would have much better improvisational computer demonstration/diagram tools, but in practice the drawing tools we have are not really designed for a computer medium, and all pretty much suck. (If Bret Victor’s ideas from “Inventing on Principle” and “Stop Drawing Dead Fish” and “Drawing Dynamic Visualizations” were turned into polished, production-ready, mainstream tools, we might have a chance.) I’ve seen some pretty effective lectures that were done live-coding style, e.g. in some notebook-based tool, but it depends on having the right topic for the lecture.
yesenadam 9y ago
(1996)
- mighty_bander 9y ago
  > 2017 > Arguing flippantly
wcr3 9y ago
Good read - thanks for sharing.
dang 9y ago
Discussion from 2016: https://news.ycombinator.com/item?id=11747598 https://news.ycombinator.com/item?id=11747598 From 2011: https://news.ycombinator.com/item?id=3220746 https://news.ycombinator.com/item?id=3220746
perl4ever 9y ago
I always thought the Feynman method was "Write down the problem. Think very hard. Write down the solution."
- nicwilson 9y ago
  That's the Feynman Algorithm.
trentnix 9y ago
This appears to have been linked to Dr. Catherine Yan's faculty page. She is a faculty member for the math department at Texas A&M. I was fortunate to take Discrete Math from her and I learned a lot. I also worked with her husband, Hua, and learned a lot from him as well. Very nice people. This may seem a bit off-topic, so I apologize if I'm stealing bits from anyone. Reading the blackboard technique item gave me a good laugh. Dr. Yan is, on her tiptoes, maybe 5' tall. And that's generous. She used the whiteboard prolifically while she lectured, and the bottom half would be covered as she provided examples for her lesson. The top half, the half she couldn't reach, was utterly spotless.
manmal 9y ago
„Every mathematician has only a few tricks“ I think the same is true for programmers. My trick (in mobile dev) is to use state machines everywhere. State management has become my mantra, and it’s helped me tremendously in making sure my apps don’t end up in an undefined state. Swift is especially great at this because it can store values in enum cases. Now, most of my bugs stem from overlooking potential substates and not propagating state changes correctly to other parts of the app; the 2nd of which can be fixed by having proper boilerplate code. Other tricks I‘ve encountered so far, partly from other programmers: - Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time) - Go as low level (eg C or C++ for iOS; examine OS internals with Hopper) as possible (superior performance and awe-inspiring source code, leading to wider community recognition) - Ask other people first if working on an unfamiliar problem (only works if your network is strong; can speed you up x100 though vs googling and digesting yourself) - Use Reactive style deliberately (if done properly, only semantical bugs are left; bonus: streams are very natural abstractions of app IO) Those are in part orthogonal to each other, but I feel that you (or just I) can’t use more than 1 or 2 tricks at once.
- submeta 9y ago
  > Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time) This! So very true. Or as Donald Knuth says: `Premature optimization is the source of all evil.‘
- scotty79 9y ago
  My trick for fixing software is "If you can't fix it, break it more and use effects of your damage to learn about the system and see what you can affect."
  - tonyarkles 9y ago
    That’s often my approach to diving into performance problems too. When a client says “it starts to slow down a bit at 2 requests/sec”, my first thought it “what happens at 20req/sec?” I call it “turn it up to 11 and see what breaks”
stablemap 9y ago
A small thing: I think it makes sense to link to the AMS’s copy. The Notices are all free. http://www.ams.org/notices/199701/comm-rota.pdf http://www.ams.org/notices/199701/comm-rota.pdf
mighty_bander 9y ago
I think this is satire. If it is, it's damned good. If not, it's at worst practical.

249 points by samasblack 9y ago

It's not obvious from the title, but it's lessons about giving mathematics lectures and about doing mathematics. Most of the lessons are applicable to any technical subject, though. Worth reading.

cholmon 9y ago

1) Lecturing - Every lecture should make only one main point - Never run overtime - Relate to your audience - Give them something to take home 2) Blackboard Technique - Make sure the blackboard is spotless. - Start writing on the top left-hand corner 3) Publish the Same Result Several Times 4) You Are More Likely to Be Remembered by Your Expository Work 5) Every Mathematician Has Only a Few Tricks 6) Do Not Worry about Your Mistakes 7) Use the Feynman Method 8) Give Lavish Acknowledgments 9) Write Informative Introductions 10) Be Prepared for Old Age

joe_the_user 9y ago
A good portion of these points involve "integrate into the mathematical exposition methods of your time" and become useless as exposition methods change. If blackboards are supplanted by digital whiteboard that autoerase or autoscroll, exposition may different - slide techniques would be useful to include. Another portion involve the "exposition culture" - that the greatest of a given mathematician still has to interface with mathematics proper (or at the limit, a mathematician who is "outre", "out-there", may publish a theorem and have mathematics simply throws up it's hands as happened with ABC theorem - at least so far). Essentially, have a strategy that lets you keep working on the hard stuff but without getting entirely lost on it. But I think the really cool parts involve rules of thumb for going through life and solving a few hard, important problems. This reminds me of Andrew Wiles talking about the problem that really, really smart math grad students have when confronted with problems that they can't solve in 24 hours. Edit: and naturally, it's worth noting that exposition method and culture are important for anyone also working on hard problems since knowing the "smell" of good or bad proofs is crucial if one is going forward towards a really big proof - see the point that most good proofs can survive a little bit of error.
- jacobolus 9y ago
  Blackboards are much better as lecture tools than digital whiteboards with autoscroll, or most uses of powerpoint, or whatever else people try, in my experience. I wish that more lecturers would consider returning to blackboards, instead of the lazy slides they currently do. It would both improve their talks and waste less of their prep time. The nice thing about blackboards is that lecturers don’t try to write every word on a screen, but just talk as normal, only putting up explicitly technical content like diagrams and formulas. They can add or remove things from the board in response to audience feedback, and can improvise new ideas. Maybe most importantly, (sufficiently large) blackboards keep a large amount of context in view at any given time. Blackboards are especially good as classroom tools because they are a fundamentally improvisational and accessible medium. You can’t prepare all the drawings in advance, which means that anything a lecturer can do on the board a student can in principle also do, and the form of the teacher’s lecture is a direct part of the pedagogy: the student can learn to imitate the same mode of thought with access to the same tools. There can be a drawing- and formula-based dialog between teacher and students in which they are all operating as equal peers, unlike powerpoint where one participant spent hours making a bunch of pretty graphs or typing up formulas in a cryptic markup language, and the other participant gets no insight whatsoever into how. Making good use of computers would mean handing out interactive demonstrations with their full code available [code might be implemented in some drawing-based environment, not necessarily just lines of ASCII] at every lecture, and then showing how the code works and showing how to twiddle the parameters as part of the lecture, alongside the traditional writing-and-drawing-on-a-blackboard part of the lecture. Ideally students would have some way of also interacting with the same medium during class. But making good interactive diagrams or writing code whose primary purpose is exposition takes 2 orders of magnitude more prep time than just throwing words and static diagrams up, and is just not feasible for individual lectures in a current education setup. Ideally we would have much better improvisational computer demonstration/diagram tools, but in practice the drawing tools we have are not really designed for a computer medium, and all pretty much suck. (If Bret Victor’s ideas from “Inventing on Principle” and “Stop Drawing Dead Fish” and “Drawing Dynamic Visualizations” were turned into polished, production-ready, mainstream tools, we might have a chance.) I’ve seen some pretty effective lectures that were done live-coding style, e.g. in some notebook-based tool, but it depends on having the right topic for the lecture.

yesenadam 9y ago

(1996)

mighty_bander 9y ago
> 2017 > Arguing flippantly

wcr3 9y ago

Good read - thanks for sharing.

dang 9y ago

Discussion from 2016: https://news.ycombinator.com/item?id=11747598 https://news.ycombinator.com/item?id=11747598 From 2011: https://news.ycombinator.com/item?id=3220746 https://news.ycombinator.com/item?id=3220746

perl4ever 9y ago

I always thought the Feynman method was "Write down the problem. Think very hard. Write down the solution."

nicwilson 9y ago
That's the Feynman Algorithm.

trentnix 9y ago

This appears to have been linked to Dr. Catherine Yan's faculty page. She is a faculty member for the math department at Texas A&M. I was fortunate to take Discrete Math from her and I learned a lot. I also worked with her husband, Hua, and learned a lot from him as well. Very nice people. This may seem a bit off-topic, so I apologize if I'm stealing bits from anyone. Reading the blackboard technique item gave me a good laugh. Dr. Yan is, on her tiptoes, maybe 5' tall. And that's generous. She used the whiteboard prolifically while she lectured, and the bottom half would be covered as she provided examples for her lesson. The top half, the half she couldn't reach, was utterly spotless.

manmal 9y ago

„Every mathematician has only a few tricks“ I think the same is true for programmers. My trick (in mobile dev) is to use state machines everywhere. State management has become my mantra, and it’s helped me tremendously in making sure my apps don’t end up in an undefined state. Swift is especially great at this because it can store values in enum cases. Now, most of my bugs stem from overlooking potential substates and not propagating state changes correctly to other parts of the app; the 2nd of which can be fixed by having proper boilerplate code. Other tricks I‘ve encountered so far, partly from other programmers: - Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time) - Go as low level (eg C or C++ for iOS; examine OS internals with Hopper) as possible (superior performance and awe-inspiring source code, leading to wider community recognition) - Ask other people first if working on an unfamiliar problem (only works if your network is strong; can speed you up x100 though vs googling and digesting yourself) - Use Reactive style deliberately (if done properly, only semantical bugs are left; bonus: streams are very natural abstractions of app IO) Those are in part orthogonal to each other, but I feel that you (or just I) can’t use more than 1 or 2 tricks at once.

submeta 9y ago
> Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time) This! So very true. Or as Donald Knuth says: `Premature optimization is the source of all evil.‘
scotty79 9y ago
My trick for fixing software is "If you can't fix it, break it more and use effects of your damage to learn about the system and see what you can affect."
- tonyarkles 9y ago
  That’s often my approach to diving into performance problems too. When a client says “it starts to slow down a bit at 2 requests/sec”, my first thought it “what happens at 20req/sec?” I call it “turn it up to 11 and see what breaks”

stablemap 9y ago

A small thing: I think it makes sense to link to the AMS’s copy. The Notices are all free. http://www.ams.org/notices/199701/comm-rota.pdf http://www.ams.org/notices/199701/comm-rota.pdf

mighty_bander 9y ago

I think this is satire. If it is, it's damned good. If not, it's at worst practical.