Slashdot Mirror
Book Review: Think Like a Programmer
MassDosage writes "After nearly 15 years or of writing code professionally it was refreshing to take a figurative step back and read a book aimed at people getting started with computer programming. As the title suggests, Think Like A Programmer tries to get to the core of the special way that good programmers think and how, when faced with large and complex problems, they successfully churn out software to solve these challenges in elegant and creative ways. The author has taught computer science for about as long as I've been programming and this shows in his writing. He has clearly seen a lot of different people progress from newbie programmers to craftsmen (and craftswomen) and has managed to distill a lot of what makes this possible in what is a clear, well-written and insightful book." Read below for the rest of Mass Dosage's review.
Think Like A Programmer
author
V. Anton Spraul
pages
256
publisher
No Starch Press
rating
8/10
reviewer
Mass Dosage
ISBN
978-1-59327-424-5
summary
An Introduction to Creative Problem Solving
Think Like A Programmer is probably best read by those with at least a year's experience with programming, such as first or second year computer science students or those picking up programming on their own. The code examples in the book are all written in C++ so a basic knowledge of C++ syntax is required but this should be easy to pick up by anyone with familiarity with related or similar languages. Experienced programmers looking to brush up on their fundamentals will most likely find something useful here too. They probably do a lot of what is suggested here already without being aware of it but it can be encouraging to see this formalized in a book. I found it gratifying to see that some of the techniques I use daily were covered here — it's good to know that I'm not the only one who scrawls down funny diagrams and sketches out a rough plan before actually typing any code.
Different types of problem solving are discussed in separate chapters which cover the use of data structures, pointers, recursion and code libraries before wrapping up with a final chapter that brings all the previous approaches together. The book is intended to be read in its entirety with later chapters making frequent references to topics covered earlier. Think Like A Programmer is not a cheat sheet or cook book with quick fixes but a more substantive book that rewards those who read it as thoroughly as it has been written. Each chapter contains a few examples which are used to explain the topic under discussion and these have been well chosen to illustrate the key concepts. A series of exercises are also included which build on and extend each chapter. The author stresses that if the reader really wants to learn something and improve their problem solving skills then these exercises should be considered even more important than the text. The best way to learn how to program is by doing and the exercises force one to put what one has just learned into practise. The first few exercises at the end of a chapter are relatively simple and are basically variations on the examples that help the reader build confidence before moving into more challenging and tricky exercises that push one to apply one's recently acquired knowledge to new limits.
Throughout the book everything is explained in a good level of detail and enough background information is provided so that the reader should never feel out of their depth. The pros and cons of the various presented solutions are clearly weighed up with logical backing. The author is obviously very knowledgeable and experienced with teaching hard concepts to new learners and this shows in his no-nonsense, down-to-earth but enjoyable writing style. The code samples are clear and well thought out as are the diagrams that accompany the various examples. The chapter on classes was the only one where I felt like focus was being lost due to too many C++ implementation details but perhaps that's just the nature of the language. I would have liked the example here to show more clearly how classes can turn a morass of functional code into something more logically grouped and easier to understand. To be fair, the exercises at the end of this chapter do ask one to do this by asking one to convert a collection of string utility functions into a more logically organized string class. This again shows the importance of actually doing the exercises and not just simply reading them.
The core idea of how programmers take a complex problem and then break this down into smaller, more manageable and solvable parts is well described. The importance of having a plan before jumping in and writing code without thinking is stressed and there are great suggestions for how to take stock of your own personal strengths and weaknesses and come up with a personal plan that works for you. The example is given of someone who likes jumping right into coding — for someone like this it probably makes sense for them to do early prototyping as a way to start solving a particular problem, as long as the longer term plan involves taking a step away from this and incorporating the lessons learned into a more thoroughly thought out solution later. In this, as in the rest of the book, the author shows his years of experience teaching a wide range of people with different skill sets and approaches to problem solving. There is no single way to think like a programmer, but rather a number of tried and tested strategies that can be employed in various ways. Think Like A Programmer captures this core idea in an satisfying, down to earth manner and I can highly recommend it to anyone wanting to improve their problem solving capabilities. I wish I had had this book when I started studying computer science — the fundamentals contained here would have been a valued addition to the text books teaching syntax and specific technologies.
You can purchase Think Like A Programmer from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Different types of problem solving are discussed in separate chapters which cover the use of data structures, pointers, recursion and code libraries before wrapping up with a final chapter that brings all the previous approaches together. The book is intended to be read in its entirety with later chapters making frequent references to topics covered earlier. Think Like A Programmer is not a cheat sheet or cook book with quick fixes but a more substantive book that rewards those who read it as thoroughly as it has been written. Each chapter contains a few examples which are used to explain the topic under discussion and these have been well chosen to illustrate the key concepts. A series of exercises are also included which build on and extend each chapter. The author stresses that if the reader really wants to learn something and improve their problem solving skills then these exercises should be considered even more important than the text. The best way to learn how to program is by doing and the exercises force one to put what one has just learned into practise. The first few exercises at the end of a chapter are relatively simple and are basically variations on the examples that help the reader build confidence before moving into more challenging and tricky exercises that push one to apply one's recently acquired knowledge to new limits.
Throughout the book everything is explained in a good level of detail and enough background information is provided so that the reader should never feel out of their depth. The pros and cons of the various presented solutions are clearly weighed up with logical backing. The author is obviously very knowledgeable and experienced with teaching hard concepts to new learners and this shows in his no-nonsense, down-to-earth but enjoyable writing style. The code samples are clear and well thought out as are the diagrams that accompany the various examples. The chapter on classes was the only one where I felt like focus was being lost due to too many C++ implementation details but perhaps that's just the nature of the language. I would have liked the example here to show more clearly how classes can turn a morass of functional code into something more logically grouped and easier to understand. To be fair, the exercises at the end of this chapter do ask one to do this by asking one to convert a collection of string utility functions into a more logically organized string class. This again shows the importance of actually doing the exercises and not just simply reading them.
The core idea of how programmers take a complex problem and then break this down into smaller, more manageable and solvable parts is well described. The importance of having a plan before jumping in and writing code without thinking is stressed and there are great suggestions for how to take stock of your own personal strengths and weaknesses and come up with a personal plan that works for you. The example is given of someone who likes jumping right into coding — for someone like this it probably makes sense for them to do early prototyping as a way to start solving a particular problem, as long as the longer term plan involves taking a step away from this and incorporating the lessons learned into a more thoroughly thought out solution later. In this, as in the rest of the book, the author shows his years of experience teaching a wide range of people with different skill sets and approaches to problem solving. There is no single way to think like a programmer, but rather a number of tried and tested strategies that can be employed in various ways. Think Like A Programmer captures this core idea in an satisfying, down to earth manner and I can highly recommend it to anyone wanting to improve their problem solving capabilities. I wish I had had this book when I started studying computer science — the fundamentals contained here would have been a valued addition to the text books teaching syntax and specific technologies.
You can purchase Think Like A Programmer from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
"craftsmen (and craftswomen)"
No need to do that. Women are included in human. Women programmers are included in programmers. Craftswomen are included in craftsmen. No need to complicate things.
I've had some self-taught programmer interns that seem to lack some of the critical problem solving skills that need to exist before the programming can begin. I've been looking for a book exactly like this: How to approach a programming problem. Is this a good gift to give to someone who really wants to be a programmer?
http://programming-motherfucker.com/
Please do not read this sig. Thank you.
Charles Petzold's book, Code, is one I recommend to anyone who asks me about getting into programming. Actually I recommend it to anyone interested in computers in general. He uses flashlights, relays, and the like to "build" logical gates, accumulators, memory, and so on. A great read that really lays out how computers work.
Entropy just isn't what it used to be.
"Cheetos, coke, pizza, mmmmmmm"
Back in the 80s when I was in college, everybody signed up for Computer Science because there was money to be made, it was the thing to do. I noticed that few people made C's...people either made straight A's or flunked out. They got it, or they didn't.
Now, as a long-time programmer and hiring manager, I find the same trend: people are either naturally really good at programming, or they just don't get it. As with any art form, reading books and education can only go so far.
Well, somewhat. There is quite a lot to be said for reading material *while* working on problems relevant to the material. (It's far too easy to only *read* something, and feel that you "know it".)
It's also pretty challenging to make that leap from reading to doing, no matter the subject. But, if you can do it...then you can *do* whatever you read including how to program.
PS: I don't reply to ACs.
Good to see No Starch Press still putting out good titles.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Back in the 80s when I was in college, everybody signed up for Computer Science because there was money to be made, it was the thing to do. I noticed that few people made C's...people either made straight A's or flunked out. They got it, or they didn't. Now, as a long-time programmer and hiring manager, I find the same trend: people are either naturally really good at programming, or they just don't get it. As with any art form, reading books and education can only go so far.
Some get it enough to get that CS degree but they are just not into it. IMHO many grads seem to fall into this category, they even have good grades. They entered the CS program not because they had an inherent interest in programming but because someone told them it was a good career path. Its just a job to them.
I found what may be a simple way to tell those who have an inherent interest from those who do not. In an interview I like to ask about projects a candidate did on their own, for their own amusement or to satisfy their own curiosity. Sometimes I have to drag it out of them, they think their projects to too small or too trivial or too silly to be mentioned. If a recent graduate has written nothing other than class projects then I get a bit suspicious. It seems that the people who "get it" and are "into it" always have little side projects they can talk about.
I prefer to open vi and then whack my student with a bamboo stick until "Hello World" compiles and runs. Repeat with more complex examples, until they know how to program.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Coincidence?
To *think* like a programmer you must have that sense that Murphy (of the law) is inside you [ie. Be humble no matter how clever you are] and in the real world [eg. A valid date might be 'June' which isn't 00:00 on 1st June]. An age ago when I wrote my book on the subject (text freely available at http://vulpeculox.net/ob/Programming.htm) I twigged that programming is not about splitting problems into bits but understanding the need then building the solution from bits. Of course there are well-known methods for doing this. Now to me a programmer is a mental athlete. I expect them to train, have good facilities and consistently run good races but why on earth would I expect a high performance person to be operating at their peak 7.5 hours a day? Resting, recuperating and reflecting goes with achievement. Enthusiasm and interest in the next challenge keep up the momentum. Constraints and management targets destroy it. Once you've got the mechanics you can graduate to the principles then the patterns then the practice and finally being able to communicate with people.