Research

I've been trying to decide if "research" is the right field for me, and just now I was reading "Advice to the new researchers" by IBM researcher Mark Wegman (here's the link, assuming they preserve it.)  Among other things, he mentioned that typically a research problem has various sub-problems a, b, and so on.  Here's a quote I liked:

 In any research problem you are taking a risk. This requires great courage. Don't think for a moment that it doesn't. Each of the sub-problems might stump you and you might fail at the whole task.... The right approach to a risky endeavor is to go more breadth first. Do a bit of work on b to understand it better, then go back to a. People resist this approach because they like doing things they know and are good at, and switching contexts can also be expensive. If success at b were guaranteed then finishing a first would have been more efficient. If you aren't failing often in research, you aren't solving hard enough problems and taking enough risks. If there's a reasonable chance of failure, then a breadth first approach to the problem allows the faster failure and consequent saving of effort.


Here another on complete understanding:

One lesson is, you must understand something fully before you can do something simply. It's okay to go through complex solutions and then simplify later, at least on really hard problems. John Vlissides always told me you need to implement something at least 3 times before you can generalize. Understanding something fully before generalizing and simplifying it is as important in software engineering as in theoretical problems.


And one more on problem selection:

Choose a problem that will move you in a direction you want to go. In other words, choose a problem that will teach you something useful as you tackle it, or have you build something that will also be helpful in future work, regardless of whether you succeed or fail on this problem. 


He referenced the wikipedia page for Heilmeier's Catechism:

A set of questions credited to Heilmeier that anyone proposing a research project or product development effort should be able to answer.

• What are you trying to do? Articulate your objectives using absolutely no jargon.
• How is it done today, and what are the limits of current practice?
• What's new in your approach and why do you think it will be successful?
• Who cares?
• If you're successful, what difference will it make?
• What are the risks and the payoffs?
• How much will it cost?
• How long will it take?
• What are the midterm and final "exams" to check for success?

There's also a page with lots of advice for researchers: http://www.cs.utexas.edu/users/dahlin/advice.html.  This has been a great resource.  I am excited about research, but I lack some confidence to jump in.  This is because of the way I like to learn compared with the way I have been expected to learn for the past few years at my university.  I could be a researcher, come to face it, if that's what I decided I wanted and ought to do.  Now that is another question, and a good one at that.

Also, I learned that pedagogy can be defined as the art or study of teaching or instructive strategies.