E010 Foundations of Programming (Python) is listed under banner number ITEC 3102 and carries 3 competency units. It teaches Python syntax and structure through variables, loops and conditional statements, and asks you to write, troubleshoot and debug simple programs. E010 and ITEC 3102 point to a single Degree Plan requirement. This is the course that decides whether later scripting, automation and data work feels like a tool you own or a language you are guessing at.
The three ideas that carry the whole course
Programming courses look like they contain a hundred things and actually contain three: storing a value, choosing between paths, and repeating work. Everything else in E010 is a variation. A list is storage with an index. A function is a named block you can repeat from elsewhere. A file read is storage that outlives the program. Students who chase syntax feel overwhelmed by week two; students who chase those three ideas find that new syntax slots into a shape they already understand.
The second half of the description is where the course earns its place: troubleshooting and debugging. Writing code that works when everything goes right is a skill you can fake by copying. Reading a traceback, forming a hypothesis about why a loop ran one time too many, and testing that hypothesis is not fakeable, and it is what the course actually wants. Time spent deliberately breaking your own working program teaches more here than another tutorial.
One specific stumbling point deserves naming early: off-by-one behaviour in loops and ranges. Python counts from zero and its range stops before the end value, and a large share of beginner bugs live in that single fact. Write out the values a loop will actually visit, by hand, on paper, the first ten times you write one. The habit disappears once the intuition arrives, and until it arrives the habit prevents hours of confusion.
WGU records the result as Competent or Not Competent, with no letter grades and no ordinary grade point average, and the 3 competency units size the course inside your six month term. Terms are flat priced, so closing an introductory programming course early leaves room for the heavier applied courses that depend on it.
Reading aspects when part of the deliverable is code
If your version of E010 is assessed by a performance assessment, the scored aspects usually split into two kinds: things your program must do, and things you must explain about it. Students handle the first kind and forget the second. WGU requires a score of 2 in each aspect for a task to pass, aspects are scored independently, and working code with no accompanying explanation leaves the explanatory aspects unanswered.
Budget both halves. Suppose the rubric has seven scored aspects, four of them behavioural and three explanatory, with a written component of roughly 1,200 words alongside the program. The behavioural aspects are proven by the code and need short pointers only, perhaps 90 words each to say where in the program the requirement is met and how to run it. That is 360. The remaining 840 goes to the three explanatory aspects at 280 each, which is enough for a claim, a code reference and a reason. Add 60 words of setup at the top and you have 1,260.
The general rule for code deliverables: never restate in prose what the code already shows. Point to it. Use the prose budget for the questions the code cannot answer, which are always why you chose this structure, what happens when the input is wrong, and how you know it works.
Shape for a program plus write-up
The usual E010 deliverable is a small program with a short document beside it. The proportions below apply to the document; the code is judged separately against its own behavioural aspects.
| Section | Content | Share |
|---|---|---|
| Purpose and run instructions | What the program does, the Python version, and the exact command to run it. | 9 percent |
| Input and output contract | What the program accepts, what it produces, and what it does with input it cannot use. | 13 percent |
| Structure walkthrough | The main blocks in order, one short paragraph each, referring to line ranges rather than repeating code. | 20 percent |
| Design decisions | Why a loop rather than repetition, why this data structure, why the logic is split the way it is. | 18 percent |
| Testing evidence | Cases you ran, including at least one boundary case and one bad input, with actual output shown. | 19 percent |
| Debugging record | One real bug you hit, what the symptom was, how you localised it and what fixed it. | 13 percent |
| Close | Known limitations and the next improvement you would make. | 8 percent |
Sources, code provenance and the honesty line
Programming has an evidence question the other foundation courses do not: where did this code come from? The language reference and the standard library documentation are the right authority for how something behaves, and citing them is normal professional practice. Where your task permits you to adapt an example, say so and cite it at the point of use, in a comment as well as in the write-up. Where it does not, do not.
This matters more than it does in an essay course because code similarity is easy to detect and because the whole value of the course is the debugging skill you only get by doing it. A program you cannot explain line by line will fail the explanatory aspects anyway, so borrowed code tends to cost you the credit it was meant to buy. Our own service works the same way: we teach, model and review, and the code you submit has to be code you can defend.
Testing evidence has its own provenance question, and students rarely think of it that way. When you report that a program handled a bad input correctly, the evidence is the actual output you captured, not your memory of running it. Paste the real terminal output, including the input you supplied, so the evaluator can see the behaviour rather than take your word for it. Where output is long, show the first and last lines and say how many were omitted. Fabricated or tidied-up output is easy to spot and expensive to be caught at.
Cite in whatever style your task sets out and place each reference beside the claim it supports. In the code itself, comments should explain intent rather than mechanics. A comment saying that a line increments a counter is noise; a comment saying why the counter starts at one instead of zero is the kind of note that reads as competence.
What passes, and what comes back
A Competent submission runs, handles at least one input it was not designed for without collapsing, and comes with a document that explains decisions rather than narrating syntax. The evaluator can see which requirement each part of the program satisfies without reading the whole file.
Returns in an introductory programming course are unusually predictable. The program works only for the example input. There is no evidence of testing beyond a single happy path. The write-up describes what each line does in English, adding length and no information. Or the program meets every functional requirement while the explanatory aspects are answered in two sentences because the student ran out of energy after the code compiled.
Nothing is deducted when performance assessment work goes back for revision, so completeness beats polish when you are deciding whether to submit, and let the evaluator find the last gap faster than you would. Evaluator comments will find the untested edge faster than you will. If your section also carries an objective assessment, WGU objective assessments are proctored, and our boundary there is absolute: we prepare with syntax drills, code reading practice and a straight read on your preassessment result. We do not sit exams for anyone, give no help from the moment it starts, and we would refuse portal credentials if they were offered.
Program runs but the write-up will not?
Send the E010 rubric and your code. We map behavioural and explanatory aspects separately and hand back a plan with word targets.
Six mistakes that cost time in E010
- Reading tutorials instead of writing programs. Watching someone else type produces recognition, not recall, and the assessment tests recall.
- Testing only the input you designed for. One boundary case and one bad input is the minimum credible testing evidence, and it is often an aspect in its own right.
- Explaining syntax in the write-up. The evaluator can read Python. Spend the words on why, not what.
- Ignoring tracebacks. The error message names the file, the line and the type of failure. Students who read them carefully debug in minutes instead of hours.
- Building the whole program before running anything. Run after every few lines. A bug found in three lines of new code is trivial; the same bug found in eighty is a weekend.
- Submitting code you cannot narrate. If you cannot explain a block aloud, it will not survive the explanatory aspects, whatever it does at runtime.
- Naming variables carelessly. A variable called x makes your own debugging harder and makes the structure walkthrough almost impossible to write clearly.
- Hiding the debugging story. The bug you fixed is evidence of the skill being assessed. Record it while it is fresh instead of reconstructing it a week later.
Three questions students ask about E010
I have never programmed. Is this course realistic for me?
Which Python version and tools should I use?
Does ITEC 3102 mean there is a second course to take?
Where E010 sits in WGU's programs
The July 2026 catalog places this code in 6 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.