Here’s another guideline that is very easy to forget, but very important. The general notion is that Smalltalk is very good at incrementally changing things, breakpointing, and checking values. Instead of wasting time thinking about what to do, or theorizing about what went wrong, just ask Smalltalk. Here are some examples:
To work out some new capability, inspect an object, browse the class if you need to, then send the object messages, building the code you need right in the Inspector workspace. Then copy the code to an appropriate method.
When working on a new feature, don’t implement all the necessary methods on all the objects you use. Instead, wait for the walkback for a method you haven’t defined. Then go to the browser, implement the method, and proceed from the walkback. (Kent calls this "just-in-time programming".) Smalltalk is keeping track of the order in which you need to do things.
When the system breaks, don’t theorize: put in a breakpoint and step through the code until you see what is wrong. You’ll find the answer much faster.
This next one is a little harder. Sometimes someone else will see this before you do.
Be sensitive to how things feel as you work. If you are slowing down, or something seems to be hard to do, or the methods are getting longer and uglier, Smalltalk is trying to tell you that you are doing the wrong thing. Remember the old joke about “Doctor, it hurts when I do this.” “Then don’t do that.”
Smalltalk is telling you to take a break. Get up and walk around. Go get some coffee, with someone else. Let them tell you what they’re doing. Take some kind of a mental break.
You know that thing where you’re trying to think of something and you can’t remember it, and as soon as you start doing something else, you remember? Let that happen. Smalltalk is telling you to take a break. Take a break
