Prepare a small bug example for a Singapore developer clinic

The problem

A junior developer in Singapore wants debugging help, but explaining the entire application uses the session before anyone can reproduce the failure.

Write the symptom and its expected behaviour separately

Choose one observable problem before collecting the whole application. Use six entries: permitted input; starting condition; actions taken; expected behaviour and its basis; observed behaviour; and the condition still uncertain. A requirement you have not established belongs in the uncertain entry. “The screen changed” needs the actual before-and-after observation; “the framework is broken” is a proposed explanation. Keep the symptom, your explanation and the evidence for each apart. Include the example revision and relevant environment with the note so another person knows which attempt you describe. Check the actual API outcome, pagination and dataset identity separately when any of those defines the expected behaviour. Here the task is making one symptom inspectable, without assuming its cause or requiring peers to reconstruct every feature.

Choose a material route you can actually use

Read what the session accepts before preparing a repository link, upload or screen share. Use an authorised extract under its actual conditions or create a genuinely independent fictional example. Removing names does not establish permission to share the remaining code, records, credentials or surrounding screen. Record which parts are supplied, omitted or illustrative. If the replacement changes the behaviour, say so rather than calling it equivalent to the original. Data.gov.sg’s retained API overview distinguishes real-time APIs from collection and dataset access, including metadata; a public practice interface can provide permitted learning context without reproducing a customer system. This guide prescribes no dataset, live request or account. A public interface also does not make unrelated private material shareable.

• Data.gov.sg API overview ↗ · Source checked 20 October 2026

Reduce one part and check whether the symptom remains

Remove an unrelated part, repeat the stated actions and record what happened. Keep the last example that still exhibits the symptom and identify what changed in the next version. If removing a component also changes the input, starting state or expected behaviour, those are separate differences that need explanation. Reduction can make a question clearer without proving that the removed component caused the failure. Keep a small ledger: example version; part removed or replaced; actions repeated; observation; and whether the original symptom remains. A stand-alone example may need a supplied dependency or permitted local service; “small” does not mean everything must fit in one file. Stop when further removal changes the question or the remaining part is outside the material you may use.

Work through a wholly invented replay

Every interface, value and observation in this case is fictional. A practice screen starts with view Alpha selected. The supplied practice requirement says a chosen view should remain selected when its details panel is closed and reopened within the same session. The learner chooses Beta, opens its details, closes the panel and reopens it. The observed label is now Alpha, although the expected label is Beta. A first opening before any choice correctly shows Alpha; that is a different starting condition. The learner prepares a smaller screen retaining only the selector and panel, repeats the four actions and records the same Beta-to-Alpha symptom. That gives the fictional record a reduced replay. It identifies neither the faulty function nor a library defect, and supplies no result from a real application.

Use the replay to ask a diagnostic question

Continue the invented case with two explanations still open: the selection might change when the panel closes, or the panel might read a different value when it reopens. The visible Alpha label alone does not choose between them. A proposed next check is to inspect the permitted selection record immediately before closing and again before reopening, keeping the actions and version fixed. Until that inspection occurs, it is a plan. If a fictional observation later says the record remains Beta at both points, that narrows the selection-change question while leaving the panel’s reading path to examine. It does not establish the cause of the real bug or demonstrate a repair. Ask a peer which observation would distinguish the explanations, rather than requesting a confident diagnosis from an unexplained screenshot.

Prepare the environment needed for this example

Keep the actual instructions that let another person inspect or repeat your example: relevant language or application version; permitted installation steps; starting command or action; input; and observed output. State any dependency or account that remains unavailable. Ask the organiser which preparation must be complete before arrival and whether the session offers installation help, supplied equipment or only discussion. A laptop line supplies no version, account or support arrangement by itself. Use the setup you are permitted to change; a workshop registration does not authorise installing tools on a managed device. If your example cannot run in the offered environment, ask whether a diagram or recorded observation is accepted for a diagnostic discussion. Such an alternative describes the question without becoming a completed reproduction.

Check the clinic’s offered help with one unsent enquiry

A focused enquiry could say: “I have a permitted reduced example with these starting actions, expected label and observed label. Can this session inspect that replay or help choose the next diagnostic check? Which setup and submission instructions apply?” Adapt it to the advertised route and omit material that the route does not accept. SGInnovate’s retained directory categories are technical discovery context, not evidence of a beginner clinic or allocated troubleshooting time. In a wholly fictional reply, a host accepts a diagram for discussion but offers no participant execution. That can support asking about a check; it leaves a runnable review unprovided. Keep admission, allowed material and diagnostic activity as separate answers. Do not send a full private repository because the topic seems relevant.

• SGInnovate events directory ↗ · Source checked 20 October 2026

Retain the proposed check and the observation actually obtained

After a permitted exchange, write the explanation being examined, one change or observation proposed, the result actually obtained and the remaining limit. Keep an unperformed suggestion unperformed. If you change a condition, repeat the recorded starting actions and compare the result with the earlier version before calling the symptom absent. An absent symptom in a changed example does not by itself establish a repaired original application. Use the test-boundary companion when the question becomes which behaviour a proposed change should protect. Use Boardzip’s free developer search for a format that addresses the remaining diagnostic question, then verify the particular session. A clear reproduction, an identified cause, a proposed fix and a checked change are separate outcomes; an event conversation can help one without delivering all four.