Not a researcher—I’m a fairly senior engineer at a large tech company. I do work closely with applied scientists, and am currently building systems used primarily by researchers.
For myself, I am driven mostly by curiosity, and struggle to maintain discipline to actually complete things once I understand them well enough to know how they probably will work.
My main technique for actually doing, as opposed to thinking and exploring, is guiding that curiosity into different levels of detail.
As long as I remember to wonder how this behavior is happening at the code level, and I remind myself that I don’t really get it fully until I see it working in the debugger , I can use that curiosity to drive the detail work of actually delivering well-understood working code.
This works at other levels too—wondering if a feature actually helps users leads to wanting to understand the overall processes that users are performing, and figuring out how to instrument things in order to measure impact.
My main technique for actually doing, as opposed to thinking and exploring, is guiding that curiosity into different levels of detail.
As long as I remember to wonder how this behavior is happening at the code level, and I remind myself that I don’t really get it fully until I see it working in the debugger , I can use that curiosity to drive the detail work of actually delivering well-understood working code.
I’ve also found this to work well in my work as a programmer, but it’s generally something I have to remind myself to do in a reactionary way and therefore doesn’t seem to help me “get my butt in the chair”. So, this is a good reminder to try and guide my curiosity in the way you described, thanks!
Not a researcher—I’m a fairly senior engineer at a large tech company. I do work closely with applied scientists, and am currently building systems used primarily by researchers.
For myself, I am driven mostly by curiosity, and struggle to maintain discipline to actually complete things once I understand them well enough to know how they probably will work.
My main technique for actually doing, as opposed to thinking and exploring, is guiding that curiosity into different levels of detail.
As long as I remember to wonder how this behavior is happening at the code level, and I remind myself that I don’t really get it fully until I see it working in the debugger , I can use that curiosity to drive the detail work of actually delivering well-understood working code.
This works at other levels too—wondering if a feature actually helps users leads to wanting to understand the overall processes that users are performing, and figuring out how to instrument things in order to measure impact.
I’ve also found this to work well in my work as a programmer, but it’s generally something I have to remind myself to do in a reactionary way and therefore doesn’t seem to help me “get my butt in the chair”. So, this is a good reminder to try and guide my curiosity in the way you described, thanks!