When I read that chapter of the book I was super struck, because I've been doing this kind of thing intuitively for many many years without knowing it was even a thing.
It goes like this: instead of building software parts independently to completion, you start by building just the bare bones: classes, functions and other things you will need, define the interfaces early and connect those parts. At this point classes have empty methods and sometimes return dummy data.
Then I go from the bottom up, fleshing out the methods, and I can start to see some end results from the outside.
It may seem like it's poor's man TDD (verifying your code as you write it, but without actually writing tests).
But one advance of this technique is, that you can put the architecture to test early in the development. I have discovered many design issues this way.
Without this "tracing bullet", I have seen things like this happen: team discusses design on the whiteboard, and after a rough UML concept, each developer goes on to write a separate part of the system.
After the first pieces are completed, issues arise when trying to make parts play together, some situations where not considered, the design is not flexible enough to cover all cases. Heavy refactoring of freshly written code ensues.
Real world example: you want to write a web shop. You make a rough sketch of your design. It'll have a few models: User, ShoppingCart, Product. Also a few controllers and views. In your empty controller, you create some dummy instances of your models. Make them interact, and put the result in the view. The view shows some unstyled cart info. And voilà, you've got a tracing bullet. You've got the most interesting bits of the application sketched and connected. Now you can start fleshing out your models, controllers and views and see the progress in the browser.