There are multitude of other reasons why many students drop out of their PhD programs. Lot of my friends started grad school with doing something innovative and original research. But at the end of the day their advisor is funding them and in most of the cases they were too dependent on the research areas of their advisors rather than their own. Of course, you can choose your advisor based on matching your research interests with theirs but things always change due funding scenarios.
My wife, brother, and I all got Ph.D. degrees. I was an MBA program prof.
Here's my reaction to the article and advice to people who want a technical Ph.D. degree:
First, it helps to be 'smart' to get a Ph.D. So, in part, think of the Ph.D. program as a path through a maze, and there don't just commit to the first path you see. Instead, look ahead over the whole maze and possible paths, investigate what the heck you are getting into, and then pick some candidate paths, with 'options' along the way to respond to 'exogenous' events.
Second, what the article said was real, but some of the 'path' decisions illustrated in that article were poor. E.g., don't get into a situation where you are depending on an advisor: So, you don't want to have to depend on an advisor for a problem, for funding, or for a 'research environment'.
When I was in graduate school, there as no shortage of tuition scholarships; the school had many more such scholarships than qualified students. My wife, brother, and I never paid even 10 cents for graduate school tuition. So, paying $0.00 tuition should be easy enough.
I didn't get any 'stipend', but then I didn't do any teaching or 'grunt' work either.
Third, realize that the main generic requirement for a Ph.D. is to produce "an original contribution to knowledge worthy of publication". If you are in a department or field that wants you to have a dozen papers published in high end peer-reviewed journals before awarding a Ph.D., then you picked the wrong department or field.
So pick a field and department that is reasonable about the research required.
Then maybe publish one paper just to help keep monsters off your back. I saw a problem in a course; there was no solution in the course; I saw no solution in the library, thought about the problem for a week and saw a rough path to a solution, took a 'reading course' to look for a solution, within minutes after the reading course was approved submitted my rough solution, worked for two more weeks and found a much nicer solution, got a nice new theorem comparable with a classic one, used the theorem to solve my problem, noticed that my solution also solved a related problem stated but not solved in a famous paper, and, thus, got a 'Teflon' back no one could attack. Later I published the paper with no difficulty.
Then, get yourself ready for doing the research, pick a problem, do the work, write it up, have the department observe that the work meets the requirements, and graduate. If there is doubt about the quality of your work, then PUBLISH your work.
Notice that computer science likes 'good' algorithms where a 'good' algorithm is one with worst case running time only a polynomial in the size of the problem. Well, usually J. Edmonds is credited with that definition of a 'good' algorithm. So, here's a J. Edmonds story (may be true): He was a math grad student at U MD but left and went to the Bureau of Standards (NBS). There he published several papers on graphs, trees, flowers, etc. A committee at his old department drove to the NBS, suggested that he stack up some of his papers, put a staple in the UL corner, and let the department call that his Ph.D. dissertation and award him a Ph.D.
Pick your own problem; do your own work; don't use an 'advisor' for anything important.
Fourth, to get yourself ready for research, take some good courses, study some good books, read some good papers, and attend some good research seminars. There read on the lines but also sometimes between the lines. E.g., at a research seminar, try to guess how the speaker selected their problem and notice the prerequisites they used in getting a solution; then notice how easy or difficult, how routine or novel, was what they did. Then consider borrowing what seemed to work. E.g., once in grad school I went to a seminar given by S. Eilenberg. Later a comment from a junior faculty member was "He sure doesn't waste time working on small problems.". Okay, try to learn from something like that.
2 comments
[ 4.6 ms ] story [ 5.2 ms ] threadHere's my reaction to the article and advice to people who want a technical Ph.D. degree:
First, it helps to be 'smart' to get a Ph.D. So, in part, think of the Ph.D. program as a path through a maze, and there don't just commit to the first path you see. Instead, look ahead over the whole maze and possible paths, investigate what the heck you are getting into, and then pick some candidate paths, with 'options' along the way to respond to 'exogenous' events.
Second, what the article said was real, but some of the 'path' decisions illustrated in that article were poor. E.g., don't get into a situation where you are depending on an advisor: So, you don't want to have to depend on an advisor for a problem, for funding, or for a 'research environment'.
When I was in graduate school, there as no shortage of tuition scholarships; the school had many more such scholarships than qualified students. My wife, brother, and I never paid even 10 cents for graduate school tuition. So, paying $0.00 tuition should be easy enough.
I didn't get any 'stipend', but then I didn't do any teaching or 'grunt' work either.
Third, realize that the main generic requirement for a Ph.D. is to produce "an original contribution to knowledge worthy of publication". If you are in a department or field that wants you to have a dozen papers published in high end peer-reviewed journals before awarding a Ph.D., then you picked the wrong department or field.
So pick a field and department that is reasonable about the research required.
Then maybe publish one paper just to help keep monsters off your back. I saw a problem in a course; there was no solution in the course; I saw no solution in the library, thought about the problem for a week and saw a rough path to a solution, took a 'reading course' to look for a solution, within minutes after the reading course was approved submitted my rough solution, worked for two more weeks and found a much nicer solution, got a nice new theorem comparable with a classic one, used the theorem to solve my problem, noticed that my solution also solved a related problem stated but not solved in a famous paper, and, thus, got a 'Teflon' back no one could attack. Later I published the paper with no difficulty.
Then, get yourself ready for doing the research, pick a problem, do the work, write it up, have the department observe that the work meets the requirements, and graduate. If there is doubt about the quality of your work, then PUBLISH your work.
Notice that computer science likes 'good' algorithms where a 'good' algorithm is one with worst case running time only a polynomial in the size of the problem. Well, usually J. Edmonds is credited with that definition of a 'good' algorithm. So, here's a J. Edmonds story (may be true): He was a math grad student at U MD but left and went to the Bureau of Standards (NBS). There he published several papers on graphs, trees, flowers, etc. A committee at his old department drove to the NBS, suggested that he stack up some of his papers, put a staple in the UL corner, and let the department call that his Ph.D. dissertation and award him a Ph.D.
Pick your own problem; do your own work; don't use an 'advisor' for anything important.
Fourth, to get yourself ready for research, take some good courses, study some good books, read some good papers, and attend some good research seminars. There read on the lines but also sometimes between the lines. E.g., at a research seminar, try to guess how the speaker selected their problem and notice the prerequisites they used in getting a solution; then notice how easy or difficult, how routine or novel, was what they did. Then consider borrowing what seemed to work. E.g., once in grad school I went to a seminar given by S. Eilenberg. Later a comment from a junior faculty member was "He sure doesn't waste time working on small problems.". Okay, try to learn from something like that.
Fifth, to pick a problem, try to start with a ...