Package code coursework so it runs beyond your own laptop

Read the execution contract

Record the required software versions, allowed libraries, entry point and expected input and output formats. Check whether the course supplies a starter project, environment file or automated marking instructions. Treat those requirements as constraints rather than replacing them with your preferred setup.

Write down how the program should be launched from the submitted directory. Avoid instructions that depend on an editor button whose configuration exists only on your machine. If the course expects a notebook, check the required execution order and whether outputs must be included.

Find hidden local dependencies

Inspect paths to data, images and configuration. Replace references to personal folders with an approach appropriate to the project and assessment. Confirm that required input files are included or obtained through the permitted route. A filename mentioned in a report does not make that file available to the program.

Check whether the code depends on an undeclared package or a manually edited environment setting. Use the course's supported dependency-recording method. Do not include passwords, access tokens or private data in the submission; ask the tutor how an approved external service should be represented if the assignment requires one.

Inspect what will actually be submitted

Use your file browser and, where applicable, repository status to see changed and untracked files. Confirm that important source files have not been left outside the submission directory. Read ignore rules if a required file is unexpectedly absent. Git's documentation notes that ignore rules do not remove files already tracked.

Keep generated outputs separate from source and inputs where the project structure allows it. Include only the outputs the brief requires. Avoid deleting unfamiliar files merely to make the folder look tidy; determine whether they are needed by the starter project or execution process first.

Run a clean-copy check

Create a separate permitted working copy from the actual submission contents and follow the run instructions. Use the specified environment where available. This reveals files or settings that the original directory was supplying accidentally. Do not test only by running the already-open editor session again.

Try representative inputs required by the assessment and inspect the outputs for completeness and formatting. If the project includes random behaviour, follow the course's instructions about reproducibility. Keep any limitations or unsupported inputs stated accurately rather than claiming the code handles cases you have not checked.

Write concise instructions and hand in deliberately

Provide the requested readme or equivalent with setup, run steps, input location and output description. Include known limitations relevant to the task. Keep explanations consistent with the submitted version; an old readme can be as misleading as missing instructions.

Build the archive or repository submission using the required process, then inspect it independently. Confirm the entry point, dependency files and essential inputs are present. Keep the submission confirmation and permitted working history. The final goal is that another person can reproduce the assessed behaviour without needing your memory of how the laptop was configured.

Your next steps

• Record the course's execution and dependency requirements.
• Check paths, inputs and undeclared local settings.
• Inspect the actual submitted files and ignore rules.
• Run a clean copy using the written instructions.

Keep planning

• Choose a student laptop from your course requirements
• Keep coursework backed up and practise getting it back
• Make spreadsheet coursework easy to check and reproduce
• Build a keyboard workflow for reading and editing coursework