Week 1: Technician Foundations and Hardware Orientation

A computer does not fail as one mysterious box. It fails as a system.

Power has a path. Data has a path. Firmware makes decisions before the operating system ever appears. A cable can be seated but wrong. A part can be functional but incompatible. A user's first description can be honest and still not be evidence.

That is where this course starts.

This week is your entry into technician thinking. You will learn how to slow down, make the system visible, protect the hardware, and turn a vague complaint into an inspectable service record. The point is not to memorize a pile of part names. The point is to understand how a working machine is organized, what each boundary does, and how a careful technician avoids creating a second problem while trying to solve the first one.

The system question

The question for Week 1 is simple:

When a computer appears broken, how do we identify what is actually happening before we touch the wrong thing?

That question drives every lesson this week. You will move from technician mindset, to internal hardware, to ports and interfaces, to firmware and boot behavior, and then into a first service ticket.

What changes by the end of the week

By the end of Week 1, you should be able to look at a desktop or approved hardware model and explain the first layer of the system:

• where power enters and gets distributed;
• where the motherboard connects the major subsystems;
• how CPU, memory, storage, expansion, cooling, and firmware each contribute to startup;
• which ports and cables carry power, data, display, or network signals;
• why ESD and electrical safety come before speed; and
• how to document an observation without pretending it is already a diagnosis.

That last one matters. A technician who writes "dead computer" has not narrowed the system. A technician who writes "no display, power LED on, fans spinning, monitor input unverified" has created a path for the next test.

How the lessons connect

Lesson 1 sets the operating rule for the whole course: evidence before confidence.

Lesson 2 opens the desktop as a system of replaceable parts. Lesson 3 follows the ports and interfaces that let those parts communicate with the outside world. Lesson 4 looks at firmware, POST, and the boot path, which means you see what happens before Windows, Linux, or any other operating system takes over. Lesson 5 pulls the week together in a service-ticket scenario.

Read the week as one investigation, not five separate assignments.

Evidence you will build

Your evidence this week should show that you can inspect before you conclude. Keep:

• a safe technician workspace record;
• a component map or census;
• a port and interface map;
• a firmware, POST, or boot-path observation; and
• a service ticket that separates observation, theory, controlled test, verification, and documentation.

The artifacts are not busywork. They are the paper trail of your thinking.

Safety boundary

You may inspect approved classroom systems, supplied images, diagrams, or sanctioned hardware models. Do not disassemble a personal device, force a connector, open a power-supply enclosure, handle swollen or damaged batteries, or perform powered internal service unless the lab explicitly directs a controlled observation.

Good technicians do not prove courage by touching dangerous hardware. They prove skill by knowing where the boundary is.