A Four-Line Help Note Inspired by a Kyoto Mokumoku Session

On September 5, 2026, around ten people met at Daikoji in Kyoto's Fushimi Ward for MiyakodeIT Mokumoku Session #62. They worked around a large table in a tatami room. Their projects varied: software development, getting started with AI, and hands-on IoT experiments. The event report documents informal conversation alongside focused work.

That setting creates an interesting practical question. If the person next to you is working on a different project, how can you explain a blocker without first reconstructing every detail of your work? The four-line note below is an editorial tool proposed in response to that setting. It was not documented as an activity used by participants at Session #62, and we have not measured whether it improves outcomes.

What gets lost when the question is just “It doesn't work”?

Consider this fictional practice scenario. Someone building a web app asks a neighbour, “My list isn't showing. Any ideas?”

Before suggesting a fix, the neighbour needs to learn what should have appeared, whether the server returned anything, what the developer already checked, and how much help they want. Reconstructing these details can consume the limited time both people have set aside for their own work. This is a plausible challenge in a mixed-project meetup, not an observed incident involving a specific attendee.

Showing the error message alone is not always enough; it may omit the expected outcome. A full work diary creates the opposite problem: too much reading for a short question. We therefore chose four fields that establish the smallest useful shared context.

Rewrite the same question in four lines

This is an example written by the editorial team. The HTTP status and response below are invented teaching values, not data captured at a meetup or from a live system.

Now the other person can begin with a particular question: why is the response empty despite the expected three records? A possible next step is to inspect the source data behind the API. This does not demonstrate that the note reduces debugging time or guarantees a correct diagnosis. It shows, within the constructed example, how making the observations visible changes what can be discussed.

Why these four fields?

The goal is different from the current observation: without the expected outcome, there is no definition of failure. Recording what has been tried discourages repeating the same check. The last field makes clear whether the person wants a five-minute decision or a longer joint debugging session. Four is an editorial choice, not an experimentally proven optimal number.

A note you can copy into your phone

```text

Goal:

Current observation (what I can verify):

What I tried (and the result):

Question (what I'd like to decide in five minutes):

```

Ask whether the other person has five minutes before showing them your screen. Do not expose accounts, API keys or customer information; check what you are allowed to share if this is client work. A mokumoku session is primarily time for independent work, not a promise of on-demand support.

At the end, add a fifth line: “Next step: ____.” Even without a complete fix, it gives you somewhere to resume.

What would count as evidence that the note helps?

At a future session, willing participants could compare a one-sentence request with a four-line note and anonymously record which facts needed clarification and whether a next action was identified within five minutes. This is a suggested study, not a completed experiment. We would need actual observations before claiming an effect on question quality or problem-resolution time.

The Daikoji report confirms a shared table, varied projects and spontaneous conversation. Whether this particular note improves those conversations remains to be tested. For the format and what to bring, see the mokumoku participation guide; find upcoming sessions on the events page.