Troubleshooting on Work You Can Explain

Emergency Triage for Broken Assignments and Files

Wed, 19 Aug 2026 00:00:00 -0500

When an assignment file disappears or stops opening, your first job is not to fix it. Your first job is to preserve what still exists and understand the situation well enough to choose a safe next step.

Do not keep editing the only copy. Do not reinstall software because one file failed. Do not run a destructive command because an AI assistant suggested it. Make a protected copy, write down the facts, and work from the copy.

Recovering Git History and Lost Code

Wed, 19 Aug 2026 00:00:00 -0500

Git may be able to recover code that disappeared from your current branch, but recovery begins with inspection. A reflog records local movements of references such as HEAD; it does not guarantee that every file or commit still exists, and it is not a substitute for a remote or tested backup.

The safe pattern is: protect the repository, inspect history, create a recovery reference, compare the candidate, and restore only after verification.

Inspect Linux Services, Processes, and Logs

Thu, 30 Jul 2026 00:00:00 -0500

Inspect before you restart, kill, enable, disable, or reconfigure anything. A process is a running program instance. A service manager may supervise one or more processes. A log is a record emitted by the kernel, service, or application. These are related evidence, not interchangeable objects.

This walkthrough assumes a systemd-based distribution for service and journal examples. Many current Debian, Ubuntu, Fedora, and RHEL-family installations use systemd, but containers, WSL environments, embedded systems, and other distributions may not run it as the system manager.

Recover Linux from a Broken Setup

Thu, 30 Jul 2026 00:00:00 -0500

Prepare recovery before Linux stops booting, but do not break or reinstall a working computer for practice. Rehearse the evidence and access paths: identify the failure layer, verify backups by restoring a test file, verify recovery media and documentation, clone a project into a new location, and test the setup repository in a disposable environment.

Before treating a backup as recovery evidence, use your backup is only real if you can restore it to test one file restore and record what the test proves.

Set Up Linux Users, Groups, and sudo Safely

Thu, 30 Jul 2026 00:00:00 -0500

Use a normal user account for daily work and elevate only a command you understand. Linux identifies processes and files with user and group IDs. sudo can authorize a user to run a command as another identity, commonly root; it does not make an unfamiliar command safe.

Account tools, administrative groups, and initial-install behavior vary by distribution. Inspect the installed system and its official documentation before adding users, changing groups, or editing sudo policy.

Understand Linux Filesystem Permissions

Thu, 30 Jul 2026 00:00:00 -0500

Linux filesystem access begins with identity, ownership, and mode bits. For a given file, the system selects the owner, group, or other permission class and checks the requested operation. Directories use the same r, w, and x letters, but their effects differ from regular files.

Learn to inspect this model before changing it. Do not respond to “Permission denied” with sudo or chmod 777.

Read a long listing

In a folder you own, run:

`git status` and `git diff`: Your Safety Instruments

Fri, 24 Jul 2026 00:00:00 -0500

Run git status and git diff before committing, switching tasks, or accepting an AI-generated edit. They answer different questions: status summarizes file states; diff shows the content changes behind those states.

Read status as an inventory

The official git status documentation states that it reports differences between HEAD and the index, between the index and working tree, and untracked files not excluded by ignore rules.

In practical terms:

untracked means the file is present but not in Git’s index;
modified, not staged means the working copy differs from the index;
staged means the index contains a change proposed for the next commit; and
clean means Git sees no tracked or untracked change to report under the current rules.

Clean does not mean correct, tested, backed up, or pushed.

Inspect Before You Change

Fri, 24 Jul 2026 00:00:00 -0500

Before a command changes files, configuration, or project state, use read-only operations to establish what exists. State the expected result, make one small change, and inspect again.

This inspect–change–verify sequence turns command-line work into an observable experiment. It complements rollback planning: inspection tells you what changed; a checkpoint gives you a path back.

Ask a state question first

Do not begin with “Which command fixes this?” Begin with a question:

Prefer Reversible Changes

Fri, 24 Jul 2026 00:00:00 -0500

A technical change is safer when you can explain the starting state, predict the intended result, and return to the starting state if the evidence does not match your prediction.

Prefer reversible changes. Inspect first, protect important work, change one thing, verify the result, and keep a clear rollback path. This method does not make every action harmless, but it limits uncertainty and makes mistakes easier to diagnose.

Reversibility is a property of the procedure

A change is not reversible merely because an Undo button exists. A reversible procedure answers six questions:

Terminal, Shell, and Command: Three Different Things

Fri, 24 Jul 2026 00:00:00 -0500

A terminal, a shell, and a command are different parts of one interaction. The terminal provides the text interface. The shell reads and interprets what you enter. A command performs a specific operation. This model helps you diagnose problems across Windows, macOS, and Linux.

The three-part model

Imagine entering this in a terminal:

python --version

Three components participate:

Terminal application: displays the prompt, accepts keyboard input, and shows text output.
Shell: reads the command line, identifies what should run, and connects input and output.
Command: python performs the requested operation; --version asks it to report version information.

Closing a terminal window, changing the shell, and installing a command are therefore different actions.

Your First Merge Conflict Should Be Deliberate

Fri, 24 Jul 2026 00:00:00 -0500

A merge conflict is Git asking a person to decide how overlapping changes should combine. Practice once in a disposable repository, with a clean working tree, before deadlines or team work make the decision stressful.

Create a controlled conflict

Use a new practice repository with no important files. Commands assume a recent Git installation and a default branch named main; adjust the branch name only if your repository uses another one.

Start a Working Log Before You Change Anything

Thu, 23 Jul 2026 00:00:00 -0500

You install a program, change two settings, copy a command from an AI assistant, and finally get an assignment to run. A week later, the same project fails. You remember the general idea, but not the directory, command, error, or setting that mattered.

This is normal. Human memory is not a reliable record of technical work. Start a working log before you change the computer. Your first entry can be one short paragraph. Add more structure only when the work produces details worth preserving.

The Student Should Own the System

Thu, 23 Jul 2026 00:00:00 -0500

A parent can configure a laptop faster than a student who has never done it. A technical friend can fix an error faster than they can explain it. Those shortcuts solve the immediate problem, but repeated shortcuts create a system the student cannot maintain.

The student should own the system. Parents and mentors should provide safety, structure, and guidance while transferring routine responsibility.

Ownership is demonstrated through action

Paying for a computer or knowing its password does not establish practical ownership. A student owns the system when they can make informed routine decisions, perform common tasks, and recover from ordinary problems.