Research requires a certain comfort with uncertainty—your ideas aren’t guaranteed to work. You accept this tension and attempt to mitigate it, but its presence is inherent to the scientific method. You may spend weeks or even months developing a hypothesis that ultimately doesn’t yield the result you expected or need.
Several recent tweets from Ryan Singer1, designer at 37signals, got me thinking about this. Here’s what he had to say:
Knowing your tools so well that you can quickly build and mock ideas lowers the opportunity cost of trying things out. If you can design but you can’t code, or you code slowly, the opportunity cost of mocking an idea is an order of magnitude higher. —@rjs [tweet 1 / tweet 2]
Granted, he’s talking about UI design, but the application to science is obvious:
- The better you know your tools, the faster you prototype the idea.
- The faster you prototype the idea, the faster you evaluate your hypothesis.
- The faster you test your hypothesis, the faster you iterate and improve the idea.
With everything on your plate in grad school, it can be hard to devote the necessary time to mastering a tool, whether we’re talking about a serious text editor, programming language, simulation framework, etc. But this mastery affords you the opportunity to later develop and test ideas with complete concentration on the actual research question—all without the transaction cost of constantly digging through manuals.
-
You might like to check out Ryan Singer’s website http://feltpresence.com/ or find him @rjs on Twitter. ↩