Foreword

With the first Apple ][ it was very important for me to have a manual that would lead others to success and learning right from the get-go, even if the user had no relevant experience. That’s how we learn. We start entering code others wrote to see how it works and then over time we learn variations.

One of my skills has always been designing things with the absolute minimum amount of chips. Before starting Apple, I saw the game of Pong at a bowling alley and I thought it would be fun to try building it on my own. My version didn’t have anything to do with Atari’s, but I did do it at least a year before they came up with a home version of the game that worked with your TV.

All in all, I ended up with 28 chips for my Pong design. This was amazing because it was back in the days before microprocessors appeared. Every bit of the game had to be implemented in wires and small gates. There wasn’t a software program that was loaded and executed, it was all hardwired.

I visited my teenage friend Steve Jobs, who was working at Atari, and showed it to a group of engineers there. And they loved it! Later on, Steve called me to say that Atari wanted to do another Pong-like game. Atari’s founder Nolan Bushnell wanted me to do it because he knew how good I was at doing designs with the fewest possible chips. Nolan had been complaining that the Atari games were going higher and higher in chip count, approaching two hundred chips for a single game. He wanted them to be simpler. And he’d seen how good I was at that.

They wanted a one-player version of Pong, but with bricks that would bounce the ball back to the paddle. It was called Breakout, maybe you remember it? So not even thinking about it, I said, “Sure.” Atari wanted it using the fewest chips possible and I was up for the challenge.

The whole game was implemented in four days and used only 45 chips.

The reason I like this book and agreed to write this foreword is because it carries a message I’ve been holding closely my whole life. It is about simplicity and sophistication. Doing more with less. This recently has become even more important with today’s mobile devices like the Apple iPhone.

Engineers should strive to do things more perfectly than even they think is possible. Every tiny part or line of code has to have a reason, and the approach has to be direct, short and fast. We build small software and hardware components and group them into larger ones. We write tiny bits of code to turn things on and off. Nothing would be elegant or beautiful without the engineer really thinking it out—really thinking about how to create the best possible end result with the fewest number of components or lines of code.

We build upon and build upon and build upon, just like a painter would with colors or a composer would with musical notes. And it’s this reach for perfection—this striving to put everything together, so perfectly, in a way no one has done before—that makes an engineer or anyone else a true artist.

—Steve Wozniak

Get Tap, Move, Shake now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.