Optimization Problem

Hello, I am a newbie when it comes to the Arduino platform. As being such, I have started to play around with some of the basics. One thing I cannot seem to get past is what seems like variables getting optimized out. For example see the code below. The program works just fine when the serial.println is on-commented but fails with them commented out. I am essentially trying to make a state machine using the inputs from the serial port as to where I should go and what to do. I thought about using a switch case but since only 1 byte can be read in from the serial port, I thought this may be a better choice. I am sure there is a way around this, or maybe I am just using bad coding practices. Any help would be great.

#define _BELL 13

int head = 0;
int data = 0;
void setup(){
Serial.begin(9600);
pinMode(_BELL ,OUTPUT);
}

void loop(){

if (Serial.available() > 0){
head = Serial.read();
//Serial.println((char)head);
if(head == 'T'){
data = Serial.read();
//Serial.println((char)data);
if (data == 'H'){
digitalWrite(_BELL,HIGH);
}
if (data == 'L'){
digitalWrite(_BELL,LOW);
}
}
}
}

Try to insert a short delay, if that fixes it the option is to change (Serial.available() > 0) to (Serial.available() == 2)

Well this is very strange. Both solutions on their own have fixed the problem. Would anyone be able to explain why this fixed the problem? I really hate to use delays so I will experiment with checking to see if the exact number of bytes I need have arrived. I am really just trying to do a simple example of serial communications.

The code is too fast, so this not an optimization problem really (not optimizing of your code anyways).

When you see code like:
a = Serial.read();
b = Serial.read();

You should always be sure that two chars are available at the serial.

When you check that you have one char, and immediately skip to reading one, then another (which you have not checked for) you depend on the serial being timed in sync with your code. Such conditions and problems are often referred to as 'race conditions' because the serial and your code are racing to get done first.

If you're operating on 9600 baud, a couple of ifs will always be faster.