Getting better

Skill with these tools builds the same way skill with anything builds: small, repeated, slightly too hard, and checked. What follows is a ladder rather than a curriculum, so you can see where you are and what the next rung looks like.

The loop

From the second session of the workshop, and worth keeping as a habit rather than a diagram:

Plan → Build → Test → Document → Iterate

• Plan: agree what you are making, and what you are not making, before anyone writes anything.
• Build: the smallest version that could possibly be useful.
• Test: run it yourself, with real input, and try to break it.
• Document: five lines that let you or someone else pick it up again.
• Iterate: go back to the plan with what you learned, which is usually that the problem was smaller than you thought.

Small, steady cycles lead to better tools, deeper research, and real-world impact. Large, occasional pushes lead to folders of abandoned work.

The ladder

Six levels, each with something concrete to try this week. Most people are on two of them at once, which is normal.

1. Using it as a better search box

   You ask questions, get explanations, and use it for drafting and summarizing. This is where everyone starts, and it is genuinely useful.

   Try this week: ask it something you already half know the answer to, then check every claim against the original source. You are practising checking, not asking.

2. Changing something that already exists

   You take a document, a spreadsheet, or a small script you already use and get one improvement made to it. Copy it first; keep the original.

   Try this week: pick the spreadsheet you rebuild every month and ask for the one step in it that annoys you most to be automated.

3. Building a small tool that only you use

   Something that runs, that you use, that nobody else knows about. This is the level where the loop becomes real, because you will be the one who notices when it breaks.

   Try this week: one of the three first projects on the Start here page, finished badly, this week.

4. Making something useful to someone else

   The moment another person uses it, everything gets harder and much more interesting: their input is different from yours, and they will do things you did not imagine.

   Try this week: give your tool to one colleague. Watch them use it without your instructions. Write down the two things they did that you did not expect.

5. Making something dependable

   You know how it fails, what it does with bad input, where the data goes, who can change it, and how to get back to a working version. This is where checking the work stops being an exercise and becomes the job.

   Try this week: write down five cases it should handle. Test all five. Add sensible messages for the ones it fails. Write the runbook, which is one page saying how to run it and what to do when it stops.

6. Building on work that already exists

   Rather than starting from zero, you take an open-source project or an existing dataset and adapt it. This is faster, and it connects you to people who have already solved part of your problem. The workshop's point about open source belongs here: you rarely need to reinvent the wheel.

   Try this week: find one open project close to your problem. Read its documentation. Send one real question, or report one thing that was wrong or missing. That is participation, and it is how these projects stay alive.

What practice actually looks like

• One small project at a time. If it will take more than a week, cut it in half and do the first half.
• Keep a log. The same four lines from the test note: what I tried, what I expected, what happened, what is next. This is also how you notice your own progress.
• Keep the failures. The experiment that did not work is the piece you will reuse next year, if you can find it.
• Read the plan, not only the code. Understanding the shape of the solution is what lets you tell when it is wrong.
• Ask one better question each week. The Discord thread where you asked something vague in month one becomes the thread where you answer someone else in month three.
• Teach one thing you learned. Explaining it to a colleague is where understanding actually lands, and it is the fastest way to find the part you only thought you understood.

Signs you are getting better

Useful to be able to see, because the feeling of progress lags behind the reality of it.

• Your prompts got shorter, and work better.
• You can predict which parts it will get wrong before you run anything.
• You fix small breakages yourself instead of starting over.
• You have a folder of tools you use, not just a folder of experiments.
• You can say clearly what your tool does not do.
• You check before you get excited, not after.

When you are stuck

1. Cut the problem in half again. Most "stuck" is "too big", and the smaller version is usually still useful.
2. Say the problem out loud to someone. The Future Herd Discord, a colleague, anyone. Naming it precisely is often the whole fix.
3. Go back one step in the loop. If building is stuck, the plan is wrong. If the plan is stuck, the problem is not defined yet.
4. Look it up on the reference shelf. Which layer are you changing is the question that most often ends a stuck afternoon.