These cover a lot of common problems I have with scientific code, one minor one to add is "build more, smaller things" - splitting up a very large monolithic code base into several smaller pieces can work with all the above tips to make the software much more useful over time. Being able to re-use pieces between projects without needing to make future projects direct dependents of humongous prior packages is a huge deal for labs that might make many tools.

The "simplify installation" one aka "package your code" is so huge. The number of projects I come across that are simply unpackaged or just have a plaintext list of deps and are otherwise a loose bundle of MATLAB or python files are always unfortunate, because they rarely survive longer than the paper announcement. Thinking about how I spent a day repackaging moseq bc someone in our lab was curious about it but couldnt install, and then never got a reply in the issue

@jonny
Shamelessly being lazy: any good resources out there teaching people how to do packaging and install systems?
@computingnature