There are two things you can do (among others).
- Fixer Upper: Having students finish or repair a program that you create is a useful early exercise. In particular, you can give them a program larger than they would be expected to write themselves. It needs to have excellent design/coding. But you have either removed or carefully broken a few parts before you give it to them. The errors introduced can be quite simple (missing punctuation) or more complex. Their task is to repair it.
The students get to (a) read code (b) see good design (c) interpret compiler diagnostics (d) grapple with structure - assuming the program has some length.
This idea is discussed in the book Pedagogical Patterns: Advice for Educators, where it is called "Fixer Upper". You can use it for program errors other than simple syntax errors.
- Use an IDE that highlights syntax problems. This is actually my main advice. Syntax errors can now be diagnosed by tools so that a programmer needn't spend a lot of mental effort on them; effort that is better spent elsewhere.
There are many such editors, from the simple, say that built in to Greenfoot, to the sophisticated, say Eclipse. Even with forty-five years of programming experience I wouldn't want to have to write with any lesser sort of tools.
Note that in natural language we often make syntax errors (in speaking and writing) and that seldom has an impact on transmission of meaning. Computer languages are picky, of course, but the tools will help you learn. If you correct a lot of errors you will get better at not making them, most likely.
At some point, of course, you would like students to be able to find/fix errors on printouts, or even figure out obfuscated code. But that doesn't need to be their first task. They have enough to do already. So make life easy when you can.
However, if you are going to use a sophisticated editor with novices there are some tricks to get them started. Staring at a blank computer screen is even less productive than searching for syntax errors. To do this requires a lab of some sort and some time for a demonstration. To do the demo I suggest that you pair the students so that there is one student at each computer. They can help one another - and should be encouraged to swap control of the keyboard back and forth as you go. The demo has two parts.
First, you install the software on your own machine whose screen is projected for the class to see. They follow along. Some students will get it faster than others, which is the reason for pairing. Without it you will be stopped too often to help individuals. If you have a assistant who can go around to solve problems as you go, all the better. If the software is already installed on lab machines and they don't need to install it on their own, you still need to do some of this step to get them used to the UI.
Second, you develop some simple program on your machine, demonstrating simple features that they need immediately. In particular, show them what happens when you make a syntax error. Show them how to recognize the highlighting or whatever the system uses. In this part of the demo it is more fruitful if the students don't work along with you step by step. But you do a bit while they watch and ask questions. Then they spend some time, in their pairs, catching up.
Finally, I note that languages with static typing (Java) have tools that can, in principle, provide better guidance than those with dynamic typing (Python, Ruby). Of course, Java has a lot of opportunities for syntax errors, too.