V. Anton Spraul - Think Like a Programmer

An Introduction to Creative Problem Solving

V. Anton Spraul

San Francisco

THINK LIKE A PROGRAMMER. Copyright 2012 by V. Anton Spraul.

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

19 18 17 16 5 6 7 8 9

ISBN-10: 1-59327-424-6

ISBN-13: 978-1-59327-424-5

Publisher: William Pollock

Production Editor: Alison Law

Cover Design: Charlie Wylie

Interior Design: Octopod Studios

Developmental Editor: Keith Fancher

Technical Reviewer: Dan Randall

Copyeditor: Julianne Jigour

Compositor: Susan Glinert Stevens

Proofreader: Ward Webber

For information on distribution, translations, or bulk sales, please contact No Starch Press, Inc. directly:

No Starch Press, Inc.

245 8th Street, San Francisco, CA 94103

phone: 1.415.863.9900;

www.nostarch.com

Library of Congress Cataloging-in-Publication Data

Spraul, V. Anton.
Think like a programmer : an introduction to creative problem solving / V. Anton Spraul.
pages cm
ISBN 978-1-59327-424-5 (pbk.) -- ISBN 1-59327-424-6 (pbk.)
1. Computer programming. 2. Creative thinking. 3. Problem solving. I. Title.
QA76.6.S685 2012
005.1--dc23
2012020396

No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The information in this book is distributed on an As Is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

STRATEGIES FOR PROBLEM SOLVING

PURE PUZZLES

SOLVING PROBLEMS WITH ARRAYS

SOLVING PROBLEMS WITH POINTERS AND DYNAMIC MEMORY

SOLVING PROBLEMS WITH CLASSES

SOLVING PROBLEMS WITH RECURSION

SOLVING PROBLEMS WITH CODE REUSE

THINKING LIKE A PROGRAMMER

No book is truly the work of one author, and Ive received lots of help on Think Like a Programmer.

Im grateful to everyone at No Starch Press, especially Keith Fancher and Alison Law, who edited, shaped, and shepherded the book throughout its production. I must also thank Bill Pollock for his decision to sign me up in the first placeI hope he is as pleased with the result as I am. The folks at No Starch have been unfailingly kind and helpful in their correspondence with me. I hope one day to meet them in person and see to what degree they resemble their cartoon avatars on the company website.

Dan Randall did a wonderful job as technical editor. His numerous suggestions beyond the technical review helped me strengthen the manuscript in many areas.

On the home front, the most important people in my life, Mary Beth and Madeline, provided love, support, and enthusiasmand, crucially, time to write.

Finally, to all the students of programming Ive had over the years: Thank you for letting me be your teacher. The techniques and strategies described in this book were developed through our joint efforts. I hope weve made the journey easier for the next generation of programmers.

Do you struggle to write programs, even though you think you understand programming languages? Are you able to read through a chapter in a programming book, nodding your head the whole way, but unable to apply what youve read to your own programs? Are you able to comprehend a program example youve read online, even to the point where you could explain to someone else what each line of the code is doing, yet you feel your brain seize up when faced with a programming task and a blank screen in your text editor?

Youre not alone. I have taught programming for over 15 years, and most of my students would have fit this description at some point in their instruction. We will call the missing skill problem solving, the ability to take a given problem description and write an original program to solve it. Not all programming requires extensive problem solving. If youre just making minor modifications to an existing program, debugging, or adding testing code, the programming may be so mechanical in nature that your creativity is never tested. But all programs require problem solving at some point, and all good programmers can solve problems.

Problem solving is hard. Its true that a few people make it look easythe naturals, the programming worlds equivalent of a gifted athlete, like Michael Jordan. For these select few, high-level ideas are effortlessly translated into source code. To make a Java metaphor, its as if their brains execute Java natively, while the rest of us have to run a virtual machine, interpreting as we go.

Not being a natural isnt fatal to becoming a programmerif it were, the world would have few programmers. Yet Ive seen too many worthy learners struggle too long in frustration. In the worst cases, they give up programming entirely, convinced that they can never be programmers, that the only good programmers are those born with an innate gift.

Why is learning to solve programming problems so hard?

In part, its because problem solving is a different activity from learning programming syntax and therefore uses a different set of mental muscles. Learning programming syntax, reading programs, memorizing elements of an application programming interfacethese are mostly analytical left brain activities. Writing an original program using previously learned tools and skills is a creative right brain activity.

Suppose you need to remove a branch that has fallen into one of the rain gutters on your house, but your ladder isnt quite long enough for you to reach the branch. You head into your garage and look for something, or a combination of things, that will enable you to remove the branch from the gutter. Is there some way to extend the ladder? Is there something you can hold at the top of the ladder to grab or dislodge the branch? Maybe you could just get on the roof from another place and get the branch from above. Thats problem solving, and its a creative activity. Believe it or not, when you design an original program, your mental process is quite similar to that of the person figuring out how to remove the branch from the gutter and quite different from that of a person debugging an existing for loop.