A basic but important research skill, 4: breaking the project down
Any worthwhile scientific project will be large, challenging, and ambitious. Even a small project, particularly for a beginner, can be intimidating and overwhelming. A key skill is to learn how to break a project down into small and manageable parts.
This applies whether one is trying to solve a particular scientific problem [how does a particular enzyme work? what is the origin of superconductivity in the iron pnictides?], write a large computer code, perform a multi-step chemical synthesis, solve a quantum many-body Hamiltonian with a specific approximation, fabricating a solar cell....
How does one do this? Are there some general principles?
I am not sure and I welcome comments and suggestions.
I also fear that current pressures to publish quickly lead to hastily put together projects without due attention to the robustness of the sub-projects.
My main suggestions are:
*be realistic. make sure each part/step is arguably manageable/doable.
* start with easy steps and processes that will build confidence and understanding. first trying to reproduce someone else's results is always a good thing!
*make sure that you have "control" of each step or "sub-module", i.e. you are sure it really does work and know what is going on. For example, if you have a large computer code using lots of sub-routines you need to be sure that each of them is numerically stable. Just, quickly throwing them together may produce garbage or be very hard to debug.
*plan steps that will produce publons.
*talk to others about how they do it, both in general and for specific projects.
Any suggestions?
This applies whether one is trying to solve a particular scientific problem [how does a particular enzyme work? what is the origin of superconductivity in the iron pnictides?], write a large computer code, perform a multi-step chemical synthesis, solve a quantum many-body Hamiltonian with a specific approximation, fabricating a solar cell....
How does one do this? Are there some general principles?
I am not sure and I welcome comments and suggestions.
I also fear that current pressures to publish quickly lead to hastily put together projects without due attention to the robustness of the sub-projects.
My main suggestions are:
*be realistic. make sure each part/step is arguably manageable/doable.
* start with easy steps and processes that will build confidence and understanding. first trying to reproduce someone else's results is always a good thing!
*make sure that you have "control" of each step or "sub-module", i.e. you are sure it really does work and know what is going on. For example, if you have a large computer code using lots of sub-routines you need to be sure that each of them is numerically stable. Just, quickly throwing them together may produce garbage or be very hard to debug.
*plan steps that will produce publons.
*talk to others about how they do it, both in general and for specific projects.
Any suggestions?
Comments
Post a Comment