BUG Riddle Answer: The Uninvited Guest in Your Code, Explained

The riddle:

Main bina bulaye tumhare code mein ghus jaata hu. Raat bhar tumhe jagaata hu. Aur jab tum mujhe dhoondh lete ho, tum khush hokar so jaate ho. Bata kya hu?

Answer: BUG. In programming, a bug is a mistake or defect that makes a program behave differently from what it should do. It may give a wrong answer, crash, or fail only for a particular input. It is not a real insect living inside your code.

The riddle turns a familiar coding problem into a character: an unwanted guest who keeps you busy until you find the mistake. Here is what each line means, followed by a tiny proof you can run.

Line 1: "Main bina bulaye tumhare code mein ghus jaata hu"

"I enter your code without being invited." Nobody deliberately asks for a wrong result. A typo, a wrong condition, a missing case or a mistaken assumption can create a bug while you are writing a program.

The "entering" part is a metaphor. A bug does not need to arrive from outside your computer. You can introduce one yourself by writing code that looks reasonable but does the wrong thing. A program can run without showing an error message and still contain a bug.

Line 2: "Raat bhar tumhe jagaata hu"

"I keep you awake all night." Finding the cause can take longer than spotting the symptom. You might see an incorrect total, but the mistake may be in an earlier calculation. A problem that happens only for one input can be especially hard to reproduce.

This line describes the frustration, not a rule that good programmers should lose sleep. Debugging means finding and fixing the cause. Save a small failing example, compare the expected result with the actual result, and check one step at a time. A break can help more than changing random lines.

Line 3: "Aur jab tum mujhe dhoondh lete ho, tum khush hokar so jaate ho"

"When you find me, you happily go to sleep." That is the relief of understanding why the code failed. But finding a suspicious line is not the same as proving the repair works. Re-run the failing input after the fix, then test nearby cases too.

For example, if a boundary condition failed at score 100, also try 99 and 101. Keep the failing case as a test so a later change does not bring the same mistake back. Passing a few tests is useful evidence, not proof that every possible bug is gone.

Tiny JavaScript proof: one equals sign changes the result

Suppose the requirement is: print "Perfect score" only when the score is exactly 100. This version starts with score 60:

let score = 60;
if (score = 100) {
  console.log('Perfect score');
}
console.log(score);

Actual output:

Perfect score
100

Why is that wrong? score = 100 is assignment, not an equality check. It changes score to 100. The assignment expression also produces the value 100, which is truthy, so the if body runs. There is no JavaScript syntax error here. The code runs, but it breaks our requirement.

Use === for a strict equality comparison in this example:

let score = 60;
if (score === 100) {
  console.log('Perfect score');
} else {
  console.log('Not a perfect score');
}
console.log(score);

Output after the fix:

Not a perfect score
60

Now the comparison does not overwrite the score. The original value stays 60. In JavaScript, = assigns, === compares without type conversion, and == compares with type-conversion rules. Do not copy this exact rule blindly into another language: operators and allowed conditions depend on that language.

Check the repair, not just the happy case

Starting score	Buggy version: message / final score	Fixed version: message / final score
60	Perfect score / 100	Not a perfect score / 60
99	Perfect score / 100	Not a perfect score / 99
100	Perfect score / 100	Perfect score / 100
101	Perfect score / 100	Not a perfect score / 101

At 100, the buggy version appears correct. That single test would hide the mistake. At the other three inputs, it prints the wrong message and overwrites the input. These outputs were run in Node.js before publication; the fixed comparison was also checked for every integer score from 0 through 120.

Bug, error message and debugging: do not mix them up

A bug is the underlying defect. An error message is something a tool or running program reports. Some bugs produce messages; other bugs produce believable but incorrect output. Debugging is the work of finding the cause and fixing it.

In Python, the official tutorial separates syntax errors from exceptions raised during execution. A wrong formula can produce a wrong answer without either kind of message. The JavaScript example above is also a wrong-behavior bug, not a syntax error.

Debugging map: from symptom to a tested repair

Requirement: numeric score exactly 100
                  |
        Reproduce with score 60
                  |
     Expected: not perfect; still 60
     Actual: perfect; score became 100
                  |
       Inspect condition score = 100
                  |
     Assignment -> value 100 -> truthy
                  |
       Fix condition score === 100
                  |
     Re-run 60, 99, 100, 101 and keep test
                  |
      Check message AND preserved input

The changed score is a second symptom. Checking only the printed message would miss accidental mutation in another version of this program. Reduce the failure to a small example before changing unrelated code.

Trace the condition before the branch

Step	Assignment version	Strict-comparison version
Start	score is numeric 60	score is numeric 60
Evaluate condition	Write 100 into score; expression value is 100	Compare 60 and 100; expression value is false
Select branch	100 is truthy, so take perfect branch	false selects the not-perfect branch
After branch	score is 100: original input lost	score is 60: original input preserved

A repeatable regression lab

Run this standalone script with Node.js. It checks every integer from 0 through 120, both the message and preserved score. The requirement here is numeric equality, not input validation. The string "100" is deliberately different from the number 100.

function buggy(input) {
  let score = input;
  const message = (score = 100) ? 'Perfect score' : 'Not a perfect score';
  return {message, score};
}
function fixed(input) {
  let score = input;
  const message = (score === 100) ? 'Perfect score' : 'Not a perfect score';
  return {message, score};
}
let mismatches = 0;
for (let input = 0; input <= 120; input++) {
  const got = fixed(input);
  const expected = input === 100 ? 'Perfect score' : 'Not a perfect score';
  if (got.message !== expected || got.score !== input) throw new Error('Failed: ' + input);
  const bad = buggy(input);
  if (bad.message !== expected || bad.score !== input) mismatches++;
}
console.log('Fixed integer cases passed: 121');
console.log('Buggy integer cases failed: ' + mismatches);
for (const input of [99, 100, 101, '100']) {
  const got = fixed(input);
  console.log(JSON.stringify(input) + ' -> ' + got.message + '; preserved=' + Object.is(got.score, input));
}

Executed output:

Fixed integer cases passed: 121
Buggy integer cases failed: 120
99 -> Not a perfect score; preserved=true
100 -> Perfect score; preserved=true
101 -> Not a perfect score; preserved=true
"100" -> Not a perfect score; preserved=true

Exam checks: cause, evidence and limits

Why do 120 buggy cases fail, rather than 121? At numeric input 100, assigning 100 happens to leave the value and expected message correct. That happy case conceals the defect.

Why check both message and score? The contract has two parts: print the right message and avoid changing the input. A test of only one part cannot establish the other.

Should string "100" be accepted? Not under this numeric-equality contract. If a form supplies text, define and test validation and conversion separately; changing === to == is not a substitute for a specified input policy.

Do 121 passing cases prove the entire program bug-free? No. They establish this contract for these inputs. Strings, missing values, floating-point values and surrounding application behavior need their own requirements and tests.

What is a regression test? A saved check of expected behavior that can catch a later change reintroducing the failure. Keep the small score-60 case even after the larger sweep passes.

Quick questions and answers

What is the answer to the riddle?
BUG: an unwanted mistake in a program.

Can code run successfully and still have a bug?
Yes. The assignment example runs but changes score and prints the wrong message.

Does finding the bug finish the job?
No. Fix it, re-run the failing case, and test other relevant inputs.

Why should we keep a test for the failing case?
It helps catch the same wrong behavior if a future change brings it back.

Practice: In the buggy version, start with score 0. What gets printed and what is score afterward? Answer: "Perfect score", then 100. Assignment overwrites 0 before the condition is checked. The fixed version prints "Not a perfect score", then 0.

Try the code in your JavaScript runtime. For another riddle with a tested trace, read the Stack riddle answer: plates, undo and LIFO. For more worked coding lessons, use the DSA series index.

Sources: MDN: assignment; MDN: strict equality; Python: errors and exceptions. The explanation and worked tests here are original.