3 ms·
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."
by 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.