One thing that continually amazes me is the amount of email I get from
readers of this blog asking for career advice. I usually try to just politely
decline; I don't think I'm particularly qualified to give personal
advice to people that I don't know personally.
But one thing that I have done before is shared a bit about my own
experience, and what I've learned about the different career paths that you
can follow as a computer science researher. About six months after I started
this blog, I wrote a post about working in academia versus working in
industry. I've been meaning to update it, because I've learned
a bit more in the last few years. When I wrote the first version, I
was a research staff member at IBM's T. J. Watson research center. Since
then, I left IBM, and I've been an engineer at Google for 2 1/2 years.
Having spent a couple of years as a real full-time developer has
been a seriously educational (and humbling) experience. If you'd like
to look at the original to see how my thinking has changed, you can find it
At least as a computer scientist, there are basically three kinds of work
you can do that take advantage of a strong academic background like a PhD. You
can go into academia and do research; you can go into industry and do
research; or you can go into industry and do development. If you do
the last, you'll likely be doing what's sometimes called advanced
development, which is building a system where you've got a specific
goal, where you need to produce something real - but it's out on the edge of
what people really know how to do. You're not really doing research, but
you're not doing run-of-the-mill programming either: you're doing full-scale
development of systems that require exploration and experimentation.
I'm going to talk about what the differences are between
academic research, industrial research, and advanced development in
terms of the basic tradeoffs. As I see it, there really five fundamental
areas where the three career paths differ:
- Freedom: In academia, you've got a lot of freedom to do
what you want, to set your agenda. In industrial research, you've
still got a lot of freedom, but you're much more constrained: you
actually need to answer to the company for what you do. And in AD,
you're even more constrained: you're expected to produce a particular
product. You generally have a decent amount of freedom to choose
a product to work on, but once you've done that, you're pretty much
- Funding: In academia, you frequently need to devote huge amounts
of your time to getting funding for your work. In industrial research,
there's still a serious amount of work involved in getting and
maintaining your funding, but it's not the same order of magnitude
as in academia. And in AD, you don't really need to worry about funding
- Time and Scale: Academic projects frequently have to be limited
in scale - you've got finite resources, but you can plan out
a research agenda years in advance; in industrial
work (whether research or AD), you've got access to resources that
an academic can only dream of, but you need to produce results
now - forget about planning what you'll be doing five years
- Results: What you produce in the end is very different
depending on which path you're on. In academic research, you've got
three real goals: get money, publish papers, and graduate students.
In industry, you're expected to produce something of value to
the company - whether that's a product, patents, reputation, depends
on your circumstances - but you need to convince the company that
you're worth what they're paying to have you. And in AD, you're
creating a product. You can publish papers along the way, and that's
great, but if you don't have a valuable product at the end, no number
of papers is going to convince anyone that your project wasn't a failure.
- Impact: what kind of affect your work will have on
the world/people/computers/software if it's successful.
To many people, this is the fundamental tradeoff between industry and
academia. The short version is that academics have a lot more freedom
than industry folks, but it comes at a serious price.
When you're a professor, you've got a huge amount of freedom. In an
important sense, you don't really have a boss. You set your agenda, and you
pursue it however you want. You can decide what to work on. You can decide
what your goals are, and you can decide when to change them. You're in
In industry, you don't have nearly so much freedom. You're constrained by
the needs of your company. Even in the most free-wheeling industrial
environment, you can't just pick what you want to do; you're expected to do
things that are at least potentially beneficial to the company. (And
that potential had better actually be a pretty high probability!)
The biggest strike here against industry is politics. (Not that there
aren't politics in academia...) In an industrial setting, you're stuck living
with the outcome of political struggles in which you aren't even a
participant. In my time in industry, I've seen very good projects be cancelled
in favor of garbage as the result of random turf wars between executives. Your
work can be outstanding - but because of the outcome of some pointless
political struggle, you could have to completely change directions on
virtually no notice.
This is the biggest problem with academia: as a professor, you need to
find a way to raise money to provide the resources you need to do your work.
That's a huge problem: most of the academic folks I know spend at least half
of their time writing grant proposals, grant reports, work summaries,
attending status meetings, and so on - doing all of the things that are
necessary to keep their work and their students funded. (And that means that
they're not nearly as free as the general statement above about being able to
do what they want would imply: academics can do what they want provided they
can get someone to pay for it; but getting someone to pay for work is very
hard; and getting someone to pay for something very different from what you've
done before can be close to impossible.)
In industry, your funding generally comes from product development groups
within your company. As an industrial researcher, you are indirectly working
for the product groups. This tends to mean that you spend much less time going
around and begging for money; it also means that you have a lot fewer choices
about who to send an application to. If the product group for your research
area isn't interested in what you're doing, you're going to have to find a new
In development, you've got some of the same problems as academic research
- but in practice, it tends to be a lot less burdensome. Before you can start
a project, you need to get someone to agree to fund the project. But once you
get going, you don't worry about budgets - it's someone else's problem. You
just get to focus on the work. (The someone elses problem is the key.
Obviously, money is still an issue: someone needs to pay for the development.
But in general, for product development, the money is allocated ahead of time
- so you don't worry about it; some administrative person is responsible for
keeping it flowing.)
It's a direct tradeoff with freedom: the more freedom you have, the more
you're stuck working to get resources; the more constrained you are, the more
secure your funding situation is. Speaking as someone with development, this
tradeoff can cut both ways: sometimes, the fact that you don't need to worry
about funding is enough freedom in itself to make up for the limitations on
what you can do; at other times, it's frustrating enough to make you want to
bang your head against a wall.
Time and Scale
This is the most direct tradeoff of any of these.
In academia, you get to spend a lot of time working on something. Every
academic researcher I know has at least the next five years of their
work planned out - and usually considerably more than that. Academics get to
really create an ambitious, long-term agenda, and follow it. In contrast, in
industrial work, you rarely get to plan more than a year or two (if you're
lucky) in advance.
On the other hand, industrial researchers tend to work on a scale that's
almost unimaginable to academics. In my field (software engineering),
academics talk about what they call large systems, which are
typically a couple of thousand lines of code. (I can't tell you how many
papers I've reviewed that talk about tools that work on "real-world large
scale systems", but turn out to max out around 10,000 lines of code.) In
contrast, one of my first projects at IBM involved doing static analysis of
templates in a C++ compiler. The code base that I ran my initial
tests on was 1.5 million lines of code. At Google, I've got a
configuration file that specifies a set of source files to be spliced
together, and that configuration file is longer than the the entire code base
used by most academic research projects.
My current project is building a system which processes terabytes of data
every day. I don't even know how many machines it's currently running on - but
it's in the thousands. And around here, that's routine.
If I were to get back into static program analysis, I could easily get
tens of millions of lines of code to test on - and I could use hundreds or
even thousands of machines to speed up the analysis if I wanted to! No
academic gets to do anything on that scale!
On the other hand: I never expected to wind up doing logs analysis. It's
a huge change from the stuff I've done before. It's still within the
general scope of things that I like to do, but it's probably not an area that
I would have gravitated towards if I were free to choose anything I wanted.
Results are the primary product of your work, and they're hugely different depending
on your career path.
In academia, you produce two things: publications and students. And the students
mostly matter because they help you produce publications. Publications are pretty
much the thing that matters in academia, so producing papers is where
you focus your effort.
Industrial research produces three things: papers, patents, and products. The
last two count for a whole lot more than the first. Patents are a big deal in industry.
Partly, that's because they bring in a lot of money; and partly because
they can save the company a lot of money. The way that patents end
up working in industry is sort of like the mutually assured destruction strategy of nuclear weapons in the real world. You want to have enough patents (bombs) to make sure that you can utterly obliterate your competition (opponents), so that they know that they
can't obliterate you without killing themselves.
Products in industry research really means prototypes. In general, industry researchers don't produce full-fledged products. What they do is create a new idea,
and build an implementation that demonstrates the idea. If it proves out, a product
development group will adopt the idea and implement it as a part of a product.
Obviously, being an engineer working on a product, what you produce is
That leads to a final tradeoff, which makes a huge difference to me:
impact. What I mean by that is what kind of affect your work has
on other people.
The primary output of most academic work is publications. When academic
work is highly successful, it has an ideological impact - the ideas influence
other people. It's a sort of indirect impact, but it shouldn't be
under-appreciated. Most of the really great things to come out of research
were built on ideas that came from academic research. It can take a long time,
and it can be very indirect - but eventually, if it's really good work, it can
have an impact. (But to be honest, most of the time, it doesn't. Most academic
work produces papers that no more than a handful of people read, and which
never influences anything.)
Industry also produces ideas and papers, but they're not the primary form
of impact. Most industrial research work produces two things: patents and
prototypes, which (if they're successful), wind up influencing the company
and/or its products. Like academia, most of it dies an unmourned death: very
few research prototypes actually wind up making much difference. But when they
do, it tends to be more tangible than what happens in academia. In industry,
when your work gets picked up, it gets picked up right away, and
you'll probably know the people doing it. Academic research tends to take
longer, and be much more indirect. As an academic, you probably won't even
know when someone is building on what you did until after they're
Industrial development is very different: you tend to have
direct, immediate, tangible impact. There's a directness to it
which is very different from anything else. In general, in the short
term, you get to see an immediate impact from your work, which is
extremely rewarding. But it's likely to be short-lived: rarely does a
development project end up turning into an influential long-lived
product. But development tends to have a higher
success rate than research, and when it's successful, it's wonderful -
you get to see the product of your work helping other people.
In my 11 years at IBM, my research never produced anything that really got
used. Selling something new to an IBM product development group is incredibly
hard - the way the company is put together, it's really hard to produce a new
product, and even for existing products, the development teams are usually so
overworked that they just don't have time to look at incorporating some new
research prototype into their system. In my time there, there were two
times that I managed to get a development group to pick up my work; and both
times, the product never got released. (And both times, the reason that it
didn't get released was completely political.)
In contrast, when I came to Google, my first project was a query language
for component dependency graphs in our build system. Within one day of when I
checked the first version of it into our code repository, I had people using
it. Within a week, I had over a hundred people actively using my in-progress
code. Now, I'd be surprised if there's a single engineer at Google who's never
Of course, the down-side of that is that my code got replaced. After
people used it for a few months, we realized that the syntax really just
wasn't right for the way it was going to be used. Since it was a query
language, I'd tried to do something SQL-like, so that it would be familiar to
people; it turned out that people wrote much more complicated queries than we
anticipated, and it was really hard to write complicated queries over a
depedency graph using a SQL-like syntax. Since by then, my time was committed
to other things, someone else did a rewrite to change the syntax, and that's
the version that people use. That's pretty typical of development in my
experience: I got to do something really cool and exciting and useful,
and I got to put it into the hands of people who needed it?
Now, in my current project, I've got a couple of hundred internal
customers. People who actively use the product of my work. People who
are affected by what I do: who have access to the information that they
need to do their jobs, because of the tools that I produced.
My work actually matters to people. The importance of that can't be overstated. I'm a person whose research
was always focused on how to build tools that help other people program. Now
I'm building tools that my coworkers really use to get their work
done. I never managed to do that in industrial research; and I never would
have been able to have such a direct impact on other people from academia.
So what do I do, and why?
These days, I'm a software engineer doing AD at Google. Doing AD at Google
isn't something special or unusual the way it was when I was at IBM; the
overwhelming majority of engineers at Google are doing what I call advanced
development. It's the nature of the company: most of what we do is on the edge
of what current technology can do. We're working with quantities of data that
are almost incomprehensible, and it's our job to make them
comprehensible. So almost everything we do winds up being on the edge.
As you can probably guess from the description above, I'm pretty happy
in advanced development. I won't pretend that it's without its frustrations.
There are definitely times when I miss the freedom that I had as a researcher.
But on balance, I'm a lot happier being an engineer at Google than I ever
was being a researcher at IBM - and my guess is that I'm happier than I would
be in academia.
Freedom is great, and I don't mean to downplay it. I would like a bit more
freedom than I have. But my experience has been that when I've had more
freedom, I was less happy. That's not because I like to have my work
dictated to me, or to be tied down to something specific and well-defined. I
know people who like development for those reasons, but they're not my
reasons. For me, it comes down to the way that the tradeoffs between freedom
and impact work out for the kind of work that I want to do. My area is tools:
I want to build tools that help other people write code. For a person who
wants to build tools, the inability to get those tools into the hands of
people who would benefit from them is incredibly frustrating. The reality of
things is that you're always stuck with tradeoffs - and in this case, the
tradeoff is pretty clear. A typical academic can't devote the time to
producing tools that are solid enough to be used for real-world development -
doing that takes a huge amount of time and effort, and that time and effort
won't generate any more publications or grants than a prototype.
For my area, the difference between academic research and industrial
research and development was demonstrated to me by an experience at a
conference back in (I think) 2001. I had papers at two workshops - one was an
industry-dominated workshop on software configuration management; the other
was an academia-dominated workshop on aspect-oriented software development. I
spent the morning at the AOSD workshop, and the afternoon at the SCM. During
the morning, I heard about 8 different academics describe their tools for
"large-scale software development", but the largest system that
anyone had used as a test-case for their system was about 1,200 lines
of code. That afternoon, at the SCM conference, I saw someone present their
results from analyzing a "moderate sized" development project - the software
for the Paris Metro, which included 4 million lines of code developed by 4,000
I want to be in the second group - writing the tools that get used by
4,000 people to build a better system. And the way to do that is to be
an engineer at a company like Google. If I'd stayed at IBM, I would definitely have
stayed in research: IBM isn't (in my opinion) a good place to be an engineer.
Beautiful post, holmes! The only thing I would add is that--while not something you commonly hear about--there are faculty who actively enjoy the process of competing for grant funding, including the writing of grant applications. I certainly do.
You know PP, I've always thought you were a nutter.. but I had no idea.
Great post. But I think there is a fourth way that you haven't discussed. I'm an academic with a foot in each camp. I rarely apply for competitive grants as I hate the process, it wastes far too much time, and the funds are often tied in ways that make life difficult. Instead, I undertake contract research for companies and organizations that helps fund the rest of my research. It is extremely easy for me to get contract research projects -- people approach me and I often say no -- so little time is wasted in the process. I only take jobs that are interesting, will lead to research papers, and that I think are really important. I make enough money on these to fund my whole research team (8 PhD students and 3 postdocs). The result is that I retain the freedom of an academic, write lots of papers, have sufficient funding to do what I want, and I get to see my ideas implemented and making a difference.
So as a follow-up question: how do you switch from one to the other? How do you take a Ph.D. from academics and convince industry to hire you? Now make your Ph.D. in mathematics with no particular application.
For me, the move was easy. My PhD is in computer science, with a specialty in compilers and parallel programming languages. While I was in grad school, I used a programming language designed by a team at IBM Research for an experiment. That team ended up posting a job ad for a summer internship. I applied, and got it because I had experience with their tools.
That gave me a connection inside IBM Research. With a PhD in an applied area that was useful to IBM, it wasn't a huge stretch to get them to hire me.
Moving to development was a bit harder. I actually interviewed with Google twice. The first time, they turned me down. After that, I ended up taking a two-year assignment at IBM to a development group, and I started writing this blog. The experience of working with one of IBMs top development teams (the Eclipse guys at OTI), and learning to explain complicated ideas clearly from writing this blog combined to make my second interview at Google go much smoother than the first one.
The general lessons that I'd draw from my experiences: If you've got any interest in getting into industry, make sure that you spend time doing something practical. My PhD work wasn't particularly successful at the time; the computers and networks just weren't up to the job. But along the way, I did work with lots of tools that were around at the time, using them to build experiments for my PhD work. It made my thesis work go a bit slower than it might otherwise have - but I learned an awful lot about operating systems, network performance characteristics, tradeoffs between different low-level implementation designs of parallel systems, data marshaling, and network protocols. Those things are what got me my jobs with IBM and Google - not my dissertation itself. (And I'll throw in a plug here: my PhD advisor, Lori Pollock, was the most wonderful advisor that any student could have asked for. She taught me the right way to approach things, and she let me take the time I needed to do experiments that weren't strictly necessary for my dissertation, but which were useful and valuable for my education. Lori is the kind of advisor who's supportive when you need support, but who'll also give you a kick in the ass when that's what you need.)
My dissertation was, frankly, a typical academic dissertation that disappeared into the ether. The way that I describe it was that it was a *lot* like Google's MapReduce - except that MapReduce did it right, and I did it wrong. (MapReduce has a notion of a keys, which are used to organize the computation. I didn't use keys; I had users design a tree-based data structure, and the maps and reduces corresponded to tree regions. A subtree-root worked sort-of like an implicit version of a MR key. The keys work much
better. Keys also provide a hook for an absolutely essential piece of map reduce. MR is actually a three step process: map, shuffle, and reduce. Shuffle can be done completely automatically - which is why programmers don't call it map-shuffle-reduce - the map and the reduce are the only programmer visible steps. But the shuffle is the key to making clean, logical reducers.)
What I learned doing my PhD was how to do research. My thesis topic was,
frankly, irrelevant. But the skills of doing research have been what's allowed me to be successful, as an industry researcher, as an engineer, and as a blogger.
I found this quote in an old (1970s) sketchbook of mine.
It had no provenance, but somehow seems relevant,
and it appears in no current Google search:
"The terminal degree for computer science should be
Dentist of Philosophy."
What a wonderful qualitative analysis! It rings true to me, who's worked in each regime. Still, it is a set of hypotheses. I wonder how it could be quantified, and the analytical model tested by meta-science. Any thoughts on that?
Regarding impact, why don't more academics work on open source software? That looks like a nice shortcut to getting code actually used. (For example, rsync came from someone's PhD thesis.) I can't really imagine writing software without intending to release it and being at least somewhat hopeful that someone will find it useful.
There are some pretty large open-source codebases too.
It seems to me that all of the differences you discuss have to do with managing research risk. Industry tends to reduce risk by making failure less likely, Academia by making it cheaper.
Google sits at two different points on the curve. You suggest your company's more adventurous than IBM to start, but the 20% time program squeezes a bit of time into cheaper, but failure-prone (or not-very-profitable) projects.
Also, as an outlier on the "planning research in advance" scale, the longest research project ever was probably the classification of simple groups, which took about 100 authors from 1955 to 1983.
You didn't mention anything about teaching. Right now I can't see myself choosing Industry over Academia (supposing I'm given the choice). And that has everything to do with teaching studentsâwhich I think is at least as important, if not more important than research as a professor. I mean, I don't think everyone else agrees, but I think I'm entitled to have my own values on that point.
A few month ago I was really surprised to find out that a professor I hear theoretical CS lectures at is the author of a highly popular LaTeX package. Maybe this is his way to get the satisfaction of people really using his stuff combined with being a researcher.
Funny - I was just reading another site which seems pretty relevant:
You kinda have to read the rest of them though I think.
But I do think academics are probably even more constrained by politics than industry types because they aren't constrained by reality so much. Egos figure so much larger.
One minor niggle with the above. The view from academia, especially around freedom, talks about professors. Most people in academia are not professors. Usually Ph.D. students spend less time getting funding but perhaps more time doing menial jobs for whoever they work for. I assume you're aware of that but it's probably worth pointing out.
Oh and "pay" is a good category to include. When I first went into academia I thought it wouldn't matter to me but it matters, if only a tiny bit. Well more than a tiny bit.
What I learned doing my PhD was how to do research. My thesis topic was,
This is nearly always the case. It is why I always laugh my ass off at early-stage grad students who absolutely agonize over the exact subject matter of their PhD theses. And I cry my eyes out when I hear about grad students joining the labs of known toxic asshole PIs because the science is so "awesome", only to crash a burn a few years later.
Incidentally, it is also the case that even as a post-doc or more senior investigator, the idea that there is only "one thing" that really interests is absurd. The rants of someone like Young Female Scientist that if she can't study exactly the thing she currently studies using exactly the methodoloical tools she currently uses represent nothing more than a pathetically ignorant lack of imagination.
On that, PP, I agree completely. Most people that I know don't end up doing anything related to their dissertation. If your interests are so narrow that there is only one thing you could possibly do for a PhD, you probably shouldn't be doing one.
Freedom in academia is an illusion. You're "free" to work on things that are fashionable to fund.
A look at the conference proceedings at a university library reveals that there are miles of shelving filled with proceedings on sterile topics, such as IP Quality Of Service (No practical applications after 30 years of conferences) and that many other interesting topics (with, I think much richer intellectual vistas and practical applications) are completely unfunded.
The "semantic web", for instance, is heavily funded in Europe, but it's hard to find a US researcher in the field because it's been redlined by funding agencies here.
An academic does have freedom to pick research topics within certain "legitimate" research areas, but other areas are entirely out of reach.
Great blog about the two worlds of academia and industry, applies broadly across the board to the fields that I work in, of life sciences and engineering.
Anytime you get a question about career choices, recommend the open discussion forum that the AAAS publishes on the same topic as your blog . . . The "AAAS Science Careers Discussion Forum" features dozens of regular posters from all areas of both academia and industry, and government research as well. Thanks,
Dave Jensen, Moderator (http://scforum.aaas.org/index.php)
Here's a viewpoint on your career choice you may not have seen.
From the Toronto Truthers:
"How can you change anything, when Google is keeping you apart? Google is the 'main' reason the people are not heard. All employees, past or present, are traitors. Here's your link.. http://www.google.com/search?hl=en&safe=off&rls=com.microsoft:en-us: WalKnDude"
Got this from a thread at the JREF and thought you might get a chuckle at it.
To turn the question around slightly, is a PhD necessary or useful to get an advanced development job at somewhere like Google? I'm an engineer with 10 years experience and have an awful lot of fun doing useful and somewhat advanced engineering. Since I don't want to take the management track, I'm wondering whether adding research credentials is a good idea.
Can you share your thoughts on the differences in roles available at a company like Google for Phd'd vs. non PhD'd engineers?
The only job for which a PhD is necessary is a university professorship.
A PhD is something you do because you have a compulsion to do it, not because it has any effect on your job prospects.
At Google, there is *no* difference in engineering roles between PhDs and non-PhDs. To be honest, for a lot of my coworkers I don't even *know* what degrees they have.
While I'm only in my first master year of Computer Science (Databases) and have no intention of pursuing a PhD (not sure if I'd accept it if I were offered it), I've always felt the same.
I want to build things that are practically relevant, that are actually used, or in your words: things that have impact. I've done that for my bachelor thesis and I'm going to do it for my master thesis. I actually totally dislike the theoretical part of what I'll be doing for my master thesis, but I *love* the capabilities that the implementation that goes along with it, will bring (in case you're interested: Google Analytics, but for page loading performance âÂ http://wimleers.com/blog/master-thesis-proposal-web-performance-optimiz…).
Thanks for this very helpful article, it goes a long way in explaining the differences between academia versus industry :)
P.S.: If you know Steve Souders, say hi from me :)
One of the things I like working in the industry, is that there is a very practical sense of need. What you are building is done directly because someone has a problem in in the real world. 'This doesn't work right'. Problem -> fix it.
Thanks, Gilbert, for mentioning the most glaring item missing. I get *so* many good ideas from my students. Of course, I'm in CS too, which is different from natural science in the pace of change. I love to teach, and I love to do research (aka messing around with something cool). The funding circus is murder and getting things published in journals is harder and harder. But as full professor: who cares (CPP would use more forceful language here, I assume). I can say what I want, and I can publish what I want on my web site if I so desire. And I don't have to travel around talking to suits, trying to explain to them some obvious, basic truths. Academia is for me, but YMMV.
Very nice article. I've never really understood the value of a PHD in CS, but your article makes it clear that theres good, interesting and impactful things you can do with one....
This post is very interesting indeed. I'm currently in the first year of my PhD program. I took this route thinking that research could lead to some of the impact you are mentioning and because I like teaching. Only time will tell whether the decision was appropriate or not.
Nice post... One thing that you did not touch on in your discussion of "academia" vs. "industry" has to do with the sort of company one is working for in industry. Like you, I've worked both in an industrial research lab and in a development group. But unlike you, the development group I worked for was at a company that was struggling to be profitable for my entire tenure there. Your experience of a lack of any struggle for funding in your current position *might* have something to do with the fact that the company you currently work for is one of the most successful of the last decade. :-)
academia vs. Industry in one panel!
Of course, this varies by field of research. I studied mathematics and philosophy (especially logic and computability), and my only research interest at the time was cryptology. It's a small field in academia, but industry values it highly. However, it seemed to me that most of the job opportunities were in government agencies, and that adds another dimension to "academia vs industry". All I would say is that government is far more restricting on freedom than even industry and the pay is worse.
Yet another dimension is the possibility of working for yourself: consulting or a start-up company. This is what I do; actually I began by consulting for someone's start-up and now we are partners in the company.
Another aspect of academia that has been left out of this conversation is teaching. I'm in a small minority, but I chose the academic route (math) so I could persue my research interests and also teach. More often researchers view teaching as a necessary nusiance, or worse, as a frustrating, daily dread. Either way teaching is an important consideration.
I thoroughly enjoyed your essay and sent it to some colleagues to share the joy. There are a couple of categories I would add. Your two industry categories are "jobs" for other people's companies, and some of us choose to form our own companies to have added degrees of freedom, and maybe to focus on research some more with a combination of business research grants and income from projects. Then there are small, usually one to five people, non-profit research institutes that may be funded by grants, but be less restrictive than an academia job. The overheads on grants in academia are, what, 30-40%, and in a private non-profit like that, can be only 5-10%. A lot of professors actually run such shelters on the side, to minimize grant writing headaches by those extra percents of each grant's money. And if someone is in such an institute full time, they don't have to teach or foster graduate students, which a lot of people actively dislike.
See, that's why I love my job. I get to do awesome academic style research on using discrete event and agent based simulation in translational medicine, and I don't have to teach any classes. I publish, but my job doesn't depend on it so I don't have the article of Damocles over my head. Same with grants: I go for them, but if I don't get it, oh well, there's always next year.
And make sure to check out the hovertext!
Let me disagree with your statement:
"The only job for which a PhD is necessary is a university professorship."
Maybe in USA and/or maybe in the environment you are accustomed to.
Here in Europe and in some of the environments I was part of, some people are obsessed with titles. Sometimes it is said that it is a heritage of Austrian-Hungarian empire where title meant everything. To have university degree (at minimum) is a ticket to some societies.
I am not talking only generally. It was my PhD (in maths, Algebraic Topology) that allowed me to work for European Central Bank (obviously besides knowing the stuff, banking supervision, but it was necessary qualification for position).
Thank god my current boss does not care for newcomer's titles - but then encourages them to do also research and recently one of my colleagues got PhD in Numerical Analysis, other just finishes its own PhD in Applied Maths (Financial), besides working in business.
A great essay, which tackles a concern for me. I'm an engineer with a UK 1st class MEng, and 10yrs experience in 'Industry-like' environments. I enjoy using maths and analysis to solve real engineering problems. It's great to be able to use my brain to help unlock problems that 9/10 of my co-workers don't even know are there.
I would have liked to have done a PhD after college, but I was worried I'd pick the wrong topic, and be 'pigeon-holed' into one field, and that was right because I've enjoyed the variety of work since. That said it woud be great to write a thick report on a topic I care about, and make a small contribution to science. And whilst I hate the ostentatious use of the PhD title as a status symbol that seems quite prevalent here in the UK, I would still like to achieve the award as a personal challenge 'because it's there'. maybe I will one day.
I enjoyed reading your article!
I think an additional motivation for choosing one career path over another is the amount of individual credit people get for their work. In industry, credit is given to a group, a VP, a department, or maybe the whole company, and there is no public or even company-wide knowledge of any individual's contribution except in very rare cases. In research, every person's name is listed individually in each paper they publish, which creates a public record of the person's work. Of course, most papers are written by more than one person but the credit still seems a lot more personal than it is in industry development jobs.
I got my Ph.D. in CS in 2004. Sadly, it seems that the Ph.D. degree is highly undervalued in CS especially when compared to other areas such as the natural sciences.
This is a great post, I'm sorry I didn't see it earlier. I've got an MS is statistics and applied math and have been in industry for about 35 years working in an advanced development environment, doing commercial software, and performing data analysis, experimental design, etc. There are a couple of things about industry that make it a little different from academia that I didn't see discussed. One, there is no tenure - companies make bad decisions, cut staff, and reorganize. The bigger the company the more you see that - Dilbert lives - and it can happen to you at very inopportune times. Two, companies in general deal with things that become obsolete, academics tend to deal with ideas. For example, a lot of the climate models are written in FORTRAN, which is probably a good idea, FORTRAN is still fast and powerful. But, these days, the number of companies using FORTRAN is pretty small, if you got stuck on a project that was using FORTRAN for the last 15 years and it ended you would be screwed. That is an extreme example but very real in these days of FPGAs and DSPs. Lastly, if you want to work in industry I would avoid degrees in math, physics, and chemistry and focus on CS or engineering. You have to be able to tell people what you do and with math/physics/chem that can be tough. My first job after grad school was with a major chemical company, they used guys with BA/MAs in chem as lab techs for guys with BSs in ChemE.