Doing it the other way around

If you build it, they’ll come…
(Actor Kevin Costner, in one of his many bad movies)

When I started doing research many years ago, I had the idea that things would go more or less as follows, very schematically: one would first look for a problem to solve, and then choose a specific experimental or theoretical approach to tackle it. In the case of experimental research, the process would entail performing measurements, either using an existing apparatus, or building a new one; a theorist, on the other hand, would either use a known methodology or develop a novel one, e.g., by writing a computer code.

Now, it is almost invariably the case that the applicability of a new methodology is more general than first envisioned; though it may have been initially designed to explore a specific system of interest, soon thereafter the creators themselves or others realize it to be more powerful and versatile than that. As its utilization is extended to other problems or areas of science, the benefits reaped by its inventors in terms of fame (mostly through citations) can be quite substantial, often dwarfing the recognition associated to the results achieved in the specific field of inquiry wherein it was first applied. When the technical advance is believed to have underlain significant progress across various disciplines, it is regarded as a discovery in and of itself, and sometimes rewarded with the Nobel prize.
Still, much of the above occurs by serendipity. Very seldom is the inventor of a new method aware from the start of its potential; typically, (s)he is much too focused on making progress on his/her own specific problem of interest to think ahead of time of the future applications of the new “mouse trap”. Indeed, the first implementation of the idea is usually very much geared toward measuring (or computing) one particular quantity; the full might of the new methodology is only unleashed later on, typically through the work of others.

Through my years in graduate school and postdoctoral training, however, I have learned that there are researchers who do it “the other way around”. That is, they will spend their time thinking of and developing new methodologies, conceived to be as general and as widely applicable as possible. Researchers of this persuasion, typically do not start out with a particular problem in mind, but rather with a broad class of problems. Once the new “weapon” has been created, they are on the lookout for something at which to “fire it”, i.e., applications. The more of these they can find, in different and possibly disconnected areas of research, the greater the impact of their method and the ensuing recognition for them. Many “instrumentation” or “computational” scientists fall in that category, and they themselves would acknowledge this much.

I have to confess that, even though for a while I have done myself research in this second way, I have come to regard it as a bad way to do science. Much better is to start from a specific problem, and keep always the ultimate scientific goal in mind, rather than that of building a new piece of gadgetry. The fundamental flaw with trying to “build the weapon first, and then look for an enemy to shoot”, is that in science there is no predicting what the enemy will look like. What makes scientific research so fascinating an endeavor, is the sheer richness and diversity of situations that one encounters, each new one rendering all that one had seen before seem almost trivial. Inevitably, the next problem will present challenges for which the existing toolbox will prove inadequate, or insufficient. Trying to imagine what the next tool will be without some basis on a specific, immediate and concrete research goal, is naive. Assembling ever more refined toolboxes based on known technologies may be a useful exercise, but is unlikely to lead to breakthroughs.

I suppose we all go through a stage, early on in our careers, when we mostly operate in this latter way. As graduate students, we spend most of the time learning a technique, building a piece of equipment, writing software, analyzing data. It is almost inevitable to make it all about that; for a graduate student, the main cause of frustration and/or celebration is the leak in the cryostat, the bug in the code, the crucial piece of equipment that suddenly stops or starts functioning properly. It’s a very stressful and tiring time, and frankly, as soon as the damn thing starts working all one wants to do is go out, have a beer and relax with friends, not think of the “big picture”.
Still, that “big picture” is important. It is the job of graduate and postdoctoral advisors to help their trainees to raise progressively their head, and look further ahead than their immediate problem of interest.
One of the questions that graduate students and postdocs ask me most often is “Do you think it is a good idea for me to learn that methodology ? Do you think that it may make me more ‘marketable’ job-wise ?”. My answer is inevitably: no. Knowing how to use a particular instrument, how to build it, how to do a specific measurement or how to do a class of computer simulations, may make a young scientist an excellent technician, but will not, per se, make him/her appear more promising a researcher. Other qualities like, creativity, ability to think outside the box, curiosity, breadth, interest for problems in different areas of science are the ones that enable one to be a successful principal investigator, graduate or postdoctoral advisor.

So, personally, I think it is best to spend one’s time, rather than trying to build the ultimate piece of artillery, thinking in terms of “where do I want to go with my research ? What fundamental physical question do I wish to address ?” Of course, choosing a broad line of research is a difficult task, and a very humbling experience. How does one pick a scientific problem ? I often worried that maybe what would seem to me a “fundamental question”, may not be that fundamental or interesting, after all. But science has a way of being kind to us, as it often offers interesting problems to work on, even though the initial direction was poorly chosen, or in retrospect seems like a dead end.

Well, OK, ’nuff said — time to go back to that code of mine. If I could only find that damn bug… man, I tell ya, this is going to be the mother of all codes. It will just end computational physics as we know it. All I need thereafter is to look for the right problem…

Tags: , , ,

4 Responses to “Doing it the other way around”

  1. Anonymous Says:

    But… having a ‘toolbox-building’ modus operandi isn’t necessarily as close-minded and ‘technician-y” as you make it out to be. Sure, becoming too invested in developing only methods and never their applications is narrow–but that describes just about every synthetic chemistry research program that exists.

    The creativity/curiosity/outside-box-thinking skills that make someone a good principal investigator can just as smoothly come from and contribute to her/him being a great tool-builder. After all, as you say you rarely know what the enemy looks like–so when you come across it, you need to be able to adapt to how to attack and that frequently requires finding or making a good gun at the time.

    ‘Chemical biology’ is almost exactly that: a flexible combination of building and using tools to attack biological questions in new ways. The tiny difference between biochemistry and chemical biology is the ‘color’ of the direction: tool-building vs. tool-using. And the division is awfully squishy and ill-defined, no biochemist is purely a tool-user and no chemical biologist is purely a tool-builder.

    Anyway, I think it is perfectly possible to be tool-focused and keep from getting bogged down by your tools as long as you keep your head out of the water. Getting too sucked in by and stuck on your ‘question’ whether it be biological or physical carries the same risk of drowning as heavy tools.

    **since we’re talking about my whole field of research, I have thought about these things a lot 🙂 –Arlenna

    • Massimo (formerly known as Okham) Says:

      Thank you for your comment. I did not make myself clear. I did not mean to imply that tool building is somehow inferior, or less dignified an activity. Quite to the contrary, it is a crucial aspect of the research endeavor.
      But, should one build a tool in vacuo, i.e., without any specific application in mind, trying to think of the most general possible “mousetrap”, and then look for applications, or develop a tool for a specific application first, in response to a need arising in the investigation of a well-defined system, and successively think of its extension to other areas ?
      In my opinion, having worked in both ways myself, the second option is the one that leads to better tools and better science. Obviously, it’s just a personal opinion.

      • Anonymous Says:

        I think I get it better now with your clarification. It’s kind of funny to me to imagine making a tool with no particular application! It seems like they are chicken and egg… I just can’t identify with spending time on something that didn’t have a definable purpose. So probably, I agreed with you all along. 🙂


      • Massimo (formerly known as Okham) Says:

        It’s kind of funny to me to imagine making a tool with no particular application !

        I have done it, more than once. I wrote general-purpose codes, hoping that they would help me in a wide variety of different problems, handling all sort of interactions, geometry, quantum statistics, that each and every time I would simply change a couple input parameters and get results right away.
        For the most part, it has not worked. Each new problem would force me to rethink the overall computational strategy, hence rewriting major parts of my code, because there were important things about the new problem (physics, not programming stuff) that I had not foreseen, when first writing it. And, trying to incorporate each time the change and extension, made the project quickly unmanageable (granted, I was trying to do it in fortran — good luck with that).

        I have now two reasonably general quantum many-body codes (certainly much more general than originally conceived to be), but they were first both initially written to handle a very well-defined physical system and get results for that one only. But then I found that I could just build on top of them, trying to get them each time to do something more, and it has worked much better. YMMV, of course.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: