Learning to Build Again

Webdesk began in 1995. This October, working with Codex, I have felt something I recognize from those early days of the Web: the excitement of discovering what I can make, and realizing that ideas I have carried around for years are becoming things I can use.

I began with a practical question. How could I work effectively with Codex across my computers, including the Linux machines where I wanted to develop features and processes? I already had websites and plenty of ideas. I wanted to reshape content, build features I had long wanted, and learn more about what was happening behind the pages.

That question opened into an exciting stretch of making things. Several projects were moving at once, and I was learning how to take part in them.

Give the work a shape

One of the most useful things I learned was to ask Codex to plan in chunks, then be patient while those chunks were completed in sequence.

A chunk gives me something I can understand and check. I can look at what has changed, try an interface, ask questions, and find problems while the work is still fresh. We can repair those problems before moving on. Sometimes a problem suggests another feature worth planning.

This has become a useful rhythm: plan a manageable piece, build it, try it, and let what we learn help shape the next piece. There can be several projects underway, but each one benefits from that rhythm.

Keep a record that can travel

Working across computers made the handoff part of the work itself.

I use an Obsidian vault, synced with Syncthing, to keep Markdown notes that both I and Codex can read. Instructions written on one machine can be opened on another. A handoff can record what happened, what remains, and the boundaries for the next round of work.

One example was a set of Windows acceptance steps for work performed on the Linux web server. That gave me a specific role: go to the other machine, try the work there, and bring back what I found.

The files give us a common record to return to. I can shape a prompt on one computer and carry it to another. I can read an explanation again. A later Codex session can be directed to the decisions and handoff notes it needs to continue.

I am finding that writing things down is part of keeping the work moving.

Discover my part in the making

The biggest surprise was how much I could participate.

Whenever I asked for an explanation, Codex helped me understand more of what was going on. That understanding gave me more ways to contribute. I could respond to an interface, describe what felt awkward, or help decide whether a feature was doing what I wanted.

Being given a role was especially helpful. Something concrete to try or observe made the next conversation better. The best results came through that back-and-forth.

With several projects underway, there were moments when the whole effort felt enormous. In my notebook I wrote that it felt like building New York City must have felt at the beginning of its greatness. That was the scale of the excitement: so many possibilities opening at once, with work actually moving forward.

Learn what to ask next

I am still learning how to ask for features at the beginning. I also want to get better at asking Codex to help me discern what should come next. My next step is to make a larger roadmap across the work, so I can see how the individual projects fit together.

That is where Webdesk belongs in this process. Right now, it is my reference desk for learning Codex. It can give the whole homepage to what I need now. When another subject becomes prominent, the useful material can move to its own page and remain available.

I want to follow my interests, record what I discover, and let a trail of usefulness accumulate. This first story is one piece of that trail.

What I most want to remember about this month is the feeling of possibility. Webdesk began in 1995. It feels good to be learning what I can build here again.