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?
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.
That's exactly what George Polya said!
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.
Is this a good gift to give to someone who really wants to be a programmer?
No. Give them this one.
"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.
This. You obviously get it.
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 taught programming for a year at university after graduating, and my observation of the students was just the same as yours - they either got it, or they didn't. There were a small number who flew through the programming tasks, and did more than was expected. There was another small number who persisted and eventually completed them. Then there was the majority who spent painful hours struggling to write anything which approximated the requirements, seeking help at every step of the way from each other and the teachers, and ending up with long, long programs which barely achieved anything.
I'm a software visionary. I don't code.
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.
If architects made buildings like programmers make software, then the first woodpecker to come along would destroy civilization.
Programmers seem to have no trouble with the concept that every single individual bit of the billion or so in a complex program has to be correct in memory for the program to work correctly.
Wait, what? I thought that the woodpecker comment meant that programs were so slipshod that they were barely held together by spit and duct tape, and one bird could wipe it out completely. (Yes, it's hyperbolic. Most adages are)
If you plug in your "perfectionist" complaint, how does it work out to anything that makes sense?
they successfully churn out software to solve these challenges in elegant and creative ways
Would those be the same "good programmers" who have churned out the last 20 years of critical Internet-facing vulnerabilities?
All that software sold, after all, so by some measure it was "successful". Just not by the old fuddy-duddy "not guaranteed never to steal your identity and strangle you in the night" definition.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I think you're mis-interpreting the complaint.
I think the complaint was not that the programmers are striving for perfect bits, but that they are assuming all bits will be perfect - that there will never be bad RAM, or corrupt input, and that their program does what they wanted it to do, rather than what it actually does....
Can you be Even More Awesome?!
Somebody ought to try that someday...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Programs have no error tolerance whatsoever. The first time something goes wrong (the woodpecker chips at the wall), the whole thing crashes. It's not that programs are perfect, but that our computing model means that if they aren't, it's super-happy crashy time.
Contrast this with the computing model of human brain, where errors are tolerated and corrected on a best-effort basis. For example, a drunkard will become increasingly uncoordinated as alcohol disturbs his motion control centers more and more, rather than simply crash all of a sudden. Or to architecture, where a building can take a certain amount of damage before coming crashing down.
But of course that error-tolerance has a price: circuits used for error-correction or materials used for extra structural strength aren't doing anything useful under normal circumstances. Thus, an error-tolerant computer would require more transistors than a normal one of equivalent speed, and require a whole new programming model besides. Alternatively, you can use normal computers with new programming models, and to some extent we already do (managed languages), but all that extra checking has a price in speed (and a typical program written in managed language is simply guaranteed to crash immediately rather than leak buffers and corrupt memory, so it's not that much of an improvement).
So in short: our programs are fast but fragile because they typically omit all of the error-checking that would make them sturdier but slower, and also don't bother with things like separating components into different memory spaces (so they couldn't interfere with each other except through the API) that would help limit damage from errors and make recovery possible.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
How to see if you think like a programmer.
Step 1. Play SpaceChem.
Step 2. Check levels of enjoyment. If you are enjoying yourself, get thee to a programming job. Preferably in the field of robotics, I guess.
Alternatives to starting your programming career would include playing Zachtronics' other games, especially the codex of engineering. They have a perfect learning curve. I know I've posted about this a couple of times, but it can't be overstated; these games are all about programming.
Consciousness is a myth. Trust me.