Mozfest!

[tpoisot]

During the Mozfest session, we brainstormed two questions. The setting was:

Scientific research is increasingly reliant on software -- the results we publish are as good as the code we write to generate them. But very few researchers are trained as software engineers. What do we teach these people so that they can write code that we all can trust?

1. How do we know if code can be trusted?
2. What should we tell new members of a group, lab, team, or teach beginners?

Below are transcripts of the discussions. We used a world-café method, with three groups.

[tpoisot]

Things newcomers should know

• Automation
• Big picture goal
• Lower cognitive load
• Maintainability / reproducibility

1. Code guidelines
2. Workflows
3. Hypotheses
4. Code review
5. Validation

[tpoisot]

Things newcomers should know

• Clear expectations: guidelines / design docs
• Mentoring: pair-programming / unwritten rules
• Fluency: libraries & APIs
• Toolchains: IDE, VCS
• Feedback: learning from what is being brought to the team (question practices)
• Documentation: broad picture, business protocols, make "hidden docs" visible (science, design choices)

[tpoisot]

How do we know if code can be trusted?

• number of lines
• OMG depenency chain!!
• Hast it been reviewed?
• How many other people use it?
• Formal audits <-> trusting code
  • What if we had the infrastructure to review code in a "pay-it-forward" way?
• Does it compile?
• Pair programming for learning and auditing
• How do we grow the community of developers/contributors
• Does it look good? (repo, readme, ...)
• How do tests scale with codebase size <-> Who will pay audits + maintenance
• Can I run it?
  • How easy it is to get the code
  • What do I need to install
  • How much will it cost?
• Does the library let me easily make a mistake?
• Continuous integration
• Documentation

1. Unit tests
   • one small part of the code
   • basic expectations (type, range)
2. Smell test
   • does it look right? (outputs)
3. Did I use the syntax correctly? (scientific analyses)
   • using other people's code
   • linters

[tpoisot]

Things newcomers should know

• Advice v. rules

1. Write code that's simple, worry about optimization later
   • What does simple mean? Modular, broken up, don't be clever, readable
2. Use libraries when you can
   • Which ones can you trust?: pin version, containers
3. Comment code and make its purpose clear
4. Get more than one pair of eyes on your code, to make your code better and help with comment / purpose
5. Use tests as documentation of purpose of code

[tpoisot]

How do we know if code can be trusted?

• The need to be lessons teaching good practices
• Context-based coding
  • biological
  • no test cases -> had to find what it wrong
• Exception handling -> encourages laziness -> less thinking about logical errors
• Good test data -> hard to find but crucial
• Logic, as simple as possible
  • Indented ifs, better way to implement logic!

[tpoisot]

How do we know if code can be trusted?

• Open source / levels of open
  • snippets
  • whole files
  • repository with readme for building
  • development environment image
• Curry-Howard isomorphism -> type theory (vs. weakly typed languages)
• Effort vs. reward for niches
• VCS (git), sign commits with pgp
• Grow the community
• Data quality
• Test-driven / behavior-driven development
• reproducible builds