Rafe Colburn (rafeco) Tue 15 Feb 05 15:25
Who do you find to be the ideal readers of the book? Is it best received by people who are new to software engineering or more experienced programmers? I don't know that I would have appreciated the book as much had I not seen many of the problems the patterns solved tackled in other ways.
Elisabeth Freeman (bethfreeman) Tue 15 Feb 05 16:22
We specifically targeted readers who have just a few years of experience (say 1-4?). Why? Because we thought that most of the design patterns books already out there were pretty advanced, and likely to be very difficult for those reasonably new to software engineering. You're right - the big "ah-ha" moments with design patterns tend to come with experience, but we're hoping that with a little head start in OO principles and design, newer programmers will be able to approach difficult problems a little differently than they might otherwise. As you point out, they won't have the same appreciation for design patterns in terms of their previous problems that a more experienced designer would, but hopefully it will help them create better designs from the start, rather than struggling through a few bad design iterations first. But certainly, the book is also appropriate for experienced programmers who are new to design patterns as well.
real virtual memory (biscuit) Thu 17 Feb 05 05:10
I'm a little late to this discussion, but... hello! Welcome to both of you. I'm currently working as a programmer *and* as a teacher, so I'm finding both the pedagogical approach and the content are giving me food for thought. I mostly work in Python now, but have played with Java enough to follow along so far in the first few chapters. I'm curious why the title of the book doesn't have the word "Java" in it. When I first cracked it open I was a little surprised at the Java-centric content (until I saw what your previous book was!). Would you ever consider doing a version specific to another language, like Python or Ruby or C++ -- or perhaps even offering downloadable appendices with the examples done in other languages? Or do you feel that's not necessary? (I apologize if these questions are answered in the book itself -- I'm home sick and the book is at work!)
Ari Davidow (ari) Thu 17 Feb 05 06:01
Or, offering code written in those other languages on the website, for those of us who would be more comfortable following along in, say, python or PHP.
Loren Rosen (loren-rosen) Thu 17 Feb 05 13:16
In the book you teach each concept more than once, in different ways. How did you decide how many ways was enough?
Elisabeth Freeman (bethfreeman) Fri 18 Feb 05 17:37
Sorry for the slow response, we were out of town the last couple of days. To answer the last couple of questions: Yes - we would definitely like to make the code available in other languages. We currently have someone working on C#. So far, the feedback has been very good - most people have not had trouble translating most of the Java code into their language of choice (mostly that's been C# from the emails I've received from readers). We tried to keep the examples as simple as possible and yet still somewhat real so that the overhead of the language and the example itself would be minimal, and I think that worked pretty well in most cases. (and anyone who feels like translating the examples into another language and submitting them for us to post would be most welcome to do so!!) To answer your question Loren: we have a "Head First" formula. :-) It's three parts: Why? So what? Who cares? So, first we explain the topic. Then we imagine someone going, ok, but WHY would I want to do that? (or do it that way, or whatever). So then we explain why. Then, we imagine the reader saying, ok, but SO WHAT? So we have to go another level deeper. Finally, we imagine the reader saying, ok... but WHO CARES? So we have to take it to that third level! Now, some simple topics don't warrent all three levels, and we do our best to judge that so we don't do simple things to death. But many do need the entire 3 levels in order to make it perfectly clear. We don't want the reader to be saying at the end "I still don't get it," and we try to take it all the way so that at the end the reader understands not only 1) the idea but also, 2) why they'd want to do it 3) the deeper implications for doing it that way (or not doing it that way) and 4) why it matters *personally* TO THEM (ie., if you don't do this you will a) get fired or b) have no sex). If we can explain the Why? So what? Who cares? in different ways, then it helps the whole thing sink in a bit too. Obviously, we don't always succeed, but this is our goal.
John Brewer (jbrewer) Fri 18 Feb 05 17:57
Could you talk a little bit about how you chose the order of the patterns in the book? I was surprised that you covered Observer so early on, for example.
Loren Rosen (loren-rosen) Fri 18 Feb 05 18:01
Another part of the explanation is HOW? One thing I liked is that, in some chapters you demonstrate that the HOW part (and the WHY part for that matter) is mostly an application of basic object design principles. I say "mostly" because in some cases there is an "aha!" aspect to the solution that makes it not completely obvious. As I recall sometimes (but not always) you pointed out the "aha" part.
Elisabeth Freeman (bethfreeman) Fri 18 Feb 05 21:13
Well, we started by choosing the list of patterns to cover in-depth from the original patterns book (Design Patterns by Gamma, Richard Helm, Johnson, and Vlissides) by how often those patterns are used. The patterns we cover in depth are the most used patterns according to a survey we found. They are also the patterns we use the most (which happened to correspond closely to the survey we used). I think putting Observer near the front of the book was driven by two factors: one, it's a very commonly used pattern, and two, it's reasonably easy to understand both from the point of view of understanding the pattern itself, and also understanding the benefits of using it. One of the interesting things about writing a Head First book is getting the challenge level right to keep the reader engaged, interested, and wanting more. Just like a game, you need to give just enough of a challenge that they feel like they've accomplished something, yet not so hard that they get stuck or don't feel like they're getting it. So we tried to arrange the patterns so that the reader could make some early gains in understanding without getting too overwhelmed, so they want to move on to more. And remember, this is a learning book, so we wrote it to read from front to back. Most technical authors do not assume this, and do not write for this. But because our books are story and challenge driven, it's important that we write this way. In addition, some of the order was driven by the programming principles. We found that explaining certain principles worked well with certain patterns. And the order of the principles also helped shaped the stories and vice versa. So in conclusion, I'd say it was an organic thing that was driven by many factors.
Ari Davidow (ari) Sat 19 Feb 05 05:50
I was about to ask the same question until <jbrewer> put it first and better. Until this book, the only design pattern that I am aware of working with is MVC, which made perfect sense when I learned it a couple of years ago and resolved a lot of issues that had kept me from progressing farther on learning to program.
Brian Slesinsky (bslesins) Sun 20 Feb 05 10:32
I read a little bit of Head First Design Patterns at the bookstore and I'm impressed. Even though I mostly know this stuff already, even the opening example got me to reconsider a few things. (In retrospect, I probably missed a few opportunities where a Strategy pattern would have come in handy.) However, the clip art thing still bugs me a little, and I'm trying to figure out why. One of my favorite books is Scott McCloud's Understanding Comics, so I think the issue is not just that your book has lots of pictures of people in it, but that they're photos. I keep thinking that these people are just models who probably don't know the first thing about programming and the words in the bubbles don't fit them. In a way, it deconstructs the use of clip art, which is an interesting thing to do, but a distraction from the goal of the book. So I was wondering whether you folks considered other artistic approaches. Would hiring an artist to draw some cartoon characters have worked as well?
Michael E. Marotta (mercury) Sun 20 Feb 05 11:32
37 messages later and I am a bit less enthused than I was. When I started the Topic, I stopped, and emailed my wife. She is a programmer, and out of town on a project. I am a technical writer. I thought this was a high-level, language independent concept, this "Head First" design idea. What I read here seems to be about menu buttons. (I mean, you do know that Engaged is mostly a convenient text editor, right? Anything serious you need to do to your account or in a conference on The Well, you do in Unix on the command line. Put two spoons of that in your Java.) On the other hand, when I go back and read some of our classic books on programming from the 1970s and 1980s, I find ideas that work in any environment. My career as a technical writer has been a learning curve. I learned C by documenting a set of extensions that were being sold; I created learning examples for the books. Eventually, it came time to work in Java, so I did. (I just thought of an analogy between software design and the architecture of houses, but I'll that go for now.) Flowcharts, Warnier-Orr, Nassi-Schneiderman, Action Diagrams, Entities, Fishbones, ... functions, subroutines, libraries of linkable programs, classes, objects, modules ... LEDs, CRTs, ... punched cards or palm pilots ... the principles of good software design are the same. I am impressed by the Disney credentials. The graphic.jpg links were interesting and insightful. So, based on the first ten entries, even though there are four inches of snow here in Ann Arbor, I will go out to Borders tomorrow and buy the book. Thanks to Elisabeth and Eric and their colleagues.
Michael E. Marotta (mercury) Sun 20 Feb 05 12:00
18 of 37: Dave (drsmith) I'm asking because of documentation issues, really. In documentation and training materials, it might be nice to mention to the reader ... Arrrrghgh!!! NEVER NEVER NEVER NEVER NEVER NEVER NEVER let the programmers write the documentation and training materials. Did I say NEVER? I meant NEVER!! Aside from the fact that that's _my_ job, I like to think that I offer the service because I can do what the programmers cannot. I come in and LEARN the system from the user's viewpoint. Then, I explain it to the users in terms that the users understand. It is _not_ (as programmers think) because they users are deficient or stupid or lazy or immoral, but because they have different vocabularies, different needs, different expectations, and different backgrounds. I offer a classic case. I started on a project that was under way. Menu item 1. was "File Maintenance." How often do the users perform file maintenance? Monthly. Why was it menu item 1? Because that's how the programmers saw the system. So, I recommended a change. Remember "Press any key to continue." The standard quip was, "Which is the 'any' key." The programmer were not stopped by that. So, I walked up to a programmer and hit the Alt a bunch of times, then the Ctrl, then the Shift. "See? Alt and Ctrl are just another kind of Shift. It goes back to teletypes. You ever use one?" No. "I have. Press those keys all you want, nothing will happen." My suggestion was to have the user press "Enter" or "Space" and let it be so. I speak several languages. I took two classes in Japanese in college. I worked for two Japanese companies. I taught myself to read classical Greek and published two articles on using the language. The point of all that is I see a computer as a mode of communication. I know that words have different meanings among different English speaking people. More people in India consider English their primary language than in the UK, US, Canada, and Australia combined. Yet, you cannot expect North American users to rely on manuals created in India, China, or Japan, even though, people in those places, do, indeed, get documentation from us. Those problems keep me awake at night. Programmers do not understand the question. Sometimes a project manager will try to save money by having the manual in "electronic format" (ahem) via Adobe PDF. Is a screen a piece of paper? They are not even the same size and shape. It has been said there that "I learn more by hacking than by reading a book." We _all_ do. That is why I work with programmers to make sure that those screen prompts, messages, pop-ups, dialogs, and do-dads are meaningful, direct, and helpful to the users -- and those users may be another generation of programmers. Field (Address) "Enter Address:" On_cursor_popup "Enter Address" On_cursor_popup user asks, "Do I put the apartment number on the same line?" We are _all_ users. You _use_ Java. You did not write it. You _use_ a keyboard you did not build as interface to a computer that you did -- and probably could not -- not buildn -- and I don't mean plugging in stuff from boxes, I mean BUILD. Personally, I am pretty happy at the hex level myself, and I think the IBM-PC reached its zenith with the PC-XT, a color monitor, a 20 meg hard drive, two floppies, 640K RAM, and a 1200-baud modem. Last night, I watched MAX HEADROOM. The night before, I watched THE MATRIX. You would be surprised how little progress has been made in computering. (I like Java. I like C. I like Laurel and she likes me. Oh, yeah, speaking of Laurel and "Head First Design"... oh, better not...)
Elisabeth Freeman (bethfreeman) Sun 20 Feb 05 15:07
Brian, we have had lots of feedback on the clip art and quite a few people feel the same way you do about it. One reason we use photos of people is so that the reader can identify with the character's expression better, for reasons I outlined earlier. Although, I have not seen studies as to whether responses to facial expressions on hand drawn people are worse. Another reason we use stock photography and do not hire someone to draw the characters is that we do not have a big budget for producting these books. Eric, myself, Kathy and Bert do *all* the design and layout for these books - when we hand them to the publisher they are camera ready. We have two choices: either we do the layout ourselves, or we write in Microsoft Word and submit our "text" as part of a template with pointers to images. Obviously the latter will not work for a Head First book. We have definitely considered other approaches to implementing the Head First learning principles. The way it was done in the four books that are out now is clearly only one approach. When Kathy and Bert started the series, it was a big gamble and they didn't know if it would work! As I write, we are attempting to refine the way we implement the learning principles... so keep an eye out for new things to come :-)
Elisabeth Freeman (bethfreeman) Sun 20 Feb 05 15:10
Michael, I'm not sure what you mean. "What I read here seems to be about menu buttons." In what way? Is it that you believe that OO principles and Design Patterns do not add anything to the art of programming? Or rather that you think Head First does not add anything to the art of learning? Or something else entirely and I'm missing your point?
Dave (drsmith) Sun 20 Feb 05 16:01
> NEVER let the programmer write the documentation < That's excellent advice in general, to be sure. I could debate you on some of the particulars -- for example, I feel that my degree in technical communication and my years of experience at writing API docs have some bearing on the question of whether I should be allowed to write documentation. But, really, this is all off topic, so let's try not to sidetrack the Head First discussion. I found it interesting, reading someone's (Beth's?) comment earlier, about how this is a learning book so it's meant to be read front to back. I started out that way, and was making steady progress. Then a specific issue came up at work, and I started jumping around the book, which really did not seem as productive at all. First of all, when I had a specific work goal in mind, I found myself hurrying more. So I think I had less patience for the humor, and I wasn't as diligent at doing all the exercies; instead, I found myself skipping ahead, looking for the answer. Then there were also references to patterns I didn't know yet, so of course that slowed me down. No epic point to make here; I'm just agreeing with the observation that this is a book that should be read front to back, and given time to sink in. Now if I could just find more leisurely reading time...
Brian Slesinsky (bslesins) Sun 20 Feb 05 16:08
I don't have any scientific studies to back me up, but personally I have no doubt that a talented artist can do better than clip art in representing all the human emotions. I mean, look at what Charles Schulz did in a tiny space with just a few lines. Comics have all sorts of conventions for showing how people feel that aren't available in realistic photography. And as Scott McCloud argued, they can also strip out the irrelevant and alienating detail in a picture so that more people can relate to them. However, it's certainly labor-intensive, and I think you've accomplished many of the things McCloud was writing about, using a different technique. And who's to say that, in an alternate universe, other people wouldn't be complaining about how the people were drawn in The Cartoon Guide to Design Patterns? So, how did you go about designing the book, anyway? I'm imagining paging through hundreds of clip art collections to find just the right pictures.
Elisabeth Freeman (bethfreeman) Sun 20 Feb 05 21:44
Brian, you are imagining right! We have stock photo disks that we use for both the 50's pictures at the front of each chapter and the characters within the chapters. Many of the drawings that support the code we hand draw ourselves. It's definitely a labor intensive creation... but fun too.
Dave (drsmith) Mon 21 Feb 05 09:21
I'm particularly fond of the stock photo on p. 169. "Look at the lines, the curves, the body, the headlights!" And just now I noticed a nice little thing I'd missed before -- the Indiana Jones-inspired item on the menu bar on the screenshot on p. 263. Wonder how many people miss that one altogether... Good lord, there's a different one on every screenshot! How'd I miss that?
Elisabeth Freeman (bethfreeman) Mon 21 Feb 05 09:38
heh heh - yes, we love those easter eggs :-)
Elisabeth Freeman (bethfreeman) Mon 21 Feb 05 09:42
Dave, regarding your comment before about reading front to back vs. jumping around, and the effectiveness (and your patience for the various aspects of the book). This is a perfect example of the difference between a learning book and a reference book. A reference book is designed (or should be) precisely so you can jump around and find the thing you need, right then. You can't really do this with a learning book and still make it a really effective learning tool. They really are very different. The trouble with many technical books today is that they try to be both and you can't really do both and still be great at either.
Loren Rosen (loren-rosen) Mon 21 Feb 05 11:13
Have you seen shouting matches between people about whether a certain design expressed this pattern or that one? Was that the inspiration for the Fireside Chats?
Dave (drsmith) Mon 21 Feb 05 11:24
Hmm. I see your point about reference books, but I don't think that I was trying to use the Head First book as a reference, exactly, even when I was jumping around. I mean, yes I jumped around somewhat-- I looked in the index for MVC and then went to that page and started reading. But then I tried to sit down and take my time and soak the info in, so I wouldn't quite say that I expected an answer "right then." In hindsight, I guess I just had different goals when I was reading front-to-back vs jumping around. When reading front-to-back, my goal was just to learn the material because it would come in useful someday soon. When I was jumping around, it was because I had a specific question in mind, and once I reached a point in the MVC discussion when I felt like I had an answer to that question, I felt my job pulling me back. I think my mood was probably, "ooh, must apply this info to that thing we've been discussing in email, and do it NOW, before I forget." So I never finished that chapter. Kinda reminds me of the classic design principle, "Never go grocery shopping when you're really hungy."
Elisabeth Freeman (bethfreeman) Mon 21 Feb 05 13:16
Loren, something like that... we've definitely seen a lot of confusion about patterns - the right way to implement them, and yes, whether or not a design expressed a particular pattern. So the inspiration behind Fireside chats was mainly to help address the confusion about patterns and give the reader a fun & interesting way to compare aspects of similar patterns, or to explore more detail about a pattern than we covered in the text.
Dave (drsmith) Mon 21 Feb 05 14:05
Now that there are several Head First books out, have you seen any signs that the Head First style is being copied by other publishers? And how would you feel about it if another publisher did mimic the style?
Members: Enter the conference to participate