How do you go from paper to code? My background is in Computational Biology, although I am a Biologist by training. I just recently started my PhD, and while I have a strong interest/curiosity in Computational Biostatistics/Epidemiology and method development, I am fairly sure I won't have to develop and implement new methods. But as I said, I am curious about it.
More precisely, I still do not understand how someone goes from a research paper to e.g., an R package. I find it very difficult, not only because maybe I do not have the proper theoretical understanding of it, but also because I find programming statistical methods particularly difficult. I know how to code, I code quite a bit, but I never had to implement a method starting from the paper presenting it.
Just to give an example, I recently came upon this paper and apparently somebody implemented it in R here (file named focus_1.0.0.tar.gz). I genuinely would not know even where to start. What kind of mental model do you need to have in order to be able to translate such a framework into code?

For me, I go through the maths until I understand it (and can identify methods to make the linear algebra efficient and stable).  Quite often this involves writing out the maths again in the smallest possible steps (as a LaTeX document).  This is often useful as a maintenance document - if you come back to the software in a year's time, you probably won't remember exactly how it works, and a step by step mathematical derivation (with annotations that explain your problems with it) is a fast way to remember it again. Usually with programming the main difficulty is not coding (e.g. working out how to tell the computer to do something) but problem solving/understanding (working out exactly what it is you want the computer to do).
The next step is to identify components of the algorithm/method that you can test individually.  Don't try to implement the whole thing in one go.  I quite like Heinlein's quote "when faced with a problem you do not understand, do any part of it you do understand, then look at it again".
It is also a good idea to read other people's code and work out why they have implemented it in the way that they have, and to look at how the code has been structured in the case of packages that are used by other people.  Documentation is also very important, if you want people to use your code, you need to make it as easy as possible, so minimise dependencies (e.g. on third party packages) make the user interface or API simple and consistent with expectations, and provide good documentation.  This takes a lot of time/effort that most of us (including me) don't seem to be able to spare ;o)
