diff --git a/GETTING_STARTED.md b/GETTING_STARTED.md
index 63d02ed..3d3cb7b 100644
--- a/GETTING_STARTED.md
+++ b/GETTING_STARTED.md
@@ -52,10 +52,10 @@ factory_girl supports several different build strategies: build, create, attribu
     # Returns a saved User instance
     user = FactoryGirl.create(:user)
 
-    # Returns a hash of attributes that can be used to build a User instance:
+    # Returns a hash of attributes that can be used to build a User instance
     attrs = FactoryGirl.attributes_for(:user)
 
-    # Returns an object with all defined attributes stubbed out:
+    # Returns an object with all defined attributes stubbed out
     stub = FactoryGirl.stub(:user)
 
 No matter which strategy is used, it's possible to override the defined attributes by passing a hash:
@@ -104,8 +104,7 @@ Attributes can be based on the values of other attributes using the proxy that i
 Associations
 ------------
 
-Associated instances can be generated by using the association method when
-defining a lazy attribute:
+It's possbile to set up associations within factories. If the factory name is the same as the association name, the factory name can be left out.
 
     factory :post do
       # ...
@@ -131,25 +130,23 @@ The behavior of the association method varies depending on the build strategy us
     post.new_record?       # => true
     post.author.new_record # => false
 
-If the factory name is the same as the association name, the factory name can
-be left out.
-
 Inheritance
 -----------
 
 You can easily create multiple factories for the same class without repeating common attributes by using inheritance:
 
     factory :post do
-      # the 'title' attribute is required for all posts
       title 'A title'
     end
 
     factory :approved_post, :parent => :post do
       approved true
-      # the 'approver' association is required for an approved post
-      association :approver, :factory => :user
     end
 
+    FactoryGirl.create(:approved_post).title     # => 'A title'
+
+As mentioned above, it's good practice to define a basic factory for each class with only the attributes required to create it. Then, create more-specific factories that inherit from this basic parent. Factory definitions are still code, so keep them DRY.
+
 Sequences
 ---------
 
@@ -223,7 +220,7 @@ Note that you'll have an instance of the user in the block.  This can be useful.
 You can also define multiple types of callbacks on the same factory:
 
     factory :user do
-      after_build  { |user| do_something_to(user) }
+      after_build  { |user| do_something_to(user)      }
       after_create { |user| do_something_else_to(user) }
     end
 
@@ -231,7 +228,7 @@ Factories can also define any number of the same kind of callback.  These callba
 
     factory :user do
       after_create { this_runs_first }
-      after_create { then_this }
+      after_create { then_this       }
     end
 
 Calling FactoryGirl.create will invoke both after_build and after_create callbacks.
@@ -264,7 +261,7 @@ Users' tastes for syntax vary dramatically, but most users are looking for a com
 
     User.blueprint do
       name  { 'Billy Bob' }
-      email { Sham.email }
+      email { Sham.email  }
     end
 
     User.make(:name => 'Johnny')