here<\/a>.<\/p>\n At least as a computer scientist, there are basically three kinds of work
\nyou can do that take advantage of a strong academic background like a PhD. You
\ncan go into academia and do research; you can go into industry and do
\nresearch; or you can go into industry and do development. If you do
\nthe last, you’ll likely be doing what’s sometimes called advanced
\ndevelopment<\/em>, which is building a system where you’ve got a specific
\ngoal, where you need to produce something real – but it’s out on the edge of
\nwhat people really know how to do. You’re not really doing research, but
\nyou’re not doing run-of-the-mill programming either: you’re doing full-scale
\ndevelopment of systems that require exploration and experimentation. <\/p>\n I’m going to talk about what the differences are between
\nacademic research, industrial research, and advanced development in
\nterms of the basic tradeoffs. As I see it, there really five fundamental
\nareas where the three career paths differ:<\/p>\n
\n- Freedom<\/b>: In academia, you’ve got a lot of freedom to do
\nwhat you want, to set your agenda. In industrial research, you’ve
\nstill got a lot of freedom, but you’re much more constrained: you
\nactually need to answer to the company for what you do. And in AD,
\nyou’re even more constrained: you’re expected to produce a particular
\nproduct. You generally have a decent amount of freedom to choose
\na product to work on, but once you’ve done that, you’re pretty much
\ntied down.<\/li>\n- Funding<\/b>: In academia, you frequently need to devote huge amounts
\nof your time to getting funding for your work. In industrial research,
\nthere’s still a serious amount of work involved in getting and
\nmaintaining your funding, but it’s not the same order of magnitude
\nas in academia. And in AD, you don’t really need to worry about funding
\nat all.<\/li>\n- Time and Scale<\/b>: Academic projects frequently have to be limited
\nin scale – you’ve got finite resources, but you can plan out
\na research agenda years in advance; in industrial
\nwork (whether research or AD), you’ve got access to resources that
\nan academic can only dream of, but you need to produce results
\nnow<\/em> – forget about planning what you’ll be doing five years
\nfrom now.<\/li>\n- Results<\/b>: What you produce in the end is very different
\ndepending on which path you’re on. In academic research, you’ve got
\nthree real goals: get money, publish papers, and graduate students.
\nIn industry, you’re expected to produce something of value to
\nthe company – whether that’s a product, patents, reputation, depends
\non your circumstances – but you need to convince the company that
\nyou’re worth what they’re paying to have you. And in AD, you’re
\ncreating a product. You can publish papers along the way, and that’s
\ngreat, but if you don’t have a valuable product at the end, no number
\nof papers is going to convince anyone that your project wasn’t a failure.<\/li>\n- Impact<\/b>: what kind of affect your work will have on
\nthe world\/people\/computers\/software if it’s successful.<\/li>\n<\/ol>\n<\/p>\n
Freedom<\/h3>\n
To many people, this is the fundamental tradeoff between industry and
\nacademia. The short version is that academics have a lot more freedom
\nthan industry folks, but it comes at a serious price.<\/p>\n
When you’re a professor, you’ve got a huge amount of freedom. In an
\nimportant sense, you don’t really have a boss. You set your agenda, and you
\npursue it however you want. You can decide what to work on. You can decide
\nwhat your goals are, and you can decide when to change them. You’re in
\ncharge.<\/p>\n
In industry, you don’t have nearly so much freedom. You’re constrained by
\nthe needs of your company. Even in the most free-wheeling industrial
\nenvironment, you can’t just pick what you want to do; you’re expected to do
\nthings that are at least potentially<\/em> beneficial to the company. (And
\nthat potential had better actually be a pretty high probability!)<\/p>\n The biggest strike here against industry is politics. (Not that there
\naren’t politics in academia…) In an industrial setting, you’re stuck living
\nwith the outcome of political struggles in which you aren’t even a
\nparticipant. In my time in industry, I’ve seen very good projects be cancelled
\nin favor of garbage as the result of random turf wars between executives. Your
\nwork can be outstanding – but because of the outcome of some pointless
\npolitical struggle, you could have to completely change directions on
\nvirtually no notice. <\/p>\n
Funding<\/h3>\n
This is the biggest problem with academia: as a professor, you need to
\nfind a way to raise money to provide the resources you need to do your work.
\nThat’s a huge problem: most of the academic folks I know spend at least half
\nof their time writing grant proposals, grant reports, work summaries,
\nattending status meetings, and so on – doing all of the things that are
\nnecessary to keep their work and their students funded. (And that means that
\nthey’re not nearly as free as the general statement above about being able to
\ndo what they want would imply: academics can do what they want provided they
\ncan get someone to pay for it; but getting someone to pay for work is very
\nhard; and getting someone to pay for something very different from what you’ve
\ndone before can be close to impossible.)<\/p>\n
In industry, your funding generally comes from product development groups
\nwithin your company. As an industrial researcher, you are indirectly working
\nfor the product groups. This tends to mean that you spend much less time going
\naround and begging for money; it also means that you have a lot fewer choices
\nabout who to send an application to. If the product group for your research
\narea isn’t interested in what you’re doing, you’re going to have to find a new
\nproject.<\/p>\n
In development, you’ve got some of the same problems as academic research
\n– but in practice, it tends to be a lot less burdensome. Before you can start
\na project, you need to get someone to agree to fund the project. But once you
\nget going, you don’t worry about budgets – it’s someone else’s problem. You
\njust get to focus on the work. (The someone elses problem<\/em> is the key.
\nObviously, money is still an issue: someone needs to pay for the development.
\nBut in general, for product development, the money is allocated ahead of time
\n– so you don’t worry about it; some administrative person is responsible for
\nkeeping it flowing.) <\/p>\n It’s a direct tradeoff with freedom: the more freedom you have, the more
\nyou’re stuck working to get resources; the more constrained you are, the more
\nsecure your funding situation is. Speaking as someone with development, this
\ntradeoff can cut both ways: sometimes, the fact that you don’t need to worry
\nabout funding is enough freedom in itself to make up for the limitations on
\nwhat you can do; at other times, it’s frustrating enough to make you want to
\nbang your head against a wall.<\/p>\n
Time and Scale<\/h3>\n
This is the most direct tradeoff of any of these.<\/p>\n
In academia, you get to spend a lot of time working on something. Every
\nacademic researcher I know has at least<\/em> the next five years of their
\nwork planned out – and usually considerably more than that. Academics get to
\nreally create an ambitious, long-term agenda, and follow it. In contrast, in
\nindustrial work, you rarely get to plan more than a year or two (if you’re
\nlucky) in advance. <\/p>\n On the other hand, industrial researchers tend to work on a scale that’s
\nalmost unimaginable to academics. In my field (software engineering),
\nacademics talk about what they call large<\/em> systems, which are
\ntypically a couple of thousand lines of code. (I can’t tell you how many
\npapers I’ve reviewed that talk about tools that work on “real-world large
\nscale systems”, but turn out to max out around 10,000 lines of code.) In
\ncontrast, one of my first projects at IBM involved doing static analysis of
\ntemplates in a C++ compiler. The code base that I ran my initial<\/em>
\ntests on was 1.5 million lines of code. At Google, I’ve got a
\nconfiguration file<\/em> that specifies a set of source files to be spliced
\ntogether, and that configuration file is longer than the the entire code base
\nused by most academic research projects.<\/p>\n My current project is building a system which processes terabytes of data
\nevery day. I don’t even know how many machines it’s currently running on – but
\nit’s in the thousands. And around here, that’s routine<\/em>. <\/p>\n If I were to get back into static program analysis, I could easily get
\ntens of millions of lines of code to test on – and I could use hundreds or
\neven thousands of machines to speed up the analysis if I wanted to! No
\nacademic gets to do anything on that scale!<\/p>\n
On the other hand: I never expected to wind up doing logs analysis. It’s
\na huge change from the stuff I’ve done before. It’s still within the
\ngeneral scope of things that I like to do, but it’s probably not an area that
\nI would have gravitated towards if I were free to choose anything I wanted.<\/p>\n
Results<\/h3>\n
Results are the primary product of your work, and they’re hugely different depending
\non your career path.<\/p>\n
In academia, you produce two things: publications and students. And the students
\nmostly matter because they help you produce publications. Publications are pretty
\nmuch the<\/em> thing that matters in academia, so producing papers is where
\nyou focus your effort. <\/p>\n Industrial research produces three things: papers, patents, and products. The
\nlast two count for a whole lot more than the first. Patents are a big deal in industry.
\nPartly, that’s because they bring in a lot<\/em> of money; and partly because
\nthey can save<\/em> the company a lot of money. The way that patents end
\nup 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
\ncan’t obliterate you without killing themselves.<\/p>\n 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,
\nand build an implementation that demonstrates the idea. If it proves out, a product
\ndevelopment group will adopt the idea and implement it as a part of a product.<\/p>\n
Obviously, being an engineer working on a product, what you produce is
\nthe product.<\/p>\n
Impact<\/h3>\n
That leads to a final tradeoff, which makes a huge difference to me:
\nimpact. What I mean by that is what kind of affect your work has
\non other people.<\/p>\n
The primary output of most academic work is publications. When academic
\nwork is highly successful, it has an ideological impact – the ideas influence
\nother people. It’s a sort of indirect impact, but it shouldn’t be
\nunder-appreciated. Most of the really great things to come out of research
\nwere built on ideas that came from academic research. It can take a long time,
\nand it can be very indirect – but eventually, if it’s really good work, it can
\nhave an impact. (But to be honest, most of the time, it doesn’t. Most academic
\nwork produces papers that no more than a handful of people read, and which
\nnever influences anything.)<\/p>\n
Industry also produces ideas and papers, but they’re not the primary form
\nof impact. Most industrial research work produces two things: patents and
\nprototypes, which (if they’re successful), wind up influencing the company
\nand\/or its products. Like academia, most of it dies an unmourned death: very
\nfew research prototypes actually wind up making much difference. But when they
\ndo, it tends to be more tangible than what happens in academia. In industry,
\nwhen your work gets picked up, it gets picked up right away<\/em>, and
\nyou’ll probably know the people doing it. Academic research tends to take
\nlonger, and be much more indirect. As an academic, you probably won’t even
\nknow<\/em> when someone is building on what you did until after they’re
\ndone.<\/p>\n Industrial development is very different: you tend to have
\ndirect, immediate, tangible impact. There’s a directness to it
\nwhich is very different from anything else. In general, in the short
\nterm, you get to see an immediate impact from your work, which is
\nextremely rewarding. But it’s likely to be short-lived: rarely does a
\ndevelopment project end up turning into an influential long-lived
\nproduct. But development tends to have a higher
\nsuccess rate than research, and when it’s successful, it’s wonderful –
\nyou get to see the product of your work helping other people.<\/p>\n
In my 11 years at IBM, my research never produced anything that really got
\nused. Selling something new to an IBM product development group is incredibly
\nhard – the way the company is put together, it’s really hard to produce a new
\nproduct, and even for existing products, the development teams are usually so
\noverworked that they just don’t have time to look at incorporating some new
\nresearch prototype into their system. In my time there, there were two
\ntimes that I managed to get a development group to pick up my work; and both
\ntimes, the product never got released. (And both times, the reason that it
\ndidn’t get released was completely political.)<\/p>\n
In contrast, when I came to Google, my first project was a query language
\nfor component dependency graphs in our build system. Within one day of when I
\nchecked the first version of it into our code repository, I had people using
\nit. Within a week, I had over a hundred people actively using my in-progress
\ncode. Now, I’d be surprised if there’s a single engineer at Google who’s never
\nused it. <\/p>\n
Of course, the down-side of that is that my code got replaced. After
\npeople used it for a few months, we realized that the syntax really just
\nwasn’t right for the way it was going to be used. Since it was a query
\nlanguage, I’d tried to do something SQL-like, so that it would be familiar to
\npeople; it turned out that people wrote much more complicated queries than we
\nanticipated, and it was really hard to write complicated queries over a
\ndepedency graph using a SQL-like syntax. Since by then, my time was committed
\nto other things, someone else did a rewrite to change the syntax, and that’s
\nthe version that people use. That’s pretty typical of development in my
\nexperience: I got to do something really cool and exciting and useful,
\nand I got to put it into the hands of people who needed it?<\/p>\n
Now, in my current project, I’ve got a couple of hundred internal
\ncustomers. People who actively use the product of my work. People who
\nare affected by what I do: who have access to the information that they
\nneed to do their jobs, because of the tools that I produced.
\nMy work actually matters<\/em> to people. The importance of that can’t be overstated. I’m a person whose research
\nwas always focused on how to build tools that help other people program. Now
\nI’m building tools that my coworkers really<\/em> use to get their work
\ndone. I never managed to do that in industrial research; and I never would
\nhave been able to have such a direct impact on other people from academia.<\/p>\nSo what do I do, and why?<\/h3>\n
These days, I’m a software engineer doing AD at Google. Doing AD at Google
\nisn’t something special or unusual the way it was when I was at IBM; the
\noverwhelming majority of engineers at Google are doing what I call advanced
\ndevelopment. It’s the nature of the company: most of what we do is on the edge
\nof what current technology can do. We’re working with quantities of data that
\nare almost incomprehensible, and it’s our job to make them<\/em>
\ncomprehensible. So almost everything we do winds up being on the edge.<\/p>\n As you can probably guess from the description above, I’m pretty happy
\nin advanced development. I won’t pretend that it’s without its frustrations.
\nThere are definitely times when I miss the freedom that I had as a researcher.
\nBut on balance, I’m a lot happier being an engineer at Google than I ever
\nwas being a researcher at IBM – and my guess is that I’m happier than I would
\nbe in academia.<\/p>\n
Freedom is great, and I don’t mean to downplay it. I would like a bit more
\nfreedom than I have. But my experience has been that when I’ve had more
\nfreedom, I was less<\/em> happy. That’s not because I like to have my work
\ndictated to me, or to be tied down to something specific and well-defined. I
\nknow people who like development for those reasons, but they’re not my
\nreasons. For me, it comes down to the way that the tradeoffs between freedom
\nand impact work out for the kind of work that I want to do. My area is tools:
\nI want to build tools that help other people write code. For a person who
\nwants to build tools, the inability to get those tools into the hands of
\npeople who would benefit from them is incredibly frustrating. The reality of
\nthings is that you’re always stuck with tradeoffs – and in this case, the
\ntradeoff is pretty clear. A typical academic can’t devote the time to
\nproducing tools that are solid enough to be used for real-world development –
\ndoing that takes a huge amount of time and effort, and that time and effort
\nwon’t generate any more publications or grants than a prototype. <\/p>\n For my area, the difference between academic research and industrial
\nresearch and development was demonstrated to me by an experience at a
\nconference back in (I think) 2001. I had papers at two workshops – one was an
\nindustry-dominated workshop on software configuration management; the other
\nwas an academia-dominated workshop on aspect-oriented software development. I
\nspent the morning at the AOSD workshop, and the afternoon at the SCM. During
\nthe morning, I heard about 8 different academics describe their tools for
\n“large-scale software development”, but the largest system that
\nanyone<\/em> had used as a test-case for their system was about 1,200 lines
\nof code. That afternoon, at the SCM conference, I saw someone present their
\nresults from analyzing a “moderate sized” development project – the software
\nfor the Paris Metro, which included 4 million lines of code developed by 4,000
\nengineers.<\/p>\n I want to be in the second group – writing the tools that get used by
\n4,000 people to build a better system. And the way to do that is to be
\nan engineer at a company like Google. If I’d stayed at IBM, I would definitely have
\nstayed in research: IBM isn’t (in my opinion) a good place to be an engineer.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[12,48],"tags":[],"class_list":["post-836","post","type-post","status-publish","format-standard","hentry","category-chatter","category-personal"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-du","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=836"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/836\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=836"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}