Maybe this will help someone struggling with this issue. Maybe it won't.

I've been an on-again, off-again Smalltalker for years. I've authored  
or co-authored several books on the subject. I've helped design and  
write two pretty substantial systems in Smalltalk. I'm not an  
engineer by training or discipline but I'm a programming language  
junkie with a pretty decent grasp of object-oriented concepts.

My early experiences with Smalltalk had two fearful faces to them.

One was the notion that I was not creating a simple program which, if  
it broke, didn't do any damage elsewhere in the universe. Rather, I  
was <insert appropriate scary overture music> *modifying THE image*.  
It was kind of like correcting God. I used to pause, my fingers  
poised over the keyboard, as I overrode some method or subclassed a  
builtin class and think, "I'm about to modify the known Smalltalk  
universe. If I screw this up...." And my fingers would fall back onto  
the desk. I'm not kidding about this. It sometimes took me a very  
long time to be willing to start coding even when I was sure what I  
was doing.

The other source of fear derived, for me, from the experience that  
said that it was hard to do basic, simple stuff in Smalltalk that  
would have been a cake-walk in Basic or Pascal, the other languages  
with which I was pretty familiar when I began my Smalltalk  
meanderings (which are far too random to qualify as a journey). Just  
an example. I remember one day thinking I'd write the Basic program  
that was sort of just after "Hello World". It printed out the numbers  
from 1 to 10 alongside their square and cube. Trivial, right? Five  
minutes after I opened and installed Basic, I had it working. Pascal  
took longer but that was because the install took longer and I had to  
learn about compilation. I could not get it to run in Smalltalk/V to  
save my gluteus maximus. I can't now remember all the gyrations I  
went through before I finally threw up my hands and asked for help.

But even after that, I remember a lot of times in which I'd spend  
hours poring over the source for various classes and methods that  
seemed like they might do what I wanted to do if only I could wrestle  
them to the ground, finally locate what I needed and then write two  
or three lines of code in a new method that just worked the first  
time exactly as I intended. But the code-shopping phase of  
programming always seemed like it took too long and I believed it  
took too long because I was incompetent somehow. Why? Because always  
before Smalltalk, productivity was measured in lines of code per hour  
or day. In Smalltalk, the real hard-core coders seemed to be the guys  
who wrote the *fewest* new lines of code per day because they figured  
out how to hook into what already worked.

I finally created this analogy. At least I think I created it. Maybe  
someone else had it before me but I didn't read it. Writing a program  
in every language except Smalltalk is like starting with a pile of  
building materials and building a house. There were some large- 
function building blocks and some very small ones, but you took them  
from a seemingly infinite pile of those pieces and you fabricated a  
house pretty much from scratch, following a blueprint whose level of  
detail and sophistication varied dramatically. Programming in  
Smalltalk is more like adding a new office or apartment to a  
skyscraper whose very building fabric has connectors for 90% of what  
you want to do and suitable building supplies to fill in the missing  
pieces. If I build a house, I don't have to worry too much about  
fitting in to some other scheme (other than rules and regulations,  
that is). But if I'm going to create a new office space atop a 3875- 
story skyscraper that already has a lot of stuff in place, I'd better  
be trying to fit organically into the existing scheme of things and  
create symbiotically.

Like all analogies, this one breaks at various points, but it does  
draw one to a single and helpful inevitable conclusion. If you want  
to master Smalltalk, spend your first days, weeks and/or months  
(YMMV) studying and understanding the key components of the class  
library. Then go design and write your new apartment of office. It  
will be much less painful, even though it will seem to take a lot  
longer at first.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
"Looking at technology from every angle"