Inkwell: Authors and Artists

    
Dave, yes we've definitely seen signs of elements of Head First
showing up in other books.  

If something is successful, of course it's going to get copied. 
There's really two aspects of Head First to copy: one, the "look and
feel", which, as I've said is just one implementation of the second
aspect, which is applying learning principles to writing books.

An example of a Head First element that I'm seeing occasionally in
other books is annotations on code and pictures.  I even saw a
beautifully designed Photoshop book the other day with really great
annotations (I'm not sure if the book came out before Head First,
however).  So, someone could copy the look & feel of annotations,
because it's different or "cool" or whatever.  However, our use of
annotations is based on studies that show that learning increases
greatly if the text explaining a piece of code (or technique or
whatever) is *right next to it*.  This is better than placing the text
directly underneath the figure or table holding the code, which is
better than having the explaination text in a paragraph following the
code on the same or next page (which is obviously the worst).  

One trend I've definitely noticed in technical books, which may or may
not have started with Head First, is the trend towards more informal
writing.  Many technical authors have a real problem with this!  But
informal writing is so much easier for people to read and remember. 
Informal does not have to equal "less technical" or "less correct". 
It's a conversational style that helps memory.
  

    


Oh, conversational style has been around a while.  It was a big
selling point for my books ten years ago.  (and I got flak for it,
too.  "too funny."  "too many words."  "too hand-holding," "not
serious enough.")  (I wrote HTML and Java books in the Teach Yourself
series back in the day)

I wanted to annotate code but the book designers would have none of it
and I didn't have any clout on the design end.  I did a tiny tiny bit
with figures but not a lot.

But I'm not trying to stomp my little foot and claim "I thought of it
first!" because that's just not true.  I'm guilty of the mixing
tutorials and references problem and guilty of the trying to teach too
much problem.  And because I was first and foremost a writer I was
always thinking from a writing perspective -- the very visual aspect
of Head First is just not the way I think.  Head First just floors me
completely.  There's so much to the head first style that is so hugely
unique and so creative.  I am deeply envious of it and find something
new and exciting every time I crack the books (I have all of them.
more, more).
  

    
 I am also envious.  Reading this book has completely sapped my
interest in working on computer books, just because I don't have the
talent or dedication to do something so interesting and effective.
  

    

Oops, I just realized I'm still using my dumb well nickname (pseud)
here.  "Who is this person?"  Sorry about that.
  

    
Hey Laura, well too bad I didn't buy your books!  I found very few
technical books that used a conversational style and I wish I had.  So
anyway just ignore those critics... it's the customer that counts,
right? :-)  And thank you for buying all the books - that's awesome! 
We really appreciate it.

It is a challenge to do all the design and layout ourselves.  There's
definitely a high level of dedication required (is that understating it
just a bit?!).  But the reward is also great... I love hearing from
readers who appreciate the format and also learn from it.

And of course, Head First isn't for everyone.  Some people truly are
looking for a reference book, some people want one book that has
*everything* about a topic.  Head First will never work for these kinds
of books.   We follow a strict 80/20 rule.  It's really tough to cut
ruthlessly, but vital for a teaching book, and it means that we had to
leave a lot out.  I'm seeing emails from readers who are now buying
*two* books about Design Patterns: GOF and Head First.  Head First to
learn it, and GOF as a reference.  (Which kind of makes me smile
because if that's true, then we've doubled the market - ha!)
  

    
Do you think the Head First style could work for more "advanced"
books?
  

    
Before we finish up, I have a few more questions I want to get in.

First, could you talk a little bit about pattern abuse?  I've noticed a
strong tendency among people just learning patterns to start trying to use
them everywhere, including places where they clearly don't belong.  How do
you go about preventing this?
  

    
I also wanted to ask about unincluded patterns - are there patterns that 
you almost included, but ended up leaving out - if so, what and why?
  

    
Loren - absolutely I think Head First can work for advanced books.  It
is a format designed specifically for learning, and I think could
apply to as advanced a topic as you could imagine. In fact, the harder
the topic, the better, since Head First is so learning-friendly and
brain-friendly.  I'd much rather learn a really hard topic the Head
First way than trying to slog through hard core technical writing :-)

John - that's a great question.  I'm not sure you do prevent newcomers
to patterns from implementing them all over the place; that's part of
the process of learning them and learning when they're useful!  Part of
my own experience in learning about and writing about patterns is
coming to the understanding that almost everyone has to go down a path
to "experienced programmer" and that patterns don't necessarily give
you some magical short cut.  They might help guide someone in the right
direction sooner, and help them understand good programming practices
a bit quicker, and perhaps to understand other people's programming
styles better (e.g. someone writing user interfaces might use MVC a lot
and understanding MVC will help you understand their code more
quickly).  But in the end, every programmer may have to learn the hard
way to Keep It Simple, Silly!  

In the last part of Head First Design Patterns, we talk about overuse
of patterns and try to stress that while a pattern can help suggest
solutions to a problem, in the end, the simplest solution may be the
best.  Some people claim that patterns should only be used when
refactoring code.  I tend to think that's a bit of overkill, especially
for the most used patterns, like Observer.  It's absolutely clear to
me that Observer is useful from the start in certain programs.  But
other patterns, like the Factory pattern and Singleton, can be overused
in situations where it just doesn't make sense because it's never
going to be an issue.

We stress in the book that "change" is a big factor in using patterns,
and that comes from our years of experience writing code where the
spec is changing every few months (or weeks (days!)).  In those
situations, planning ahead is helpful and that's where patterns can
really shine.  In this case, adding patterns in when you refactor
probably makes a lot of sense.  You've implemented the first version;
it's successful; someone comes along and says, ok we're going to be
maintaining this and updating it for a while.  So that's the time to
think: where is it that my program needs to be most adaptable to
change?  That's probably where you want to use a pattern.

We suggest pattern study groups, whether that's at work, school or
perhaps even online if you are studying them on your own - and I think
this can help a great deal if you are working with someone with more
experience in the area - a pattern mentor! or at the least an
experienced mentor.  This person hopefully will help to guide people
new to patterns to help them see where using a pattern makes sense and
where it's just not necessary or would add complexity for no benefit.
  

    
Ari - well we originally chose the patterns we included from a list of
the "most used" patterns.  Every pattern from that list except Builder
made it in.  The other pattern we really wanted to do, but just ran
out of time was Bridge (because it's so abstract and so interesting). 
In addition, we had planned a whole chapter around an extended example
that included a whole bunch of patterns (it was a lambda-moo style
MUD), but that example ended up containing several patterns we knew we
wouldn't be able to include (like Chain of Command and a few others),
and was too complicated so we left that out too.

Most of the leaving out was a combination of running out of time (and
space! we didn't want to go over 700 pages) and also trying to focus on
what would be most useful to the reader.  It's that 80/20 rule again! 
The purpose of Head First Design Patterns is really two-fold: to help
you learn the patterns we do cover, and also help you learn how to
learn patterns.  Because if you can do that, then you can pick up a
reference book and quickly learn a new pattern.  
  

    

Interesting that you mention picking up a reference book and learning
a new pattern...  I haven't tried that yet, but I have found myself
wondering about it.  As in, when I finally pick up that daunting
hardcover design patterns book, will I find that I've been spoiled
by Head First?  Something tells me I may find myself thinking,
"Nope, don't quite get it.... damn, where's the Fireside Chat
when I need one?!"
  

    
Advanced books are often difficult because they cover a lot of ground
very quickly. A Head First style advanced book might have to be
thousands of pages long.
  

    
Given that O'Reilly publishes it, why isn't Head First Design Patterns
available from Safari (O'Reilly's online book service)?
  

    
Head First Design Patterns is not on Safari because Safari books are
automatically extracted from XML - assuming the author uses the
standard O'Reilly template.  Since we use In Design, there is no way to
extract the data.  We'd have to place PDF pages on the site instead,
and no one's gotten around to implementing that yet.
  

    
Makes sense.  A non-paginated version would be very confusing.
  

    
Perhaps we have time for one last question:

What's it like being married to your writing partner?
  

    
You just had to ask, didn't you? :-)  

Most of the time it works really well for us.  We've worked together a
lot (more than most couples), and so we've had a lot of practice. 
It's nice to have something big and creative like a book to focus on
together (except when it takes over your entire life of course).  A
book is such an intense effort that it's nice working with someone that
you don't get sick of (most of the time) and it's hard to find those
people.  We knew going into it that we don't get sick of each other, so
that was a plus. Also a plus, being able to bounce book ideas off each
other while on a trip to the grocery store (minus - when one of us
says, "that's a really stupid idea!" :-)

I really enjoyed learning from Eric; as with any working team we both
bring different talents to the job, and Eric had previously published a
book, and was a better writer than I am.  He really helped me to focus
on writing clearly and make sure that every sentence, every word - and
for Head First, every picture - was really right.

The hardest part of working together, as I'm sure you suspect, is
leaving disagreements behind at the work table and not going to bed
mad. 

 
  

    
>Head First Design Patterns is not on Safari because Safari books are
>automatically extracted from XML - assuming the author uses the
>standard O'Reilly template.  Since we use In Design, there is no way
>to extract the data.  We'd have to place PDF pages on the site
>instead, and no one's gotten around to implementing that yet.

The taxonomy of a publishing industry antipattern!
  

    

Elisabeth and Eric, it's been such a pleasure having you join us here in
Inkwell. Thanks so much for being our guests, and thanks to you, John, for
so ably leading this conversation.

Our virtual spotlight has turned to new guest nows, but that doesn't mean
you have to stop. This topic will remain open for continued discussion
indefinitely, so please feel free to carry on, if you have the time.

Thank you again for being here.
  

    
#40 of 69:   Michael, I'm not sure what you mean.  "What I read here
seems to be about menu buttons."  In what way?

What I meant was that in this discussion after about the first dozen
posts or so, talk seemed to get away from broad, basic principles of
design patterns and get bogged down in how to do this or that in Java
(or C#).  

"Is it that you believe that OO principles and Design Patterns do not
add anything to the art of programming?"

Not at all!  That is why I bought the book.  As I said, I was
impressed the credentials of Freeman and Freeman and I have not read
any kind of software design book in about a decade.  OO is just today's
FORTRAN, but it _is_ today's standard.  So far, I am having a good
time with the book.

"Or rather that you think Head First does not add anything to the art
of learning?"

That is a much deeper question.  I was hoping you would have the
answer to that.  We are pretty much stuck with books.  I write the
"Internet Connections" column for the ANA's NUMISMATIST magazine.  So,
I spend a lot of time reviewing educational websites and looking at CDs
and basically, little comes close to books in terms of efficiency. 
That said, I know as a trainer (robotics and factory automation) that
books are limited and limiting as a medium.  Nothing competes with
hands-on.  

That goes for another of my interests, flying.  Read all the books you
want. Take all the training classes.  Nothing replaces being in the
cockpit.  Yet, there are advantages to books, etc.  For one thing you
can stop reading a book and think about it.  You are not supposed to do
that in the cockpit...  

So, for the book you wrote, for my having just begun it, I am pretty
well satisfied from the viewpoint of a documentation specialist and
trainer that your team has done an excellent job of pushing the limits
of print by CORRECTLY integrating text and graphics.

(Oh, well... there was one thing... a typo right up front.  "Elizabeth
lead research and development...")

#64 of 69 " Since we use In Design, there is no way to
extract the data."

Sure there is!  Contact the people at Avatar Data Publishing.  Coletta
Perry was the president of the QuarkXPress user group before InDesign
was launched and now she is the source in the USA for EasyCatalog. ADP
has all kinds of solutions.  They can make Filemaker Pro sit up and
bark like a dog. Just ask them.  Extracting data for print publication
is what they do!
  

    
Thank you Cynthia and John!  We really enjoyed all the questions and
of course talking about Head First and Design Patterns.  I'd like to
point everyone to the Creating Passionate Users Blog where we (well,
actually mostly Kathy - she's a blogging maniac) blog about Head First
principles and related things: http://headrush.typepad.com.  

And we'll keep checking back here to see if there's more discussion.

Thank you Well users!
  

    

"What I meant was that in this discussion after about the first dozen
posts or so, talk seemed to get away from broad, basic principles of
design patterns and get bogged down in how to do this or that in Java
(or C#)."

Weird.  I don't recall *any* discussion of how to do things in Java or
C#.  I wonder if there is another thread somewhere that I missed??


#64 of 69 " Since we use In Design, there is no way to
extract the data."

"Sure there is!  Contact the people at Avatar Data Publishing. 
Coletta Perry was the president of the QuarkXPress user group before
InDesign was launched and now she is the source in the USA for
EasyCatalog. ADP has all kinds of solutions.  They can make Filemaker
Pro sit up and bark like a dog. Just ask them.  Extracting data for
print publication is what they do!"

Well, all I meant is that there is currently no way for O'Reilly
Publishing to extract the data with their current Safari technology.
  

    
"Even self-assured design-pattern toting geek girls need feminine
hygiene products"

http://fishbowl.pastiche.org/2005/08/12/the_head_first_girls_double_life