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.

Fifth, to pick a problem, try to start with a problem from OUTSIDE your department and hopefully outside academics. The usual criteria for peer-reviewed publication is work that is "new, correct, and significant". If you are well prepared, then "correct" will be easy for you. "New" may be also. For "significant", let that be partly or largely from the real problem and not just from some hopeless trilogy of trying to amaze your readers, knock them off their feet with your brilliance, and wow them with your chances for a Nobel prize.

Sixth, quite broadly the best work in any field is to 'mathematize' the field. Okay, basically have your Ph.D. in applied math although you may call it mathematical sciences, systems analysis, engineering/economic systems, statistics, mathematical finance, computer science, electronic engineering, mathematical genetics, etc.

So, for that path, start with a good math background -- at least a good undergraduate major in pure math, likely some selected grad courses in pure and applied math, and some more math on your own.

For the 'original' aspect, actually good work through the math path I outlined will have you doing enough challenging exercises so that your ability to do 'original' work will have a very good start. You might refine that start by drawing from others, but I never did.

For the 'competitive' aspect, nearly everyone in your field will all their careers be struggling terribly with math and be really short on it, but you will effortlessly totally blow them out of the water. You can use theorems they can't understand, and you can state and prove new theorems they can't understand and where they can't check the proofs -- both easily. Did I mention you can blow them out of the water, effortlessly? Then your research will 'mathematize' the real problem you picked and be considered good work.

Here's a big secret: The world of pure to moderately pure math is awash in super nice tools that have not been at all well exploited in applied fields. So, learn some such tools, pick your practical problem, make some extensions in the tools needed by your practical problem (those extensions may be all the challenging 'original' work you do), follow through, write any needed software, learn TeX, type in your paper, submit it, stand for an oral exam, graduate, and do something else.

If you want an academic career, okay, but that would extend what is here, be chapter two, and be beyond the scope of this post!

For your 'confidence', get that from the path I outlined here and do NOT depend on your department to give you your confidence. Don't expect to get self-esteem, praise, acceptance, approval, a sense of belonging, emotional security, or financial security from your department. Your main security is that you know the math and can blow out of the water essentially all the profs in your department.

Note: In some of the best US computer science departments, the mathematical backgrounds and abilities of over 80% of the faculty are down in the laughable area. Blowing them out of the water is trivial.

Notice that often departments don't want to teach or help students but want to 'filter' them. Or they want to insist that the students be like some impossible dream in their own mind. Or they are sadistic and want to crush students. Or they want to make sure that their students can't do better work than they do. Or they want their students to follow the dead end path they took and that stopped them. Looking at the faculty, you can be looking a ward in a funny farm. Don't let them hurt you; don't let them get their rotten hands on your program; instead, work largely independently.

If you can work through the math path I outlined, then you are plenty good enough to do your research no matter what the faculty might say if you gave them a chance. Try to stay out of their sights; don't let them shoot at you.

In my case, I had a good background in pure and applied math from school, work, and independent study, selected my dissertation problem before I entered graduate school, took some very good courses my first year (dropped some bad ones), did my research independently in my first summer, struggled with departmental nonsense, wrote my software, typed in my work, submitted, stood for my oral exam, and GRADUATED.