Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Image

Book Review: Think Like a Programmer 98

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.

*

This discussion has been archived. No new comments can be posted.

Book Review: Think Like a Programmer

Comments Filter:
  • Silly Words (Score:5, Insightful)

    by pubwvj ( 1045960 ) on Friday August 31, 2012 @03:45PM (#41193793)

    "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.

  • by Radres ( 776901 ) on Friday August 31, 2012 @04:30PM (#41194331)

    s/obfuscated/abstracted/

    there *is* a slight difference in intent between those two words.

  • by Anonymous Coward on Friday August 31, 2012 @04:30PM (#41194335)

    ...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

  • by Anonymous Coward on Friday August 31, 2012 @04:43PM (#41194443)

    I for one approve of this idea!
    People who don't want to learn the nasty details of how computers work, and what's under the abstractions will always suffer from leaky abstractions (http://en.wikipedia.org/wiki/Leaky_abstraction). If you don't learn what the abstractions are meant to abstract, you don't really understand it. The abstractions are meant to make coding easier, not to replace understanding.

  • by Anonymous Coward on Friday August 31, 2012 @04:48PM (#41194485)

    Actually, yes, very much. You *will* be a better programmer if you understand what your code runs on top of. I started out as an embedded systems programmer writing assembly code for hardware, and feel what I learned there still applies to what I do now as a web app dev.

  • by LordofEntropy ( 250334 ) on Friday August 31, 2012 @04:52PM (#41194519)

    In my opinion, absolutely. He gets into programming later in the book as he describes how you give instructions to this 8-bit machine he has basically built in the book. Getting a basic understanding of memory, instructions, and the logical constructs used in computers, I think is critical to any programmer. Otherwise inheritance is just "oh I can use this stuff in my class magically" without understanding what is actually happening—which will make other concepts like pointers, multiple inheritance, and polymorphism very confusing.

  • by Tony Isaac ( 1301187 ) on Friday August 31, 2012 @04:54PM (#41194541) Homepage

    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.

  • Re:Silly Words (Score:4, Insightful)

    by Fallingcow ( 213461 ) on Friday August 31, 2012 @05:15PM (#41194705) Homepage

    I just wish people would stop using "she" for the genderless singular pronoun. It makes me think they're talking about someone specific and that I missed who it is, so I need to scan up. Very disruptive to reading.

    At this point, I'd say using the plural pronoun "they" for double-duty as the singular-genderless is less jarring. Just give in and use it.

  • by perpenso ( 1613749 ) on Friday August 31, 2012 @06:32PM (#41195305)

    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.

  • Re:Silly Words (Score:5, Insightful)

    by ShanghaiBill ( 739463 ) on Friday August 31, 2012 @07:07PM (#41195555)

    Apparently that's where we are headed. The so-called professional newspaper in my town won't use the words 'fisherman', 'fireman', or 'policeman' beause those words "are not inclusive enough".

    If children are told to draw a policeman or fireman, they will almost always draw a man. If they are told to draw a police officer or a firefighter, they are more likely to draw a woman. The gender neutral terms are more inclusive, and are also more descriptive (does a fireman fight fires, or does he set them?), so why not use them?

    I'll get off your lawn now.

  • 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 [vulpeculox.net]) 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.
  • Re:Silly Words (Score:0, Insightful)

    by Anonymous Coward on Friday August 31, 2012 @11:42PM (#41197233)

    Thats GoodThink citizen ShanghaiBill.

    Of course, now we must address the fact that more women than men get degrees. Obviously we should have a quota system now to protect men until equality can be achieved.

    Also, we must address the fact that women live longer than men. Obviously we should spend all health research on men now until equality can be achieved.

    Also, we must address the fact that almost all military casualties are men. Obviously we should draft women until equality can be achieved. This may take some time because men have been dying unfairly for all of recorded history.

    After all, it's equality that matters, right citizen?

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...