D684 Introduction to Computer Science, catalog number ICSC 2211, is the four CU entry course of the WGU School of Technology computer science sequence. It introduces the field and its essential concepts, including programming basics taught through language agnostic pseudocode and computational thinking. The pseudocode choice is deliberate: it removes syntax as an excuse and puts the reasoning in plain view.
Thinking before syntax
Students with some coding experience often find ICSC 2211 unexpectedly awkward, because their fluency is in a language and the course refuses to let them use it. Students with no experience frequently do better, since they have nothing to translate from. Either way, the skill under examination is decomposition: taking a problem stated in words and reducing it to unambiguous steps that a machine could follow.
Pseudocode is unforgiving in a useful way. There is no interpreter to tell you a variable was never initialised, no autocomplete to supply a method, and no library call to hide a loop you did not want to write. Everything the algorithm does has to be visible, which is exactly why it is used for teaching and why the resulting work is easy to assess.
The other thing this course establishes is vocabulary. Data types, control flow, functions, parameters, scope, arrays, complexity, abstraction, algorithms, hardware and software layers, and the general shape of how a program becomes something a processor executes. Every later course assumes this vocabulary, and gaps here surface as confusion two courses downstream rather than as difficulty now.
Planning your preparation from the scored aspects
Where a course includes performance assessment work, the scoring detail lives in your Course of Study rather than the public catalog. Open it and count the aspects. Each is scored independently against a three point scale and each needs a 2 to pass a task, so partial coverage does not average out.
Where a course includes a proctored objective assessment, the preparation logic is different but the planning is similar: work out which topics are in scope, test yourself on each rather than rereading, and treat any topic you cannot explain aloud as unlearned regardless of how familiar it feels.
The word budget, worked. For any written task, count the scored aspects and divide. Six aspects against a 1,600 word expectation, minus 120 for an opening and 100 for a close, leaves about 1,380, or 230 per aspect. Then rebalance towards the aspects that ask you to justify an algorithm choice or trace an execution, and away from the ones that ask you to define a term. Definitions are cheap and short; justification and tracing are where an introductory submission either demonstrates understanding or reproduces a textbook.
A structure that fits an introductory computing task
Task directions take precedence where they specify a shape. Where they do not, this ordering suits most introductory algorithmic work.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Problem restatement | The problem in your own words, with inputs and expected outputs named | Catches misunderstandings before any design work happens |
| Decomposition | The problem broken into sub problems, each independently describable | The core computational thinking skill being assessed |
| Algorithm | Pseudocode with clear control flow and named variables | Judged on unambiguity rather than on elegance |
| Trace | A worked example showing variable values step by step | Proves the algorithm works and exposes off by one errors |
| Edge cases | Empty input, single item, largest value, invalid data | The section that separates careful work from adequate work |
| Efficiency | Roughly how the work grows as input grows | Informal reasoning is fine at this level; silence is not |
| Justification | Why this approach rather than an obvious alternative | Even one sentence lifts an introductory submission noticeably |
Always include the trace. It takes ten minutes, it catches most logic errors before submission, and it is the single most convincing thing you can put in an introductory algorithm task.
Evidence craft in an introductory course
The habits that make later courses easier are worth building here, when the problems are small enough to see whole.
- Name variables for what they hold. Pseudocode with single letters everywhere is harder to trace and harder to score.
- State assumptions explicitly, including what the algorithm expects about input validity.
- Trace with real values rather than describing what a trace would show.
- Keep pseudocode genuinely language neutral, since borrowing syntax from a language you know defeats the purpose of the exercise.
- Cite any source you learned an approach from, including course materials, in the format the directions require.
- Use APA where written work calls for sources, and keep quotation minimal.
Write the edge cases before writing the algorithm. Knowing that the input might be empty changes the structure of the solution, whereas discovering it afterwards produces a patch bolted onto the front.
What separates Competent from a submission sent back
Where the course assesses written work, aspects score independently and returns are usually one section deep.
- Every variable is initialised before use, and the trace shows it.
- Loop boundaries are correct, and the trace demonstrates the first and last iterations.
- Edge cases are handled rather than mentioned.
- The pseudocode could be implemented by someone who has never seen your notes.
- The efficiency discussion says something about growth rather than about speed in general.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return is a delay rather than a mark. Terms run six months at a flat rate, and an introductory course is worth closing early because everything after it depends on the vocabulary it establishes.
Six mistakes that cost time in D684
- Writing a language and calling it pseudocode. The exercise is to express logic without syntax, and importing syntax removes the point.
- Skipping the trace. Most logic errors in introductory work are visible in the first three steps of a manual trace.
- Off by one boundaries. The most common defect in early algorithm work and the easiest to catch deliberately.
- Ignoring empty input. An algorithm that assumes at least one item fails on the most likely awkward case.
- Memorising definitions without connecting them. Knowing what a parameter is matters less than knowing why scope exists.
- Treating four competency units as a small course. It carries more weight than the three CU courses around it for a reason.
- Reading the material instead of solving problems with it. Recognition feels like understanding while you are reading and disappears the moment a blank page appears, which is why working through unfamiliar problems is the only preparation that reliably transfers.
Practising decomposition properly
Computational thinking is the transferable skill in D684, and it improves with a specific kind of practice rather than with more reading.
Take a task you perform without thinking and write it as instructions for someone who will follow them literally and without judgment. Making a sandwich is the classic example and it is genuinely useful, because the first attempt always fails: the instructions assume the bread is already sliced, the jar is open, the knife exists. Every one of those assumptions is the same kind of assumption that breaks a program.
Then add the awkward cases. What happens if there is no bread. What happens if the jar is empty. What happens if the instruction says repeat until finished but nothing ever sets finished. Those three questions map directly onto missing input, resource exhaustion and infinite loops, and practising them on a familiar task builds the instinct faster than practising them on unfamiliar algorithms.
Finally, practise reading rather than only writing. Take pseudocode somebody else wrote, trace it with values, and predict the output before checking. Reading code is a distinct skill from writing it, it is the skill you use most in a working career, and it is barely practised by students who only ever produce their own solutions. Half an hour of tracing other people's algorithms is worth more than an evening of rereading a chapter.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: decomposition practice, pseudocode conventions, traces worked with real values, edge case checklists and informal efficiency reasoning. Where the course includes a proctored objective assessment, support is preparation only: topic mapping, practice problems, drilled vocabulary and an honest readiness call. We never sit assessments and we never ask for portal credentials.
D684 is the foundation for everything after it, and gaps here are expensive later. Terms are six months at a flat rate, so a solid four CU start is worth the time it takes.
Questions students ask about D684
Is D684 the same course as ICSC 2211?
Do I need to know a programming language first?
Can you take the exam for this course?
Where D684 sits in WGU's programs
The July 2026 catalog places this code in 2 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.