Live data from Hacker News

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

math.tamu.edu

21–30 of 31 posts

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

#21
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.

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

#22

Earlier quoted context omitted.

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 inter…

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…

Recently at the NWCPP meeting, the usual presentation was not possible. So I offered to do an extemporaneous one to fill the time. I had no slides and no notes prepared, so I used the whiteboard.

I expected it to be terrible, but was pleasantly surprised how well it went off - it was one of my best presentations. The audience was very much engaged with the whiteboard and I'd erase/adjust things with each point.

I came away thinking I should do that more often.

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

#23
„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.

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

#24
post #9

Earlier quoted context omitted.

> Publish the Same Result Several Times Is this not frowned upon? Serious question. Serious journals and conferences ask you to certify that you didn't publish that work elsewhere. Yes, you can work around that by doing some extra experiments/ minor tweaks/etc. so that it is "different" .. but I thought that's a sort of "tolerated cheating", not something you'd actively/publicly advise others to do.

I have a colleague who is very concerned about self-plagarism. Seriously. An excellent example of forgetting what we are about.

Rightly so. I once had to review a paper from a guy who only had half a dozen publications that were all but identical. Whole pages were copied between the papers and it wasn't at all clear what the novel contribution of each paper was supposed to be.

You can publish the same result multiple times, but please reference the previous publication and explain exactly what has changed that warrants another paper.

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

#26
post #23

„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 an…

> 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.‘

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

#27
post #23

„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 an…

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."

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

#28
post #10
post #9

Earlier quoted context omitted.

> Publish the Same Result Several Times Is this not frowned upon? Serious question. Serious journals and conferences ask you to certify that you didn't publish that work elsewhere. Yes, you can work around that by doing some extra experiments/ minor tweaks/etc. so that it is "different" .. but I thought that's a sort of "tolerated cheating", not something you'd actively/publicly advise others to do.

What TFA actually says is that you publish your early ideas on the result in a lower-tier journal, then both things progress side by side——as you refine your ideas, you submit to progressively more prestigious publications.

The thing is, you cannot submit to a "lower-tier journal"; once you get accepted to one journal, no other journal will allow you to resubmit the same results (even with readability improvements).

The way I've seen things done in CS these days is not so bad, though:

Iteration 1: When you are done, you submit to arXiv and simultaneously to a conference. Conferences usually have as strict page limit, so many things get swept into the appendix.

Iteration 2: You get review comments from the conference; depending on the rigor of the reviewers, these may or may not be ideas how to improve the text. You submit the camera-ready version of the conference paper.

Iteration 3: If the paper was more extensive, you start preparing a journal version, where you can move things back from the appendix make the text cohesive again. You probably also have feedback from the conference participants, which is often extremely useful.

Iteration 4: You submit to a journal, you get a (usually quite thorough) reviews and you integrate them to the final version of the paper.

---

Bottom line: I'm saying it's not so bad (compared to just a single iteration) but I hate this system. First, it does not allow community contributions from outsiders (such as PhD students who read your paper and notice something small that can be improved) and second, after Iteration 4 it is nigh-impossible to make small improvements to the paper unless it was spectacularly wrong.

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

#30
post #23

„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 an…

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."

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”

Post reply on HN