Predict Before You Press Run

The Run button is useful. It is also capable of training a terrible habit: edit randomly, run again, stare at output, repeat until something looks right.

Professional reasoning works in the opposite direction. Make a prediction, then use execution to test the prediction.

Read code as state changes

Consider:

void main() {
    int score = 10;
    IO.println(score);
    score = score + 5;
    IO.println(score);
}

Before running it, trace the variable.

Expected output:

10
15

The line score = score + 5 looks strange if you read = as mathematical equality. In Java assignment, read it operationally:

evaluate the expression on the right
              |
              v
store the resulting value in the variable on the left

The old value can be used to calculate the new value.

Sequence is part of meaning

Compare:

int count = 3;
count = count + 1;
IO.println(count);

with:

int count = 3;
IO.println(count);
count = count + 1;

The same statements appear. Their order changes the observable result.

That means source code is not just a bag of commands. Program state evolves through an ordered execution path.

Trace before running

Predict the final output of each program.

Program A

void main() {
    int x = 2;
    int y = x + 3;
    x = 10;
    IO.println(y);
}

Does changing x later automatically rewrite the value already stored in y?

Program B

void main() {
    String label = "A";
    label = label + "B";
    label = label + "C";
    IO.println(label);
}

Trace the value after every assignment.

Program C

void main() {
    int a = 4;
    int b = a;
    a = 9;
    IO.println(a);
    IO.println(b);
}

This is a useful preview of a larger idea: what exactly gets copied or shared when values and objects are assigned? For primitive integers here, b receives the current integer value. We will revisit reference behavior when objects arrive.

Controlled experiment: one variable at a time

Take Program A and create three versions.

• Version 1: original program.
• Version 2: change only the initial value of x.
• Version 3: restore Version 1, then change only the expression used to create y.

For each version write:

change made:
predicted output:
actual output:
claim supported or rejected:

If two things change at once, a passing output does not tell you which change caused it. This is the same experimental discipline you will use while debugging larger systems.

Output is evidence, not explanation

Suppose a classmate shows you only this output:

5

Can you tell whether the source used 2 + 3, 10 / 2, a variable, a method, or hard-coded text? No.

Output proves something happened. To explain why, you need source, inputs, state, and the path through the program.

Unit evidence

Submit a trace for one program with at least four state changes. Include:

• the source;
• a state table created before execution;
• predicted output;
• actual output;
• one controlled modification;
• one sentence identifying what the experiment proved.

The goal is not to guess correctly every time. The goal is to make your thinking inspectable enough that a wrong prediction becomes useful evidence.