Week 01 · lesson

Lesson 1: The Technician Mindset

A user says, "The computer is dead."

That sentence feels clear until you have to fix the machine. Dead can mean no power, no display, no boot device, a frozen operating system, a bad monitor input, a loose cable, a failed outlet, or a user who pressed the wrong button because the system was asleep.

So the first move is not to guess.

The first move is to turn the sentence into evidence.

That is the technician mindset: slow enough to see the system, disciplined enough not to invent facts, and practical enough to make the next test safer and more useful than the last one.

Evidence before confidence

Confidence feels good. Evidence is better.

A beginner hears "dead computer" and starts naming parts: power supply, motherboard, RAM, CPU. A technician starts with what can be observed:

User report: no visible display after pressing the power button.
Unknowns: power state, monitor state, cable path, startup sounds, diagnostic lights, recent changes.
Next safe observation: check external power, monitor input, system LEDs, fan behavior, and cable placement.

Notice what happened there. The vague complaint became a serviceable problem. We still do not know the fix, but we know what information is missing.

That is progress.

Technician troubleshooting path from user complaint through known-good boundaries to verification and documentation.
Technician troubleshooting path from user complaint through known-good boundaries to verification and documentation.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

The technician loop

Most support work follows a loop:

  1. identify the problem;
  2. gather information;
  3. form a theory;
  4. test the theory;
  5. plan and implement the fix;
  6. verify full functionality; and
  7. document what happened.

Do not read that as a poster on the wall. Read it as a control system.

If your theory fails, you return to the evidence. If the fix works only once, you verify. If you change something, you document it so the next person does not have to rediscover the same path.

A technician is not someone who always knows the answer. A technician is someone who can keep the investigation from turning into chaos.

Safety is part of the diagnosis

Before touching internal hardware, ask whether the system is safe to inspect.

Look for:

  • connected external power;
  • exposed conductors;
  • damaged batteries;
  • liquid damage;
  • hot components;
  • loose metal objects or tools;
  • unstable surfaces;
  • electrostatic discharge risk; and
  • whether the device is actually approved to open.

For classroom work, disconnect external power before opening a desktop unless the lab specifically requires a powered observation. Never open a power-supply enclosure. A PSU can contain dangerous stored electrical energy even after the computer is unplugged.

The safety check is not separate from troubleshooting. It decides what tests are allowed.

ESD: the invisible failure path

Electrostatic discharge, or ESD, happens when electrical charge moves suddenly between objects at different electrical potentials.

The annoying part is that the discharge does not need to be dramatic. You can damage a component without seeing a spark or feeling a shock. The machine may fail immediately, or it may become unstable later. That is why ESD discipline feels boring until it saves you.

Good service habits include:

  • work on a stable surface;
  • avoid carpet when possible;
  • handle circuit boards by their edges;
  • avoid touching gold contacts or component pins;
  • use an ESD strap or grounded ESD procedure when the lab provides one; and
  • keep components in antistatic packaging until needed.

The mindset is simple: do not make the hardware worse while trying to understand it.

Build a technician station

Before you open a system, give the work a shape.

Use four zones:

ZonePurposeWhy it matters
System zoneThe computer or approved modelKeeps the device stable and visible
Parts zoneRemoved screws, covers, brackets, and componentsPrevents mystery parts and lost hardware
Tool zoneScrewdrivers, labels, flashlight, meter, or test equipmentKeeps tools from rolling into the system
Evidence zoneNotes, photos, diagrams, and service recordCaptures what changed and why

This is not fancy. It is how you prevent the classic beginner disaster: three screws left over, one cable forgotten, and no record of the original state.

Convert the complaint

Scenario:

A desktop was working yesterday. Today the user presses the power button and sees no display. They say, "The computer is dead."

Do not diagnose it yet.

Translate it.

What is actually known

Known: the user reports no visible display after pressing the power button.
Not yet known: whether the system powers on, whether the monitor works, whether the cable path is correct, whether firmware begins POST, or whether the operating system starts.

Questions that create evidence

  • Does the power LED turn on?
  • Do fans spin?
  • Are there beep codes or diagnostic LEDs?
  • Is the monitor powered?
  • Is the display cable connected to the correct output port?
  • Is the monitor on the correct input?
  • Did anything change since the system last worked?

The phrase computer is dead is not evidence. It is a user description. Useful, yes. Final, no.

What to carry forward

The first lesson of the course is not "be careful" in a generic way.

It is this:

A technician earns trust by making the system more visible with every step.

That means safe setup, precise language, controlled tests, and documentation that another person can follow.

By the end of this lesson, you should be able to explain why technician work begins with evidence instead of assumptions, identify basic electrical and ESD hazards, describe a safe hardware service area, and turn a vague complaint into specific next questions.

Next we open the machine and start naming the hardware that makes the system work.

Read it. Prove it.

Lesson knowledge checks

Answer from the lesson you just completed. Results stay in this browser and are not submitted.
Knowledge check 1

A user says, ‘The computer is broken.’ What should a technician do first?

Knowledge check 2

Why is documenting the original system state useful before making a change?