Back to PIT Home

Heads-up — AI-assisted content: The formatting and some of the written content on this page were drafted with the help of an AI assistant. The material has been reviewed by Mr. Johnston and is presented in good faith, but specific steps (especially VS Code menus, terminal commands, and tool versions) may differ slightly from what you see on your actual machine. Because you've been given this notice, you are expected to flag any irregularities you encounter — bring the exact wording, screenshot, or error text to class so we can correct the page. Reporting a mismatch is full credit; following a wrong step silently is not.

Transitioning to Professional Local Development

From CMU Academy in the browser → VS Code + Python + CMU Graphics + Git on a real machine · 3-hour practicum

Open Why this matters for every career, not just coders

Every profession has a "workflow." Pilots run a pre-flight checklist before every flight. Surgeons follow a sterile-field protocol. Accountants close the books on a fixed monthly cadence. Line cooks follow mise en place. The work looks different, but the pattern is identical: a sequence of steps, in a specific order, with specific tools, that produces reliable results.

In this practicum, you're going to learn the professional software development workflow: set up environment → write code → verify it runs → commit a snapshot → iterate. Even if you never write code professionally, the bigger skill you're practicing — learning a new workflow quickly and following it without skipping steps — is exactly what employers in every field hire for. CTE Standard 130.312(c)(1)(B) calls this out by name: flexibility, open-mindedness, initiative, and willingness to learn new knowledge and skills.

What You Will Do

You will move one of your own CMU Academy programs out of the browser and into a real local development environment, then use Git to take versioned snapshots of your work — the same way professional developers do every day.

Learning Objectives

By the end of this 3-hour practicum, you will be able to:

  • 1. Verify a working professional Python environment (VS Code + Python) on a local machine.
  • 2. Install cmu-graphics with pip and run a CMU Graphics program locally.
  • 3. Migrate one of your CMU Academy programs into VS Code with improved formatting, naming, and comments.
  • 4. Initialize a local Git repository and create meaningful commits.
  • 5. Articulate why version control matters — and recognize parallel "workflow" and "versioning" practices in other industries.
  • 6. Submit a professional PDF deliverable documenting your work.

Practicum Blocks

  • Block 1 — Mission Briefing & Environment Validation 0–25 min
  • Block 2 — Installing & Testing CMU Graphics 25–60 min
  • Block 3 — Importing a Real CMU Program 60–100 min
  • Block 4 — Introduction to Git 100–130 min
  • Block 5 — Iteration & Versioning 130–160 min
  • Block 6 — Final Deliverable Submission 160–180 min

Block 1 — Environment Validation0–25 min

Before you write a single line of code, professional developers verify their environment. A bad PATH, missing interpreter, or wrong terminal will silently waste hours later. Validate first, then code.

Your tasks

  1. Open VS Code.
  2. Open the integrated terminal (Ctrl + ` or View → Terminal).
  3. Verify Python is installed and on PATH:
    python --version
    You should see something like Python 3.x.x. If you see "command not found" or a Microsoft Store popup, raise your hand — that's a PATH issue.
  4. Create a project folder named exactly:
    cmu-local-project
  5. Open that folder in VS Code (File → Open Folder).
  6. Create a new file hello.py with one line:
    print("Python works!")
  7. Run it from the terminal:
    python hello.py
Checkpoint screenshots (save for your PDF):
  • Terminal showing python --version output
  • Terminal showing successful execution of hello.py

Pre-flight "Validate before you fly" is everywhere

Verifying your environment before coding is the same instinct as a pilot's pre-flight checklist or a surgeon's "time-out" before incision. The pattern: confirm tools, confirm conditions, then begin the work. Industries that adopted this idea formally:

  • Aviation — pre-flight checklists (cockpit, fuel, weather) before every takeoff.
  • Medicine — the WHO Surgical Safety Checklist is used in operating rooms worldwide.
  • Construction — daily Job Hazard Analysis and equipment inspection before work begins.
  • Restaurants — line cooks do mise en place (everything in its place) before service.

"It works on my machine" is the developer version of skipping the checklist. Don't.

Block 2 — Installing & Testing CMU Graphics25–60 min

You'll use pip (Python's standard package manager) to install cmu-graphics on your local machine and verify that a graphics window opens outside the browser.

Install the package

pip install cmu-graphics

If pip reports a permissions or network error, screenshot the exact error text — documented failures are still full credit, and the error text is what the supervisor will help you triage.

Smoke-test program

Create smoke_test.py:

from cmu_graphics import *

app.background = 'black'
Circle(200, 200, 50, fill='lime')

cmu_graphics.run()

Run it. A window should open with a black background and a green circle.

Checkpoint: Screenshot of the open CMU Graphics window plus the terminal that launched it. If the window does not open, screenshot the error and write a one-sentence diagnosis.
Reflection (1 short paragraph in your PDF): What advantages or disadvantages did you notice running CMU Graphics locally instead of in the browser? Consider: speed, file access, debugging, sharing your work, dependencies.

Packages Package managers exist in almost every modern toolchain

pip install feels like a coding-only thing, but the same pattern — "pull in a trusted third-party component instead of building from scratch" — runs almost every modern industry. Once you understand the idea here, you'll spot it in fields that aren't software at all:

  • Architects & engineers use Revit/AutoCAD component libraries — pre-built doors, HVAC, fixtures.
  • Musicians & producers install plugin packs (VSTs, sample libraries) into their DAW.
  • Designers import Adobe component libraries and Figma design systems.
  • Accountants install QuickBooks/Xero add-ons for industry-specific reporting.

The shared mental model: a registry, a trusted source, a version, and dependency on other components. That's pip, npm, the App Store, and an architect's CAD library — all the same idea.

Block 3 — Importing a Real CMU Program60–100 min

Choose one of your existing CMU Academy programs — ideally one you're proud of. You'll copy it into VS Code and bring it up to a professional baseline.

Required improvements

  • Copy the program into a new file in cmu-local-project (e.g. my_program.py).
  • Add the from cmu_graphics import * import if it's missing.
  • Add the cmu_graphics.run() call at the bottom.
  • Rename any unclear variables (no more x1, temp, stuff).
  • Add at least 3 comments explaining why something is there (not just what it does).
  • Clean indentation; break long lines.
Watch out: CMU Academy is forgiving about some things that the local cmu-graphics package is stricter about — case sensitivity, missing imports, and the explicit cmu_graphics.run() call. If your program ran in Academy but not locally, that's exactly the kind of "browser vs. real environment" delta you should document.
Checkpoint: Screenshot of your imported program running locally, plus a short note (1–2 sentences) on any differences you had to resolve.

Documentation "Comment why, not what" is a writing skill, not a coding skill

The instinct to leave behind a clear paper trail of why a decision was made is one of the highest-paid soft skills in any career — not because writing comments is hard, but because most professionals don't do it. A few examples of where this same skill shows up:

  • Medicine — chart notes (SOAP format) record why a clinician made a decision, not just what they did. Insurance audits and malpractice cases hinge on this.
  • Law — legal memos and briefs cite reasoning, not just outcomes.
  • Engineering — design rationale documents accompany every set of CAD drawings.
  • Journalism — reporters keep "source notes" that explain why a fact was included or omitted.
  • Customer service — ticket notes that say "called back at 3pm, customer requested upgrade because of X" beat "talked to customer" every time.

If you can write a clear "why" comment, you can write a clear chart note, brief, ticket, or design doc. Same muscle.

Block 4 — Introduction to Git100–130 min

Git is the version control system used by ~90% of professional software teams. The concepts in this block are the ones that show up on day one of any internship or developer job.

Vocabulary you need for this block

TermOne-line meaning
Version controlA system that tracks every change to your files so you can review, revert, or collaborate without losing work.
GitThe most widely used version control software. It runs locally on your machine.
GitHub / GiteaHosting services for Git repositories — not Git itself. (Think: Word vs. OneDrive.)
Repository (repo)A folder Git is tracking. The history lives inside a hidden .git directory.
CommitA snapshot of your project at a moment in time, with a message describing the change.
Staging areaThe "shopping cart" of changes you've selected to include in the next commit.

Your Git tasks

From the terminal, inside cmu-local-project:

git init
git status
git add .
git commit -m "Initial local CMU project"
git log
Read the output, don't just run the commands. git status tells you exactly what state the repo is in. If your commit message looks wrong, fix it — the log is permanent.
Checkpoint: Screenshot of git status showing a clean tree after committing, and the git log output showing your first commit (hash + message + your name).

Versioning Version control existed long before Git — in every serious industry

Git is the software developer's flavor of an idea that nearly every regulated or collaborative profession already uses. If you understand the concept here, you'll recognize it immediately in these fields:

  • Law — "redline" comparisons and Word's Track Changes are versioning. Contracts are amended through dated, numbered revisions.
  • Engineering & manufacturing — CAD files and Bills of Materials are tracked through PLM (Product Lifecycle Management) systems with full revision history, approvals, and rollback. The discipline is called configuration management.
  • Accounting & finance — audit trails. SOX (Sarbanes-Oxley) and SEC rules require every change to financial records to be traceable to who, when, why.
  • Healthcare — EHR (Electronic Health Records) systems are append-only by law. You can't edit a chart note — you add an addendum. That's a commit.
  • Film & music production — Pro Tools, Avid, and Final Cut all keep snapshot/version history. "We need the cut from Tuesday" is a checkout.
  • Government & legislation — bills are tracked through numbered revisions; the U.S. Code is essentially a permanent change log of all federal law.

Different tools, same idea: never overwrite the past — always be able to answer "what did it look like on Tuesday, and who changed it?"

Block 5 — Iteration & Versioning130–160 min

One commit isn't version control — it's a save. You earn the benefits of Git by committing often, with meaningful messages, as you make real changes.

Make at least two more commits

Modify your program in a meaningful way. Pick one or more:

  • Change colors / styling
  • Add animation or movement
  • Add keyboard or mouse interaction
  • Change the layout or add a new shape group
  • Refactor a section for clarity

Then:

git status
git add .
git commit -m "Improved visuals and added keyboard interaction"

Repeat with a second meaningful change and a second descriptive commit message.

Commit message rules of thumb:
  • Imperative mood: "Add animation" — not "Added animation" or "Adding animation".
  • Specific: "Fix circle off-screen on resize" beats "bug fix".
  • ~50 characters for the summary line.
Reflection (full sentences, in your PDF):
  1. Why might version control be important in professional software development?
  2. What problems could arise if a team of developers worked without version control?
  3. How is keeping a Git commit history different from saving files named program_v2.py, program_v3_final.py, program_v3_FINAL_real.py? What does Git give you that the rename approach doesn't?

Iteration Iterative work is the dominant model in modern industry

"Make a small change, test it, capture the result, repeat" is the same engine that powers:

  • Manufacturingkaizen (Toyota's continuous improvement) and Lean methodology. Every change is small, measured, documented.
  • Marketing — A/B testing. Run version A, run version B, keep the winner, repeat.
  • Design — design sprints, low-fi prototypes, user testing iterations.
  • Education — formative assessment cycles: teach, assess, adjust, re-teach.
  • Medicine — clinical trial phases I → II → III; each builds on the prior.

"Big-bang" work — one giant attempt with no checkpoints — lost out in most industries decades ago. If you internalize the commit-often habit here, you'll be ahead of most adults at their jobs.

Block 6 — Final Deliverable160–180 min

Compile everything into a single professional PDF named LASTNAME_FIRSTNAME_LocalDevPracticum.pdf and submit it through Schoology.

Required sections (in this order)

  1. Cover page — your name, date, class period, lab title.
  2. Environment verification — screenshots from Block 1 (Python version, hello.py run).
  3. CMU Graphics test — screenshot of the smoke-test window plus your short paragraph on local vs. browser differences.
  4. Imported program — screenshot of your program running, with notes on what you had to change.
  5. Git evidence — screenshots of git status, the first git commit, and git log showing all three of your commits.
  6. Iteration log — describe the two changes you made in Block 5 and why.
  7. Reflection — 2 well-developed paragraphs covering: what you learned, how local dev differs from browser-based coding, why version control matters, and which of the "Profession Connection" callouts from this lesson surprised you most.
Submission rules: Single PDF, professional formatting (headings, captions on screenshots, complete sentences). No screenshots of screenshots. No upside-down phone photos of your monitor.

Grading Breakdown

CriterionPoints
Effort & professional engagement throughout the block30
Cover page10
Environment verification10
CMU Graphics test10
Imported program10
Git evidence10
Iteration log10
Reflection10
Total100

Honest documented failures (with the exact error text) are worth full credit on the affected sections. Pretending something worked when it didn't is academic dishonesty.

Lesson Expectations

  • Capture exact error text on any failure — screenshot plus the literal message.
  • Try at least one documented workaround before escalating to the teacher. Bring the exact error text with you when you do escalate.
  • If you finish early, the website lists extension activities (start with the Gitea publishing extension). Idle time is not an option.

Finished Early? Start the Required Extension

If you finished the main lab early, start the required extension now — otherwise you will complete it during a follow-up class meeting. The extension adds a remote-hosting step to your project and is part of the same PDF deliverable.

Open the Gitea Extension: Publishing to the Classroom Server

Other ways to use spare time productively

  • Add more interaction to your program (mouse events, keyboard handlers, animation timing) and commit each change separately.
  • Intentionally break your code, then use git restore . or git checkout <hash> -- . to roll back. Document what happened.
  • Help a classmate troubleshoot their environment — mentoring others is on the TEKS rubric too.
  • Read ahead about .gitignore and create one that excludes __pycache__/.

Career "Even a little coding" shows up in fields you wouldn't expect

If you're sitting in this class thinking "I'm not going to be a developer, so why does this matter?" — here's the honest answer: almost every modern field has at least one role where basic Python, SQL, or Excel automation is the difference between two equally qualified candidates.

  • Journalism — "data journalism" desks at the New York Times, Washington Post, ProPublica, and the Texas Tribune use Python and R every day to analyze public records and government data.
  • Law — e-discovery firms hire paralegals who can write small scripts to filter millions of emails. "Legal tech" is one of the fastest-growing job categories in law.
  • Medicine & public health — R is the dominant language of biostatistics. Epidemiologists, hospital quality teams, and public health departments run on it.
  • Sports — every MLB, NBA, and NFL team now has an analytics department. The starting credential is often Python, R, or SQL — not a sports management degree.
  • Agriculture — John Deere and Climate Corp run "precision agriculture" platforms on Python. Farm managers analyze soil sensor data the same way a developer reads server logs.
  • Marketing & e-commerce — the people who can pull their own data out of Google Analytics or a CRM with a script get promoted faster than those who file tickets for it.
  • Finance & accounting — Excel is the floor; Python (for analysis) and SQL (for pulling data) are the ceiling. Most large firms now teach Python in onboarding.
  • Film, photography, & design — batch processing (renaming, resizing, exporting thousands of files) is a Python one-liner. Studios pay for that skill.
  • Government & nonprofits — civic-tech roles (data.gov, U.S. Digital Service, Code for America) hire people who can translate between policy and code.

You don't need a CS degree to use any of this. You need just enough coding to not be the person who has to ask someone else every time. This lesson is part of building that "just enough."

Quick Command Reference

# Check Python is installed
python --version

# Install CMU Graphics
pip install cmu-graphics

# Run a Python file
python my_program.py

# Git: initialize a repo (do this once per project)
git init

# Git: see what state the repo is in (use this constantly)
git status

# Git: stage all changes
git add .

# Git: take a snapshot
git commit -m "Descriptive message in imperative mood"

# Git: see your commit history
git log

# Git: see what you changed since last commit
git diff

# Git: throw away local edits (CAREFUL)
git restore <file>

More Info — Trusted Sources

Bookmark these. They are the references professional developers actually use — not random blog posts.

Back to PIT Home