How to Work With Starter Code in a Programming Assignment

You download the assignment, open the project, and find 18 files before you have written a single line of code. Some contain TODO comments. Others have names you have never seen before: pom.xml, requirements.txt, CMakeLists.txt, package.json, tests, src, resources. Your IDE may have a button that runs something, but you aren’t sure it runs the same command the professor will.

Then comes the dangerous thought: It might be easier if I delete this and build my own version. Usually it isn’t.

Starter code is part of the assignment specification. The files, function names, method parameters, class interfaces, build instructions, tests, and folder structure tell you how your work will connect to the rest of the project. You may only need to implement three functions, but the grader may call those functions from code you never edit or see.

The safest approach looks like this:

Preserve the original project.
Run it before changing anything.
Identify the files and interfaces you are expected to modify.
Implement one small requirement at a time.
Test both the new behavior and the behavior that already worked.
Review every changed file before submitting.

That sounds cautious, and it is. Most starter-code disasters have little to do with writing the required algorithm. They happen when the student changes the contract around it.

What starter code is actually doing for you

Starter code can look like extra complexity, especially in an introductory course. In practice, it often removes decisions that aren’t part of the learning objective.

An instructor may provide:

Function and method stubs so your code can be tested directly
Required classes or interfaces
Sample inputs and expected outputs
Public tests or a test runner
A build configuration
Dependency files
Data-loading utilities
A graphical interface around the function you must implement
A command-line entry point
Documentation and submission scripts

This is common in real university coursework. MIT’s introductory Python problem sets, for example, provide functions with defined signatures and warn that changing those definitions can cause the supplied unit tests to fail. Berkeley’s CS 61A projects identify exactly which files students should edit and tell students not to change required function signatures. Stanford’s CS106B handouts name the specific source files you edit, say to submit only those files, and in places forbid changing the provided public prototypes.

Details vary from course to course, but the lesson holds: don’t assume every file in the project belongs to you in the same way.

Think of the project as a set of contracts

A contract is an agreement between one piece of code and another. It answers questions like:

What is this function called?
Which arguments does it accept?
What does it return?
Which files must exist?
How is the program started?
What input format is accepted?
What output format is produced?
Which exceptions or error values are expected?

Consider this Python stub:

def calculate_average(scores):
    """Return the arithmetic mean of a non-empty sequence of scores."""
    raise NotImplementedError

You have been asked to replace the placeholder with a working implementation. The editable part is the function body. The assignment may already fix these details:

The function must still be named calculate_average.
It must accept one argument.
Callers will supply a sequence of scores.
It must return a value rather than print it.
The input is guaranteed to be non-empty.

This implementation preserves that contract:

def calculate_average(scores):
    """Return the arithmetic mean of a non-empty sequence of scores."""
    return sum(scores) / len(scores)

This rewrite does not:

def get_average():
    scores = input("Enter the scores: ").split()
    print(sum(scores) / len(scores))

The second version changes the name, removes the parameter, introduces interactive input, prints instead of returning, and attempts arithmetic on strings. Even if you repaired the arithmetic, an autograder importing calculate_average wouldn’t find it.

Easy to miss: the calculation and the interface are separate problems. You can correctly understand how to calculate an average and still break the way the assignment expects to call your code.

Your first 15 minutes with a starter project

Don’t start by hunting for every TODO. Start by working out what you received.

1. Read the assignment page and README together

The assignment page often describes the learning objective and deliverables. The README usually describes the project itself: setup, commands, folders, dependencies, and known limitations.

Make a short note of:

Required language and version
Required IDE, compiler, interpreter, or framework
Setup command
Run command
Test command
Files you must submit
Files you are allowed to edit
Libraries you may or may not use
Required function, method, and class names
Input and output rules
Collaboration and outside-help rules

Don’t trust your memory after one reading. Keep the list beside the editor.

2. Draw a small project map

You don’t need a detailed architecture diagram. One line per important file is enough.

src/main.py             program entry point
src/parser.py           reads and validates the input file
src/report.py           functions I must complete
tests/test_report.py    supplied public tests
data/sample.csv         sample input
requirements.txt        Python dependencies
README.md               setup and run instructions

This map turns “18 mysterious files” into a few roles. It also lets you ask a focused question: I understand that main.py calls report.py, but I cannot tell whether I am allowed to change the parser.

3. Preserve the original state

If the project already uses Git, check its status before editing:

git status

If course policy and repository permissions allow it, record the supplied state with a baseline commit:

git add .
git commit -m "Record assignment starter code"

Some classroom repositories arrive with a starter commit already in place, in which case you may not need another one. Don’t create commits for their own sake; you just want a reliable point of comparison.

If Git isn’t part of the assignment, keep an untouched copy of the download. Label it clearly (assignment-original, for example) so you don’t edit it by accident.

4. Run the supplied project unchanged

Use the documented command, not a guessed one, and not only the IDE’s Run button.

The untouched project may:

Pass setup tests
Display placeholder output
Fail a test because a method is deliberately unfinished
Raise NotImplementedError
Open an interface with missing functionality
Compile successfully but show instructions for the next step

Record what happens. This is your baseline behavior.

Suppose three tests fail before you touch the code. After two hours of work, three still fail. That doesn’t automatically mean you made no progress, or that you broke all three. You need to know which failures were expected at the start and how they changed.

If the unmodified project fails in a way the instructions do not mention, stop and investigate the environment. Confirm the language version, working directory, dependency installation, file permissions, and command. Rewriting application code won’t fix a missing package or the wrong directory.

Decide what is editable, protected, and generated

Create three buckets.

Editable files

These are the files or sections the assignment asks you to complete. Typical signals include:

“Implement this function”
TODO markers
Placeholder exceptions
Stub methods
A list of files to submit
An explicit student-code directory

Protected project files

You may read these files to understand the system, but should not edit them without permission. Examples include:

Public interfaces
Instructor tests
Build scripts
Framework adapters
Provided data loaders
Sample-solution binaries
Generated API clients

Protected files still matter: your code has to work with each one as supplied.

Generated or local files

These are created by tools or your development environment:

Compiled binaries
Object files
Cache directories
Virtual-environment folders
IDE settings
Test reports
Local databases
Log files

They are often useful locally and wrong to submit. Follow the assignment instructions and existing ignore rules rather than deleting files at random just before the deadline.

Read tests without turning the tests into the specification

Public tests are valuable because they show how your code is called and what behavior is observable. They can reveal:

Expected argument types
Expected return values
Boundary cases
Exception behavior
Naming conventions
Whether order matters

But public tests are rarely the complete specification. Hidden tests can use different inputs against the same contract. Hard-code the examples you can see in the test file and you’re solving the test data, not the assignment.

When a test fails, write down four things:

The input the test supplied
The result it expected
The result or exception your code produced
The requirement that explains the expected result

The fourth point matters. If you can’t connect the test to the brief, you may not yet understand the rule you are implementing.

Don’t edit instructor tests just to turn the suite green. If the course expects you to write additional tests, place them where the project permits and keep the supplied tests intact.

Work one requirement at a time

A starter project encourages two bad extremes. Some students are afraid to touch anything. Others fill every stub in one long session and run the program only at the end.

Use a tighter loop:

Choose one requirement.
Find the function or class that owns it.
Identify a normal case and one boundary case.
Implement the smallest complete behavior.
Run the focused test.
Run the tests that previously passed.
Inspect the change.
Save a meaningful checkpoint.

This isn’t slow: it keeps you from spending an afternoon debugging the interaction between seven untested changes.

A fuller example: completing a grade-report project

Imagine a starter repository with this structure:

grade-report/
├── README.md
├── data/
│   └── sample_scores.csv
├── src/
│   ├── main.py
│   ├── parser.py
│   └── report.py
└── tests/
    ├── test_parser.py
    └── test_report.py

The brief says:

Do not modify main.py or parser.py.
Complete three functions in report.py.
Do not print from those functions.
Preserve the supplied signatures.
Submit only report.py.

The first function is:

def calculate_average(scores):
    """Return the arithmetic mean of a non-empty list of numeric scores."""
    raise NotImplementedError

Your first implementation is simple. Run only the relevant test group, then all the report tests, then the parser tests, which should still pass even though you never intentionally touched the parser.

The second function is:

def assign_letter_grade(average):
    """Return A, B, C, D, or F using the thresholds in the assignment brief."""
    raise NotImplementedError

Before coding, turn the threshold table into cases. Pay particular attention to exact boundaries: 90, 80, 70, and 60. An implementation that works for 95 and 75 can still be wrong at 90 if the comparison uses > instead of >=.

The third function builds a report row. Here, reuse the two verified functions instead of recoding their logic in a new block. The project grows by combining pieces you’ve already tested.

This example is deliberately ordinary. Starter-code work is usually less about dramatic algorithms than about respecting boundaries while extending behavior.

Inspect the change, not just the final output

A program can appear to work while containing changes you didn’t intend.

With Git, use:

git status
git diff
git diff --staged

git status tells you which tracked and untracked paths differ from the recorded state. git diff shows line-level changes to tracked files that you have not staged yet, and git diff --staged shows the changes you have already added. New files appear only in git status until you stage them.

Review for:

A renamed file
An accidentally edited test
A changed function signature
A hard-coded path such as /Users/name/Desktop/...
Debugging output
Commented-out starter logic that should have remained
Credentials or API keys
Formatting changes across an entire file
Generated files or local environment folders

The large formatting change deserves special attention. If your editor reformats 500 lines while you change 12, the meaningful change becomes harder to review, for you and possibly for a grader. Configure formatting deliberately or keep it separate from the functional work.

MyCodingPal’s Git workflow for programming assignments explains checkpoints, diffs, and recovery in more detail.

The most common starter-code mistakes

Renaming a required function or class

You choose a clearer name, but the tests still import the original one. Add private helper functions if permitted; preserve the public interface.

Changing the parameter list

You add a parameter because the function needs more information. Before changing the signature, check whether that information already exists in object state, configuration, or another supplied argument. Tests can’t call the new signature unless the assignment author designed for it.

Moving files to “clean up” the project

Imports, package declarations, resource paths, build systems, and grading scripts may depend on the original structure. Preferring a different folder layout isn’t a good enough reason to migrate an assessed project.

Adding prompts or decorative output

A human may appreciate Please enter a number:. An exact-output test may treat it as incorrect. A function that should return a value shouldn’t quietly turn into an interactive program.

Editing a build file to make the local machine happy

Changing versions or dependencies may solve a local setup problem while creating a submission-environment mismatch. First reproduce the documented environment as closely as possible.

Catching every exception

Wrapping a large section in a broad exception handler can hide the location and type of a real defect. Handle errors only when the contract defines a useful response or when you can add meaningful context.

Deleting “unused” code

A method can look unused because visible code never calls it. Hidden tests, frameworks, reflection, callbacks, or configuration may still depend on it. Confirm ownership before removing supplied code.

Asking AI to rewrite the repository

An AI tool can produce a clean-looking alternative that ignores the course’s interfaces, allowed libraries, required algorithm, or language level. If course policy permits AI assistance, use it on a narrowly described question and review every proposed change against the assignment contract. Never paste private course materials or restricted repositories into an external system without permission.

A language-by-language reminder

The contract appears in different places depending on the language and project.

Python

Check function names, parameters, module paths, package versions, relative file paths, and whether functions return or print. A notebook may also require you to preserve cell order or named variables.

Java

Package declarations, public class names, interfaces, method signatures, access modifiers, constructors, and the expected Java version all carry part of the contract. Renaming a public class without renaming the file stops compilation before tests run. Changing a package without updating the folder layout and imports can break other files and test discovery.

C and C++

The contract lives in header interfaces, function prototypes, the compiler standard, make targets, ownership rules, and required source files. A supplied Makefile often expresses the build contract more accurately than a manually assembled IDE configuration.

JavaScript and TypeScript

Look at exported names, module format, scripts in package.json, dependency lockfiles, framework conventions, and test configuration. Replacing the package configuration can change far more than the function you were assigned.

R and data-analysis projects

Pay attention to working directories, file paths, object names, package versions, expected plots or tables, and whether the assignment must run from a clean session. Code that relies on objects left in the workspace is not reproducible from the submitted script alone.

When the starter code itself appears wrong

Starter code can contain a defect, an outdated instruction, or an environment assumption that doesn’t hold on your machine. Respond with evidence, not silent reconstruction.

Before contacting the course team:

Return to an untouched copy.
Run the documented command.
Record the full output.
Confirm the required version and working directory.
Check course announcements and known issues.
Ask whether classmates see the same baseline behavior without sharing prohibited code.

Then send a focused report:

“I downloaded a fresh copy of Assignment 2 and ran python -m pytest from the project root using Python 3.12, as listed in the README. Test collection stops with ModuleNotFoundError for the supplied course_utils package before any student function runs. I have not edited the repository. Is there an additional setup step or an updated starter package?”

That gives the instructor something reproducible. “The starter code is broken” does not.

What to send a tutor or teaching assistant

When you need help, prepare:

The relevant paragraph from the assignment instructions
A project map or the names of the relevant files
The permitted code excerpt
The exact command
The complete error or failed-test output
Expected and actual behavior
The smallest input that reproduces the problem
A diff or clear description of what you changed
What you already tried

Follow the course rules for sharing code. Don’t upload a private repository publicly just because it’s convenient.

The MyCodingPal guide to asking for help with coding homework shows how to turn this evidence into a useful question. If outside tutoring is permitted, a tutor can help you map the project, interpret a failing test, or understand the relevant programming concept. Students who want more direct support can also look at the do my coding homework options, but they should still make the final change and be able to explain it.

A clean submission rehearsal

Don’t let the first clean run happen after the deadline.

Create a fresh folder or clean checkout containing only the files the grader will receive. Follow the setup and run instructions as if you were the teaching assistant.

Check:

Does the project build from the documented command?
Are all required files present?
Are filenames and letter case correct?
Are dependencies declared rather than available only on your machine?
Are relative paths used where required?
Is the entry point unchanged?
Are tests and sample cases reproducible?
Is debugging output removed?
Are local paths, credentials, and personal data absent?
Does the submission archive contain the files at the expected level?

The MyCodingPal autograder checklist covers compiler flags, line endings, paths, packaging, time limits, and memory issues that can appear after upload.

Final checklist

Before submitting starter-code work, confirm that:

I kept an untouched baseline.
I ran the project before editing it.
I know which files and sections I was expected to change.
I preserved required names, signatures, packages, and paths.
I implemented one coherent requirement at a time.
I ran focused tests and regression tests.
I did not alter supplied tests merely to make them pass.
I reviewed every changed and untracked file.
I removed debug output, secrets, generated files, and hard-coded local paths.
I performed a clean run using the submitted files.
I can explain what I changed and why it belongs there.

Extending an existing system without breaking its contracts is part of the assignment itself, not an obstacle between you and the “real” one. Preserve the structure and make small verified changes. Let the brief, not your assumptions, decide what can move.

Frequently asked questions

Can I delete the starter code and begin again?

Only when the assignment explicitly allows it. Even then, you may still need to preserve required filenames, signatures, interfaces, and outputs. Starting again also means taking responsibility for setup and integration work the starter project already solved.

Can I add helper functions?

Many assignments permit private helper functions while protecting the required public interface. Check the instructions. Place helpers in an allowed file and avoid changing the functions that tests call.

Should I edit the public tests?

Not unless the assignment tells you to. You may be expected to add your own tests in a designated location, but changing supplied expected values doesn’t fix an incorrect implementation.

What if a required function needs more information?

Look for existing parameters, object fields, configuration, or supplied collaborators. If the interface genuinely seems insufficient, ask the course team before changing it.

Why does my implementation work in my own project but fail in the starter project?

Your personal project may use different package names, dependency versions, working directories, input methods, or output conventions. Reproduce the assignment environment and compare interfaces before copying more code.

Is it acceptable to ask for help understanding starter code?

That depends on the course policy, but conceptual explanations and debugging guidance are often treated differently from having someone implement assessed work. Read the written rules, ask when uncertain, and disclose assistance when required.