Here's a slightly different piece of advice.
When you get in 100 pages, around the point where you start getting lost and frustrated, stop reading and write some simple programs. Don't do the large projects everyone else is suggesting. Just some simple project euler programs or programming praxis. Writing a program that plays poker is always a good test project, if you can't think of anything.
The reason for doing this is that, for most languages, everything that you want to write can be written with what you learned in the first hundred pages. You'll know how to declare a variable, write a function, and implement flow control. You don't need to know more.
However, the code you're going to write will be really crappy. That's the point. If you're like me, that part of the book where you're getting stuck is when they start introducing language features to solve problems that you've never had. For instance, like many people first learning Haskell, I kept getting stuck on Monads. I eventually gave up and just started trying to write Haskell without them. I could write code, but certain sections were very tedious and ugly. I got tired of writing the same ugly boilerplate over and over again and checked the documentation to see if there was anything to help. Lo and behold, monads eliminated that boilerplate and I could now understand where the author was coming from.
I'm guessing that, depending on what language you're studying, you're getting lost somewhere around classes, macros, monads, or namespaces. Whatever it is, just write some code without it. I'd argue against picking a big project for yourself, since you'll be subconsciously guided by what you know how to implement. Instead, take a small list of test projects and complete several of them. This lets you learn the language well enough to find the ugly points. Then go back to reading and I bet the advanced capabilities, which remove those ugly bits, will make much more sense.