I probably should’ve been doing this weekly but I didn’t so I’m starting now–Wednesdays or Tuesday posts, probably.

So far the bulk of my work on the loo package has been revamping the package in accord with latest tooling and development practices. I’ve updated the testing suite to use testthat version 3, relied further on a dependency (posterior) to deduplicate code across the organization, started a draft proposal to adopt the air formatter, and restructured the workflow for building the pkgdown website. These are all (somewhat) important contributions to the codebase, but my main project of adding more measures is just starting.

Working in a team is very fun and interesting; I’m learning a lot. I’ve oft mentioned to my friends who do research (in life sciences, CS, stats, economics, etc.) who work in labs that working in a proper lab sounds very interesting; collaborating and having a group to rely and discuss things with sounds quite nice. Til this project, basically all my research has been entirely independent, with my only companion being my advisor/PI–whilst I enjoy that, it feels very different to working in a group. Now, I can always appeal to Aki, Jonah, or Noa and they’ll probably have the answer to my question. I think I’m starting to learn what kinds of questions I should think and solve on my own, and which questions merit discussion, but I do worry a little that I’m overusing their help.

Additionally, this is one of the first brownfield projects I’m working on, and the mentality is quite different. I’m very used to using the latest tooling, writing decent software but not really checking too much, and moving very fast without much concern about API breakage or sem ver on a whole really. I write a lot of scripts and not too much software (though I’d argue that my some or more of my scripts are engineered and can merit the arbitrary designation of “software”) but this project is a lot of SWE, and a little math/stats. I’m not used to using older technologies, which is partially what motivates my suggestions to bring things to the latest standards–I know more about modern tooling than I do about older tooling.

My mentors write code very carefully, and that is a very useful skill that I’m learning through this project that I didn’t really think about when signing on. I think greenfield projects can be more fun, in that I would get to decide everything and there is no “baggage” of years of development which you have to take care of, but this project offers a new kind of challenge; maintaining compatibility with older versions and making changes in a minimal way is a novel constraint. I’m sure that most of my career I’ll end up working on brownfield projects so this is a very useful opportunity for me to learn how to work on such a project, especially since my mentors are quite nice and very understanding which contributes to a “safe” and low-stakes environment on a whole.

I’m excited to get started on the meat of the project!