Yes, Ph.D. students can suffer. I got a Ph.D. in some applied math in engineering, didn't suffer very much, saw some terrible suffering by others, and can offer my brief advice here.

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.