What software development is

Why this matters

Everything Git does is about files that developers write. If those files are a mystery, Git will be one too. This lesson opens the box: what is in a program, who writes it, and what the words mean that your colleagues use without thinking.

Software is written, not built from parts

An application is a program people use: a website, a phone app, a command-line tool, a report generator. Every application is made from source code: instructions written by people, in a programming language, as plain text files. Source code is readable, at least in part, by anyone who knows the language, and the instructions are followed literally by the computer.

Here are the first lines of the playground program, src/trailguide.py, written in Python:

def load_trails(path=DATA_FILE):
    """Read the CSV file and return a list of trails (one dictionary per trail)."""
    with open(path, newline="", encoding="utf-8") as f:
        trails = list(csv.DictReader(f))
    for trail in trails:
        trail["distance_km"] = float(trail["distance_km"])
    return trails

You do not need to understand it. Notice three things: it is text; it has structure (a named block, load_trails, with indented lines inside); and it tells the computer what to do step by step: open a file, read the rows, turn the distance column into a number, hand the list back.

From source code to a running program

Source code does nothing by itself. Something has to run it:

• Some languages (Python, JavaScript) are interpreted: a program called the interpreter reads the source and executes it directly. python3 src/trailguide.py means "Python, run this file".
• Others (Java, C#, Go, Rust) are compiled first: a compiler translates the source into a form the machine runs faster, producing a build (files such as .jar or .exe). Then that build is run.

Either way, the source code is the original, and everything else is produced from it. That is why teams keep source code in Git and usually do not keep the produced files there (lesson 1.4 has more).

Application, project, repository

The three words are used loosely and mean different things:

A project can contain several applications; a repository is one project with a history. On GitLab a repository lives inside a "project" (GitLab's word for the page with issues, merge requests and the repository); on GitHub the repository is the project.

Why plain text matters to you

Developers do not write code in Word. Source code, tests, configuration and documentation are all plain text: characters, line by line, nothing hidden. That has a consequence you will feel every day:

• Git can show exactly which lines changed between two versions, and who changed them.
• Reviewers can comment on a single line.
• Two people can change different lines of the same file and Git can combine the results.

This is why documentation lives in Markdown files next to the code (lesson 1.11), and why a .docx in a repository makes developers unhappy: Git can store it, but it cannot show what changed inside.

Do and don't

Common mistakes

• Calling the application "the code". Colleagues say "the code" for the source and "the app" or "the service" for what runs. Mixing them causes confusion in bug reports.
• Looking for the program in the repository. The repository has the source; the runnable program may be produced from it by a build. If you cannot find a .exe, that is normal.
• Editing a copy. Double-clicking a file in a downloaded ZIP and editing it there changes nothing in the repository. Work inside the project folder that Git tracks.