A place to build one thing

By Code from zero · myAudience

myAudience · AI-generated original illustration · Original AI-generated illustration; not documentary evidence; no third-party artwork reproduced.

A small program becomes easier to build when its behavior can be stated independently of its screen. Identify the inputs, the output and the rule connecting them. For a booking cost, hours might be an input and money an output. A function can calculate that result while a separate interface collects and displays values.

Data needs both a value and a meaning. The number 3 could represent hours, people or a currency amount. Name the unit and validate the permitted range. A text field may deliver a string rather than a number, so converting and checking input is part of the boundary, not a detail to leave to chance.

Separate calculation from side effects. A function that receives valid hours and returns a cost is easier to test than one that also edits the screen, saves an account and sends a message. Keeping those actions separate helps reveal whether a defect is in the rule, the input handling or the presentation.

Worked example: an original pricing rule is cost = 5 + 8 × hours. At zero hours it returns 5, at three hours 29, and at half an hour 9. Whether charging a fixed fee for zero hours makes sense is a product decision, not a mathematical error. Check: what should happen for −2 hours? The input should be rejected if the allowed range is nonnegative, rather than displaying a negative booking price.

The workstation is generated art, not a working application. Before adding more features, write down normal, boundary and invalid cases, including the expected error behavior. Passing a few examples does not prove every property, but clear cases make a small rule reviewable and prevent an attractive interface from hiding undefined behavior.

Image: illustration, not a documentary photograph.