Computer Science (CS) departments have become increasingly effective at teaching programming to students from diverse backgrounds and experience levels. While the primary goal of this pedagogical shift has been to broaden participation in CS, many other students, particularly those working with large and complex datasets, have also benefited. However, a significant gap remains between learning how to program and developing robust, reproducible software. Introductory CS courses rarely cover essential software engineering principles such as design, testing, construction, and maintenance. These topics are typically reserved for upper-level CS courses, leaving non-CS students to either learn them independently or risk producing lower-quality software.
Software Engineering for Scientists (SWE4S) addresses this gap by combining key concepts from upper-level CS courses such as algorithms, data structures, data science, and software engineering into a single, accessible semester-long course. The challenge is to select the most relevant material and deliver it in a way that is rigorous yet approachable. To guide topic selection, we solicited input directly from trainees and their research advisors.
This repository contains notes and example Python and Bash scripts used in Software Engineering for Scientists, taught at CU Boulder.
For more information about the course, contact Ryan Layer at ryan.layer@colorado.edu.
| Week | Dates | Topics | Assignment |
|---|---|---|---|
| 1 | Aug 21, 26 | Intro1, Setup1, 2, 3, 4, 5, GitHub1, 2, 3, GitHub Classroom1 | 1 |
| 2 | Aug 28, Sep 2 | Python1, 2 | 2 |
| 3 | Sep 4, 9 | Best practices1 | 3 |
| 4 | Sep 11, 16 | Project pitches | |
| 5 | Sep 18, 23 | Unit tests1, Functional tests1 | 4 |
| 6 | Sep 25, 30 | Continuous integration1 | 5 |
| 7 | Oct 2, 7 | Test driven development1, Sorting Searching and Indexing | 6 |
| 8 | Oct 9 | Reading Day | |
| 9 | Oct 14, 16 | Code review1 2 3 | 7 |
| 10 | Oct 21, 23 | Workflow1 | 8 |
| 11 | Oct 28, 30 | Hash tables1, Benchmarking1 | 9 |
| 12 | Nov 4, 6 | Using/creating libraries | |
| 13 | Nov 11, 13 | Project code review | |
| 14 | Nov 18, 20 | AI code assistants | |
| 15 | Nov 25, 27 | Fall break | |
| 16 | Dec 2, 4 | Project presentations |
| Topics |
|---|
| Configuration files 1 |
- Weekly assignments - 60%
- Final project - 40%
- Proposal - 10% Code Review - 10%
- Presentation - 40%
- Content - 40%
- Weekly assignments - 90%
- Final project (optional) - 30% (yes, that adds up to 120)%
This class is the first of its kind and we will be flexible with the pace of topics and assignments. While attendance is not required, this is a hands-on class and lectures will be interactive. Supporting documents will be provided, but many details will only be covered in class.
All assignments and grading will be managed through GitHub Classroom. For each assignment, we will provide a link. Follow the link it to accept the assignment and clone the repository. Submissions must follow Python best practices and use the appropriate GitHub workflow. Unless stated otherwise, we will only evaluate the v1.0 release, using its release date as the official submission time. Late or incorrectly released assignments will not be accepted. Collaboration is allowed, but each student must submit original work. Unless noted otherwise, assignments are due by 5 PM one week after they are posted.
All graduate students are required to propose and complete a project. Each project team must consist of 2 to 4 members, with no more than three graduate students per team. Teams of four must include at least one undergraduate. Projects may address any scientific question but must incorporate the software engineering and design principles covered in class. While the scientific question does not need to be novel, all contributions must be original. Teams are encouraged, but not required, to meet with the instructor to discuss their topic. A brief in-class proposal will present the scientific question, and a longer final presentation will highlight the software product and results. Each team will also conduct and present a code review of another team’s project. Undergraduates are encouraged, but not required, to either join a team or propose their own project.