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?


More precisely, I still do not understand how someone goes from a research paper to e.g., an R package.

Like a lot of things in life, sometimes the hardest part is just getting started. A lot of people set themselves up for failure by just, well, thinking they aren't prepared enough and are going to fail, so they effectively give up before they even try.
With that said, you do have to know at least a little to get started. In the context of writing R packages based on a paper, you don't necessarily need to be comfortable with the math or theory behind the topic to get started. You might find the process of writing the package actually helps with developing that deeper understanding you eventually do want to have, and that over time you'll make changes to the package that reflect that. I actually have a very robust, user-friendly R package where I started in this situation. I have a lot of programming experience, and someone I know had this non-trivial theory he'd been developing but didn't have the ability to properly implement in a package, so he asked me to help. The details of the math and theory were mostly unfamiliar to me since my expertise is somewhere else. I didn't even know the details of creating an R package at that point. But now, after having gone through the process of creating the package, I'm at a point where I'm even able to make my own contributions and advancements to the theory and its applications.
To start, what you need to do is think about what users might want in a package. What does the paper present that potential users will find useful? This does require at least a high-level understanding of what the paper is accomplishing; presumably, you wouldn't be trying to write a package for a paper if you had no idea what the paper is about. So make a list of the things that users will want. Now assign these items to function names without worrying about the details of how these functions work internally. For example, you might have one function that does a core statistical analysis, one that calculates confidence intervals, one that calculates variances, and maybe one that does a basic visualization.
Next, what are the most fundamental inputs you need for these functions? There might be a lot of little things that are useful for convenience, tuning, or flexibility in the function, but these aren't important yet. What's important is just getting the basic functionality running; you can go back and deal with the finer details later so that they don't overwhelm you now.
Now, what are these functions returning for values? In other words, what would a user expect or find most useful in terms of results? Part of this may end up shaping or being shaped by the previous point about inputs. If you have one function that builds on the result of another, then the input of one is going to be the output of another. So depending on the situation, you might have one function that returns simple things like a numeric or a vector, and you might have another function that returns complex things like a list or class object.
Once you have a list of the functions you want, what they need for inputs, and what they produce, you now have what you need for a basic skeleton package. So start coding by creating a bunch of empty functions. Or maybe just have them print something. If you've never written a package before, this a good time to try  building and installing it (locally on your computer) to make sure it works. As you work, periodically build, install, load, and test your package to make sure everything is doing what you think it is.
Finally, with a skeleton package setup, you can now start digging into the mathematical/theoretical details. Your functions act as guide to help you break down this task so that you don't try to overwhelm yourself by focusing on everything at once. Just focus on one thing and work on getting the basics of the function running. You absolutely should not be worrying about performance at this point. Same goes for other things like weird corner cases with input data. You should be focused on getting things implemented in the simplest manner possible. Once everything is running and you have a better feel for everything, then you can revisit.
Eventually, you will pick up a deeper understanding of what it is you're trying to accomplish with your package. You might find yourself realizing that there are functions you need that you didn't think of before, or maybe a couple of your functions need to be combined. You may even look back and realize there is a completely different way of doing things that is better. For my package, v0.1.0 (essentially a beta) and v1.0.0 (first production release) are night and day different. I completely rewrote the package from scratch for v1.0.0. v0.1.0 was great for learning, not only the math and the theory, but how my framework decisions felt both as a user and as a package maintainer. Turns out, it was clunky and unpleasant for both, and a complete overhaul was worth investing in. So don't worry about getting it perfect right away; take your time in the pre-release stage to try things, and preferably give some potential users a chance to try it and give feedback as well. I can't tell you how often other people's real-world data will expose weird corner-cases you never considered...
Some additional tips:

*

*Technical debt: sometimes there are situations where there are multiple ways to do a task. Before publishing your package, you need to think ahead what these choices mean, because if you just take the easy way, you may find it costs you a ton of time later to work around. It's best to take care of this before publishing because you want to avoid breaking things for users once they start using the package. There are tons of articles on "technical debt". Spend some time reading a few of them.

*Maintenance burden: If you intend to create an R package, please be committed to maintaining it. A huge problem I've seen with scientific software is that many people publish software/packages as a one-off task for a publication and then let it rot, which ultimately costs others a lot of time and energy when things go wrong with the software for them. Hopefully you aren't one of them. To that end, you have to be aware of how your choices in designing the package are going to affect your time commitments later. Every little thing you add is one more thing that can break, needs to be tested, requires support for users, etc., leading to more time spent maintaining your package instead of other things you want to do. So be judicious with what you add and what you cut from the feature list; if you try to add every little convenience thing that people want, you will regret it later. The same goes for thinking about what external packages you need for your package; every dependency you add is another chance for a change someone makes in their package to break your package.

*For publishing an R package, please put it on CRAN. I can't tell you how many times I've looked at the GitHub repo for non-CRAN packages (with peer-reviewed publications) only to find fundamental flaws that CRAN's "annoying" policies would have prevented. Seriously, one package I looked at changed multiple default R behaviors that many other common packages implicitly depend on. Simply by loading the package, it could completely alter the behavior of other packages in a way that was completely silent with non-obvious changes in results, and could only be fixed easily by restarting R (and never loading the package again). The commands this package was using to do this are explicitly prohibited in CRAN packages. If the author had tried to publish to CRAN, they would have caught it (or maybe they did try and decided it wasn't worth the hassle to fix just to get on CRAN...)

*Use automated testing (for R, see the 'testthat' package). This really should be a requirement for any package. Unfortunately, just because a package has unit testing doesn't mean it's being done well. It can be a bit of an art form figuring out how to do it well.

*Good documentation is necessary. And I don't just mean the typical R function references. I expect most people benefit from having a variety of tutorials/vignettes explaining concepts and giving examples. Trying to write these will actually contribute to your own understanding of the math and theory, or at the very least give you confidence in what you have learned. For R, I recommend looking at the 'pkgdown' package for this; it helps you build a website for your package that's hosted as part of your package's GitHub repo.

Some parting words: If you're going to write software for scientists, please keep in mind how important of a responsibility it is. If you really dedicate yourself and do it right, you could make a huge difference in the ability of many people to do their research more efficiently and effectively. But if you half-ass it or are lazy about maintaining it, you could screw a lot of people and cost them a lot of time, energy, and potentially money. Either way, you have the potential to make an out-sized impact on science that you might not normally have by just staying in your own little research bubble.
