exception handling when they are actually working in JavaScript.
Maybe we should be teaching scientists and engineers about computer
science more generally. But as Greg
Wilson points out, they don’t want
much—they see computer science
as a “tax.” What’s the core of computer science that even scientists and
engineers ought to know? Alan Kay
recently suggested a “Triple Whammy” (http://computinged.wordpress.
com/2010/05/24/the-core-of-computer-
science-alan-kays-triple-whammy/)
defining the core of computer science:
1. Matter can be made to remember,
discriminate, decide, and do.
2. Matter can remember descriptions and interpret and act on them.
3. Matter can hold and interpret and
act on descriptions that describe anything that matter can do.
That’s a pretty powerful set. It goes
way beyond Python vs. Java, or using
Perl to check genome sequences with
regular expressions vs. using MATLAB
for analyzing data from ecological simulations. How do we frame the Triple
Whammy in a way that fledgling scientists and engineers would find valuable
and learnable?
Reader’s comment
The worrying trend I see is that many
computer engineering graduates are
interested in learning only a large set of
programming languages, but dislike courses
like algorithm design, not realizing that these
languages are merely tools for implementing
solutions. The end result is what you could
call technicians but not engineers.
—Farhan Ahmad
Greg Linden
“Research in the Wild:
Making Research
Work in industry”
http://cacm.acm.org/
blogs/blog-cacm/97467
How to do research in academia is well
established. You get grants to fund
your group, attract students, publish
papers, and pump out Ph.Ds. Depending on who you ask and how cynical
they have become, the goals are some
combination of impacting the field,
educating students, and personal aggrandizement.
Research in industry is less established. How to organize is not clear.
The purpose is not even well understood. The business strategy behind
forming a research group sometimes
seems to be little more than a variant of the Underpants Gnomes’ plan
in South Park. Phase 1: Hire Ph.Ds.
Phase 2: Phase 3: Profit!
Generally, researchers in industry
are supposed to yield some combination of long-term innovation, improving the sophistication of technology
and products beyond simple and obvious solutions, and helping to attract
talented and enthusiastic developers.
To take one example in search, without researchers who know the latest
work, it would be hard for a company to
build the thousands of classifiers that
ferret out subtleties of query intent,
document meaning, and spamminess,
all of which is needed for a high-quality
search experience. Information retrieval is a field that benefits from a long
history of past work, and researchers
often are the ones that know the history
and how to stand on giants’ shoulders.
Even so, there are many in industry
that consider researchers an expensive
luxury that their company can ill afford.
Part of this comes from the historically
common organizational structure of
having a separate and independent
research lab, which sometimes looks
to be a gilded ivory tower to those who
feel they are locked outside.
The separate research lab is the traditional structure, but a problematic
one, not only for the perception of the
group by the rest of the company, but
also because the researchers can be so
far removed from the company’s products as to have little ability to make an
impact. Many companies appear to
be trying other ways of organizing researchers into the company.
For example, Google is well known
for integrating many of its researchers
into product groups and shifting them
among product groups, working side-
by-side with different development
teams. While on a particular project,
a researcher might focus on the part
of the problem that requires esoteric
knowledge of particular algorithms,
but they are exposed to and work on
many problems in the product. When
this group comes together, everyone
shares knowledge, and then people
move to another group, sharing their
knowledge again. Moreover, these
ephemeral teams get people to know
people, yielding valuable peer net-
works. When a tough research prob-
lem later comes up and no one nearby
knows how to solve it, finding the per-
son in the company who can solve it
becomes much easier.
Reader’s comment
Research as a process and a profession and
as a mind set is quite different than product-making. Pushing the two too close together
or expecting people to be good at both may
not always be optimal. See my “Research as
product” post on the FXPAL Blog.
—Gene Golovchinsky
Mark Guzdial is a professor at the georgia Institute
of technology. Greg Linden is the founder of geeky
Ventures.
© 2011 aCm 0001-0782/11/0300 $10.00