If you're not going to become a professor, then why bother pursuing a Ph.D.?
pgbovine.net
pgbovine.net
This statement is essentially a post hoc ergo propter hoc fallacy.
Anything that didn't leave you wiser after six years would be a pretty terrible way to spend time. Heck, simply being alive for six years probably makes you somewhat wiser.
also, that's sort of why i had the parenthetical following that statement ...
(Two obvious caveats: Not every Ph.D. student received these benefits—many grew jaded and burned-out from their struggles. Also, lots of people cultivate these positive traits without going through a Ph.D. program.)
I understand the grind as a tool for personal sharpening better than a successful graduate would because it is all I have to take from the experience - no plaudits, no social or familial approval, no resume bullet (rather more like a gaping resume maw, depending upon the attitude of the person reading it).
I have no idea -- that's why I put that parenthetical caveat in that paragraph :)
I can't speak directly for pgbovine, but I had a similar experience as in his book (finished fall 2011). I also can't compare to your situation since I don't know you. But I share pgbovine's sentiment: The PhD wasn't necessarily fun, but it was personally fulfilling. It also left me with a deep sense of accomplishment and appreciation for "just how far the rabbit hole goes." I often describe research as: 80% banging head against a wall, 10% cursing, 10% progress.
Some of my recent work is more akin to "engineering consulting." I've found this job to be vastly different from research -- implementing solutions that are mostly-known rather than exploring uncharted territory. It's probably closer to 30% banging head on a wall and 70% progress, without any cursing (and saner hours with better pay). YMMV.
No, it's not.
A post hoc ergo propter hoc fallacy is to assert that X causes Y _solely_ because X and Y co-occur. Philip asserts that doing the Ph.D. caused him to be wiser, savvier, etc, but he did so on grounds other than just citing their co-occurrence. Much of the rest of the article explained _how_ X caused Y, i.e., how doing the degree resulted in this or that bit of wisdom.
On a broader note, it really bogs down a discussion to point out 'logical fallacies' when they aren't there. Ideally, we'd all go out of our way to try to see another person's point, even when it's poorly made, but the antithesis of that is to criticize a point on technical grounds, when those technical grounds aren't even there.
just to provide some context, this page is the epilogue of a ~100-page memoir of my Ph.D. experiences [1], so parts of it might not make any sense as a standalone article.
Basically, what I feel like I got most out of it, was that it was a good life, that I ended up really enjoying. I did theory and I felt like my professors let us kind-of do whatever we want. We got paid enough money to live and I had a lot of time to enjoy my hobbies. I learned to play tennis and surf (I went to school in LA). But I would figure things out and work when I was inspired.
That is pretty much how I live now and it is still great!
Some days I feel a bit demented. I was certainly sharpened but the experience feels a bit like opening Pandora's box. Anyone else feel like that?
That is very reminiscent of Nietzsche.
Also worth reading, when it comes to the question of to do or to not to do a PhD is: http://philip.greenspun.com/careers/women-in-science
How is this paternalistic or uninviting to women?
> A lot more men than women choose to do seemingly irrational things such as become petty criminals, fly homebuilt helicopters, play video games, and keep tropical fish as pets (98 percent of the attendees at the American Cichlid Association convention that I last attended were male). Should we be surprised that it is mostly men who spend 10 years banging their heads against an equation-filled blackboard in hopes of landing a $35,000/year post-doc job?
Are you certain? See http://openwetware.org/wiki/DIYbio/FAQ/News
In general, though, we're still chasing the long tail of knowledge. Nobody's going to build a cutting-edge particle collider, space probe, or Inca ruin in their spare time.
Arguably microbiology is a lot more like computer science than other experimental sciences economically, at least in certain respects; for example, once you've got something interesting, you can probably execute a fairly cheap reproductive process and get a whole bunch more of it. (Well, this is cheap compared to reproducing a particle collider, at least.)
Fun to think about.
Doing research in biological sciences often involves millions of dollars of funding and just isn't something that can be circumvented. My girlfriend is currently pursuing a PhD in Neuroscience. Studying that brains of hundreds of animals isn't something that I'd want her doing in the kitchen.
Learning from others is important, as is having a team to work together on hard problems. If your study requires something being done every hour for 72 hours straight, one person can't do that. Not everything can be automated.
Studying something that's controlled by the government and/or dangerous is impossible outside an academic environment. Getting plutonium and building your own nuclear reactor at home is generally frowned upon. Studying smallpox at home is generally frowned upon. Getting a DEA license for legal drug research is frowned upon. Conducting medical research on humans without an oversight board (and medical support, consent, etc) is generally frowned upon. Most animal supply places won't send hundreds of genetical engineered and bred mice to your apartment.
This isn't a slap against you, but its clear that while HN understands engineering well, they don't get science for the most part.
Programming is much more meritocratic.
Like the author, I learned a great deal during the years of my (European-style, not American-style) program. I learned how to explain complex ideas to experts and laymen alike. I learned how to present data to make a compelling argument, both in text and in graphics. I learned how to read complex technical writing and extract the author's point. I learned how to ask a series of questions that got to the core of a complex matter. There are all soft skills - but I have found that the complement the set of skills that I got from the subsequent years in industry very well.
I also had three years to meet and talk to some extremely smart people, which has helped me in several big ways and many small ways in the years since I graduated. Maybe the biggest reason I don't regret doing a PhD was that I got to spend two years gratifying my intellectual curiosity about a topic that I was really interested in. Few people get such an opportunity, and for those who enjoy that kind of thing it's an opportunity not to be missed.
Anyway, maybe s/he entered with a Masters, which could be compulsory for the Euro-style programs, and not counted towards the average length, which may be 3-4 years.
IIRC, there are a few types of Masters like an MPhil which are pretty much labels that you were in a PhD program but didn't finish your PhD.
You learn an incredible amount about what you're studying and what you're interested in, and an academic environment is where some people learn best.
There are very few environments in the world that give you the kind of access to information that an academic environment gives you. Being a graduate student at a major university gives you access to nearly every journal article in the world, numerous domain experts, and advanced labs for the physical sciences. There are few to no industry jobs that provide this level of information access to someone right out of undergrad.
That said, graduate school is not for everyone. If your goal is to learn, and learn how to learn, then graduate school might be for you. If your goal is to make money, or learn enough to make money or produce popular apps, then graduate school may not be appropriate.
It's also the case that for some areas, like computer science, there is an increasing amount of free resources that one can make use of outside of graduate school. Many journal articles are free, and one can always buy and read through textbooks outside of school.
The main question in CS, imo, outside of certain capital-intensive areas (robotics, HPC), is learning styles. Do you learn better taking formal courses, having a supervisor oversee your project, having formal evaluation milestones (quals, proposal, thesis, defense)? Some people do, some don't.
I do think the process of doing research and thinking of your goal in terms of "research contribution" rather than "product" is valuable for many intelligent/curious people. I'm less sure (despite being an academic myself) that the formal academia route is the best way for everyone, though. Imo the most valuable part of academia is the interaction with a research community in an area that interests you: work on a project, collaborate with some people, submit papers to conferences, get reviewer feedback, revise things, present papers, chat at the conference banquet, get inspired with new problems or ideas, etc., etc. You don't strictly have to be an academic to do any of that, especially in CS, although a large proportion of people who do are. Some of it is just culture I think: I think a lot of people outside academia who could submit interesting conference papers just don't even have that possibility on their horizon as something they could do, or would want to do.
The thesis and defence is useful in the same way that publications are. However, even there, if you get a bad committee with political or personal axes to grind, it can be very much not that helpful. My experiences with publications are the same. I've had good rejections that help me improve the work as well as several bad rejections (from conferences where you cannot respond) where the reviewer simply did not understand the research.
In short, for some people a PhD is very hands on rather than overly formal.
But I'll give the points anyway for bothering to answer.
(They are the only two I've heard of.)
The latter happens.
http://www.huffingtonpost.com/grace-nasri/law-schools-feel-t...
I'm not sure about the US but the former happens in the UK:
http://www.telegraph.co.uk/health/healthnews/9274753/Up-to-1...
Perhaps not to the same extent, though.
There's a huge glut of unemployed lawyers, most of whom racked up a lot of debt getting their degrees.
http://www.nytimes.com/2011/01/09/business/09law.html?pagewa...
I was certainly very lucky, but fully and deeply understanding my field helped me do research which was considered by others interesting.
For the question "why bother pursuing a Ph.D.", I never had any desire for an academic career but got a Ph.D. to learn material I believed would help my career in business, the money making kind. The program did teach me some powerful material and gave me some good practice in doing original work.
I've published in artificial intelligence, computer science, and applied math of engineering.
Currently I'm working on the making money part. Some of what I learned in my Ph.D. program -- both some powerful material and how to do original work -- is crucial to the crucial core 'secret sauce' of my business work.
Scope. I restrict my comments here to technical fields, e.g., applied math, engineering, computer science, applied physics. I can't comment on biomedical fields.
For how I got a Ph.D. without undue "suffering", broadly at US research universities in technical fields, the main requirement for a Ph.D. is enough 'research'; in case of any doubt, one way to 'prove' that your work is 'research' is to publish it in a peer-reviewed journal (or conference proceeding); the usual criteria for publication are "new, correct, and significant". It also helps if the work is novel and, for work in engineering (and computer science, here and below), useful. It also helps to write and present the information clearly, at least in part (snow jobs can be useful in places).
My suggestion for research in engineering is to (1) accumulate some background knowledge in some tools that can help in the research, (2) pick a good problem, (3) have some bright ideas, (4) execute and graduate.
For more:
(1) Tools. A common recommendation in research (in technical fields) is to 'mathematize'. So the most valuable tools can be some useful math. I recommend undergraduate abstract algebra, linear algebra, analysis, and optimization. For graduate math, I recommend measure theory, functional analysis, ordinary differential equations, probability (based on measure theory), stochastic processes, mathematical statistics, and control theory. More is welcome in, say, mathematical physics.
(2) Problem. I suggest for a problem, try to pick one so that the solution you find will likely be seen by academics as useful outside academics. A big part of success in research is problem selection. I picked my own problem and declined ones suggested by faculty; I did like my problem better. If only since the person who cares the most about your problem and Ph.D. is you, for the sake of a good problem I suggest you at least try to pick your own problem. Then, in picking a problem, look and think carefully and critically; since that problem is like a horse you have to ride across the finish line, pick carefully.
Next, with your problem in hand, I suggest you do the main original research independently, that is, without faculty supervision.
So, keep your problem and work secret. Wait to tell others until you have the main research nicely done and the time is right for you explain to others.
Reason for the independence and secrecy: You get to do your work without interference or 'helpful suggestions' from others. Others can't 'share' or steal your work. You get to hit bumps in the road, backtrack, make mistakes, change your mind, have some better ideas, modify your problem, select what to include or exclude, etc. without opening yourself to criticism from others.
If some faculty start to be too critical, then one solution is for you just to publish what you have.
(3) Bright Ideas. Put your feet up, pop open a cold can of, perhaps, caffeinated soda, review your math tools, review what is known about your problem area, review your specific problem, and then start thinking.
Here is my non-standard suggestion for how to do much of the crucial thinking: Do a lot of the thinking with just rough conceptual, heavily intuitive models about how your subject works and what is likely true or false. Use at least some simple facts, scenarios, etc. to test your models. E.g., think, "If this is true, then likely that is true, and we can see from some simple cases that that is not true." Or, "This looks like wild stuff, but maybe it's true, and is there any solid reason to believe it's not true?".
Be quite willing, for maybe a few days, to consider some far out, radical, seemingly impossible results, and then evaluate them as above.
Commonly play two separate roles, (A) dream up wild conjectures and (B) (somewhat constructively) critique the conjectures.
Likely do most of this work just between your ears. It's better to identify the main ideas between your ears than just to push symbols around on paper (or a computer screen) without some clarifying ideas for why the symbol pushing is promising.
Here's one trick: When you see something that works, maybe not even original, take it apart into tiny pieces, accepting nothing as 'obvious', and see solid theorems and proofs for every little step. Then formalize and generalize. E.g., even if the case in R^1 is 'obvious', it may be that there is so far no good R^n version but your breaking apart into little pieces shows you how to do a good R^n version.
When you have something worth writing down, do so. When you have something that looks like it can be solid, write out what you have carefully, likely as theorems and proofs.
I do my more mathematical writing by typing Plain TeX into my favorite text editor.
It's fun!
For a nervous, straight-A student, OCD, over achiever terrified of their own shadow and any possible chance of criticism (not me, but I've seen such people), relax, work quietly out of the view of others, and show colleagues and/or profs only final, solid results, maybe already published.
Q. Why pick a problem that academics will believe is useful outside of academics?
A. Because such a problem helps set aside that you are trying for academic, pure as the driven snow, glory, and that lowers some standards and reduces chances of jealously and criticism. You will be answering the common complaint that academics is useless and have a fairly strong additional reason for the work to be regarded as "significant". Also since you may be solving a practical problem, if you pick a recent problem from practice, then likely there is so far no clean solution for that problem published in academics; so your solution can be seen as both "new" and "significant".
Q. Why present work as theorems and proofs?
A. Because 'mathematizing' a field is highly respected, and it's super tough to argue with a carefully done proof. If you learn how to write proofs from Birkhoff, Halmos, Rudin, Coddington, Bourbaki, von Neumann, Breiman, Dynkin, etc., then that part of your work, heavily both in practice and in principle, will be immune to serious criticism. The proofs in parts of computer science can be okay but generally are a long way downhill from proofs from the names I mentioned. Actually, only a little of computer science is good at 'mathematizing' their field, and the flip side of this situation can be an opportunity for you. With solid theorems and proofs, it's easier for your work to meet the criterion of "correct".
For getting research grants, that's asking for money. Generally it's easier just to make the money in business.
For getting a good academic career, in practice the main technique is politics. The main substantive technique is to become well known for doing some research that is regarded as especially good. Then you can get a 'bidding war' going on for your services from universities that want well known, highly regarded faculty.
For business, say, an Internet based 'information technology' startup, pick a problem where a much better solution will be very valuable and where you have a good shot at doing some original research to get some 'secret sauce' for such a solution. The solution can be "very valuable" from, say, a little money from many sources or a lot of money from a few sources. Then do the original research and implement it in software. For protection of your intellectual property, keep your software locked up inside your servers, and don't let users know what's going on behind the curtain.
Go live, get users and, hopefully, revenue, i.e., 'traction'. Grow. Smile on your way to the bank.
In academics, commonly you can get some competent peer-review of your original, technical work, but in business mostly you can't. Instead, it is as if business believed in a Markov assumption: The core 'secret sauce' and the future value of the business are conditionally independent given the current level of traction. That is, the business world wants to evaluate projects much as in accounting where for a startup they may be willing to use surrogate measures such a traction. For the secret sauce, the business world has little desire or ability to evaluate that, and the flip side of this situation can be an opportunity for you.