I’m sharing a few thoughts over the code development – research relationship accumulated over the past three years, in the hope these will be helpful to someone else.
- Our primary goal is to publish, explain, and communicate to others what our research is about. Writing down a few slides or paragraphs about the ideas we are pursuing, experimental conditions, results, feelings, and possible research directions for the future is worth investing our time. In so doing, we ensure that we go through our work thoroughly, finding out when we are doing things that could be done in a more efficient, or even completely different way.
- We try to be researchers, thus code is a means to reach a goal, not the goal itself.
- Think before writing code. At times it is enough to stop writing, start thinking, then realize that the code we were going to write was absolutely useless. Let’s think of what the output is that we would like to have, what the inputs are that we have at hand, then find the shortest path to do that.
- Save intermediate results. If something takes more than a few minutes, we should save the intermediate results. If every time we modify a small detail we need to re-run the whole code again and it takes hours, we are wasting our time and losing focus.
- The black-box is evil. We need to know what libraries and code written by others is doing. Or at least we need to be very conscious that the fault might be in the way we are using others’ code.
- If it takes a long time, it’s probably wrong. Check out resources usage, identify the bottleneck, and see whether the problem is in the way we wrote the code.
- When an algorithm works fine, let’s first publish it in a paper. Then, when the paper is submitted, let’s rewrite the code in a decent way so that it can be used in the future. Including sanity checks and tests before and after code revision. Comments/documentation is important to remind ourselves and explain to others what we have been doing.
Research-code thoughts
