4 ms·

So, lots of low hanging fruit. Can you identify (say) five things that academics can do with an existing code base that will make your job easier (and therefor

So, lots of low hanging fruit. Can you identify (say) five things that academics can do with an existing code base that will make your job easier (and therefore cheaper to the downstream users)? Perhaps pitch the top five pick at the abilities of a computer science student looking for a project? Can you identify (say) three key practices to adopt when starting a new project given the likely skill levels of postgrad students in your domain? You could get an ebook out of those I imagine.

tome 9y ago
1. Use version control 2. Have significant test coverage 3. Have at least a rudimentary form of Continuous Integration, even if it's just running a script on every check in.
tellarin 9y ago
Proper version control would already be a huge gain.
vanderZwan 9y ago
> So, lots of low hanging fruit. Well, yes and no. Speaking as someone who has done this as well: if it's UI stuff, or gluing processes together, it's fine. But sometimes they want you to fix up a custom algorithm they implemented. Which can be one of those cutting-edge scientific things that actually require a PhD-level of knowledge and insight into the topic. So you can only get half-way with untangling the spaghetti mess without sincerely not knowing for sure if you broke something or fixed a bug, because you don't know what the correct output should be.
greydius 9y ago
I don't have time to give a fuller answer right now, but if I were to write an ebook as you suggested, the recurring theme would be "design for collaboration." Make your project easy for others to use and contribute to. And, contrary to what many people have stated in this thread, I think this aligns with the incentives of academic research. If someone else can easily extend your project with some new ideas, then you've just co-authored another paper. In addition, projects that gain traction beyond your own research group are more likely to get funding. 1) test suite - this shouldn't require explanation 2) documentation - both top level docs with examples and well-commented code. keep track of units 3) one-step build - I should be able to download the project, type 'make' (or something equivalent), and start using it
- Balgair 9y ago
  > design for collaboration You have a different view of how academia works than most academics. Most PIs these days do NOT collaborate and are actively hostile towards it. It's a shame, but it's true. Also, the niche-ing of academia is real, in many fields, there may be only 3 other people on the planet that understand what you are actually doing, and many of them may not speak English and you may not know they are out there until 2 years from now (publishing takes a long time). Most code is written by grad-students that barely know what a for loop is, let alone how to use git, and they only write it to do it once for a specific paper. Look into MatLab, that is the most used language in bio, by far. It's basically psuedo-code that compiles, and it's still a mystery to most grad-students.

tome 9y ago

1. Use version control 2. Have significant test coverage 3. Have at least a rudimentary form of Continuous Integration, even if it's just running a script on every check in.

tellarin 9y ago

Proper version control would already be a huge gain.

vanderZwan 9y ago

> So, lots of low hanging fruit. Well, yes and no. Speaking as someone who has done this as well: if it's UI stuff, or gluing processes together, it's fine. But sometimes they want you to fix up a custom algorithm they implemented. Which can be one of those cutting-edge scientific things that actually require a PhD-level of knowledge and insight into the topic. So you can only get half-way with untangling the spaghetti mess without sincerely not knowing for sure if you broke something or fixed a bug, because you don't know what the correct output should be.

greydius 9y ago

I don't have time to give a fuller answer right now, but if I were to write an ebook as you suggested, the recurring theme would be "design for collaboration." Make your project easy for others to use and contribute to. And, contrary to what many people have stated in this thread, I think this aligns with the incentives of academic research. If someone else can easily extend your project with some new ideas, then you've just co-authored another paper. In addition, projects that gain traction beyond your own research group are more likely to get funding. 1) test suite - this shouldn't require explanation 2) documentation - both top level docs with examples and well-commented code. keep track of units 3) one-step build - I should be able to download the project, type 'make' (or something equivalent), and start using it

Balgair 9y ago
> design for collaboration You have a different view of how academia works than most academics. Most PIs these days do NOT collaborate and are actively hostile towards it. It's a shame, but it's true. Also, the niche-ing of academia is real, in many fields, there may be only 3 other people on the planet that understand what you are actually doing, and many of them may not speak English and you may not know they are out there until 2 years from now (publishing takes a long time). Most code is written by grad-students that barely know what a for loop is, let alone how to use git, and they only write it to do it once for a specific paper. Look into MatLab, that is the most used language in bio, by far. It's basically psuedo-code that compiles, and it's still a mystery to most grad-students.