Zen of IDM†

The more common a task is, the easier it should be to do.

But uncommon tasks should still be doable without creating a mess.

If a frequent task takes multiple lines of code to accomplish, ask if it could take one instead.

There should always be at least one obvious way to run your code.

Expect that code should take only seconds to run, and if it does not, ask whether it can.

If you have time to write code, you have time to write simple documentation and tests.

A test should never be so complex as to require debugging itself.

Assume that every problem you have has already been solved, and first look for that solution.

But when faced with a new question, repurposing old code may not be the best option.

And if you did just solve something hard, find a way for your solution to help other people.

Write your code as if it will be seen by others, and then actually share it with them.

Ask of your code: does it bring joy? Clarity? Utility? And for whom?

Credo for Research

Your code is part of your research, not distinct from it.

Good code doesn’t mean good research, but bad code can mean bad research.

If you write code, that makes you an engineer, whether you like it or not.

Write code that embraces change: change is not rejection, it is improvement.

Now is better than hopefully soonish: prioritize code that provides immediate benefit.

Iterate quickly: code is an experiment; the more you experiment, the more you learn.

Sometimes a day spent coding can save five minutes asking a researcher what they need.‡

Ask yourself: will your code ultimately help save lives? If not, does it have purpose?

Contributors: Ace Thompson, Charles Eliot, Cliff Kerr, Dan Klein, Dina Mistry, Edward Wenger, Mary Fisher