Reflection · Fix Everything? No.

You had more maintenance needs than time. That was intentional — real operations rarely look like unlimited money, unlimited people, fix everything. You had to choose, and every yes created a not yet. That's the interesting part of the whole exercise.

Priority is a claim

When your team says "Switch-A deserves attention before the broken mouse," that's a claim, and it needs the same kind of defense as any other claim this course has asked for: impact, urgency, dependencies, backup, evidence. "It sounded worse" isn't a defense.

Reflection prompt (150-200 words)

Which Week 18 maintenance decision was hardest for your group, what evidence did you use to choose between competing needs, and what risk remained because another issue had to be postponed?

Your response needs:

1. the competing issues — what two or more things you were deciding between
2. the evidence — what information actually mattered
3. the decision — what you prioritized
4. the deferred risk — what remained unresolved
5. the follow-up — what should happen next

Example

Our hardest decision was whether to replace Station 02's intermittent headset or spend the same maintenance capacity investigating Switch-A. We prioritized Switch-A because four player stations depend on it and the maintenance history showed a recent shared outage. The headset problem affected only one user, and a tested spare was available, which reduced its immediate impact. We still documented the headset as a maintenance need, since intermittent failures can become more frequent over time. The lab could operate with the spare temporarily, but the original headset should be inspected before it's returned to service.

That's real reasoning — specific, evidence-backed, and honest about what's still unresolved.

Go past "we fixed the most important things first"

That sentence says nothing on its own. Which things, why, based on what evidence? Give the actual mechanism behind the decision.

Unresolved is a legitimate status

Professional maintenance documentation uses states like unresolved, monitoring, escalated, and scheduled — not everything becomes simply "fixed," and pretending otherwise throws away useful information that someone will need later.

Looking back at the technical block

Week 15 asked what's in the system. Week 16 asked where the connection failed. Week 17 asked how to operate the system consistently. Week 18 asked how to decide what the system needs before availability is lost. That's a real systems-thinking sequence, not just "learn computer parts, learn internet, fix computer" — you built a working model of how the whole thing holds together.

By now you can identify components, map dependencies, read a network path, define a symptom, form hypotheses, test with evidence, document an incident, build a readiness procedure, verify function, prioritize maintenance, and document follow-up. That's legitimate systems thinking at an introductory level.

Final course reflection sentence

Finish:

Before this course, I thought esports was mostly __________. Now I understand that esports also depends on __________.

Don't worry about making it sound impressive — make it accurate.

Week 18 closeout

The semester closes near where Week 1 began. Week 1 said esports is bigger than the game. Eighteen weeks later, that claim has actually been demonstrated — through players, teams, culture, communication, conflict, digital communities, careers, education, portfolios, computer systems, networks, operations, and maintenance. The game sits inside a much larger system, and now you can see it.