---
title: "I Gave My Desktop a Job Before I Gave It a Phone"
canonical: https://dxdev.com/blog/2026-04-30_i-gave-my-desktop-a-job-before/
datePublished: 2026-04-30
---
# I Gave My Desktop a Job Before I Gave It a Phone

Seven small failures in one morning, and every one of them came from the same gap: the desktop I was typing into had no written idea of what it was for, what it could reach, or what was off limits. A temporary note went into a folder that exists on some computers but not on Windows. A set of instructions tangled itself in quotation marks. A cleanup step refused to run in the order I expected. None of it was dramatic, but it added up to a ticket closed from the wrong machine, because nothing on the page told me which machine I was on.

The work was finished. The change had been sent where it needed to go, the old working copy had been cleaned up, and the ticket showed as done. But the computer I used to close it was not the computer where the main copy of that work lived. I had reached across machines and made it happen anyway.

Nothing blew up. That almost made the problem easier to miss.

What I had really done was ask a computer to act as if it knew its place in the house when nobody had told it. I was treating every open window like the same kitchen drawer. If I reached in and found the right spoon, fine. If I reached in and found a screwdriver, I was supposed to remember why it was there.

First, I tried to keep going the way I always had, using whatever computer and command window was in front of me. That did not work as a dependable way to finish the job. It cost a morning of patience in seven small pieces.

One instruction tried to save a temporary note in a folder that exists on some computers but not on Windows. It failed immediately. Another set of instructions got tangled in quotation marks. A cleanup step refused to go in the order I expected, so I had to undo the order in my head and try again. None of those problems was dramatic. Together, they were like finding three different light switches every time you walk into the same room.

The real issue was not that the computer was bad at following instructions. It was that the instructions had no home. They did not say what this machine was for, what it could reach, or what was off limits.

So I gave the desktop a job description.

I made a fresh home for its working instructions and put four simple things in it: a welcome note, a short file of instructions, a map of the machines I use, and a folder for small helper programs. The important file answered three plain questions before any work began.

What is this computer for? Its job is to help run work, not to store every important note or hold every copy of the code.

What can it reach? It can use the work already on its own hard drive, send changes to the right shared place, and contact one always available computer when that is needed.

What can it not reach? No email. No online file cabinet. No live systems. No paid services unless I have deliberately set up the access.

That last list mattered most. An agent is a computer helper that can follow directions and use tools. A helpful one can still make a mess if it guesses that access exists just because access would be convenient. Giving the helper a written boundary is like putting a labeled key ring by the door. It should not try every key in the building.

I also wrote down which computer has which role. One is for running work. Another holds knowledge. Another stays available when I am away. I did not want the next session to play detective, looking at file names and old notes to guess the map. I wanted it to read one page and know where it was.

Then I gave the written rules some hands.

I created a few small programs for ordinary jobs: keeping track of a session, writing down what happened, and showing the state of the different copies of the work. I kept the instructions in readable files and the repeatable actions in the small programs. That way, when one of the seven problems returns, the fix can live in the process instead of living only in my memory.

One choice was especially important. I normally use a tool that turns long computer answers into short, tidy summaries. It saves attention. But I learned that a pretty summary can be the wrong thing when the helper must check an exact number or a specific line of information. It is like asking someone to read the address on a package, then handing them a postcard that says, "It is going somewhere nearby." For the steps that need to be exact, I used the full answer instead.

Later that day, I gave the desktop a way to be reached from my phone. I used SSH, which is simply a secure way to open a computer from somewhere else. The connection uses my own keys and stays on a private network, rather than leaving a door open to the public internet.

The useful test came during a jog to a store. An approval I had been waiting for arrived while I was out. Before, that would have meant waiting until I got back to the keyboard. Now I could open my phone, connect privately to the desktop, and send the next step there.

The phone was not the important part. The order was. First, I named the computer's job. Then I wrote down what it could and could not do. Only after that did I make it easy to reach from anywhere.

The phone was never the interesting part, because the desktop already had its answers on one page before any key was set up: a job, a short list of what it could reach, and a longer list of what it could not, which was no email, no online file cabinet, no live systems, and no paid services unless I had set them up on purpose. That page is why the ticket I closed from the wrong computer was a one-time morning of seven small failures and not a habit. When the approval arrived during the jog, the only thing I had to decide was the next step, not which machine I was talking to or what it was allowed to touch.