Actually, I have been successfully using Smalltalk systems, including Squeak, for quite some time.
My problem is that it took me far longer to get to that point than the average programmer would find comfortable.  Perhaps it DOES mean that a change in mindset, documentation style, coding style is necessary in order to communicate beyond the community.  I don't know.

Self-documenting code is an ideal promoted by just about every advocate of a given programming language or development methodology.  Theoretically, if a procedure, or data structure, or class is small enough to be defined on one page, and functionally "hangs together", it is easily understood, and by definition is the most definitive description of its behavior.  In practice, however, separate descriptive documents, including relevant diagrams, cross-references, etc. is necessary in the "real world" where engineering team membership changes constantly, and people with different learning styles need to
comprehend eachothers work quickly.

Perhaps the Smalltalk engineering style as it is today has evolved because of the exceptional cohesiveness of the Smalltalk community.  The folks at Disney have been working together on this project for so long that they can probably communicate telepathically!  But if the community wants to grow, and convince an investor to put money into developing a product using Smalltalk at its heart, we must make it easier to comprehend the system quickly, and without telepathy :-)  The fact that commercial Smalltalk has found considerable acceptance in some industries indicates that there is hope for Squeak - but
there is a major difference in the documentation and other educational materials between Squeak and commercial Smalltalks.

I'm merely trying to determine what that difference is, and as a result am trying to think like one of the thousands of programmers who do NOT use Squeak or Smalltalk, and what would be useful to them.  I go around talking to myself like "I am an instance of a rectangle, I am defined by my two corners, I answer my area... etc. etc." when I try to understand how to use the mindboggling body of existing Smalltalk and how to bend it to meet my needs.  I do not know whether that kind of thinking is useful to a C programmer who is curious about Squeak, and if it is, I don't know how to help someone think that
way.  All I know is that it took me about 15 years, or half my programming career, and a lot less time to be comfortable with C and cousins.  In all fairness, I don't think I'll ever figure out C++, and I strongly believe that many programmers who did are probably faking it.

We have probably all had the learning experience of finding and fixing a bug such as the printOn: one you found.  I know it was a breakthrough when it happened to me (although I have forgotten the details - a prerogative of the aged).  Is there a way we can turn experiences like this into a way of teaching others?

I do print stuff, by the way.  Lots of it.  Read it, too.  Most of the good Smalltalk I've seen reads like a good book, better than some books written ABOUT Smalltalk.  I still would not recommend that to a complete neophyte as a way of encouraging him/her to join the fun.

Ed