By Ronnie Mbuqe
Programming turns an intention into explicit steps and conditions. A computer cannot safely infer all the exceptions hidden inside a phrase such as 'give a discount'.
Specify who qualifies, which amount is discounted and what happens at a boundary. Then trace ordinary, missing and extreme inputs before trusting the result.
'Find the cheapest room' leaves the computer with unanswered questions
A cheap room that sleeps two is not a useful answer for four guests. A low nightly rate can also lose its advantage once the complete stay is priced. Before writing code, a programmer must decide what counts as an acceptable answer.
We will turn the vague request into a small rule and follow three candidates. The learning outcome is precise instructions: valid inputs, a comparison and a deliberate response when nothing matches.
Filter for suitability before choosing the smallest total
The teaching rule requires availability and capacity for four guests, then compares complete stay totals. Room A costs R1,000 but sleeps two. Room B costs R1,200 and sleeps four. Room C costs R1,100 and sleeps four, but is unavailable.
A is rejected for capacity; C is rejected for availability. B is the lowest-priced suitable option even though its displayed amount is the largest of the three. The word cheapest only becomes meaningful after the constraints are defined.
If all rooms fail, return a clear no-match outcome. Do not substitute zero as the price, because that can be read as a free room. The rule must also say what happens when two valid options tie.
Which candidate does the stated rule select? Type A, B or C.
This checks a prediction about the worked example. It does not run server code, contact an API or change a booking.
B. Suitability is checked before price. The lowest number among all candidates is not necessarily a valid answer.Read the explanation without the checker
B. Suitability is checked before price. The lowest number among all candidates is not necessarily a valid answer.
Make C available and repeat the decision. Then create a tie and write the extra rule a real program would need.
Why is a precise rule more useful than telling a computer to be sensible?
People fill gaps using context.
Trace the explanation
Programs execute the rules actually specified. Converting a request into conditions exposes missing decisions, such as what to do with an empty field, a repeated request or an unavailable service.
Source and further reading: Microsoft Learn
Practical examples: What Is Programming
Payment
A payment program checks the amount, currency, account, method and response from a payment provider. It must distinguish success, rejection, delay and an unknown result. The difficult case is often not “take payment” but preventing a second charge when a user retries after a slow response.
Booking
A booking program searches availability and then confirms it under changing conditions. Two people may request the final room at nearly the same moment, so the code needs a controlled reservation step instead of trusting an earlier search result.
School
A marks system calculates totals only after checking that subjects, assessments and captured scores are valid. Rules may differ by grade or term. Programming expresses those rules consistently and makes exceptional cases visible instead of leaving every person to calculate differently.
Games
A game loop repeatedly reads player input, updates the world and redraws the result. Rules decide collision, scoring and winning, while timing keeps movement consistent. The player sees action; the program is continuously evaluating state and choosing what happens next.
The instruction 'book the cheapest room' is not precise enough
Cheapest for one night or the whole stay? Before or after taxes? Must it sleep four people? A programmer first turns a vague request into decisions the system can apply consistently. Writing syntax before settling these questions risks automating the wrong meaning.
Take an illustrative rule: return the lowest total price among available rooms that sleep at least four guests. Now a candidate must pass capacity and availability checks before the price comparison. Choosing the smallest nightly figure first could select a room that cannot satisfy the booking.
A delivery rule charges R40 for each of 3 parcels, with no discount. What total should the program return?
Trace the explanation
40 × 3 = R120. Before coding, define whether the charge is per parcel, per order or per destination. The same multiplication can be correct arithmetic but the wrong business rule.
Source and further reading: Microsoft Learn
Why does one successful example prove so little?
An example exercises one path through the rules. Other inputs can take different branches or expose an assumption that was never written down.
A rule that works for a R100 purchase might fail at zero, on a refund or at a discount threshold. Pick cases that challenge the decision, rather than repeating the easiest one.
A program needs a plan for the empty answer
What if no room passes the checks? Returning zero as the price could look like a free stay. Returning a message such as 'no suitable room found' describes a different outcome and lets the interface respond properly.
Try writing three examples before writing code: one suitable room, several suitable rooms, and none. Add a tie in price and decide how it is resolved. These examples reveal missing rules early. The exercise also explains why tests should describe meaningful behaviour, not merely repeat the same calculation in a second place.
If code runs without an error, has it solved the user's problem?
Not necessarily. It may consistently implement the wrong rule. Correct syntax and successful execution do not establish that requirements, units or business assumptions are right.
Questions about What Is Programming?
Is programming only about typing code?
No. A lot of programming is thinking, planning, testing and fixing problems. Most working programmers spend more time reading existing code and tracking down why something broke than they spend typing brand-new lines.
Can beginners learn programming?
Yes. Beginners should start small and use simple examples before moving to bigger projects.
Do I need advanced mathematics to learn programming?
Not for most everyday application development. Logical thinking and patience matter more at the beginning, although some fields such as graphics, cryptography or machine learning use more mathematics.
Which language should a beginner learn first?
Choose a language that matches something you want to build. The fundamental ideas, variables, conditions, loops, functions, data structures and debugging, transfer between languages.
What is debugging?
Debugging is the process of finding why actual behaviour differs from expected behaviour, then locating and fixing the cause instead of only hiding the symptom.
Why do programmers write tests?
Tests capture expected behaviour and can warn a team when a later change accidentally breaks something that used to work.
A tiny program: input, decision, output
Programming is the process of describing steps a computer can execute. The most useful beginner concepts are values, variables, conditions, repetition, functions, and tests. You do not need to memorise every command before building something small; you need to understand what each step is supposed to do.
Example: checking whether a learner passed
mark = 67
if mark >= 50:
result = "Pass"
else:
result = "Try again"
print(result)
The variable mark stores a value. The condition compares it with 50. Exactly one branch runs, and print displays the result. If the mark changes to 49, the program follows the other branch. Testing both sides of the boundary is more useful than testing only 67.
How beginners can reason through a problem
- Write the expected input and output in plain language.
- Work through one example by hand.
- Break the task into steps small enough to explain.
- Translate those steps into code.
- Run normal, boundary, and unexpected-input tests.
- When the result differs from expectation, inspect one assumption at a time.
Why code that runs can still be wrong
A program may execute without crashing and still calculate the wrong answer. For example, if a discount is meant to apply only to orders above R500, using > rather than >= changes what happens for an order of exactly R500. The correct operator depends on the written requirement. Tests should represent the rule, not merely confirm that the code runs.
Build a small project
Try a quiz that asks three questions and counts correct answers, a weekly expense total, or a temperature converter. Start with a clear input and expected output. Add one feature at a time, save working versions, and write down any bug you fix. A small finished project teaches more than a large unfinished one.
Further reading: The official Python tutorial introduces core programming concepts. The example above uses Python-style syntax.
Someone requests a discount for large orders. What questions must be answered before implementation?
One reasoned response
Specify the threshold, eligible products, discount basis, rounding and whether discounts combine. Examples at the boundary often reveal ambiguity better than another paragraph of vague requirements.
Source and further reading: Microsoft Learn
Make the computer's decisions visible
When a program behaves unexpectedly, write down the input, the expected output and the actual output. Then trace the values through the code. This turns “it does not work” into a question you can test. A print statement, debugger or small test case can reveal where the program first diverges from the expected behaviour.
Example: test a boundary
def has_discount(total):
return total >= 500
for amount in [499, 500, 501]:
print(amount, has_discount(amount))
The three test amounts sit just below, exactly on, and just above the threshold. If the requirement says “R500 or more”, all values from R500 upward should qualify. Boundary tests are powerful because mistakes often hide in words such as “at least”, “more than”, “before” and “up to”.
Separate the problem from the language
Before searching for syntax, describe the logic in plain language: what information enters, what rule is applied, and what result should leave. Then translate it into the language you are using. If the task is still confusing in plain language, adding more code is unlikely to help.
As a beginner, practise small programs that you can finish and explain. Save a working version before changing it, test after each meaningful change, and read error messages carefully. The aim is not to avoid all bugs; it is to build a repeatable method for finding and correcting them.
Sources
Sources and further reading
A closer lookA valid date can still break a booking rule
A form accepts a syntactically valid checkout date that falls before check-in. Parsing succeeds, yet the business meaning is invalid.
Work through the distinction
Separate format validation from relationship checks and policy checks. A useful error says what needs changing and preserves other entered fields. Repeat important validation on the server because client-side code can be bypassed.
What remains after successfully parsing both dates?
Choose an answer to see feedback. You can try again.
Show the answer and explanation
Check their order and applicable rules. Separate format validation from relationship checks and policy checks. A useful error says what needs changing and preserves other entered fields. Repeat important validation on the server because client-side code can be bypassed.