How should we make it attractive for them [young people] to spend 5,6,7 years in our field, be satisfied, learn about excitement, but finally be qualified to find other possibilities?" -- H. Schopper<p>Given that cheap and disposable trainees — PhD students and postdocs — fuel the entire scientific research enterprise, it is not surprising that few inside the system seem interested in change. A system complicit in this sort of exploitation is at best indifferent and at worst cruel.<p><a href="https://news.ycombinator.com/item?id=7766377" rel="nofollow">https://news.ycombinator.com/item?id=7766377</a>
My best advice to graduate students: enjoy!<p>If you're lucky, you have an advisor that teaches you much more than science and research. My advisor taught a lot about how to work in a political environment (yeah, universities are highly political environments).<p>If you are very lucky, you have an advisor that asks you to teach. By teaching undergraduate student, you learn all the small details of your scientific area. I was lecturing in physical chemistry as a graduate student - and even supervising undergraduates - and after a couple of years I knew all the fundamentals of physical chemistry by heart. That knowledge helped me through writing my thesis.
Great read, even for this grad school drop out.<p>Being wrong (or failing to arrive at an answer) is, when my ego doesn't get in way, amazing.<p>Until reading this article, I thought of it mainly as an opportunity to improve my knowledge base (which is why I also enjoy, "I don't know about that, please explain.")<p>But, the bigger win is when you improve your process of analyzing and solving. I suppose I have stumbled into that approach unconsciously but to make it explicit is far more powerful.<p>Now, where else can I go apply that...
His advice about research and published work applies to software as well. Just because someone published that shiny new framework before you and got lots of upvotes does not mean you should despair. You should look at and learn from it and ask yourself how you could have approached the problem differently. You will learn a lot and chances are pretty high there is still something unique in your work that can be factored out and either published on its own or integrated into the more popular framework.
Does anyone know how to answer this question:<p>How do I know when a proof is worth learning?<p>A lot of times I can get by with just an intuition that the statement <i>ought</i> to be true and some knowledge of what the proof uses but without a full understanding of the proof. But that's not something to be done every time. Any advice on knowing when I can or can't skip a proof?