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"
...neither the summary nor the book, I feel I am immensely qualified to comment on this subject.
Seriously, programming is a brain function akin to playing a musical instrument (actually reading music
seems to be the correlative item). No amount of book learning is going to teach the unteachable.
You can learn the facts, but not their creative application - that's where that magic originates.
So a book may have some useful facts about successful programmers, but the 'how do' will never be there
(how did Mozart create, etc.)
We have enough .NET programmers, we don't need any more.
CAPTCHA = construe
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
Every time the question of how to best think like a programmer comes up, one needs to remind people to not think like programmers. Remember the old but true adage: 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. And this is assuming that there aren't errors or oversights in the program design, language, or algorythm.
Isn't there anyone out there working on this insane situation?
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.
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
why would I want to think like one?
Somebody ought to try that someday...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
That FORCES you to break a problem down into its indivisibly small steps.
When you can do that 'on instinct' you can code a program 'on spec' alone with no need for flowcharts and whatnot.
Spend your time on defining the data (structures) and the program almost writes itself! :)
Unless you are a game programmer or a researcher that must code software tools to do your work, all you'll need to computerize some business process is addition, subtraction, multiplication, division, and binary sorting and searching along with the data and control structures your programming language has to offer.. Anything else you need is just I/O (GUI, text, [sound], files, or tcp/ip sockets) or 'big guns' like SQL.
CAPTCHA: conserve (what good programmers are supposed to do when writing software. :) )