Skip to main content
Back to module
Python Fundamentals · Mini Project

Sharing your code

Reading49mLesson 3 of 3 in this module

Publish a script on GitHub with a clear README so others can understand, run and reuse it.

Why it matters

Code that only lives on your laptop helps nobody else, including your future self and future employers. Publishing a small project with a clear README shows that you can finish something, explain it and make it usable. For career changers in particular, a few small, well-documented projects on GitHub are often more convincing than a certificate, because a reviewer can see exactly how you work.

What "shareable" means

A shareable project lets a stranger answer four questions in under two minutes:

  1. What does this do?
  2. How do I run it?
  3. What does the output look like?
  4. What do I need installed?

The README file answers them. Everything else (clean code, tests, a licence) builds trust.

Tidy the code first

Before sharing, spend fifteen minutes on:

  • Names. Replace x, data2 and temp_final_v3 with names that explain themselves.
  • A short comment or docstring at the top of the file saying what it does.
  • A main guard, so the file can be imported without running everything:
def main():
    report = format_report(summarise(load_records(read_text("sensors.csv"))))
    print(report)


if __name__ == "__main__":
    main()
  • No secrets or personal data. Remove passwords, API keys, real names, student records, patient data and anything your employer or school owns. Use a small made-up sample file instead. Once something is pushed to a public repository, assume it has been copied, even if you delete it later.
  • Run it one last time from a fresh terminal, following your own README instructions exactly.

A README that works

README files are usually written in Markdown (README.md), which GitHub renders as a formatted page. A good structure for a small project:

# Sensor log analyser

Summarises a CSV log of sensor readings: count, min, max and mean per sensor.
Blank lines, comments and non-numeric values are skipped and counted.

## Requirements

- Python 3.10 or newer
- No third-party packages (standard library only)

## Usage

```bash
python3 analyse.py sample_data/sensors.csv
```

## Example output

```text
humid: n=1 min=55.0 max=55.0 mean=55.0
temp-a: n=3 min=20.0 max=22.5 mean=21.3
2 lines skipped
```

## Input format

One reading per line: `date,sensor,value`, for example `2026-10-01,temp-a,21.5`.

## Running the tests

```bash
python3 test_analyse.py
```

## Ideas for later

- Group by day as well as by sensor
- Write the report to a file

Keep it short and concrete. Example output is the part readers value most, so never skip it.

Putting it on GitHub

GitHub is the most common place to share code. The basic flow in the browser, with no command line needed:

  1. Create a free account at github.com.
  2. Click New repository, give it a short lowercase name such as sensor-log-analyser, choose Public, and tick Add a README file.
  3. Use Add file > Upload files to upload your .py file and the sample data.
  4. Edit README.md in the browser and paste in your README.
  5. Optionally add a licence (Add file > Create new file, name it LICENSE, and choose a template such as MIT) so others know they may reuse the code.

The Git & the Command Line course teaches the professional way to do this with git add, git commit and git push, which keeps a full history of every change. The browser upload is fine for a first project.

Other files worth adding

  • requirements.txt lists third-party packages (one per line, such as pandas==2.2.3) so others can run pip install -r requirements.txt. If you use only the standard library, say so in the README instead.
  • .gitignore lists files Git should never upload, such as __pycache__/, .venv/ and any real data files.
  • A test file, even a few assert lines, shows that you check your work.

Asking for feedback

Sharing is also how you improve. Post the repository link in a forum (such as this site's forums) or ask a friend to follow your README from scratch. Ask specific questions: "Is the README enough to run it?" or "Is there a simpler way to write summarise?" When someone reports a problem, thank them and fix the README or the code: if they were confused, the next reader will be too.

Common mistakes

  • No README, or a one-line README. Most visitors leave without trying the code.
  • Missing run instructions or example output.
  • Committing secrets or private data. Check every file before uploading.
  • Sharing code that only works on your machine, for example with a hard-coded path like C:\Users\me\Desktop\data.csv. Use relative paths or a command-line argument.
  • Waiting until it is perfect. Share version 1; improve it in public.

Quick recap

  • A README answers: what it does, how to run it, example output, requirements.
  • Tidy names, add a main guard and remove secrets before sharing.
  • A public GitHub repository with a README, the script, sample data and optionally a licence is a complete first project.
  • requirements.txt and .gitignore help others run your code safely.
  • Ask for specific feedback and treat confusion as a README bug.

Try it

In the Do tab you will publish your mini project (or any small script) in a public GitHub repository with a complete README.

Also in this lesson: